Print preview Alt+C doesn't activate "close" button anymore (& similar for other print preview UI with alt-keys)

VERIFIED FIXED in Firefox 28

Status

()

Core
Print Preview
VERIFIED FIXED
5 years ago
5 years ago

People

(Reporter: dholbert, Assigned: masayuki)

Tracking

({regression})

Trunk
mozilla28
regression
Points:
---
Bug Flags:
in-qa-testsuite ?
in-testsuite ?

Firefox Tracking Flags

(firefox25 affected, firefox26 affected, firefox27 affected, firefox28 verified)

Details

(Whiteboard: [good first verify] [bugday-20140108])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
STR:
 1. View about:blank
 2. File | Print Preview
 3. Alt+c to activate "Close" button. (or Alt+p, Alt+u, etc, to activate other UI)

ACTUAL RESULTS: Nothing happens.
EXPECTED RESULT: Close button (or whatever you chose) should be activated.

From a local mozregression run, it appears this regressed a few months ago:
{
Last good nightly: 2013-07-25
First bad nightly: 2013-07-26

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=a4c1961bf723&tochange=46d73e889cb4
}

There isn't anything print-related in that pushlog, but Masayuki landed a bunch of keypress handling stuff for bug 501496 that day -- that seems like the most likely related thing, at first glance.
(Reporter)

Comment 1

5 years ago
(This isn't about:blank specific, of course; I just chose that as a trivial testcase)
I can reproduce this bug on Win8.1 too. I guess that print preview consumes keydown event before ESM handles accesskey if bug 501496 is the actual cause.
OS: Linux → All
Keywords: regression
Looks like this consumed all keydown events while Alt key is pressed:
http://mxr.mozilla.org/mozilla-central/source/layout/printing/nsPrintPreviewListener.cpp
(Reporter)

Updated

5 years ago
Hardware: x86_64 → All
Access key is handled by ESM::PreHandleEvent() with keypress event without checking defaultPrevented value.

Therefore, before bug 501496, even if keydown event is consumed by content, following keypress event worked as modifier key. This means that such key event may have caused "double action".

Anyway, we need to kill only the event propagation of keydown events of printable keys. But looks like nsPrintPreviewListener approach looks hacky to me. I believe that it should be killed by PresShell level but such change is really risky and too big change.
Assignee: nobody → masayuki
Status: NEW → ASSIGNED
Created attachment 8336717 [details] [diff] [review]
Patch

nsPrintPreviewListener shouldn't consume keydown event because it kills following keypress event. Instead, it should just stop propagation of keydown event both in default event group and system event group.

https://tbpl.mozilla.org/?tree=Try&usebuildbot=1&rev=4101d7df065a
Attachment #8336717 - Flags: review?(matspal)
Attachment #8336717 - Flags: review?(bugs)
Comment on attachment 8336717 [details] [diff] [review]
Patch

The code changes looks fine to me, so r=mats if Olli thinks this is the
right fix from an event handling point of view.
Attachment #8336717 - Flags: review?(matspal) → review+
(Reporter)

Updated

5 years ago
status-firefox25: --- → affected
status-firefox26: --- → affected
status-firefox27: --- → affected
status-firefox28: --- → affected

Updated

5 years ago
Attachment #8336717 - Flags: review?(bugs) → review+
https://hg.mozilla.org/mozilla-central/rev/f73da8ab5911
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28

Updated

5 years ago
status-firefox28: affected → fixed
Flags: in-testsuite?
Flags: in-qa-testsuite?
Whiteboard: [good first verify]

Comment 9

5 years ago
Check on Firefox Nightly 29. The fix works for me. 

[bugday-20120108]

Comment 10

5 years ago
[bugday-20140108]
(In reply to AShickur Rahman from comment #9)
> Check on Firefox Nightly 29. The fix works for me. 

Would you mind checking the latest Aurora build? (http://aurora.mozilla.org)

Comment 12

5 years ago
Checked on Aurora build 28.0a2 (2014-01-08), linux x86_64. Fix works for me.

Updated

5 years ago
Whiteboard: [good first verify] → [good first verify] [bugday-20140108]

Comment 13

5 years ago
Works fine in latest aurora 28.0a2 (2014-01-21), Win7 x32

Comment 14

5 years ago
work fine in Nightly build 29.0a1 (2014-01-21), Win 7 x64

Comment 15

5 years ago
[bugday-20140120]

Comment 16

5 years ago
[bugday-20140122] - works fine in Latest aurora and Nightly build - Win 7 x64
Status: RESOLVED → VERIFIED
status-firefox28: fixed → verified
You need to log in before you can comment on or make changes to this bug.