when expanded menus unexpand, takes highlight with it




19 years ago
11 years ago


(Reporter: jmd, Assigned: mikepinkerton)



Firefox Tracking Flags

(Not tracked)




19 years ago
to observe:
- Click on view
- Move mouse down to Toolbars ... expanded menus pop out
- Move mouse down to Sidebar ... highlighting of selection disapears when
  Toolbars colapses (1 sec delay)

Seeing this on linux 2000/06/06-08 (this morning's).

Win32 doesn't seem to do this, with sunday's build. (2000/06/04-08)
Target Milestone: --- → M21


19 years ago
Target Milestone: M21 → Future

Comment 2

19 years ago
Is this still happening, or have other fixes fixed this as well?

Comment 3

19 years ago
No, this still happens on Linux (but not on win32 or mac).

Comment 4

18 years ago
*** Bug 89084 has been marked as a duplicate of this bug. ***

Comment 5

18 years ago
Bug 74059 seems to have a little more meat than this one.  Should we mark this a
dupe of that?

Comment 6

18 years ago
*** Bug 74059 has been marked as a duplicate of this bug. ***

Comment 7

18 years ago
Severity: trivial -> normal, as this is now (maybe it always was) triggering for
user bookmarks. This is VERY annoying, and makes two bookmark folders
side-by-side kinda of useless. You move to the first, it expands, you move down
to the second, it unhighlights as the first unexpands. You then have to move off
it, and back on.

If you have trouble reproducing (sometimes it works OK 5 or 10 times in a row),
try only moving a little bit in to the second menu item, instead of moving the
mouse all the way to the middle. Perhaps this helps because it's affected by
when the mouse /stoped/ moving and came to rest (so try it faster, if you have

When I get 'in the groove', it'll reproduce every time. Trying to look for a
bookmark through 4 or 5 folders makes me want to rip my hair out.

Untargeting for re-eval. (Was Future)
Severity: trivial → normal
Target Milestone: Future → ---
Is bug 74059 really a dupe?  I see the behaviour given in this bug, but I can't
reproduce it with the info in Bug 74059 or Bug 89041.

I've noticed that if I move from a menu item with a submenu to an item with no
submenu (as given in this bug) then it takes away the highlight.  But if it
moves onto an item WITH a submenu, everything seems normal.

This is on Linux build 2001072221.

Comment 9

18 years ago
I think so.

Bug 74059 basically is about the same issue, the only difference here is the
type of menu item moved to. The behaviour is similar in both cases, as I have
writen in my comment in bug 74059:

If the menu item moved to does not have a submenu, it is unselected when the
previous submenu disappears. If it has a submenu, it is unselected and no
submenu is displayed. Moving the mouse afterwards selects the menu item and
displays the submenu (if it has one). I can easily reproduce both.

Adding myself to cc: list.
*** Bug 84585 has been marked as a duplicate of this bug. ***


18 years ago
Blocks: 89041

Comment 11

18 years ago
Hmmm.... I wonder if there's something weird like a stray NS_MOUSE_EXIT_SYNTH
message getting sent.  I've seen it before in menus.  Check out my comments in
bug 29401 (2000-04-04 19:06 comment) and bug 52033 (2001-07-25 01:24 comment).

I don't have windows so I can't look into this.  But my guess would be easy
enough to check, just throw a printf() in the NS_MOUSE_EXIT_SYNTH check in
nsMenuFrame.cpp.  See if two messages fire when the submenu closes.

No longer blocks: 89041


18 years ago
Target Milestone: --- → mozilla1.1


18 years ago
Blocks: 89041
*** Bug 99029 has been marked as a duplicate of this bug. ***
*** Bug 101366 has been marked as a duplicate of this bug. ***

Comment 14

17 years ago
*** Bug 112834 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.1alpha → Future
*** Bug 341157 has been marked as a duplicate of this bug. ***
This bug is not present in the 1.5 release builds but in the trunk builds so apparently this has been fixed and then regressed again.

While for regular menus this is only mildly irritating it is outright annoying with D&D behavior in the bookmarks toolbar which becomes quite an "adventure". Hopefully the fix can be transfered from branch to trunk?

Comment 18

13 years ago
This has never been fixed AFAIK. Firefox is not using XP Toolkit anyway, so bug 341157 shouldn't have been marked as a dup of this bug.
*** Bug 341157 has been marked as a duplicate of this bug. ***
Firefox doesn't use xpfe, but since XP Toolkit owns things like layout/xul, "not using XP Toolkit" would mean having forked XUL. We may be crazy, but we're not that crazy.
I guess what confuses me a bit is that this bug has never been marked as fixed/wfm yet the branch builds don't have this problem. That lead me to believe that the problem with the trunk builds is actually a new regression.
This has regressed between the 10th and 13th of May (there are no linux builds available between these dates in the archive).


Since a big patch for bug 326273 landed right in that timeframe could this be a threading issue?
> This has regressed between the 10th and 13th of May (there are no linux builds

I can reproduce this bug in 2006-05-10-04-trunk also but only by sliding across two menuitems (e.g. start on View -> Font Size and go over Page Style to Character enconding before the Font Size submenu closes). With 2006-05-12-12-trunk and current trunk that's not necessary. I can't reproduce the bug in 2.0.
I'm not seeing this anymore in current nightlies so this can possibly be closed.

Comment 25

11 years ago
Sure, a bug like this was fixed
Last Resolved: 11 years ago
Resolution: --- → FIXED


11 years ago
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets


11 years ago
Duplicate of this bug: 74059

Comment 27

11 years ago
Neither cause nor cure identified, so WFM?

I trust someone will change it back if I'm wrong.

You need to log in before you can comment on or make changes to this bug.