16592 - Problems selecting context menu item w. right mouse button

Status: VERIFIED WORKSFORME

(Core :: XUL, defect, P3)

Description

[Mats Palmgren (inactive)]

OVERVIEW DESCRIPTION:
Selecting a menu item in the context menu with the right mouse button
causes a crash if the menu has been popped up several times in a row with
the right mouse button only.

TO REPEAT:
1. start mozilla
2. click right mouse button on background to bring up the context menu
3. click right mouse button outside it to pop it up at another position
4. select a menu item in it with the RIGHT mouse button

You may have to repeat step 3+4 a few times but it always crash here for me:
MOZILLA caused an invalid page fault in module GKWIDGET.DLL

VERSION & OS:
mozilla nightly build 1999-10-15-12-M11 on Windows 98 SE.

Comment 1

[Sean Richardson]

This procedure also reliably causes a crash
with 1999-10-15-11-M11 on Windows NT

Comment 2

[Peter Trudelle]

reproduced in today's win98 opt bits, reassigning to saari as p2 for m12

Comment 3

[Peter Trudelle]

mass-moving all m12 bugs to m13

Comment 4

[Eli Goldberg]

[Contextual menu bug --- QA Assigning to self.]

Comment 5

[sairuh (rarely reading bugmail)]

assigning this contextual menu bug to me...

Comment 6

[saari (gone)]

M15

Comment 7

[sairuh (rarely reading bugmail)]

cannot repro this on either win98 or winNT using today's comm. bits
(2000-011909). marking as wfm. lemme know if anyone else still sees this.

Comment 8

[Sean Richardson]

Testing with 2000-01-19-08-M13 nightly binary on NT, this bug no longer occurs,
but something strange does. If the Steps under "TO REPEAT" are followed exactly,
at the end of step 4 a *third* context menu will pop up in another location,
which will work normally.

This would hardly be worth reporting, except that if the click in step 4 is
changed to a LEFT click, that click does nothing. That problem has been filed
as Bug 24482, "Context menu does not work if repositioned before use".
This odd behaviour may provide a clue as to the cause of that bug.

Comment 9

[Mats Palmgren (inactive)]

IMHO, this bug is still alive - it just doesn't crash anymore. As
[e-mail] noted there is a third menu appearing, the position of it and
the fact that it is possible to get two menu-items highlighted in this menu
indicates to me that there is still something broken here.
Anyway, a right click in a context menu probably should be taken as a left click
(as native menus do).

Comment 10

[leger]

Clearing WORKSFORME resolution due to reopen.

Comment 11

[leger]

BULK MOVE: Changing component from XP Menus to XP Toolkit/Widgets: Menus.  XP 
Menus component will be deleted.

Comment 12

[Sean Richardson]

The right-click on context menu issue raised by [e-mail] in latest
comment is the subject of bug 17159, "[4.xP] right click doesn't work within 
context menus" and bug 21549, "[4.xP] selecting item in context menu requires 
second click (left)", ASSIGNED to [e-mail], M16. 

The question has been raised in 21549, what popular apps allow 
ight-click-selection on a context menu? - the answer is clearly NN 4.x. 
Adding a notation to that bug to that effect.

So this bug can be about the weird behaviour, and 17159 and 21549 about using 
right-clicking on a context menu the same as a left-click.

Since this has been REOPENED, and [e-mail] took all the rest
of the context menu bugs, here's one more ;-).

Comment 13

[Mike Pinkerton (not reading bugmail)]

bulk accepting xpmenu/popup bugs. sigh.

Comment 14

[:deanis74]

You can also duplicate this weird menu behavior by double-clicking with the
right mouse button.  This opens a context menu at the pointer position, closes
it, then opens a second context menu in an improper position.

Comment 15

[:deanis74]

Sorry, a slight correction on that.  You first have to open a context menu
normally, with a single right-click, then double-click with the right mouse
button somewhere else in the window.

Comment 16

[:deanis74]

Odd.  I was playing around with nsContextMenu.js and found that the first time 
through, this.target.tagName.toUpperCase == "TD", while the second ("bad 
stuff happening") time through it's == "BROWSER".  This usually throws an 
exception because it falls through the big 'if' tree in setTarget() to the final 
'else'.  I got around this exception by throwing in:

} else if (this.target.tagName.toUpperCase() == "BROWSER") {
  // do nothing

before the final 'else', and now the second ("bad") menu that comes up is a 
frame-specific menu.

I don't know if this helps at all or not.

Comment 17

[Mike Pinkerton (not reading bugmail)]

moving all defects not directly related to P0 beta2 features off to M18.

Comment 18

[Peter Trudelle]

Mass moving M18 bugs to M19

Comment 19

[Peter Trudelle]

mass-moving all bugs to m21 that are not dogfood+ or nsbeta2+ or nsbeta2-

Comment 20

[sairuh (rarely reading bugmail)]

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

Comment 21

[Sean Richardson]

Testing with the 2000-06-23-08-M17 nightly bianry on WinNT, this no longer 
appears to ba a problem.

Current behaviour:
A context menu is invoked by a right-click.
A right or left click elsewhere dismisses the context menu.
A right or left click on an item in the context menu activates it.
No odd behaviour depending on the sequence of clicks before trying to 
activate a context menu item.

If that's all according to spec, this chitinous critter can be calle w.f.m.

Comment 22

[Mike Pinkerton (not reading bugmail)]

ok, wfm too

Comment 23

[John Morrison]

verified wfm win32/linux/mac 20000626nn builds (mac using ctrl-click for 
context menu).

Comment 24

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/c62fa59180ac
[fenix] For https://github.com/mozilla-mobile/fenix/issues/16592 - Fix missing collection snackbar for a11y (https://github.com/mozilla-mobile/fenix/pull/16593)