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

VERIFIED FIXED in Firefox 28



5 years ago
5 years ago


(Reporter: dholbert, Assigned: masayuki)



Bug Flags:
in-qa-testsuite ?
in-testsuite ?

Firefox Tracking Flags

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


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


(1 attachment)

 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


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.
(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:
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
Created attachment 8336717 [details] [diff] [review]

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.
Attachment #8336717 - Flags: review?(matspal)
Attachment #8336717 - Flags: review?(bugs)
Comment on attachment 8336717 [details] [diff] [review]

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+
status-firefox25: --- → affected
status-firefox26: --- → affected
status-firefox27: --- → affected
status-firefox28: --- → affected
Attachment #8336717 - Flags: review?(bugs) → review+
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28


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. 


Comment 10

5 years ago
(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? (

Comment 12

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


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

Comment 16

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