Opened 9 years ago

Closed 9 years ago

Last modified 9 years ago

#10570 closed defect (wontfix)

Tooltip: element cursor changes to pointer when tooltip appears (FF/mac)

Reported by: JP Owned by:
Priority: high Milestone: tbd
Component: Dijit Version: 1.4.0
Keywords: dijit.Tooltip, cursor, style, pointer Cc:
Blocked By: Blocking:

Description (last modified by bill)

In Firefox, when you hover over an element with a dijit.Tooltip, the cursor automatically changes to the standard arrow, regardless of the cursor that has been defined in the style attribute for the body or element (i.e <body style="cursor:pointer">,<div style="cursor:pointer">).

See attached tooltip.html to reproduce the issue. If you hover over the element w/the tooltip in Firefox, you will notice that the cursor becomes the standard arrow and the pointer is not maintained.

Tried connecting to the open() method of tooltip, and then use setTimeout() to change the cursor style after the tooltip has been displayed, but no luck.

This issue does not happen in IE or Safari, but is a high priority issue because if you attach a dijit.Tooltip to a link, then when the user hovers over it, instead of a pointer (ie, hand icon), you get the arrow which is very confusing since the mouse is on a link.

Attachments (1)

tooltip.html (1.7 KB) - added by JP 9 years ago.

Download all attachments as: .zip

Change History (8)

Changed 9 years ago by JP

Attachment: tooltip.html added

comment:1 Changed 9 years ago by bill

I don't understand, it's impossible to hover over a tooltip because it will disappear as soon as the user moves the mouse off of the anchor node.

comment:2 Changed 9 years ago by JP

You do not have to hover over the tooltip. I may have been a little unclear.

Lets say you have an image that is a link .. i.e.

<a href=""><img id="thisImage" src=""/></a>

If you connect a dijit.Tooltip to thisImage, you will notice that in Firefox, when you hover over the image (that is a link), you see the Hand cursor (pointer) for a split second, and then when the tooltip appears, the pointer turns into a standard arrow. Meaning the pointer is not maintained since it is a link and should have the pointer cursor. You will see in Safari and IE that the pointer is maintained.

Does that make sense? Thanks much for the quick response.

comment:3 Changed 9 years ago by bill

Description: modified (diff)
Priority: highnormal
Summary: Cursor support needed for dijit.Tooltips in Mozilla FirefoxTooltip: element cursor changes to pointer when tooltip appears (FF)

Ah.... OK that makes sense, not sure why it's happening.

Firebug reports that the cursor is still "help". (I modified your test case to just do the simple thing you described.)

No idea how to fix this as it seems like a firefox bug.

comment:4 Changed 9 years ago by bill

Resolution: wontfix
Status: newclosed
Summary: Tooltip: element cursor changes to pointer when tooltip appears (FF)Tooltip: element cursor changes to pointer when tooltip appears (FF/mac)

Actually this is only a FF/mac problem, and it's fixed in FF3.6 alpha, so I'm not going to workaround it in the dijit code. Nonetheless I traced through it.

The first issue is that the first time a page displays a tooltip, Tooltip.js creates the singleton MasterTooltip widget (creating it's DOMNode and attaching it to <body>). That messes up the cursor on FF (due to a FF bug). That can be worked around by adding:

	dijit._masterTT = new dijit._MasterTooltip();

to either Tooltip.js or to your HTML page.

However, the second issue is that displaying that MasterTooltip also messes up the cursor, and that happens every time you hover an element w/a Tooltip, not just the first time.

This is triggered by this code in

// Firefox bug. when innerHTML changes to be shorter than previous
// one, the node size will not be updated until it moves. = (this.domNode.offsetTop + 1) + "px";

That code is from [9833], claiming to fix some BIDI issue. But testing FF3.5 on both mac and windows I don't see that problem anymore (using test_Tooltip.html), so I'll remove that code.

However, it's also triggered by the code in place.js: = best.x + "px"; = best.y + "px";

(where "node" is the tooltip). Obviously that code can't be removed because it positions the tooltip.

comment:5 Changed 9 years ago by bill

(In [21091]) Remove some FF workaround code that's no longer needed (probably it was for FF2 but there's no documentation about it), refs #3049 ([9833]), #10570 !strict.

comment:6 Changed 9 years ago by JP

You guys are awesome! Thanks for the quick turnaround.

So it seems like there are a few issues with the workaround. I confirmed that this only happens on Mac also.

For the workaround, I added dijit._masterTT = new dijit._MasterTooltip(); in my onLoad(), but it seems like there is more that is needed (since this alone does not fix the issue).

Is it better to wait until Firefox 3.6, or is there a viable workaround for Firefox 3.5 that doesnt break anything else (As you suggested about some code above.

comment:7 Changed 9 years ago by bill

I have no workaround, I'm just saying to wait until the next FF release.

Note: See TracTickets for help on using tickets.