374288 - Menupopup menuitems incorrectly displaying parent toolbarbutton's tooltip

Status: VERIFIED FIXED

(Core :: XUL, defect)

Description

[Michael Kraft [:morac]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070315 Minefield/3.0a3pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070315 Minefield/3.0a3pre

When a toolbarbutton is displayed on the toolbar that has a "tooltiptext" attribute and also contains a menupopup child node with menuitems, the menuitems will incorrectly display the toolbarbutton's tooltiptext if the menu items do not have their own tooltip attribute.

Reproducible: Always

Steps to Reproduce:
1. Open the back or forward toolbar button's popup menu and hover over one of the entries in that menu.
2. Open the search toolbar button's popup menu and hover over the "Manage Search Engines..." entry.

Actual Results:  
1. Every entry in the back or forward popup menu displays the tooltip text "Go back one page" or "Go forward one page"
2. The Search button's tooltip text is displayed (eg: "Search using Google") all the way to the left of the browser.

Expected Results:  
1. The URL of the menu entry should display in the tooltip.
2. No tooltip should display.

This is also affecting extensions.  My extensions put toolbar buttons up and they have tooltip text set and all the menuitems in their associated popups display the button's tooltip text when they are hovered over.

Comment 1

[Michael Kraft [:morac]]

This only affects menus that pop up using a little arrow next to the button (ie: type "menu" and "menu-button").

Popup menus attached to type "button" work fine.

Comment 2

[Nickolay_Ponomarev]

This is a follow-up to bug 147670, since judging from bug 209314 comment 19 it worked this way ever since the fix for 147670.

Could not find any discussion on this, except for bug 147670 comment 42 through 49. Neil, did I miss anything or was it never addressed?

Comment 3

[Nickolay_Ponomarev]

Stupid bugzilla midairs.

Comment 4

[[e-mail]]

(In reply to comment #2)
>Neil, did I miss anything or was it never addressed?
No, it was never addressed. All I did was change the behaviour from an empty or random text to the inherited text that is correct for most of XUL.

Comment 6

[Michael Kraft [:morac]]

The problem as originally described appears to have been fixed in the 1.9 release code somehow.  I can't reproduce this problem with the "tooltiptext" attribute propagating down into the menus using Firefox 3.0.

I can however reproduce the problem if the "tooltip" attribute is used instead of the "tooltiptext" attribute, so I'm leaving this open.

Comment 7

[Nickolay_Ponomarev]

Attachment: testcase

Comment 8

[Michael Kraft [:morac]]

Attachment: same example as above, except using tooltiptext

Turns out I was wrong the problem does still affect tooltiptext.  So it affects both tooltiptext and tooltip.

Comment 9

[Neil Deakin]

Attachment: check for the target being in a menu/popup

Will try to get a test working but will likely mean waiting for a delay.

Comment 10

[[e-mail]]

Comment on attachment 374509 [details] [diff] [review]
check for the target being in a menu/popup

>+          (tag == nsGkAtoms::menupopup ||
>+           tag == nsGkAtoms::panel ||
>+           tag == nsGkAtoms::tooltip)) {
Are you sure we don't have any popups left?
(Is there no easier way to do this?)

Comment 11

[Neil Deakin]

(In reply to comment #10)

> Are you sure we don't have any popups left?

Don't think it matters here that much.

> (Is there no easier way to do this?)

Only if we get the frame or box object, but that's harder in itself.

Comment 12

[[e-mail]]

Comment on attachment 374509 [details] [diff] [review]
check for the target being in a menu/popup

>+           tag == nsGkAtoms::tooltip)) {
After all, we wouldn't want to create bogus tooltips for tooltips now, would we ;-)

Comment 13

[Neil Deakin]

Checked in, but still need to figure out a way to create a test

Comment 14

[Henrik Skupin [:whimboo][⌚️UTC+1]]

The changeset would be very helpful for verification. It would be nice when it can be posted too when resolving a bug. It will simplify our QA work. Thanks.

Verified fixed on trunk with builds on Windows and OS X: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090511 Minefield/3.6a1pre ID:20090511031307