From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020411 BuildID: 2002041103 If I click the bookmarks button and then go to one of the pages I have bookmarked, the page loads ok but the Bookmarks button remains highlighted on the personal toolbar. In previous Mozilla releases, the button was no longer highlighted. Reproducible: Always Steps to Reproduce: 1. Click the Bookmarks button on the personal toolbar 2. Choose one of the sites bookmarked and go to it. 3. Notice how the Bookmarks button remains highlighted Expected Results: Bookmarks button should lose focus and not be highlighted anymore

David, what theme are you using? Does this happen n both modern and classic?

I checked it with both classic and modern, and it happens on both. I just uploaded a screenshot of what it looks like in modern theme.

*** Bug 137540 has been marked as a duplicate of this bug. ***

Confirming on 2002041408 on WinXP.

I'm using release candidate 1 - 2002041711 - and this problem seems to have gone away.

Now I've upgraded to 2002041903 and the problem is back.

*** Bug 138282 has been marked as a duplicate of this bug. ***

This is a trunk only problem. Branch builds don't seem to have this problem.

Not only the Bookmarks button but also other personal toolbar folder buttons do behave like that if a bookmark inside them is clicked. At least in trunk build 2002042608 on Win2k. Another thing I see: the button looses its 'hovered' state (i.e. its border) as soon as the mouse pointer leaves the html display area (not sure how it is called officially...) - no matter in which direction. Can you confirm that?

I'm now seeing this on a branch build.

confirming on win2k and build 20020427 and later. 2002042406 is the last build (that I've tried) that doesn't have this problem.

oh, i've tried 2002042708, 2002042808 and 2002042906.

Some more precise observations regarding comment #10: Bookmark folder stays highlighted *as long as you do not move the mouse over some element of the mozilla window*. Exempt from this are the area where the html pages are shown - *and the border to the right of this area, including the scrollbar*. This means: if you click in a personal toolbar subfolder on a bookmark that is located somewhere over the html area, the folder will stay highlighted as long as you move the mouse over ther html area and also will stay when you move the mouse to the *right* out of the mozilla window. As soon as the mouse moves over another element of the mozilla window the highlighting disappears. Similarly a plain bookmark in the personal toolbar stays highlighted/hovered after clicking as long as you do not move the moues out of the area of that button. Now it should be easy to find out, where changing a state or something was forgotten... :-)

I'm seeing this with build 2002-04-29 branch on WinNT P.S. It would help if the words "icon" and "toolbar" were included in the Summary.

Focus is in the loaded content (as it should be), button just retains the mouseover appearance.

Nav triage team: nsbeta1-

A branch build from 24-Apr-2002 12:40 doesn't have this bug, but the build from 25-Apr-2002 12:38 has it. I'm seeing this on WinXP. On trunk builds, this bug was seen before 24-Apr-2002 meaning that the checkin that caused this was checked in on the trunk before on the branch.

So it seems like this might have been caused by my checkin of bug 5693. However, it also seems to be Windows-only. I'm surprised that my checkin would have caused changes to menus, since menus don't use :hover or :active for their hover and active effects. However, it is possible. I'm certainly willing to help someone who can debug the problem.

*** Bug 138849 has been marked as a duplicate of this bug. ***

Confirming on Win98 RC2 2002051006 with all Themes.

*** Bug 143902 has been marked as a duplicate of this bug. ***

*** Bug 143910 has been marked as a duplicate of this bug. ***

*** Bug 144573 has been marked as a duplicate of this bug. ***

Does anyone know if this bug is going to be fixed for 1.0?

*** Bug 145520 has been marked as a duplicate of this bug. ***

confirming on win2k, rc3 (build: 2002052306) will this bug make it all the way to 1.0?

I hope this bug would be fixed for 1.0 release. It is kinda annoying. And would make 1.0 not so professionnal :-)

I think I wanted to report the same bug for 1.0 rc3 Just my observation, because I'm not sure whether all of it has been mentioned here: 1. move the mouse over the Bookmarks-icon in the toolbar -> icon is highlighted as all other menus (e.g. File) do 2. click the icon -> the icon is drawn pressed (or "downlighted") 3. select a bookmark -> the icon changes from pressed to highlighted (and not to normal as it should) 4. Moving the mouse over any icon, which has a mouse-over effect, brings the Bookmarks-icon to the normal state (interesting: in tabbed-browsing it is sufficient to move the mouse over any tab to bring the icon in it's normal state) The Bookmarks-icon in the menubar behaves correct. I'm clearly nominating this bug for 1.0!!

another thing i see (build 2002052406, win2k) is that if you change the order of the bookmarks listed in the personal toolbar folder, they are shown in the wrong/old order until you move the mouse out of the html area. hope it helps!

and oh! I see this with the "manage bookmarks"-window both open and closed. that is, if you change the order of the bookmarks, and then, with the "manage..."-window still open, move the mouse over any part other than the html area, the order of the bookmarks is updated! same thing if I change the order and then close the "manage..."-window.

*** Bug 147689 has been marked as a duplicate of this bug. ***

*** Bug 146970 has been marked as a duplicate of this bug. ***

This bug affects buttons that use that hover state. Try going to the sidebar and opening up Customize Sidebar.

I can confirm that this happens on Win2k and WinXP. I was very disappointed to see that this wasn't fixed in time for 1.0. It is a very obvious and annoying bug that clearly hurts the image of Mozilla. People might think, "If they can't fix something as little as that in two months, how can they fix more serious bugs?" This bug is annoying enough to me to keep me from using Mozilla as my primary browser. I really think this needs to be fixed, ASAP.

nominating for Buffy

re: dbaron's comment 19: the bookmark toolbarbutton has a class="bookmark-item" attribute. Therefore, its :hover and :active states are defined in themes/classic/communicator/bookmarks/bookmarksToolbar.css and in themes/classic/global/win/toolbarbutton.css but may inherit other style rules.

dbaron: _moz_menuactive is only used for showing the highlighted state on menu items. The hover effect on a toolbar button is, in fact, just a :hover rule. I don't think the proper notifications are happening to take the button out of the :hover state.

*** Bug 155642 has been marked as a duplicate of this bug. ***

This happens with any button that has a dropdown component that extends out of the button's toolbar. Summary should be changed as it is not bookmarks only, nor is it restricted to the personal toolbar. It happens to the forward and back button histories also.

Changing summary. If you can think of a better way to say it, please do.

Probably not a necessary additional comment but I believe it happens to the print button as well. Menus and Menubuttons are affected.

Nav triage team: nsbeta1+/adt2

If the mouse point is outside the document when menu was closing, the chrome window will not receive mouseexit event, so the current hover state will not be cleared. We should clear the hover state manually.

I wonder if a better and more general approach would be to fire a mouseexit event on the Windows platform when the menupopup closes, since it seems to be fired on linux.

This is a limit of Windows event system. GTK has enter_notify_event/leave_notify_event that pretty match our NS_MOUSE_ENTER/NS_MOUSE_EXIT event, but Windows only has "mouse_move". I'm not sure whether this problem can reproduce on other platform, such as OS2, Mac. If it's a Windows only problem, we can put those code within a #ifdef XP_WIN/#endif block. But, in fact, my fix doesn't affect *nix at all.

Bug 147689 which has been marked as a dup to this occured on Mac OS X. It is not MS Windows only,

All/all.

*** Bug 142832 has been marked as a duplicate of this bug. ***

Windows normally creates NS_MOUSE_ENTER/NS_MOUSE_EXIT events from native mouse move messages. Why isn't that happening here? Is there a tweak we could do at the widget level to ensure that these events are fired?

You can reproduce the problem even by this way: 1) click Bookmarks button; 2) move mouse to highlight whatever a menuitem in the popup; 3) press ESC. At this time, there is no any native mouse event to be fired. So we can't rely on mouse event in this case.

Shouldn't :hover actually be going away as soon as you move the mouse off of the bookmarks button?

Not if you want it to act like a "regular" application (on Windows). I think that the pop-up is a child of the button anyway so that it counts as the mouse being over the parent.

I didn't say it shouldn't appear to be depressed, I said I'm not sure if the :hover pseudoclass should apply. There are other ways to make it appear depressed, such as using an attribute, like menus and menu items.

Since bug 5693 fixed, now a widget can inherit the :hover state from its child. See: http://lxr.mozilla.org/seamonkey/source/content/events/src/nsEventStateManager.cpp#3583 When mouse moves off the button, the menuitem, that is the child of the button, obtains :hover state, so the button is still hovered.

Comment on attachment 92686 [details] [diff] [review] changed some comments Something still seems wacky here. If the :hover content is removed or hidden, we should unset the hover state all the way up the content chain. I'd be surprised if we didn't have code in place to do that; perhaps it's not triggered in this case. In the interest of fixing this for 1.1, I'm going to go ahead and sr= this, but I do believe there's a more generic correct fix.

Comment on attachment 92686 [details] [diff] [review] changed some comments r=ben@netscape.com

Comment on attachment 92686 [details] [diff] [review] changed some comments a=asa (on behalf of drivers) for checkin to 1.1 Is someone around that can get this checked in this evening?

checked into trunk! modify some comments to fit current situation - still looking for a better approach.

This definitely doesn't seem like the correct fix. I remember the day this started happening -- shouldn't we have reviewed checkins from the day before? Or has someone done that already?

blake, see comment 19, I think this started happening after dbaron's check in of bug 5693. I had a preliminary investigating: http://lxr.mozilla.org/seamonkey/source/content/events/src/nsEventStateManager.c pp#3583 - nsCOMPtr<nsIContent> hoverContent = mHoverContent; - while (hoverContent) { - if (aContent == hoverContent) { - aState |= NS_EVENT_STATE_HOVER; - break; - } - nsIContent *parent; - hoverContent->GetParent(parent); - hoverContent = dont_AddRef(parent); - } if we changed above code to: + if (aContent == mHoverContent) { + aState |= NS_EVENT_STATE_HOVER; + } also can fix this problem. but of course this is not a good idea.

Confirming bug "death" on trunk build 2002080304 - WinXP. Another one bites the dust. Next ? :-) Thanks to all coders for fixing this - graphically speaking - ugly one.

a question to dbaron, about the hierarchical :hover whether parent content should inherit the :hover state from its child 1) even though its frame doesn't contain its child's frame? 2) even though its child is hidden/disabled?

I was about to mark this VERIFIED, until I realised that I'm using a build from before the patch was checked in (build 2002080204-TRUNK on Win98SE). Oh well, it works fine for me, but then maybe it always had....

This "bug" could remind you; sort of like leaving a drawer to a filing cabinet you're working with open for a moment. What was the need to get rid of it?

David, are you sure that you followed the steps in comment 0 strictly? I can reproduce it using 2002080204-TRUNK on Win2000.

OK, re-read the instructions, and realised that I was using the "main" Bookmarks menu rather than the one on the Personal Toolbar (why is it in two places anyway?). OK, I do see the problem, which is good as my build doesn't have the patch.

OK, this time I tested following the instructions exactly, and used a build with the patch (2002080504-TRUNK). Works fine. Marking Verified.

a=rjesup@wgate.com for 1.0 branch; please change mozilla1.0.2+ to fixed1.0.2 when checked in.

fixed on 1.0 branch.

thanks, timeless!

verified on Windows, Linux, Mac using the branch build (20021031)