Alexander Moore Reporter
	Description • 16 years ago

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_2; en-us) AppleWebKit/525.13 (KHTML, like Gecko) Version/3.1 Safari/525.13
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9b5) Gecko/2008032619 Firefox/3.0b5

If you open http://www.wired.com/print/science/discoveries/magazine/16-03/ff_seacowboys,
the page will partially load, show a print dialog, then resume loading.  

When it resumes loading you will get an Alert dialog that says "The document cannot change while Printing or in Print Preview."

The Print Dialog at this point will have focus and can be moved around the screen, but all of it's widgets and the rest of Firefox will be frozen and will not respond to interaction. Firefox will take up all available processor utilization at this point.

Reproducible: Always

Steps to Reproduce:
1.Open http://www.wired.com/print/science/discoveries/magazine/16-03/ff_seacowboys
2. Print Dialog will appear after some of the page is loaded
3. Rest of page will load
4. Alert dialog will appear saying "The document cannot change while Printing or in Print Preview."
5. Print dialog will have focus and will be able to be moved around, but rest of application will be non-responsive / locked up at this point, Firefox will use up all available cpu time.
Actual Results:  
Application locks up after Alert dialog appears. Cpu utilization maxed out.

Expected Results:  
Canceled the print dialog and alerted me about the changing page.
OR
Showed the alert as it does now, but also made sure the alert has focus / priority over print dialog.

Only addon being used was No-script, was testing with global scripts turned on though.

	Bob Uliss
	Comment 1 • 16 years ago

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.5; en-US; rv:1.9pre) Gecko/2008042204 Minefield/3.0pre


Can not duplicate
This problem appears be fixed in this release

Without this Addon - do not see the problem.
with NoScript v1.6 add on installed - you get a yellow Warning bar appearing on the bottom on the FF window - Scripts partially allowed ...

 -  I changed the NoScripts preferences to allow top level sites one time - reloaded the site and now got the print dialog but FF continues to work OK after pressing the Cancel Button on the Print Dialog box.

Please provide more information. Exact settings - what global scripts are you referring to?

	Tomasz
	Comment 2 • 16 years ago

I am now seeing the same issue with 3.1 and 3.03 on OS X. 

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081001 Minefield/3.1b1pre

The same lockup occurs with the dialog boxes mentioned when trying to print and follows with the spinning beach ball of death. 

What was missing from the initial report is that the underlying page must do a reload while the print dialog is open. For instance 

1) Load http://tomasz.ods.org/sandbox/refresh.html 
2) Open a print dialog and wait
3) Spinning beach ball of death should show up when  "The document cannot change while Printing
or in Print Preview" is displayed

	Tony Chung [:tchung]
	Comment 3 • 16 years ago

(In reply to comment #2)
> I am now seeing the same issue with 3.1 and 3.03 on OS X. 
> 
> Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre)
> Gecko/20081001 Minefield/3.1b1pre
> 
> The same lockup occurs with the dialog boxes mentioned when trying to print and
> follows with the spinning beach ball of death. 
> 
> What was missing from the initial report is that the underlying page must do a
> reload while the print dialog is open. For instance 
> 
> 1) Load http://tomasz.ods.org/sandbox/refresh.html 
> 2) Open a print dialog and wait
> 3) Spinning beach ball of death should show up when  "The document cannot
> change while Printing
> or in Print Preview" is displayed

Confirming the bug from the steps here.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081003 Minefield/3.1b1pre

	Daniel Holbert [:dholbert]
	Comment 4 • 16 years ago

Here's a testcase based on the URL in comment 2, with the print dialog now spawned automatically.

FWIW: I can't reproduce this bug on Linux using today's nightly.  I do get the "The document cannot change while Printing or in Print Preview" alert, but it's got focus, so I can click "OK" and dismiss it.  Also, I don't get any excessive CPU usage.

	Tomasz
	Comment 5 • 16 years ago

Using the new test case I see the same thing happen. Time line plays out just like before, the the browser is hung and cpu starts spinning.

	Daniel Holbert [:dholbert]
	Comment 6 • 16 years ago

So, in both Windows and Linux, we correctly steal focus for the "Document cannot change" message, so the user can click it away.

But on Mac, it sounds like we get confused & end up hanging when that dialog tries to get focus.

This sounds basically like a focus-handling issue on Mac -- moving to Widget: Mac, CC'ing some mac guys, and flagging as blocking1.9.1?

	Tomasz
	Comment 7 • 16 years ago

imagine the spinning beach of death being in the image as well as screen grab does not show it.

	Tomasz
	Comment 8 • 16 years ago

Added screen shot of hang. The spinning beach ball is camera shy and you will just have to imagine it being there.

Interestingly this time the "Print" button disappeared. My initial test was with 3.1b1 9/29 nightly build while today's testing is with the 10/3 nightly.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b1pre) Gecko/20081003 Minefield/3.1b1pre

	Marcia Knous [:marcia]
	Comment 9 • 16 years ago

Confirming this happens on the branch as well, using Firefox 3.0.3 Adding nom flag for 1.9.0.4.

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 10 • 16 years ago

I can't reproduce this -- the page never finishes loading (and so the
"alert dialog" from step 4 never appears).

But the problem sounds an awful lot like that of bug 442442 -- which
I'm currently working on, and am close to having a patch for.

	Daniel Holbert [:dholbert]
	Comment 11 • 16 years ago

Steven: Were you trying to reproduce it using the attached testcase?  (I know that the Wired URL for this bug never finishes loading, but I'd thought the testcase did.)

In any case, the steps in Comment 2 (which requires manually opening the print dialog after pageload) should still reproduce it.

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 12 • 16 years ago

Thanks, Marcia.

I was trying the Wired URL.  Just now I've tried the testcase
(attachment 341668 [details]), and found that this bug _is_ a dup of bug 442442,
and the patch I'm working on _does_ fix it.

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 13 • 16 years ago

Marcia, try my tryserver patch at

https://build.mozilla.org/tryserver-builds/2008-10-03_13:33-smichaud@pobox.com-bugzilla436473/smichaud@pobox.com-bugzilla436473-firefox-try-mac.dmg

It's not the final version, but it's very close.

Let me know your results.

	Tomasz
	Comment 14 • 16 years ago

Patched version allows me to cancel the print job and then acknowledge the warning. No hang and subsequent CPU spin.

I'm guessing were opting for that work flow rather then acknowledging the warning while IN the print dialog ?

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 15 • 16 years ago

I've posted a patch at bug 436473 and another tryserver build:

https://build.mozilla.org/tryserver-builds/2008-10-03_16:46-smichaud@pobox.com-bugzilla436473/smichaud@pobox.com-bugzilla436473-firefox-try-mac.dmg

	Steven Michaud [:smichaud] (Retired) Assignee
	Comment 16 • 16 years ago

(In reply to comment #14)

> I'm guessing were opting for that work flow rather then
> acknowledging the warning while IN the print dialog?

I didn't "opt for" this ... we have no choice in the matter :-)

The problem is that the two different modal dialogs (the Print dialog
and the alert) are two different kinds of modal dialogs, from two
different sources, which are very difficult to make work together.

The Print dialog is an app-modal Cocoa dialog provided by the OS (its
event loop is run by the OS).  The alert is window-modal (or
"doc-modal") dialog (also known as a "sheet") provided by Gecko
(though the "sheet" is also provided by the OS, it's Gecko that runs
its event loop).

Once the Print dialog is running, no keyboard or mouse events can
(basically) be allowed to go to other windows.  If they did, one could
break out of the Print dialog, which would cause other problems.

Ideally Gecko (or Cocoa widgets) would recognize that an app-modal
dialog (the Print dialog) was already open, and the alert would open
as another app-modal dialog above the Print dialog.  But Gecko's
implementation of modality wasn't designed with Cocoa widgets in mind,
and as a result Gecko has no (explicit) support for app-modal dialogs.

I hope we can work towards this kind of solution.  But it will require
design changes in both Gecko and Cocoa widgets.  This can't happen
without the involvement of people both inside and outside of Gecko
widgets, and will (needless to say) take time.  It's not something
that can (realistically) be expected in a a 1.9.0.X or 1.9.1 release.

	Marcia Knous [:marcia]
	Comment 17 • 16 years ago

The tryserver build Steven posted in Comment 15 does eliminate the hanging issue for me.