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.

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

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.

Neil, can you take this on the assumption that it's a focus issue?

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

The documentation for WM_INITDIALOG says that true should be returned for focus to be set.

Might as well return true from this other usage of WM_INITDIALOG in the same file.