Closed Bug 628157 Opened 9 years ago Closed 9 years ago

Ctrl+p renders print dialogue but pressing enter will not execute printing, and Tab Key Keyboard Navigation also does not work.

Categories

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

x86
Windows XP
defect
Not set
major

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: hspandey, Assigned: enndeakin)

References

()

Details

(Keywords: regression, ux-control, ux-efficiency, Whiteboard: [hardblocker][has patch])

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b10pre) Gecko/20110123 Firefox/4.0b10pre
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b10pre) Gecko/20110123 Firefox/4.0b10pre ID:20110123030331

Control p gives print dialogue but pressing enter will not execute printing. To execute printing you are required to click OK through mouse navigation.

Reproducible: Always

Steps to Reproduce:
1.Ctrl+p to print (any page any site any file)
2.Print dialogue appears
3.Press enter
Actual Results:  
No response

Expected Results:  
Page printing should be executed

Tried it out on my upgraded profile from 3.6, new beta profile and a freshly created profile result does not change.
Summary: Control p gives print dialogue but pressing enter will not execute printing → Ctrl+p renders print dialogue but pressing enter will not execute printing
Regression window:
Works:
http://hg.mozilla.org/mozilla-central/rev/01fa971e62ee
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100827 Firefox/4.0b5pre ID:20100827190212
Fails:
http://hg.mozilla.org/mozilla-central/rev/0886ad6e6aaa
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b5pre) Gecko/20100827 Firefox/4.0b5pre ID:20100827190555
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=01fa971e62ee&tochange=0886ad6e6aaa

in local build,
build from 7804b5cf4313: fails
build from 687b70fea4d0: works
Blocks: 130078
Status: UNCONFIRMED → NEW
blocking2.0: --- → ?
Ever confirmed: true
Keywords: regression
Version: unspecified → Trunk
Tab Key Keyboard Navigation also does not work.
Summary: Ctrl+p renders print dialogue but pressing enter will not execute printing → Ctrl+p renders print dialogue but pressing enter will not execute printing, and Tab Key Keyboard Navigation also does not work.
Sounds like another case of focus not getting to where it should be.
I can confirm this.  I updated from FF 3.6 to FF 4.0b10 today, and press CTRL-P for print, but the keyboard has no access to any of the functions of the print dialogue, e.g the various underlined links to be accessed by the ALT key, Cancel to be accessed by Esc, Print to be accessed by Enter.  Yet the dialog has a blue header as if it was the active window.

I'm in Windows 7 Home.
Mozilla/5.0 (Windows NT 5.1; rv:2.0b11pre) Gecko/20110129 Firefox/4.0b11pre ID:20110129030338

I can verify. The OK button looks like it has focus, but the Enter key won't initiate printing.
Hard blocker for a11y issues.
blocking2.0: ? → final+
Whiteboard: [hardblocker]
Neil, can you take this on the assumption that it's a focus issue?
Assignee: nobody → enndeakin
>uiwanted

this one is pretty easy :) pressing enter should indeed successfully act on the control that visually displays that it has the focus (in this case print).
Attached patch fix (obsolete) — Splinter Review
The documentation for WM_INITDIALOG says that true should be returned for focus to be set.
Attachment #509435 - Flags: review?(jmathies)
Might as well return true from this other usage of WM_INITDIALOG in the same file.
Attachment #509435 - Attachment is obsolete: true
Attachment #509505 - Flags: review?(jmathies)
Attachment #509435 - Flags: review?(jmathies)
Whiteboard: [hardblocker] → [hardblocker][has patch]
Status: NEW → ASSIGNED
Attachment #509505 - Flags: review?(jmathies) → review+
http://hg.mozilla.org/mozilla-central/rev/bf732d3308db
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Keywords: helpwanted
Resolution: --- → FIXED
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.