682531 - Bookmarks Toolbar endless recursion

Status: RESOLVED FIXED

(SeaMonkey :: Bookmarks & History, defect)

Description

[H. Hofer]

Attachment: SeaMonkeyBookmarks.jpg

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0a1) Gecko/20110826 Firefox/9.0a1 SeaMonkey/2.6a1
Build ID: 20110826003137

Steps to reproduce:

Try to open the 'Bookmarks' toolbar button.


Actual results:

Every item on the drop-down shows the same children and goes into an endless recursion,
see screenshot.


Expected results:

The correct child menus should open, like they do from the "Bookmarks" menu.

Comment 1

[H. Hofer]

I tried to remove 'places.sqlite', but after syncing, the same effect shows again.
All other 'devices' (SeaMonkey 2.3, Fx 6.0, 9.0) seem OK.
Also, the 'Bookmarks' main menu is OK.

Comment 2

[H. Hofer]

Attachment: Empty Bookmarks Toolbar

If I click through the 'Bookmarks' main menu first, without touching the toolbar, then try to open the toolbar 'Bookmarks', most the sub-menus are missing (see attachment).

Comment 3

[therube]

Error Console show anything pertinent?

Is "syncing" required?
Does this happen with a new copy of places.sqlite?

Does it happen with a new Profile?
In Safe Mode?
With the Default theme?

Comment 4

[therube]

I can confirm the second issue, Coomment 2.

Comment 5

[H. Hofer]

(In reply to therube from comment #3)
> Error Console show anything pertinent?
Unfortunately not.
> Is "syncing" required?
No.

> Does this happen with a new copy of places.sqlite?
Yes (deleted an re-generated).

> Does it happen with a new Profile?
Yes.

> In Safe Mode?
Yes.

> With the Default theme?
Yes.

Comment 6

[H. Hofer]

It also happens under Windows 7, new Profile, default Theme.
Need more screenshots? ;-)

I suspect, it has something to do with the landing of bug 677539, as
it also happens on a freshly installed Aurora 2.4 {Build ID: 20110816013002}
and Aurora 2.5 {Build ID: 20110827013004} build.

This might be a problem for the upcoming 2.4 beta!

Setting the version accordingly...

Comment 7

[Philip Chee]

Jens, looks like your patch in Bug 677539 caused this.

> +    if (!document.getElementById('bookmarksMenu')._placesView)
> +      new PlacesMenu(aEvent, 'place:folder=BOOKMARKS_MENU');

Wot about id="bookmarks-button" then?

Comment 8

[[e-mail]]

D'oh! Try using (!aEvent.currentTarget.parentNode._placesView)

Comment 9

[Jens Hatlak (:InvisibleSmiley)]

I haven't looked into this yet and won't have time for a couple more hours, but the current code (onPopupShowing) is used for both the main (window) menu and the Bookmarks button, while the old code did indeed differentiate between parentNode and bookmarksMenu (see attachment 552796 [details] [diff] [review]). If what Neil suggests doesn't work for both cases (again, haven't checked yet), we might need to pass in an extra parameter.

Comment 10

[Jens Hatlak (:InvisibleSmiley)]

Attachment: patch [Checkin: comment 11]

Thanks Neil, works like a charm (and Phil for directing me here).

This needs to land on Aurora/Beta in order to fix the regression introduced by my previous change in bug 677539.

Comment 11

[Jens Hatlak (:InvisibleSmiley)]

Comment on attachment 556584 [details] [diff] [review]
patch [Checkin: comment 11]

http://hg.mozilla.org/comm-central/rev/bb592d005d2f
http://hg.mozilla.org/releases/comm-aurora/rev/ad5bc4ef1e4a
http://hg.mozilla.org/releases/comm-beta/rev/06fdb5abb9bd