Last modified: 2011-02-15 22:17:05 UTC
Created attachment 7927 [details] a screenshot in which the runaway box is seen Go to any page in the main namespace of the Hebrew Wikisource, for example the one in the URL field. In the upper left corner there will be an icon with an eye (id="mw-fr-revisiontag"). When the user runs the mouse over it, a pop-up box opens, listing the status of the revision. It will open in the wrong direction, becoming almost impossible to actually be read. I tested it on Windows XP, with Firefox 3.6, MSIE 8 and Chrome 10.0.614.
Hi Amir, thanks for the report. A workaround that I think will work is to put this in common.css for the site: #mw-fr-revisiondetails { left: -3px; right: auto; } ...and then reference this bug in the comments so that you all know to remove the workaround after the bug is fixed.
@Rob, was this actually fixed in the code already or not ?
(In reply to comment #2) > @Rob, was this actually fixed in the code already or not ? It wasn't.
(In reply to comment #1) > Hi Amir, thanks for the report. A workaround that I think will work is to put > this in common.css for the site: > > #mw-fr-revisiondetails { > left: -3px; > right: auto; > } > > ...and then reference this bug in the comments so that you all know to remove > the workaround after the bug is fixed. This workaround worked, thank you.
Fixed in r79872 (not live).
This should be deployed with 1.17. See http://techblog.wikimedia.org/2011/02/1-17deployment-attempt2/
It seems that it happens again in he.wikisource after the 1.17 upgrade. With the workaround in Comment 1 it worked well. After today's upgrade we deleted the workaround code from common.css and now the bug is back.
Some more details. I tried it in other browsers and the results are quite weird. If i open it in Chrome after cleaning cache and cookies, it appears correctly. If i log in to any account, the display becomes broken. If i log out, it stays broken. If i clean cache and cookies again, it becomes good. The above is correct only for Chrome. In Firefox it is always broken.
I thought 1.17 was rolled back?
(In reply to comment #9) > I thought 1.17 was rolled back? Must be in one of the first deploy groups.
(In reply to comment #10) > (In reply to comment #9) > > I thought 1.17 was rolled back? > > Must be in one of the first deploy groups. I specifically asked for it to be in the first wave of new deployment to test for possible RTL issues.
I actually can't reproduce this now on my own wmf1.17 test wiki.
the ".rtl div.flaggedrevs_short_details" CSS is making it to bits somehow...
(In reply to comment #13) > the ".rtl div.flaggedrevs_short_details" CSS is making it to bits somehow... That should be "isn't".
Actually this file doesn't use bits, just http://he.wikisource.org/w/extensions/FlaggedRevs/client/flaggedrevs.css.
(In reply to comment #15) > Actually this file doesn't use bits, just > http://he.wikisource.org/w/extensions/FlaggedRevs/client/flaggedrevs.css. Yeah, that'll do it. FlaggedRevs, like LiquidThreads, was assuming that $wgExtensionAssetsPath == "$wgScriptPath/extensions" , which breaks now that we have /extensions-1.17 for 1.17 wikis. I fixed that, and this bug is now fixed.
(In reply to comment #16) > (In reply to comment #15) > > Actually this file doesn't use bits, just > > http://he.wikisource.org/w/extensions/FlaggedRevs/client/flaggedrevs.css. > Yeah, that'll do it. FlaggedRevs, like LiquidThreads, was assuming that > $wgExtensionAssetsPath == "$wgScriptPath/extensions" , which breaks now that we > have /extensions-1.17 for 1.17 wikis. I fixed that, and this bug is now fixed. Did you live hack it? You can just set $wgFlaggedRevsStylePath instead.
