Page MenuHomePhabricator

suboptimal placement of "More details" tipsy tooltip
Closed, ResolvedPublic

Description

The "More details on Wikimedia tooltip", which appears when hovering over the Commons icon in the bottom bar has suboptimal placement in both LTR and RTL languages.

In LTR languages its arrow is not exactly at the Commons icon itself. For an example see:
https://en.wikipedia.org/wiki/ASCII#mediaviewer/File:ASCII%20Code%20Chart-Quick%20ref%20card.jpg

In RTL languages it goes off screen to the left and causes a horizontal toolbar to appear. For an example see:
https://he.wikipedia.org/wiki/ASCII#mediaviewer/%D7%A7%D7%95%D7%91%D7%A5:ASCII%20full.svg

In both cases hover over the Commons icon. Notice that it's on the bottom left side in the RTL wiki.


Version: unspecified
Severity: normal

Details

Reference
bz64258

Event Timeline

bzimport raised the priority of this task from to Needs Triage.Nov 22 2014, 3:10 AM
bzimport added a project: MediaViewer.
bzimport set Reference to bz64258.
bzimport added a subscriber: Unknown Object (MLST).
Amire80 created this task.Apr 22 2014, 7:45 PM
Tgr added a comment.Apr 22 2014, 8:35 PM

This is a tipsy bug (two tipsy bugs, actually). Would be nice to fix upstream, but the lazy way is to just switch to ne/nw tip placement so the tip is positioned in the corner of the bubble.

We can't easily fix the fact that when pushed against the arrow of the screen, the arrow doesn't point to exactly what we want. The arrow position in this case is "south" which means exactly 50% of the width for the arrow position. Since the bubble is "blocked" by the edge of the screen and its width is maintained, the arrow can't point to the element we wanted, because of the tipsy-s CSS (as defined in jquery.tipsy.css). I don't think this issue can be fixed without writing a significant amount of code upstream to handle a special arrow positioning in those situations. At the moment only the bubble has conditional position logic, the arrow just follows the bubble based on its gravity. Tipsy just has no logic whatsoever to guarantee that the arrow always points to the right element.

As for the second part (going outside of the screen), I couldn't actually figure out what code in tipsy makes the magic happen in the LTR case. I'm guessing it has to do with the actual width measuring, but I can't be sure.

Given that switching the arrow placement fixed both issues effortlessly and that the alternative is adding a significant amount of code to the upstream, I'll got for that.

Change 130604 had a related patch set uploaded by Gilles:
Change the tipsy gravity for the strip buttons

https://gerrit.wikimedia.org/r/130604

Change 130604 merged by jenkins-bot:
Change the tipsy gravity for the stripe buttons

https://gerrit.wikimedia.org/r/130604

Gilles triaged this task as Unbreak Now! priority.Dec 4 2014, 10:11 AM
Gilles moved this task from Untriaged to Done on the Multimedia board.
Gilles lowered the priority of this task from Unbreak Now! to Needs Triage.Dec 4 2014, 11:23 AM
Restricted Application added a project: I18n. · View Herald TranscriptJun 2 2015, 2:20 PM