If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Bookmarks link in personal toolbar doesn't always work

VERIFIED WORKSFORME

Status

SeaMonkey
Bookmarks & History
P3
normal
VERIFIED WORKSFORME
18 years ago
13 years ago

People

(Reporter: Sarah Dwyer, Assigned: Steve Lamm)

Tracking

({helpwanted})

Trunk
x86
Windows NT
helpwanted

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: Possible fix is sitting here collecting dust)

Attachments

(1 attachment)

(Reporter)

Description

18 years ago
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

18 years ago
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

18 years ago
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

Updated

18 years ago
Target Milestone: --- → M18

Comment 7

18 years ago
Move to M21 target milestone.
Target Milestone: M18 → M21

Comment 8

18 years ago
Has anyone reviewed this patch and/or has it been checked in?
Keywords: helpwanted
Whiteboard: Possible fix is sitting here collecting dust

Comment 9

18 years ago
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: 18 years ago
Keywords: patch
Resolution: --- → WORKSFORME

Comment 10

17 years ago
Verified
Platform: PC
OS: Windows 98
Mozilla Build: 2000101020 M18 Trunk Build
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.