Closed Bug 137033 Opened 22 years ago Closed 22 years ago

Chrome buttons remain highlighted after dropdown item selected

Categories

(SeaMonkey :: Bookmarks & History, defect)

defect
Not set
normal

Tracking

(Not tracked)

VERIFIED FIXED

People

(Reporter: davidstl, Assigned: bugs)

References

Details

(Whiteboard: [adt2])

Attachments

(2 files, 1 obsolete file)

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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
Keywords: mozilla1.0, nsbeta1
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.
Summary: Bookmarks button remains highlighted after going to bookmarked page → Bookmarks button in personal toolbar remains highlighted after going to bookmark
Focus is in the loaded content (as it should be), button just retains the
mouseover appearance.
Nav triage team: nsbeta1-
Keywords: nsbeta1nsbeta1-
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.
Keywords: regression
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.
Keywords: regression
*** 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.
Keywords: mozilla1.0.1
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.
Blocks: 1.1b
nominating for Buffy
Keywords: nsbeta1-nsbeta1
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.
Summary: Bookmarks button in personal toolbar remains highlighted after going to bookmark → Chrome buttons remain highlighted after dropdown item selected
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
Keywords: nsbeta1nsbeta1+
Whiteboard: [adt2]
Blocks: 1.1
No longer blocks: 1.1b
Attached patch manually clear hover state (obsolete) — Splinter Review
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.
Keywords: mozilla1.0patch
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.
Attachment #92567 - Attachment is obsolete: true
Bug 147689 which has been marked as a dup to this occured on Mac OS X.  It is
not MS Windows only,
All/all.
OS: Windows 2000 → All
Hardware: PC → All
Keywords: review
*** 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.
Attachment #92686 - Flags: superreview+
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?
Attachment #92686 - Flags: approval+
checked into trunk!

modify some comments to fit current situation - still looking for a better 
approach.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
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.
Status: RESOLVED → VERIFIED
Keywords: mozilla1.0.2
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)
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: