261043 - context menu shortcuts no longer work on Linux or Mac OS X

Status: VERIFIED FIXED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[sairuh (rarely reading bugmail)]

this has been an issue since at least the 2004091907-trunk builds. not a problem
in mozilla 1.8a3 (8/17).

to test (eg, make sure focus in within the web page content area):

* on Linux hit either shift-F10 or the context menu key (located in the
lower-right of PC keyboards, btwn the Windows and Control keys).

* on Mac OS X, hit control-spacebar.

expected: the context menu should appear for web content (usually in the
upper-left of the content area).

actual results: the context menu doesn't appear. occaisionally on Mac I can get
it to appear after selecting some content, but most of the time that doesn't
work. (no js console errors, alas.)

Comment 1

[sairuh (rarely reading bugmail)]

interestingly, not a problem on Windows (Asa's box).

Comment 2

[sairuh (rarely reading bugmail)]

looks like this broke sometime btwn 1.8a3 (8/17) and 2004082507-trunk builds.
(sorry, don't have intermediate builds.)

Comment 3

[sairuh (rarely reading bugmail)]

interesting thing: this seems limited to certain windows:

* navigator (browser)
* sidebar
* bookmarks manager
* js console

but this is not a problem in others:

* mailnews 3pane
* mail compose
* web page compose
* history manager
* download manager
* addressbook window

Comment 4

[sairuh (rarely reading bugmail)]

items in comment 3 tested on linux so far (2004092206-trunk, fedora core 2)...

Comment 5

[sairuh (rarely reading bugmail)]

also appears to fail in various chrome textfields throughout the app.

Comment 6

[Asa Dotzler [:asa]]

Aaeon, this may be a 1.8a4 blocker. Can you please take a look at this, ASAP?

Comment 7

[Aaron Leventhal]

Asa, this isn't related to the other regressions. It regressed before bug 68841
(accesskey underlining) was checked in. It would be nice if someone more
familiar with Mozilla on Linux or Mac could take a look.

Comment 8

[Kyle Yuan]

Attachment: don't overwrite the mouse event's eventType

no idea about the Mac OS X.

Comment 9

[Kyle Yuan]

Comment on attachment 159828 [details] [diff] [review]
don't overwrite the mouse event's eventType

Only tested on gtk2 build.

Comment 10

[Mitch]

*** Bug 260953 has been marked as a duplicate of this bug. ***

Comment 11

[Kyle Yuan]

Attachment: same thing for mac

Comment 12

[Aaron Leventhal]

Kyle, any idea why it regressed? What checkin changed things?

Comment 13

[Marcia Knous [:marcia]]

Sarah: Asa wants to hunt down a smaller window as to when this might have
happened. I can take a look at the Mac builds since you mentioned there were no
intermediary builds.

Comment 14

[sairuh (rarely reading bugmail)]

(In reply to comment #13)
> Sarah: Asa wants to hunt down a smaller window as to when this might have
> happened. I can take a look at the Mac builds since you mentioned there were no
> intermediary builds.

unless you've got mozilla builds on a machine that are older than 8/25, it might
be difficult. unfortunately, the ftp site
(ftp://ftp.mozilla.org/pub/mozilla.org/mozilla/nightly/) doesn't have any
mozilla builds before 8/25.

is there an older repository elsewhere?

Comment 15

[Kyle Yuan]

(In reply to comment #12)
> Kyle, any idea why it regressed? What checkin changed things?

Assigning a key event type to a mouse event is always wrong. I think this just
gets revealed after someone fixed something.

Comment 16

[Asa Dotzler [:asa]]

archive.mozilla.org has older builds. 

Comment 17

[Christian :Biesinger (don't email me, ping me on IRC)]

maybe bz can help with a regression range...

Comment 18

[Boris Zbarsky [:bzbarsky]]

This broke between 2004-08-20-07 and 2004-08-21-08.  That's the range when bug
238773 (splitting up nsDOMEvent into multiple classes) landed.  ccing people
involved in that bug, since I bet that's what caused this one.

I agree with comment 15, in any case... any way we can change the event classes
to prevent that from being possible?

Comment 19

[Asa Dotzler [:asa]]

So is attachment 159828 [details] [diff] [review] still worth reviewing and landing? Time is short on 1.8a4. 

Comment 20

[Boris Zbarsky [:bzbarsky]]

As far as I can tell, it's the right fix, yes, but this is not exactly my area
of expertise....  And if we want to have context menus usable via keyboard in
1.8a4, then yes it's worth it.  I can land it once bryner reviews.

Comment 21

[Asa Dotzler [:asa]]

Thanks Boris. I'll try to help chase down reviews. 

Comment 22

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 159828 [details] [diff] [review]
don't overwrite the mouse event's eventType

Requesting 1.8a4 approval.

Comment 23

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 159831 [details] [diff] [review]
same thing for mac

Requesting 1.8a4 approval for the mac patch too.  I've checked in the Linux
one.

Comment 24

[Calum Mackay]

*** Bug 260953 has been marked as a duplicate of this bug. ***

Comment 25

[Boris Zbarsky [:bzbarsky]]

Mac fix checked in.  Marking fixed.

Comment 26

[sairuh (rarely reading bugmail)]

with 2004092709-trunk (non-installer, gtk1) on fedora 2, both shift+f10 and the
context menu key work now. either marcia or I will check on Mac once a seamonkey
build comes out.

Comment 27

[Marcia Knous [:marcia]]

Using Mozilla 1.8a4
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a4) Gecko/20040927,
this now works on the Mac - control-spacebar does bring up the context menu.

Comment 28

[sairuh (rarely reading bugmail)]

thanks for checking, Marcia! vrfy'ing as fixed.