Page MenuHomePhabricator

[jquery.tipsy] Feature to keep tip active when hovering to and over the tip itself
Closed, DeclinedPublicFeature

Description

nominally this is an enhancement request, but in reality it's a bug.
here goes: tipsy (the jquery plugin that allows for better tooltips) has a "html" attribute, which allows displaying html (including links) in the tooltip.

what's missing is the ability to tell the tooltip to stay up if the mouse hovers over the tooltip itself (in addition to when the mouse hovers above the control that "owns" this tooltip). this is needed if one wants to use html tooltips with clickable picese - it's very frustrating to the users to move the mouse from the control to the clickable item just to have the tooltip disappear. using long "delayOut" is very unsatisfying compromise - it forces a choice between short delay (some users are not quick enough to click in time) and long delay (annoying tooltips that do not go away when you don't want them any more).

this hampers the usefulness of tipsy greatly, and in some cases forces developers to handle the "show" and "hide" of the tooltip themselves, resorting to disgusting mechanisms such as setTimeout().

just one example:
enwiki has a very useful gadget named "popup".

http://en.wikipedia.org/w/index.php?title=MediaWiki:Gadget-popups.js

this gadget's code is sheer monstrosity - it weighs more than 1/4 ton(!) and 7600 lines(!!).

using jquery and tipsy, one can easily implement this functionality with nice and tight code using way less than 1000 lines weighing less than 50K, but one thing that's required is a way to tell tipsy to stay up when the mouse hovers over the tooltip.

(not really the reason for this bug, just an example of useful tool where the tooltip contains clickable items, and staying up on hover is absolutely required)

tipsy has a "trigger" option that accepts "manual" or "hover" values. please add "hover_tooltip" or somesuch that will behave like "hover" does, but will keep the tooltip open when moving the mouse from the control to the tooltip itself.

if this is to be done it probably should be done in mediawiki - the tipsy development seems to be dead for several years now.


Version: 1.19
Severity: enhancement

Details

Reference
bz35212

Event Timeline

bzimport raised the priority of this task from to Low.Nov 22 2014, 12:18 AM
bzimport set Reference to bz35212.
bzimport added a subscriber: Unknown Object (MLST).

Created attachment 10237
patch to teach tipsy a new value for the trigger parameter - "hovertip".

this patch teaches tipsy one more possible value for the "trigger" parameter.
currently if "trigger" is undefined tipsy will trigger on "focus".
otherwise it can be "hover" or manual".
the new value is "hovertip". it behaves like "hover", except it will keep the tooltip open when hovering above the tooltip itself *OR* the element.

attachment tipsy.patch ignored as obsolete

please note that tipsy is no longer maintained by upstream. Will probably have to fork the project and take over its maintenance.

see the last two lines of the "description" (first message).

i sent the patch to the tipsy developer, so maybe he/she will get an appetite to add this functionality. this is the most often requested/asked about enhancement to tipsy one finds on stackoverflow and similar boards.

peace.

Created attachment 10239
discard the first patch - silly syntax error.

ooops - whitespace damage + silly syntax errors.

attachment tipsy.patch ignored as obsolete

This patch should be applied directly to upstream. Since it is abandoned, we need take over the project.

See Bug 35241 - take over jquery.tipsy plugin

Created attachment 10247
third time's a charm: avoid annoying flicker when moving mouse from element to tooltip.

better (and more polite) behavior gets rid of flicker when moving from element hover to tooltip hover, + minor cleanup of existing code.

attachment tipsy.patch ignored as obsolete

Created attachment 10248
instead of patch, cleaned up version of jquery.tipsy,js

so i did some more tests.

current tipsy code (both mediawiki version and upstream head version) has several bugs:

  • setting "title" to a string does not work (bug in getTitle() function)
  • "fallback" does not work as advertised (works only if "title" is set to a function that returns empty string)
  • some non-fatal lint issues, such as semicolons after function definition, redeclaration of vars in functions.

also, the github head version (still with all those bugs) supports one more built-in auto function that's not in mediawiki version.

so instead of creatin yet-one-more-patch, here is the cleaned up jquery.tipsy.js with those issues cleaned, "hovertip" support, and the "autoBounds()" function from github head version.

(if we take it, we need to update the doc also to describe both "hovertip" option and use of "autoBounds()" function)

peace.

attachment jquery.tipsy.js ignored as obsolete

sumanah wrote:

kipod, thank you for your patch. Are you interested in using developer access to directly suggest it into our Git source control system?

https://www.mediawiki.org/wiki/Developer_access

https://www.mediawiki.org/wiki/Git/Workflow#How_to_submit_a_patch

chicovenancio.justforbugzilla wrote:

I've gone ahead and submitted Kipods tipsy version after testing. https://gerrit.wikimedia.org/r/#/c/9962/

(In reply to comment #9)

I've gone ahead and submitted Kipods tipsy version after testing.
https://gerrit.wikimedia.org/r/#/c/9962/

as this patch does not meet the expected gerrit standards, it was rejected.
at the very least, it should be broken into 3 seperate pieces:

  1. merge upstram changes
  2. fix the upstream bugs
  3. add new functionality (i.e., support "hovertip" for trigger parameter).

ideally, before or after #2 there should be some more changes:

2.5) reformat code to adhere with mediawiki coding standrard (yuck - spaces after "(" and before ")" ? disgusting), and add some comments to better document the code.

as indicated, this depends on bug #35241 (taking over tipsy maintenance), which is still up in the air.

peace.

I can't find a patch to review. Did this get fixed?

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:14 AM