Last modified: 2012-09-03 14:35:18 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T41220, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 39220 - A bad filename should be changed silently instead of stopping the upload with "unknown-warning"
A bad filename should be changed silently instead of stopping the upload with...
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
UploadWizard (Other open bugs)
master
All All
: Unprioritized normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 39303
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-10 09:25 UTC by Raimond Spekking
Modified: 2012-09-03 14:35 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Raimond Spekking 2012-08-10 09:25:42 UTC
When the filename on the local computer has an invalid/bad character (like a leading space in my case) the UW stops the upload with a non helpful "unknown-warning".

The old upload form shows at least the better message 

'badfilename' => 'Filename has been changed to "$1".',

and I can retry with the changed filename.

I think the UW should change the filename silently and continue with the upload, maybe notifying the user in the last step about the changed filename.
Comment 1 Mark Holmquist 2012-08-16 16:31:48 UTC
Hi!

Recently, a patch to MediaWiki core [0] changed the behavior of API warnings. We now get those at the first step, even if we don't handle them necessarily.

Could you try to reproduce this bug, and let us know if it still occurs? If so, the solution would likely be very different from before this patch.

It looks like the deployment window might have been before you reported the bug, but I'm not sure. I just got the first report of it being fixed this morning, so I'm trying to confirm all of these bugs.

[0] https://gerrit.wikimedia.org/r/#/c/9261/

Thanks!
Comment 2 Raimond Spekking 2012-08-16 18:12:34 UTC
(In reply to comment #1)
> 
> Could you try to reproduce this bug, and let us know if it still occurs? If so,
> the solution would likely be very different from before this patch.
> 

I can reproduce this bug on commons.wikimedia.org, tested today. No change in behavior :-(
Comment 3 Tomasz W. Kozlowski 2012-08-18 15:10:07 UTC
I have also encountered this bug today, but with a message: "Error: http://bits.wikimedia.org/commons.wikimedia.org/load.php?debug=false&lang=en&modules=ext.uploadWizard&skin=vector&version=20120818T022835Z&* at line 42: InvalidCharacterError: String contains an invalid character."

I agree with Raymond here - the UploadWizard should automatically change the name of the file and continue with the upload instead of stopping it with such an error message.
Comment 4 Derk-Jan Hartman 2012-08-25 21:11:22 UTC
Still a problem. The issue here is upload titles.

mw.UploadWizardUpload.js should properly ignore the 'badfilename' warning
Test case. Create a file with in the filename the character '['

When using a destination name with this character, you have no errors and the character is automatically stripped from the title. However you get no feedback of this while you type, it happens automagically when you press 'next'
Comment 5 Derk-Jan Hartman 2012-08-28 06:05:19 UTC
https://gerrit.wikimedia.org/r/#/c/21698/
Comment 6 Mark Holmquist 2012-08-28 16:38:36 UTC
Merged, so we should have this fixed in master. If it's not fixed in master (and be sure that you're testing on master), reopen.
Comment 7 Derk-Jan Hartman 2012-08-29 21:28:39 UTC
This was reopened, without explanation.... Can someone tell me what the behavior is that they have verified is not working, so that it can be fixed ?
Comment 8 Derk-Jan Hartman 2012-09-03 14:35:18 UTC
closing again

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links