Prior to bug #383930, tooltips would cache the current target of the mouse event, and set that as the document's tooltipNode while launching the tooltip. However the new mechanism has the popup manager trying to read the target from the now stale event, and using the tooltip's binding parent instead. The tooltip's triggerNode is the same as document.popupNode of course. Example markup: <content> <xul:hbox tooltip="_child"> <xul:tooltip/> </xul:hbox> </content>
Background information: tabbrowser tab tooltips have stopped working in SeaMonkey. Firefox is not affected because its tabs are no longer anonymous.
Do you mean that the popup manager should be retrieving the event's originalTarget rather than the event's target?
Well the old behaviour was that the tooltip node was the current target relative to the element with the tooltip attribute. So assuming the original target and the tooltip node are in the same document, we could check the binding parent chain until we got to a node with the same binding parent.
Created attachment 466776 [details] [diff] [review] Untested fix
Comment on attachment 466776 [details] [diff] [review] Untested fix OK, I think I understand what this is doing now.
Comment on attachment 466776 [details] [diff] [review] Untested fix smaug, do you know a better way to do this (work out what the target would have been during the original event dispatch)?
So where is the "stale" event stored? If the event is stored somewhere and popup is triggered using it later, what prevents someone to re-dispatch it between the original dispatch and launching the popup?
After some thought, I think it would be better to just add a ShowTooltip method to the popup manager which takes a content node instead of an event, thus avoiding these issues.
Comment on attachment 466776 [details] [diff] [review] Untested fix I assume there is a new patch coming to remove the dependency of a dom event.
Created attachment 468078 [details] [diff] [review] Remove the event
Comment on attachment 468078 [details] [diff] [review] Remove the event Seeking approval to fix the regression from the blocking bug 383930.
Any progress on the approval for 2.0? It would be really nice to have tab tooltip preview back for SeaMonkey.
Hm, the patch doesn't build anymore due to the changes to FirePopupShowingEvent in bug 558072. Changing the call from FirePopupShowingEvent(aPopup, nsnull, popupFrame->PresContext(), popupFrame->PopupType(), PR_FALSE, PR_FALSE); to FirePopupShowingEvent(aPopup, PR_FALSE, PR_FALSE); seems to work, I do get the tooltip preview with the patch.
Comment on attachment 468078 [details] [diff] [review] Remove the event a=beltzner
Pushed changeset e6086627037c to mozilla-central.
Verified fixed with SeaMonkey 2.1b1pre, built from http://hg.mozilla.org/mozilla-central/rev/2754923dff6e
7 years ago