Last modified: 2012-05-09 01:30:10 UTC
Created attachment 7854 [details] 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.
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.
I can't replicate this. Could you please describe (or attach) the file you're trying to upload?
Created attachment 7858 [details] 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.
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.
*** Bug 26078 has been marked as a duplicate of this bug. ***
*** 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. :-/
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.
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 [details] Screenshot This bug is still happening on live Commons. See attached screenshot. I'm using Firefox 3.6.13 on Ubuntu 10.10.
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.
Added tag for release Elvis
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). * Uploading 3 JPG photos * Firefox 3.6.16 * Ubuntu 10.10 * Prototype http://commons.prototype.wikimedia.org/wiki/ as of r84733
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.
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.
(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 > 88. 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" ?
r70135
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 ***
