Closed Bug 26550 Opened 25 years ago Closed 17 years ago

Menu hilite missing on second click

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Version:
1.4 Branch
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
mozilla1.0.1

People

(Reporter: mmastrac, Assigned: hyatt)

References

Details

(Whiteboard: [Hixie-P0]) 

The little menu hilites around the active menu item disappear if you click a
menu item repeatedly.  Very minor issue.

Reproduction steps:
1.  Click the file menu to open the menu.
2.  Click the file menu again the close the menu.
3.  Click the file menu once more to open the menu - notice the lack of hilite
around "file"

Actual Behaviour:
There is no hilite present around the File menu item

Expected Behaviour:
The third click should hilite the menu as the first one did.
Okay...  There's something I believe is a side-effect of this bug I just noticed
after I posted that one.  If you try moving the mouse down to the menu after
step 3 of my description, you find the menu just disappears and your mouse
cursor is left with the menu selection look.

I'm fairly certain these two bugs are one and the same, however, but I'll file
another report if needed.

this sounds a lot like 17042.


*** This bug has been marked as a duplicate of 17042 ***
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → DUPLICATE
verif.
Status: RESOLVED → VERIFIED
I'm reopening the bug, as the bug it was marked a duplicate as has been fixed,
but this bug is still there.  This one doesn't deal with menus being disabled,
but rather the menu hilite disappearing from the root menu after clicking the
menu item three times in succession.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
i thought i had a bug on this already, maybe it went away already....
Status: REOPENED → ASSIGNED
Target Milestone: --- → M17
Mass moving M17 bugs to M18
Target Milestone: M17 → M18
*** Bug 40099 has been marked as a duplicate of this bug. ***
*** Bug 40389 has been marked as a duplicate of this bug. ***
mass-moving all bugs to m21 that are not dofood+, or nsbeta2+
Target Milestone: M18 → M21
*spam*: transferring current XP Menu bugs over to jrgm, the new component owner.
feel free to add me to the cc list (unless am the Reporter) of any of these, if
you have any questions/etc.
QA Contact: sairuh → jrgm
*** Bug 44824 has been marked as a duplicate of this bug. ***
Target Milestone: M21 → Future
The bug as reported here is fixed, but seems to have manifested itself in
slightly different behaviour somewhere else.  Try this:

1.  Click "File"
2.  Move the mouse over to Edit while the file menu is still showing
3.  Click repeatedly without moving the mouse

At this point you'll see the menu hilite disappear while the menu continues to
hide and show.
Keywords: helpwanted
Target Milestone: Future → mozilla1.0
I just spent about 30 minutes trying to figure out why the outermost pixel of a 
menu acted differently to mousedowns than the rest of the menu, but I was 
actually hitting this bug.

This bug seems to be one of the main causes of a strange visual thing where one 
menu name is raised but another menu is displayed, which I see fairly often.
See also bug 65525.
This bug is still present, but acting subtly different.  To reproduce it now:

1.  Click the file menu
2.  Move the mouse to the Edit menu while the file menu is still displayed
3.  Click the mouse again without moving it

It looks like the menu isn't getting the hover event when you have just clicked
it off, then as soon as it gets a mousemove event, everything goes back to normal.

(adding my new email to CC)
On top of it all, it looks like you don't even have to go to a different menu
item!  Just click, move the mouse to the left a pixel or two and click again. 
No matter how many times you click, the menu hilight won't appear (until the
mouse is moved, that is).  It works fine if you continually click in the same area.
[Note that this may be platform specific, although the original report did not
 mention a specific OS. My system is Linux-2.4.0 with XFree-4.0.3 running the
 Mozilla 2001062506 nightly build.]

I can still reproduce this bug exactly as described in the initial report.
Additionally, when the menu pops up again in step 3, the keyboard navigation
(using cursor keys or the underlined menu shortcuts) is broken and does not
work at all. Pressing ESC will not dismiss the menu.

If I press ALT-V, the View menu appears on top(!) of the file menu (which
is still visible). Keyboard navigation then works for the view menu.

If I move the mouse cursor away from the File menu fast enough (after step 3),
I can highlight other menu titles with the mouse while the File menu is shown.
Pressing cursor down then will open another menu (again, while File menu is
still visible). Once another menu (like View) has been show in this way, I
can even dismiss the View menu and scroll the page or edit form elements while
the File menu is still visible. Mouse clicks outside the File menu will not
close it then. (If I do not move the mouse fast enough at the beginning, the
File menu title will get highlighted and everything works normally.)

A further note: If you try to open a menu while the target window is not the
active window (i.e. does not have focus), you jump straight to step 3 of the
bug descrption: The menu title is hilighted at first (before clicking), but
when I click on it the highlighting (border) disappears, the menu is show and
behaves in the same strange way.

(If you don't think that this is a related issue, tell me and I will file a
 separate bug for this.)

adding myself to cc: list

I can reproduce this issue under Windows, 2001070204 as well.
Here's what I get with build 2001081006 on Linux.
When I mouseover a menuitem such as "Tasks", it receives a hilite.
(Hold the mouse pixel-perfectly still.)
Clicking on it depresses the hilite and opens the menu.
Click again to make the menu and hilite disappear.

At this point, clicking on the menu will not cause the hilite to appear.
However, moving the mouse a little will update the state of the hilite.



new owner
Assignee: pinkerton → hyatt
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla1.0.1
On Linux I can make the highlight dissappear simply by clicking the menu bar
item to open the menu.

 1. Move to menu, highlight visible.
 2. Click. Menu opens, highlight disappears.
 3. Move mouse. highlight reappears.

Since I am using a track pad, it is _very_ easy to get this behaviour. It is
also rather disturbing.
Whiteboard: [Hixie-P0]
I've just discovered another way to reproduce the bizarre behaviour- I think
this is more recent.  Perhaps this is the root cause of the bug?

1.  Click the a top-menu item normally to open it.
2.  Click the menu item again to open it, but this time, delay 1sec between
mousedown and mouseup.

The menu will then stay open, even though the hilite is gone!  Keyboard
navigation is broken in this case, as reported by other users.

I've started hitting this more often now that I have a stylus.

Any ideas where this bug might live?  I've been nagged by this thing for so long
that I'm tempted to fix it myself.  :)
Matthew: That's bug 179567.
(Ian in comment #21)
> On Linux I can make the highlight dissappear simply by clicking the menu bar
> item to open the menu.
> 
>  1. Move to menu, highlight visible.
>  2. Click. Menu opens, highlight disappears.
>  3. Move mouse. highlight reappears.
> 
> Since I am using a track pad, it is _very_ easy to get this behaviour. It is
> also rather disturbing.

Is this still a problem in linux?

WFM in windows.

I no longer see this on Linux, neither in Mozilla nor in Firefox (but Firefox is not really relevant here, since the problem occured with the old XPFE toolkit that is not used in Firefox), so I guess this is WORKSFORME now.

Tested with:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050702
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5
WFM - depress, raised never varies
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a3pre) Gecko/20070216 SeaMonkey/1.5a
URL: n/a
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 17 years ago
Keywords: helpwanted
Resolution: --- → WORKSFORME
Version: Trunk → 1.4 Branch
Component: XP Toolkit/Widgets: Menus → XUL
QA Contact: jrgmorrison → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.