Opened 14 years ago

Closed 8 years ago

#8267 closed defect (fixed)

Combined bug when the tooltip is placed overlapping the "around" node.

Reported by: Eugene Lazutkin Owned by: bill
Priority: low Milestone: 1.10
Component: Dijit Version: 1.2.3
Keywords: Cc:
Blocked By: Blocking:


After long debugging I was able to pinpoint the problem: if for some reason the tooltip node is placed overlapping the "around" node, it pops up under the mouse cursor. On FF onmouseleave is generated causing hide() to be called aborting show(). It looks like there is no tooltip on this node.

The call chain:

  • is ultimately called to show the tooltip.
  • It shows the tooltip, immediately sets its opacity to 0, and starts the fade in.
  • Showing the node causes it to pop up under the mouse cursor.
  • onmouseleave is generated.
  • dijit.Tooltip._onMouseLeave() is called.
  • dijit.Tooltip._onUnHover() is called.
  • dijit.Tooltip.close() is called.
  • dijit.hideTooltip() is called.
  • dijit._MasterTooltip.hide() is called.
  • We got the result! :-(
  • But!
  • onmouseenter is generated.
  • And the cycle repeats forever.

Obviously this happens only when the tooltip is placed unfortunately. One possible reason is the tooltip label is long, and it is measured incorrectly --- the actual tooltip is shown in two lines (automatic line wrap), and can be placed without overlap. I venture to suggest that dijit.placeOnScreenAroundElement() thinks that it is huge one-liner (it is) and tries to center it somehow causing the overlap.

Change History (15)

comment:1 Changed 14 years ago by Eugene Lazutkin

Personally I would be satisfied if one simple rule is implemented: if mouse over the "around" node or the tooltip node --- keep the tooltip open. So if the tooltip pops up under the mouse it still counts as valid hovering.

As to why it is placed like that --- it would be nice to fix, but not necessary for this ticket.

comment:2 Changed 14 years ago by Eugene Lazutkin

Experimented a little bit more. Some huge labels wrapped in 3 lines, placed a little bit off, but without overlapping. Some labels are just unlucky I guess. Probably they are on the verge of wrapping and the placement is spectacularly wrong.

Limiting width of dijitTooltipContainer helps in general, but this effect is not desirable: small width looks bad on big monitors, yet still can be too big for small monitors.

comment:3 Changed 13 years ago by bill

Hmm yeah, looking at dijit._place() (in place.js) it calls

var mb = dojo.marginBox(node);

on the (tooltip) node, but at that point it's probably at (0,0) so it expands to the full width of the viewport. The code just isn't setup for variable sized tooltips.

As you suggested I guess we could detect the mouse being over the around node or the tooltip node, although it doesn't solve the root issue. Also probably have to be careful that the onmouseleave event on the around node, which is immediately followed by the onmouseenter event on the tooltip, doesn't start the fadeout process.

Or we could start by limiting the width of all tooltips to viewport.w/2 -target.w, or something like that.

comment:4 Changed 13 years ago by bill

PS: do you have a test case that reproduces this? Or does it happen with the dijit/tests tests?

comment:5 Changed 13 years ago by bill

Milestone: tbd1.4
Owner: set to bill

comment:6 Changed 13 years ago by bill

Milestone: 1.41.5

comment:7 Changed 12 years ago by Adam Peller

Milestone: 1.51.6

comment:8 Changed 11 years ago by bill

Milestone: 1.61.7

comment:9 Changed 11 years ago by Adam Peller

moved to 1.7.1 for consideration. Please move to 1.8 as appropriate.

comment:10 Changed 11 years ago by Adam Peller


actually moving to 1.7.1

comment:11 Changed 11 years ago by bill

Milestone: 1.7.1future

comment:12 Changed 9 years ago by bill

Priority: highlow

comment:13 Changed 9 years ago by bill

Milestone: future2.0

See patch attached to #4284, which fixes this problem.

comment:14 Changed 9 years ago by bill

Milestone: 2.01.10

Might as well check this into SVN and then merge to github, so it's available for the 1.x and 2.x streams.

comment:15 Changed 8 years ago by Bill Keese <[email protected]…>

Resolution: fixed
Status: newclosed

In f36259200942691b1ff4a7542eedf3c52a4e588c/dijit:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 
Note: See TracTickets for help on using tickets.