tooltiptext="" should use an anonymous tooltip, so that the tooltip itself needn't be specified.

I assume that this would take some sort of default tooltip look, like a yellow background with black text?

... and multiline tooltips! See: http://bugzilla.mozilla.org/show_bug.cgi?id=57599

Wouldn't you be able to do multiline tooltips with <description>?

Yes, when I'm done, all tooltips will be multi-line by default.

removing dependency done in error

*** Bug 80208 has been marked as a duplicate of this bug. ***

--> hewitt

Ok, so here's what I have done here. I am moving all of the tooltip listening stuff out of nsXULPopupListener and into layout. nsXULPopupListener will now only worry about popup and context popup types. I'm creating an anonymous tooltip element in nsDocElementBoxFrame, and storing a reference to it in nsRootBoxFrame. Whenever a xul frame is created for an element that wants a tooltip, nsRootBoxFrame will create a tooltip listener for it and send it on its merry way. This anonymous tooltip will be used for all elements that only have tooltiptext specified on them. tooltip="..." is still supported, of course. The default tooltip can be overriden by the user by placing a <tooltip default="true"/> in their document. There is also some special handling to support tooltips in outliners. As you hover over each cell in the outlinerbody the tooltip will change. You can determine which cell the mouse is over using the mouse coordinates from onpopupshow* events and outlinerBoxObject.getCellAt (see bug 112286).

sr=hyatt + if (aModType == 3) // removal + rootBox->RemoveTooltipSupport(aContent); + if (aModType == 2) // addition + rootBox->AddTooltipSupport(aContent); Ick. Use the real constants here, not hardcoded numbers. Also, my sr is conditional on you running the leak tests to make sure this doesn't leak.

I ran the leak log and there were no extra leaks with this patch turned on. I tested created and destroying a bunch of xul documents and showing a variety of tooltips.

a few things: 1) could you step through in the debugger to make sure that the dtor for nsXULTooltipListener is actually getting called? Just being paranoid. 2) I'm not familiar with nsDocElementBoxFrame. We're creating tooltip node for every one of these, regardless? Doesn't that sound a bit wasteful? How many of these are there in, say, the navigator window? 3) Check that the TITLE attribute still works (just a reminder, i'm sure it does).

1). Yes, the destructor is called when the tooltip source content goes away. 2). There is only one nsDocElementBoxFrame per XUL window, so, there will only be one tooltip content instance created for the navigator window, or 2 if you have the sidebar open with a xul page visible. 3). Yes, the title attribute still works in html pages.

This hasn't been checked in yet has it?

I had implemented titletips in xbl/js a long time ago, but never really liked doing it that way. This new version of the patch rolls titletip support into the C++ tooltip listener, which is a much cleaner way to do it. Also, I moved that 21px top offset we had hard-coded in C++ and moved it into CSS as a margin.

Comment on attachment 60146 [details] [diff] [review] new patch with titletip support r=pink, looking good

fixed