Last modified: 2013-04-22 16:14:27 UTC
Created attachment 11151 [details] Screenshot of bug There is an errant line break causing strange formatting after the last radio button in the option pictured in the attached screenshot. This occurs at least on both Chrome and Safari for Mac. Steps to reproduce: (1) Begin to upload more than one file in UploadWizard. (2) Select "Provide copyright information for each file individually on the next page." (3) On the "Describe" screen, select "This file is my own work." and then "Use a different license" Note, the same behavior does not occur when you get to the "Use a different license" from the "Release rights" screen when specifying licensing in a batch. On IRC, Brooke diagnosed the problem as follows: [7:50pm] <Brooke> I said it's probably white-space:nowrap;. [7:50pm] <Brooke> Based on the symptoms. [7:50pm] <Brooke> I imagine the HTML is constructed something like... [7:50pm] <Brooke> <label>reason <a>foo</a></label> [7:51pm] <Brooke> And the label has the white-space:nowrap;. [7:51pm] <Brooke> But the a tag doesn't inherit that property. [7:51pm] <Brooke> So the line breaks in the middle. [7:51pm] <Brooke> Where it says "legal code". [7:51pm] <Brooke> Because that's the first spot where it can break. [7:51pm] <Brooke> I imagine they're using white-space:nowrap; to keep the icons on the same line and shit.
Hmm, don't see no white-space css prop on the label. (Additionally this bug does not appear when testing on chrome for me - the label seems to wrap fine. Maybe this has been fixed in the mean time).
Following the steps listed above, I can confirm the error occurs on commons and test2. I used Firefox 18 and IE 9 on Vista
Thanks - removing "testme" keyword
i am getting this error on chrome ,firefox but couldnt find any whitespace:nowrap property anywhere, Can someone explain me why is this observed ?
Cannot reproduce with Firefox 17.0.1 on http://commons.wikimedia.org/wiki/Special:UploadWizard - in my case, either dialog is slightly wider, or fontsize is slightly smaller, but cannot reproduce by changing window size either.
I tried to reproduce be artificially making the containing div smaller by inserting css (since it has a fixed width). (For reference I was testing on commons, in language en and chrome on linux) It is possible (although would be surprising) that this could only show up in certain languages on certain wikis if someone manually changed one of the system messages to something which had code to prevent line wrapping.
-keyword easy. It's only easy if it was the white-space css property is to blame. Since said property is no where in sight and we don't know why this is happening, this may not be easy.
(In reply to comment #6) > I tried to reproduce be artificially making the containing div smaller by > inserting css (since it has a fixed width). (Specifically I messed around with the min-width prop on div#upload-wizard ) Tested on test2.wikipedia.org with firefox 16.0.1. Could not reproduce. Things seemed to wrap fine (I of course, once again was making the div artificially be smaller).
I also can confirm (again, using the steps in the description) that the error appears on FF 18 for Ubuntu and on Chrome 23, FF 17, and IE 9 on Windows 7. Like before, I tested on commons(http://commons.wikimedia.org/wiki/Special:UploadWizard) and test2(http://test2.wikipedia.org/wiki/Special:UploadWizard).
Cannot reproduce on http://test2.wikipedia.org/wiki/Special:UploadWizard using IE 8.0.6001.18702 on Windows XP Professional SP3 either. For me the 5 steps at the top are already too wide to make the license string not fit down there.
I don't know why it's reproducing inconsistently between users. If there is some other piece of information I can provide, besides "it happens for me," to help narrow this down, let me know.
found a fix https://gerrit.wikimedia.org/r/#/c/44660 , working fine in firefox ,chrome (ubuntu)
(In reply to comment #12) > found a fix https://gerrit.wikimedia.org/r/#/c/44660 , working fine in > firefox ,chrome (ubuntu) Superseded by <https://gerrit.wikimedia.org/r/44686>, apparently.
