Closed Bug 626403 Opened 9 years ago Closed 9 years ago

Scroll wheel stops working after pressing no on 'Do you wish to add a printer?' prompt


(Core :: Widget: Win32, defect)

Windows 7
Not set



Tracking Status
blocking2.0 --- -


(Reporter: emorley, Assigned: enndeakin)



(Keywords: regression)


(2 files)

Breaking out from bug 619330 comment 10.

The mouse scroll wheel stops working after the user clicks 'no' on the 'No printers installed, do you wish to add a printer?' yes/no prompt. Note: the prompt is still of the old window-modal style.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b10pre) Gecko/20110116 Firefox/4.0b10pre ID:20110116030325

1) Make sure no printers added in printers control panel (including print to file or similar)
2) Launch Firefox/Minefield with clean profile
3) Press ctrl+P 
4) Click 'no' on the subsequent "No printers detected, do you wish to add one?" prompt. (See screenshot for prompt shown)

- After clicking 'no', the prompt disappears and scrolling the current page with the mouse wheel works as before.

- Prompt disappears but scroll wheel doesn't work until you switch to another tab and back again - or Firefox is minimised and restored.

Works fine in 3.6.13, so regression in Firefox 4.

Regression range...

Last good nightly: 2010-08-27 
First bad nightly: 2010-08-28

...there are a lot of items in there - so might need bisection using try builds - unless someone can see something obvious.

NB: Due to an unrelated regression (see bug 619330) ctrl+P does not work if no printers are installed, if you use builds between 2010-12-04 and approx 2011-01-15. So the steps in this bug only apply to builds outside of this range.
blocking2.0: --- → ?
Forgot to mention:

- Not sure if this affects any other remaining window-modal prompts or not (I can't for the life of me remember what things are still window-modal, but I know there are still a few of them left).

- XUL might not be the correct component, can someone move if necessary.

In local build
Build from 7804b5cf4313 : fails
Build from 687b70fea4d0 : works
Suspected bug:
7804b5cf4313	Robert O'Callahan — Bug 130078. Part 2. Remove widgets from all subframes. r=dbaron
Blocks: 130078
Thanks for the reduced range :-)

(Out of interest, how did you build those so fast or do you just have hourlies cached?)
(In reply to comment #3)
> Thanks for the reduced range :-)
> (Out of interest, how did you build those so fast or do you just have hourlies
> cached?)
I cached  m-c hourly(not all) and my local build in local HDD.
Also, the "X" in the title bar of the printer prompt is greyed out / pressing escape doesn't work (see screenshot). Unlike the main issue in this bug, it happens in 3.6 and even as far back as 2007-01-01 (that's as far back as I tried). Is it expected behaviour or should I log (obviously separately)?
What happens if you click somewhere inside the current tab (maybe restoring focus to it), does the mouse wheel work then?
If I click inside the page area, scrolling still doesn't work. Same for clicking the current tab title and then back to page content area.

However, if I give the address bar focus and then back to the page content area, scrolling works again. Or if I navigate to another page by clicking on a link in the page content area, scrolling works fine again as well.
Sounds like focus isn't getting restored properly after the dialog is dismissed.
Assignee: nobody → enndeakin
blocking2.0: ? → -
Component: XUL → Event Handling
QA Contact: xptoolkit.widgets → events
The messages being received by the window when ::PrintDlgW is called are:

Press Ctrl+P
  WM_ACTIVATE (deactivate)
- Dialog appears and click on No
  WM_ACTIVATE (activate)
- PrintDlgW returns

So Windows is setting then killing the focus on the window again.
Component: Event Handling → Widget: Win32
QA Contact: events → win32
Attached patch workaround patchSplinter Review
I tried this with the PD_NOWARNING flag (which disables the no printers warning) and it still doesn't work.

Windows seems to be trying to open the regular print dialog, unfocusing the browser window, doing only the initialization of the print dialog but never showing it, but then never refocusing the browser window again.

More detailed order of messages:

- PrintDlgW() gets called
- WM_KILLFOCUS message
- some ime messages
- WM_ENABLE (disable browser window)
- a WM_SETFONT, WM_NOTIFYFORMAT and WM_QUERYUISTATE bunch of messages sent to the print dialog (received via nsPrintDialogUtil.cpp:PrintHookProc)
- WM_ENABLE (enable browser window again)
- PrintDlgW() returns

This patch just focused the dialog if PrintDlg returns false.

I tested some other applications and most newer ones show the regular print dialog and the warning at the same time. This can be done by enabling the disabled block of code which calls PrintDlgEx. This also fixes the issue, but isn't a suitable change for now.
Attachment #509521 - Flags: review?(jmathies)
Comment on attachment 509521 [details] [diff] [review]
workaround patch

Doesn't seem to interfere with anything after playing with it for a while. r+ from me.
Attachment #509521 - Flags: review?(jmathies) → review+
Attachment #509521 - Flags: approval2.0?
Closed: 9 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.