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.
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.
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.
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.
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.
Created attachment 6892 [details] [diff] [review] Patch to get correct dismissal listener target in case of attribute notification reordering
Move to M21 target milestone.
Target Milestone: M18 → M21
Has anyone reviewed this patch and/or has it been checked in?
Whiteboard: Possible fix is sitting here collecting dust
adding patch keyword. the question is, "does this still happen?" I think not. I cannot reproduce it with the 2000071008 builds
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → WORKSFORME
Verified Platform: PC OS: Windows 98 Mozilla Build: 2000101020 M18 Trunk Build
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.