Last modified: 2011-02-15 22:17:05 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 26414 - The revision tag pops up a window in the wrong direction in an RTL environment
The revision tag pops up a window in the wrong direction in an RTL environment
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
FlaggedRevs (Other open bugs)
unspecified
All All
: Normal major (vote)
: ---
Assigned To: Nobody - You can work on this!
http://he.wikisource.org/wiki/%D7%A2%...
:
Depends on:
Blocks: rtl
  Show dependency treegraph
 
Reported: 2010-12-24 14:11 UTC by Amir E. Aharoni
Modified: 2011-02-15 22:17 UTC (History)
5 users (show)

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


Attachments
a screenshot in which the runaway box is seen (24.09 KB, image/png)
2010-12-24 14:11 UTC, Amir E. Aharoni
Details

Description Amir E. Aharoni 2010-12-24 14:11:07 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.
Comment 1 Rob Lanphier 2010-12-24 19:25:59 UTC
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.
Comment 2 Derk-Jan Hartman 2011-01-05 22:04:21 UTC
@Rob, was this actually fixed in the code already or not ?
Comment 3 Aaron Schulz 2011-01-05 22:36:41 UTC
(In reply to comment #2)
> @Rob, was this actually fixed in the code already or not ?

It wasn't.
Comment 4 Amir E. Aharoni 2011-01-08 18:02:27 UTC
(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.
Comment 5 Aaron Schulz 2011-01-08 19:58:20 UTC
Fixed in r79872 (not live).
Comment 6 Rob Lanphier 2011-02-10 22:21:55 UTC
This should be deployed with 1.17.  See http://techblog.wikimedia.org/2011/02/1-17deployment-attempt2/
Comment 7 Amir E. Aharoni 2011-02-11 13:37:48 UTC
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.
Comment 8 Amir E. Aharoni 2011-02-11 16:41:34 UTC
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.
Comment 9 Aaron Schulz 2011-02-11 20:19:27 UTC
I thought 1.17 was rolled back?
Comment 10 Aaron Schulz 2011-02-11 20:21:43 UTC
(In reply to comment #9)
> I thought 1.17 was rolled back?

Must be in one of the first deploy groups.
Comment 11 Amir E. Aharoni 2011-02-11 21:39:52 UTC
(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.
Comment 12 Aaron Schulz 2011-02-12 18:11:15 UTC
I actually can't reproduce this now on my own wmf1.17 test wiki.
Comment 13 Aaron Schulz 2011-02-15 05:32:29 UTC
the ".rtl div.flaggedrevs_short_details" CSS is making it to bits somehow...
Comment 14 Aaron Schulz 2011-02-15 05:32:51 UTC
(In reply to comment #13)
> the ".rtl div.flaggedrevs_short_details" CSS is making it to bits somehow...

That should be "isn't".
Comment 15 Aaron Schulz 2011-02-15 05:35:45 UTC
Actually this file doesn't use bits, just http://he.wikisource.org/w/extensions/FlaggedRevs/client/flaggedrevs.css.
Comment 16 Roan Kattouw 2011-02-15 21:04:31 UTC
(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.
Comment 17 Aaron Schulz 2011-02-15 22:17:05 UTC
(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.

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


Navigation
Links