Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.4; en-US; rv:1.9b5pre) Gecko/2008032504 Minefield/3.0b5pre ID:2008032504 I clicked on a link which opens a new tab in my current browser window. The loading takes a while so I hit Cmd+W to close this tab. But now Firefox hangs and I accidentally hit Cmd+W again. After some seconds both tabs were closed and following error appears multiple times within the Error Console: Error: this.mCurrentBrowser is null Source File: chrome://browser/content/tabbrowser.xml Line: 0 When I open the History menu from within the main menu it is empty. Even "Recently Closed Tabs" is deactivated and doesn't let me restore the additionally closed tab. Everytime I open the History menu following error appears: Error: aMenuPopup.getResultNode is not a function Source File: chrome://browser/content/browser.js Line: 6398 See the attachment how its look like.

When you restart Firefox afterwards all seems to be fine again. I will try find some clean and reproducible STR.

I got it again. It happens time by time when closing a tab. The correct menupopup node is used but there is no getResultNode function inside this object. I don't know if this can/will make firefox3 but I'll ask for to get attention. Do you need more information to this malfunction? I'm still not able to provide a clean STR.

This does not block the final release of Firefox 3.

Also seen in Bookmarks Menu. Its intermittent, but real.

(In reply to comment #4) > Also seen in Bookmarks Menu. Its intermittent, but real. Huh. Haven't seen this before! Thats really annoying. All my bookmarks under "Bookmarks Menu" are gone. Nothing is shown when opening the Bookmarks menu from within a browser window. If I focus the Error Console all of them are shown. That's very suspicious. The error message I mentioned in the former comments doesn't seem to be the cause because it appears each time for my current build (08040604) when opening the history menu. Raising severity to major to reflect missing ui components.

Ok, after a restart the Bookmarks Menu entries are shown again and the error doesn't come up. Sorry, but I still don't have STR.

The mac menu code assumes that wrapping the element (which is hidden, i.e. has no frame) for JS usage implicitly applies the binding. This used to work reliably for a while. Now, It seems that it occasionally doesn't work - and when it doesn't, even accessing the element directly from js context doesn't help (the menu doesn't work the next time you open it either).

What do you mean by "applies the binding"? On trunk, wrapping an element which is in a document will check whether there is a binding applied to it. If there is not, and the element doesn't have a frame, the binding is loaded and the implementation is installed. If it's safe to run script at this point, the constructor is run. Otherwise, an event is posted to run the constructor. Is the problem here that a constructor is not running synchronously when you wrap the node? Or that the binding implementation is not being installed?

The binding implementation is not being installed, as far as I can tell (we get element.foo() is not a method errors, etc).

That could happen if the node is being wrapped before your wrapping attempt and either the style rule attaching the binding does not apply to the node when it's wrapped or the node is removed from the document and reinserted after it has been wrapped. Are you in any of those cases here?

Not as far as I can tell, no. The menupopups are "static" node in browser.xul (the history and bookmarks menupoups), the nodes are applied from places.css to menupoup[type="places"]. There's are no clear steps to reproduce either :(

I can't think of obvious reasons for the binding to be applied in those cases, then... I assume this is a chrome binding (that is, not some 3rd-party theme that loads bindings from somewhere weird)?

Oh, and I assume we don't change the type of the menupopup dynamically?

Mano do you want to take this bug? i don't have a Mac to try debugging and feels like more related to toolkit than to places

(In reply to comment #13) > Oh, and I assume we don't change the type of the menupopup dynamically? > No, it's set once within browser.xul. (In reply to comment #14) > Mano do you want to take this bug? i don't have a Mac to try debugging and > feels like more related to toolkit than to places > No, I don't know Core:XBL.

unassigning from me, hope someone has better knowledge on this (And a way to debug)

Well, one way to do this is to put a dump() in the binding constructor and a printf in the code that tries to make sure the binding is attached, and see which are called and in what order.

I would also check whether certain extensions make this more likely to reproduce. Not to blame them, but just to allow others to reproduce reliably...

Bug 402798 can be a dupe of this, or connected, maybe it contains some useful addotional info.

The given STR in bug 402798 comment 11 makes this bug reproducible at any time. But only for the History menu and not the Bookmarks menu. I'm sure that I haven't customized my toolbar when I filed this bug. So there have to be some other STR with opening pop-up windows and opening/closing tabs. So bug 402798 could be a dupe or even this one.

I can't reproduce this bug but can reproduce bug 402798. When the bug occurs, no xbl seems to be attached to the menu, that is, DOM Inspector shows no binding for the menupopup. The Cocoa code caches a flag mXBLAttached which is set to true after WrapNative is called on a menupopup. This flag is never cleared at any point so WrapNative will only be called once per menupopup. Maybe the wrapper is going away for some reason?

I thought we prevented wrappers that have a binding attached from being gced...

I can reproduce bug 402798 simply by opening the customize dialog and then opening the bookmarks menu. Commenting out parts of wrapToolbarItems in customizeDialog.js seems to fix the bug. I wonder if this has something to do with the fact that the items on the palette have a place attribute to indicate whether they are on the palette or toolbar, and places code uses this same attribute for something else as well.

Toolbar customization would fit the "the node is removed from the document and reinserted after it has been wrapped" case from comment 10.

Added a workaround patch to bug 402798 which just doesn't remove the menubar on Mac. Does this patch fix this bug too?

Neil, can we land the other patch and resolve this bug? I actually don't see this anymore, but I suspect 402798 would be the root cause.

Scratch that, I can reproduce still. Just adding a separator to the nav toolbar on customize does it for me. Neil, please land that patch ASAP?

I can't reproduce any more on today's build with bug 402798 landed, going to call this FIXED by that.

I'll have a look at this the next weeks, if I'm able to verify the fix.

Bug 451915 - move Firefox/Places bugs to Firefox/Bookmarks and History. Remove all bugspam from this move by filtering for the string "places-to-b-and-h". In Thunderbird 3.0b, you do that as follows: Tools | Message Filters Make sure the correct account is selected. Click "New" Conditions: Body contains places-to-b-and-h Change the action to "Delete Message". Select "Manually Run" from the dropdown at the top. Click OK. Select the filter in the list, make sure "Inbox" is selected at the bottom, and click "Run Now". This should delete all the bugspam. You can then delete the filter. Gerv