Closed Bug 41766 Opened 24 years ago Closed 16 years ago

when expanded menus unexpand, takes highlight with it

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: jmd, Assigned: mikepinkerton)

References

Details

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)
ick
Status: NEW → ASSIGNED
Target Milestone: --- → M21
Target Milestone: M21 → Future
Is this still happening, or have other fixes fixed this as well?
No, this still happens on Linux (but not on win32 or mac).
*** Bug 89084 has been marked as a duplicate of this bug. ***
Bug 74059 seems to have a little more meat than this one.  Should we mark this a
dupe of that?
*** Bug 74059 has been marked as a duplicate of this bug. ***
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
trouble.)

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.
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. ***
Blocks: 89041
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
Target Milestone: --- → mozilla1.1
Blocks: 89041
*** Bug 99029 has been marked as a duplicate of this bug. ***
*** Bug 101366 has been marked as a duplicate of this bug. ***
*** Bug 112834 has been marked as a duplicate of this bug. ***
fffffffuture
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?

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).

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2006-05-10&maxdate=2006-05-13&cvsroot=%2Fcvsroot

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.
Sure, a bug like this was fixed
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
Neither cause nor cure identified, so WFM?

I trust someone will change it back if I'm wrong.
Resolution: FIXED → WORKSFORME
You need to log in before you can comment on or make changes to this bug.