Closed Bug 682531 Opened 9 years ago Closed 9 years ago

Bookmarks Toolbar endless recursion

Categories

(SeaMonkey :: Bookmarks & History, defect)

defect
Not set

Tracking

(seamonkey2.3 unaffected, seamonkey2.4 fixed, seamonkey2.5 fixed, seamonkey2.6 fixed)

RESOLVED FIXED
seamonkey2.6
Tracking Status
seamonkey2.3 --- unaffected
seamonkey2.4 --- fixed
seamonkey2.5 --- fixed
seamonkey2.6 --- fixed

People

(Reporter: hhofer42, Assigned: InvisibleSmiley)

References

Details

Attachments

(3 files)

Attached image 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.
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.
Version: SeaMonkey 2.3 Branch → Trunk
Attached image 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).
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?
I can confirm the second issue, Coomment 2.
(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.
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...
Version: Trunk → Seamonkey 2.4 Branch
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?
Blocks: 677539
Status: UNCONFIRMED → NEW
Ever confirmed: true
D'oh! Try using (!aEvent.currentTarget.parentNode._placesView)
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.
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.
Assignee: nobody → jh
Status: NEW → ASSIGNED
Attachment #556584 - Flags: review?(neil)
Attachment #556584 - Flags: approval-comm-beta?
Attachment #556584 - Flags: approval-comm-aurora?
Attachment #556584 - Flags: review?(neil)
Attachment #556584 - Flags: review+
Attachment #556584 - Flags: approval-comm-beta?
Attachment #556584 - Flags: approval-comm-beta+
Attachment #556584 - Flags: approval-comm-aurora?
Attachment #556584 - Flags: approval-comm-aurora+
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → seamonkey2.6
OS: Windows XP → All
Hardware: x86 → All
Version: Seamonkey 2.4 Branch → Trunk
You need to log in before you can comment on or make changes to this bug.