Last modified: 2014-09-24 01:08:24 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T37212, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 35212 - [jquery.tipsy] Feature to keep tip active when hovering to and over the tip itself
[jquery.tipsy] Feature to keep tip active when hovering to and over the tip i...
Status: PATCH_TO_REVIEW
Product: MediaWiki
Classification: Unclassified
JavaScript (Other open bugs)
1.19
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on: 35241
Blocks: tipsy
  Show dependency treegraph
 
Reported: 2012-03-13 23:16 UTC by kipod
Modified: 2014-09-24 01:08 UTC (History)
6 users (show)

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


Attachments
patch to teach tipsy a new value for the trigger parameter - "hovertip". (2.89 KB, patch)
2012-03-14 20:23 UTC, kipod
Details
discard the first patch - silly syntax error. (2.92 KB, patch)
2012-03-15 02:56 UTC, kipod
Details
third time's a charm: avoid annoying flicker when moving mouse from element to tooltip. (6.28 KB, patch)
2012-03-15 18:23 UTC, kipod
Details
instead of patch, cleaned up version of jquery.tipsy,js (8.91 KB, text/javascript)
2012-03-16 14:35 UTC, kipod
Details

Description kipod 2012-03-13 23:16:35 UTC
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.
Comment 1 kipod 2012-03-14 20:23:53 UTC
Created attachment 10237 [details]
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.
Comment 2 Antoine "hashar" Musso (WMF) 2012-03-14 20:25:37 UTC
please note that tipsy is no longer maintained by upstream. Will probably have to fork the project and take over its maintenance.
Comment 3 kipod 2012-03-14 20:30:00 UTC
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.
Comment 4 kipod 2012-03-15 02:56:14 UTC
Created attachment 10239 [details]
discard the first patch - silly syntax error.

ooops - whitespace damage + silly syntax errors.
Comment 5 Antoine "hashar" Musso (WMF) 2012-03-15 07:24:58 UTC
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
Comment 6 kipod 2012-03-15 18:23:25 UTC
Created attachment 10247 [details]
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.
Comment 7 kipod 2012-03-16 14:35:38 UTC
Created attachment 10248 [details]
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.
Comment 8 Sumana Harihareswara 2012-05-25 02:38:45 UTC
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
Comment 9 Chico Venancio 2012-06-03 13:26:26 UTC
I've gone ahead and submitted Kipods tipsy version after testing. https://gerrit.wikimedia.org/r/#/c/9962/
Comment 10 kipod 2012-06-11 16:53:55 UTC
(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.
Comment 11 Derk-Jan Hartman 2014-05-18 14:33:38 UTC
See also:
https://gerrit.wikimedia.org/r/#/c/133973/
https://gerrit.wikimedia.org/r/#/c/133975/

Where i resubmitted part of the upstream changes

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


Navigation
Links