Spun off from bug 112264. MailNews wants the column picker to have a tooltip.
Comment on attachment 115520 [details] [diff] [review] Proposed patch r=varga
Attachment #115520 - Flags: review?(varga) → review+
Comment on attachment 115520 [details] [diff] [review] Proposed patch sr=sspitzer thanks neil (and jan, for the review)
Attachment #115520 - Flags: superreview?(sspitzer) → superreview+
Fix checked in.
Really marking checked in... apologies...
Status: NEW → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → FIXED
Created attachment 116092 [details] Screenshot showing rogue tooltip There appears to be some brokeness with this. The tooltip appears in the correct place when hovering over the column picker *button*, but hovering over any menu item causes the same tooltip to appear, but in the wrong place. See attached screenshot. I initially thought that I'd broken this whilst fixing bug 173874 but backing out that patch (and the fix for bug 73970, which highlighted bug 173874) from my tree showed that I hadn't. What I did find was that in nsMenuPopupFrame::SyncViewWithFrame() parentPos is 0,0 for the column picker menu tooltips, which seems wrong.
That's nothing. Open the File toolbarbutton menu, then hover over something else with a tooltip, then hover over the menu, you get the same tooltip :-)
But at least it's in the correct place :-) In fact you don't even need to open the File tool bar button menu first; you can open it after hovering over something else, provided you open the menu before the File button tooltip appears. Seriously, this all seems rather pointless. Why do the menu items have tooltips at all, since they are the same as the button's tooltip? They appear to be just inheriting the tooltip from the parent. Can this behaviour be suppressed?
Component: XP Toolkit/Widgets: Trees → XUL
QA Contact: shrir → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.