Page MenuHomePhabricator

Upload wizard doesn't complete upload and gives 'permissiondenied' error in several browsers
Closed, ResolvedPublic

Description

Upload Wizard not working on Firefox, Ubuntu

See attachment. Currently I'm using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.12) Gecko/20101027 Ubuntu/9.10 (karmic) Firefox/3.6.12.
It was the same in Firefox 3.5, as reported in bug 24709 comment 1.


Version: unspecified
Severity: critical
URL: http://commons.prototype.wikimedia.org/uwd/Special:UploadWizard

Attached:

Upload_Wizard_not_working_on_Firefox,_Ubuntu.png (768×1 px, 76 KB)

Details

Reference
bz26076

Related Objects

StatusSubtypeAssignedTask
DeclinedNone
ResolvedNone
ResolvedNone
ResolvedNone
Resolvedkaldari
Resolvedkaldari
Resolvedkaldari
InvalidNone
ResolvedNone
ResolvedNone
ResolvedNone
Resolvedkaldari
ResolvedNone
ResolvedNone
Resolvedkaldari
ResolvedNone
DeclinedNone
Resolvedkaldari
ResolvedNone
DeclinedNone
Resolvedkaldari
Resolvedkaldari
ResolvedNone
Resolvedkaldari
DeclinedNone
ResolvedNone
ResolvedNone
ResolvedNone
InvalidNone
Resolvedkaldari
Resolvedkaldari
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
Resolvedkaldari
Declinedkaldari
Resolvedkaldari
Resolvedkaldari
Resolvedkaldari
ResolvedNone
ResolvedNone
ResolvedNone
Resolvedkaldari
Resolvedkaldari
Resolvedkaldari
ResolvedNone
Resolvedkaldari
Resolvedkaldari
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
ResolvedNone
Resolvedkaldari
ResolvedNone
ResolvedNone
ResolvedNone

Event Timeline

bzimport raised the priority of this task from to High.Nov 21 2014, 11:17 PM
bzimport added a project: UploadWizard.
bzimport set Reference to bz26076.

neilk wrote:

Works for me on Firefox 3.6.10 on Ubuntu 10.04.

This problem was occurring for a short while on /uwd/ but I've fixed it. Try emptying cache and reloading, or just shift-reload?

Ok, I've tried again. No need to empty the cache, it loaded and now it's exactly like bug 26077 and bug 26078. Reopening with different summary.
Does the upload wizard depend on Flash? I may have some problems with it.

(In reply to comment #2)

Ok, I've tried again. No need to empty the cache, it loaded and now it's
exactly like bug 26077 and bug 26078.

Just tried with another machine, Firefox 3.6.12, Ubuntu 10.10 (and no problems with Flash). Same problem.

Oh, and if I click "remove" the neverending upload then the "Click here to upload a file" button doesn't work.

neilk wrote:

I can't replicate this.

Could you please describe (or attach) the file you're trying to upload?

Created attachment 7858
One of the test images

It's just a random photo; I'm attaching one, but it's the same for every image I've tried.

Attached:

DSCN2665.JPG (1×2 px, 990 KB)

neilk wrote:

Nemo_bis: I uploaded that with no problem.

I suspect there is a network or system issue on your end since you see the exact same problem with every browser.

UploadWizard does not use Flash, so that's not it.

Marking your other issues as dupes of this one. I'm not saying it's NOT a bug with us, it's just that until further notice I think it may be a systems thing, not a browser thing.

neilk wrote:

*** Bug 26078 has been marked as a duplicate of this bug. ***

neilk wrote:

*** Bug 26077 has been marked as a duplicate of this bug. ***

I've read about a similar error here: http://commons.wikimedia.org/w/index.php?title=Commons:Usability_issues_and_ideas&oldid=46356413#uploading_a_duplicate
The previous file shouldn't be a duplicate because I've never uploaded it anywhere, but I've tried with another photo which I can't upload here and I definitely can't have uploaded anywhere because I don't own the rights on it, and it says "Getting file information and previews" forever; I've tried with a smaller png and I managed to upload it, the same with a couple of wallpapers, 1024×768px, 400 and 1000 KiB (61_1024.JPG and Imga023_1024.JPG), then I've tried with another photo like the first one (different filename, more complex) and it's the same, "Getting file information and previews" forever. Perhaps a problem with resolution? I really don't understand. :-/

neilk wrote:

I tried uploading the file you attached, and it worked for me. But that's probably why it's failing for you now.

I just have to make that duplicate error thing work. Right now it's like two dangly wires that I need to connect together, shouldn't be too hard.

(In reply to comment #10)

The previous file shouldn't be a duplicate because I've never uploaded it
anywhere, but I've tried with another photo which I can't upload here and I
definitely can't have uploaded anywhere because I don't own the rights on it,
and it says "Getting file information and previews" forever

I can reproduce this error every time.

I tried twice with a brand new file (new image, new filename) after shift-refreshing, but it still doesn't work. The wizard stays stuck at "Getting file information and previews..."

I'm using Firefox 3.6.12 on Ubuntu 10.10 as well.

Is this a dupe of new bug 26108 ?

As requested, I checked the error was still happening, and it is (the prototype is currently running r77221 )

This is working fine for Neil and myself on Commons (the real one, not the prototype). Can you reproduce this there?

(In reply to comment #15)

This is working fine for Neil and myself on Commons (the real one, not the
prototype). Can you reproduce this there?

Now I get this error: «The server returned an error we did not understand: "permissiondenied"». With the same files, and even one which worked on the prototype.

martins wrote:

I'm receiving the same error, using Google Chrome beta 9.0.597, at http://commons.wikimedia.org/wiki/Special:UploadWizard, logged in as Smith609, on six files that I'm trying to upload.

Error text: The server returned an error we did not understand: "permissiondenied"

Also got the same error:

  • The server returned an error we did not understand: "permissiondenied"

When trying to upload one img or even 2-3.

Firefox 3.6.13, windows 7

I just ran into this bug on Commons (with Firefox 3.6.13, on Ubuntu 10.10) while trying to upload two PDFs. The files upload just fine in the old uploader:
http://commons.wikimedia.org/wiki/File:Classroom_handout_-_moving_out_of_your_sandbox.pdf
http://commons.wikimedia.org/wiki/File:Classroom_handout_-_Submitting_an_article_to_the_Did_You_Know_process.pdf

The behaviour was the same as Guillaume describes in comment #12: it hangs indefinitely on "Getting file information and previews" for the first file, with the progress bar counting up rather than down. There are now 16 minutes remaining for my upload.

Created attachment 7983
Screenshot

This bug is still happening on live Commons. See attached screenshot. I'm using Firefox 3.6.13 on Ubuntu 10.10.

Attached:

uploadwizardbug.png (538×913 px, 40 KB)

I can reproduce the "The server returned an error we did not understand: "permissiondenied" error too on Firefox 3.6.13 / Mac, Chrome 8.0.552.231 / Mac and Safari 5.0.3 / Mac.

neilk wrote:

Added tag for release Elvis

neilk wrote:

Since many users seem to be seeing this but staffers don't this might be related to nonstaff or nonadmin accounts. Recheck what's going on.

FYI the behavior described in comment 12 and comment 19 still happens for me. The first file has been "uploading" for 15 minutes, the spinner keeps spinning, and I have "24 minutes left" (and increasing).

neilk wrote:

Ok, for the first time I am able to reproduce this.

The error seems to be something server side with particular filenames or files. I am able to get this traceback:

#0 \/srv\/org\/wikimedia\/prototype\/wikis\/commons\/includes\/api\/ApiBase.php(1107): ApiBase->dieUsage('Permission deni...', 'permissiondenie...')
#1 \/srv\/org\/wikimedia\/prototype\/wikis\/commons\/includes\/api\/ApiUpload.php(89): ApiBase->dieUsageMsg(Array)
#2 \/srv\/org\/wikimedia\/prototype\/wikis\/commons\/includes\/api\/ApiMain.php(668): ApiUpload->execute()
#3 \/srv\/org\/wikimedia\/prototype\/wikis\/commons\/includes\/api\/ApiMain.php(350): ApiMain->executeAction()
#4 \/srv\/org\/wikimedia\/prototype\/wikis\/commons\/includes\/api\/ApiMain.php(334): ApiMain->executeActionWithErrorHandling()
#5 \/srv\/org\/wikimedia\/prototype\/wikis\/commons\/api.php(116): ApiMain->execute()
#6 {main}

Which means it's dying here, in ApiUpload.php line 89:

85 Check permission to upload this file
86 $permErrors = $this->mUpload->verifyPermissions( $wgUser );
87 if ( $permErrors !== true ) {
88
TODO: stash the upload and allow choosing a new name
89 $this->dieUsageMsg( array( 'badaccess-groups' ) );
90 }

For whatever reason the server doesn't think we need to or ought to know why this was a bad upload, though. Will investigate further.

Bryan.TongMinh wrote:

What it means is that the target filename is in someway protected or otherwise forbidden for creation. The proper solution would be to fix the TODO on line 88. I implemented this in the UI some time ago, but haven't done this in API yet.

neilk wrote:

(In reply to comment #26)

What it means is that the target filename is in someway protected or otherwise
forbidden for creation. The proper solution would be to fix the TODO on line

  1. I implemented this in the UI some time ago, but haven't done this in API

yet.

Yes, the specific problem here (in I think the majority of cases) is that

  • commons.prototype is an InstantCommons site.
  • some filenames are in use over on Commons, hence they are reserved on commons.prototype too.
  • but, we couldn't replace those files here even if we wanted to
  • so we get the perplexing "permissiondenied" error (why it isn't more informative is beyond me)

Working on a fix now.

What do you mean that you "implemented this in the UI" ?

neilk wrote:

r84762, r84768 fixes this partially -- at least you can get past the first upload page.

However, it kicks the problem down to page 3, and now we *really* need to check for all possible title errors before submitting and recover from errors that may occur (Bryan Tong Minh just added more descriptive errors in r84768).

So, closing this bug and going to work on 24758.

*** This bug has been marked as a duplicate of bug 24758 ***

Gilles raised the priority of this task from High to Unbreak Now!.Dec 4 2014, 10:21 AM
Gilles moved this task from Untriaged to Done on the Multimedia board.
Gilles lowered the priority of this task from Unbreak Now! to High.Dec 4 2014, 11:20 AM