27227 - Bookmarks link in personal toolbar doesn't always work

Status: VERIFIED WORKSFORME

(SeaMonkey :: Bookmarks & History, defect, P3)

Description

[Sarah Dwyer]

For some reason sometimes I click on the bookmarks link in the personal toolbar
and it doesn't always open. It's kind of annoying. I can't tell you how to
reproduce it beyond just trying to see if you can click the whole area you would
expect a user to click on and see if it works.

Comment 1

[Claudius Gayle]

what build id (lower right corner of browser) are you using for this and bug 27226? I'm using 2000021008 and I'm not having any 
such problems. The bookmarks popup on the bookmarks/personal toolbar works on the first click and i can surf the imported IE 
links (bug 27226) just fine.

Comment 2

[Chris Nelson]

I can somewhat verify this. In the latest build (2000022808) for Windows, I'm 
finding that clicking on links _in_ the bookmarks menu doesn't always work. 
Sometimes the page loads, sometimes not.

Steps to reproduce:

1) Open Mozilla (make sure you have default bookmarks)

2) Open the bookmarks menu, enter the Business and Finance menu, and then

3) Click in the empty space to the left of the text "Career Center" in the 
submenu. Click close to the edge of the menu.

Although it doesn't happen everytime, occasionally the link will fail to load in 
the browser.

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm seeing a similar problem. Bookmarks in submenus of any Bookmarks menu (main 
menubar or personal toolbar) work only intermittently. (Bookmarks at the top 
level seem to always work.) There doesn't seem to be any pattern to the failure; 
sometimes trying the same bookmark repeatedly will eventually work. In failure 
cases, OpenBookmarkURL is simply not being called, and there is no visible error 
of any kind.

I've tried smashing and recreating the entire profile area, both using default 
data and migrating a 4.x profile, and I see the problem regardless.

I first noticed this sometime last month. It makes Mozilla fairly unusable for 
me.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

OK, I've found what I think is causing my problems. When I click on a menu, it 
calls CaptureRollupEvents on the window widget so that if a suitable event 
occurs (e.g. a click outside the menu), the menu is automatically dismissed. So 
far so good. Now, if I bring up a menu and then a submenu, and I click in the 
submenu, *sometimes* Windows is delivering a WM_ACTIVATE event before the 
WM_LBUTTONDOWN. This causes the main menu to be dismissed, and the submenu too 
--- before the WM_LBUTTONDOWN arrives! In fact the WM_LBUTTONDOWN is simply 
discarded because the submenu's window is destroyed before it can be handled. 
Hence the menu item does not fire.

These WM_ACTIVATE events are not always sent; I haven't yet figured out a 
pattern. If the WM_ACTIVATE event is not sent then everything works because, 
although the WM_LBUTTONDOWN event dismisses the main menu and the submenu, it is 
also processed normally.

The basic bug seems to be that the menu dismissal listener is not pointing to 
the submenu.

There may be a secondary bug lurking around; I'm not sure why processing of 
WM_ACTIVATE should be using the mouse cursor position to determine whether the 
rollup widget should rollup or not.

Comment 5

[Robert O'Callahan (:roc) (email my personal email if necessary)]

OK, the bug is due to the fact that attribute change notifications come back in 
varying order. The problem is when we have submenu1 open and we switch to 
submenu2. Sometimes the attribute change happens like this:
   submenu2.open <= true
   submenu1.open <= false
The first change notification sets the menu dismissal listener to point to 
submenu2, great. The next notification sets the menu dismissal listener to point 
to submenu1's parent, the main menu! Bad bad bad.

This looks like hyatt's code so I'm taking the liberty of CC'ing him.

I have implemented a patch that modifies the behaviour when the "open" attribute 
changes to "false". I only redirect the dismissal listener to the parent menu IF 
it is currently directed to the popup that's being closed. The patch seems to 
solve all my problems. I will attach.

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Attachment: Patch to get correct dismissal listener target in case of attribute notification reordering

Comment 7

[don]

Move to M21 target milestone.

Comment 8

[fig\tree]

Has anyone reviewed this patch and/or has it been checked in?

Comment 9

[Claudius Gayle]

adding patch keyword.

the question is, "does this still happen?" I think not. I cannot reproduce it with the 2000071008 builds

Comment 10

[Keyser Sose]

Verified
Platform: PC
OS: Windows 98
Mozilla Build: 2000101020 M18 Trunk Build