Closed Bug 491552 Opened 15 years ago Closed 14 years ago

Firebug toolbarbuttons don't work

Categories

(Core :: XUL, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: johnjbarton, Unassigned)

References

Details

(Keywords: regression)

Attachments

(1 file)

699 bytes, application/vnd.mozilla.xul+xml
Details
1. Install Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090505 Minefield/3.6a1pre (nightly)
2. Add Firebug from http://getfirebug.com/releases/1.5X/
3. Open Firebug by clicking on its status bar icon
4. Select CSS panel
5. Click on "global.css" to try to get to another file.
 
Nothing happens.

On FF 3.6 Some buttons work, some do not. 
On FF 3.0 all buttons work.
Rob it would be great if you could verify this one.
Blocks: 491553
Is it possible to create a smaller testcase? e.g. a XUL window with toolbarbuttons but just alert()s?
The url you gave in the STR doesn't work however I can see the problem on 1.4 builds. It looks like the global.css toolbarbutton has nothing in its popupmenu. I can only presume that you have an event listener attached to it for the popupshowing event. Have you verified that the code attaching that is running and that the event is firing? This event seems to be working elsewhere in Firefox.
Summary: toolbarbuttons don't work → Firebug toolbarbuttons don't work
(In reply to comment #3)
> The url you gave in the STR doesn't work 

Sorry: http://getfirebug.com/releases/firebug/1.5X/

however I can see the problem on 1.4
> builds. It looks like the global.css toolbarbutton has nothing in its

Try the URL
http://www.mozilla.org/projects/firefox/3.6a1pre/whatsnew/
open firebug, reload.
The CSS panel should have 5 entries, they dont' popup.
The Script panel should have 2 entires, they don't popup.

> popupmenu. I can only presume that you have an event listener attached to it
> for the popupshowing event. Have you verified that the code attaching that is
> running and that the event is firing? 

Firebug works on FF 3.0. So if there is a problem in Firebug, it's caused by changes in FF3.6 that I don't know about. Or its caused by FF 3.6. Either way I need help.

> This event seems to be working elsewhere
> in Firefox.

Yes, and many buttons in Firebug work on FF 3.6 was well. But some do not.

The file lists I mention above are implemented with 'binding' id panelFileList:

http://code.google.com/p/fbug/source/browse/branches/firebug1.5/content/firebug/bindings.xml#499

Since both file lists fail and that is the only button that I know which fails, the problem must be related to that binding. Any thoughts on how to sort this out?
(In reply to comment #4)
> > however I can see the problem on 1.4
> > builds. It looks like the global.css toolbarbutton has nothing in its
> 
> Try the URL
> http://www.mozilla.org/projects/firefox/3.6a1pre/whatsnew/
> open firebug, reload.
> The CSS panel should have 5 entries, they dont' popup.
> The Script panel should have 2 entires, they don't popup.

How are you verifying that the menupopup contains those entries, with the DOM inspector? That is what I used and they weren't there. The binding you reference doesn't include any items in the menupopup so they are generated, where are they generated and is that code executing?
The entries are generated dynamically:

   <handler event="popupshowing"><![CDATA[
            if (this.popup.firstChild)
                return false;
            var locator = this.getLocator();
            var objects = locator.getLocationList();
(http://code.google.com/p/fbug/source/browse/branches/firebug1.5/content/firebug/bindings.xml#673)

Since we don't see the popup, I assume this code is never called. I can verify this tomorrow.

Looks like the only other place this construct is used is the option menu on each panel tab. I don't specifically remember if they work or not.
I tested the other place we use 'popupshowing', and the button works.  So unfortunately it means the problem is more specific to something in the fileLlist widget.

I added a tracing call:
        <handler event="popupshowing"><![CDATA[
        FBTrace.sysout("bindings.xml popupshowing");
            if (this.popup.firstChild)
                return false;
            var locator = this.getLocator();
            var objects = locator.getLocationList();

The message is printed on FF 3.0 when the button is pressed, but not on FF 3.6. This confirms that the popupshowing is not called when it should be.
Attached file testcase
The bug here is to do with locating the element to pop up. We have the following bound to a hbox:

<content popup="_child">
  <xul:button type="menu">
    <xul:menupopup/>
  </xul:button>
</content>

The popup attribute is causing the problem. When entering nsXULPopupListener::LaunchPopup, it finds the popup="_child" and attempts to look for a real menupopup element inside the hbox, or an anonymous menupopup element as a direct child in the binding. Neither exist so nothing pops up. The same happens when moving popup="_child" onto the xul:button element.

It's a pretty easy fix on firebug's side, just remove the unnecessary popup attribute. Not sure what has changed to cause this though.
For what it's worth, you should probably add regressionwindow-wanted in cases like this.

This regressed between the 2009-02-27-02 nightly build (rev cc8d4e656113) and the 2009-02-28-02 (rev f3d5f4a980a0).  Pushlog range:  http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=cc8d4e656113&tochange=f3d5f4a980a0
Keywords: regression
Looks like a regression from bug 311053 (tested via local backout).  Not sure why that checkin matters here, but I bet enn and Neil will know!
Blocks: 311053
I suppose the event should not be cancelled if the popup isn't found. Bug 311053 causes menus to not open if the mouse event is cancelled.

Firebug should still remove the unneeded popup attribute of course.
I removed the popup="_child" attribute and the button works. Does anyone have
an idea why the attribute was used?  As in, now that is removed should I expect
any bad things to result?

Thanks for the help!  As long as the attribute is not needed, I'm find if this
is closed with any resolution you choose.
(In reply to comment #12)
> Does anyone have an idea why the attribute was used?
Perhaps an earlier version used
<content popup="_child">
  <xul:button/>
  <xul:popup/>
</content>
and maybe the _child was overlooked when it was improved to use type="menu".
No longer blocks: 491553
No longer blocks: 491553
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: