Closed Bug 718542 Opened 12 years ago Closed 8 years ago

printing leads to "force quit" condition

Categories

(Firefox :: Untriaged, defect)

Product:
Firefox
Component:
Untriaged
Version:
11 Branch
Platform:
x86
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox11 - ---
firefox12 - ---
firefox13 - ---

People

(Reporter: hwine, Assigned: smichaud)

References

Details

Attachments

(1 file)

Stack of dialogs with alert sheet underneath
(deleted), image/png
Details
Attached image Stack of dialogs with alert sheet underneath (deleted) — 
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:9.0.1) Gecko/20100101 Firefox/9.0.1
Build ID: 20111220165912

Steps to reproduce:

Called up print dialog -> "save as pdf" -> file save dialog box, and waited


Actual results:

alert sheet in for "unresponsive script" came up behind all the modal dialog boxes. Could not move the modal dialogs to select or activate buttons in alert sheet. Dialog boxes no longer response to continue, cancel, or complete printing operation. No menu elements were accessible, either.

Only way to close the application was to force quit firefox. This occurred in both Aurora builds 11.0a2 (2012-01-08) & 11.0a2 (2012-01-16) and Nightly builds 12.0a1 (2012-01-13) & 12.0a1 (2012-01-16)

It did not happen my beta build (whew).


Expected results:

I should have had some way to dismiss either the stack of modal dialogs and/or the alert sheet.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
I disagree this is a duplicate. It is a regression in Aurora (v11) & Nightly (v12).

This bug does not appear as described in either v9 (release) or f10 (beta)
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
>I should have had some way to dismiss either the stack of modal dialogs and/or the alert sheet.

That expected result is a dupe of bug 476541.
Xou can hang v9 if you have a modal window (print or file save as) and a page that triggers for example the slow script warning at the same time.

Or is it about the slow script warning itself ?
Likely it is because I am not being clear enough. I am seeing a change in behavior between 10. & 11. for this specific case:
 start in new empty browser window & tab without any user scripts
 print that empty window
 FF 9 & 10 - no problem <= implies this isn't bug 476541
 FF 11 & 12 - hang as described.

It's the regression that is of concern to me. (I see no reports of bug 476541 occurring in 9. Perhaps the original underlying bug was fixed by some other change, and bug 476541 s/b closed as fixed in 9.) I agree that if the behavior was observable in 9 & 10, this would be a duplicate of bug 476541.

I hope that clarifies. I am not familiar with the FF procedures for regression handling, so I'll defer to your experience.
Summary: printing leads to "force quit" condition → Regression: printing leads to "force quit" condition
Blocks: 729328
Applicable info from https://bugzilla.mozilla.org/show_bug.cgi?id=729624#c0

>  b) start paying bills, and want to save an interim page as a PDF for
> reference. Bring up Print dialog -> save as pdf -> navigate folders to home
> server -> start typing name & BAM- FF hang requiring force quite in the
> middle of my banking transaction!!!!!!! (Obviously, I find this unacceptable)
> 
> The underlying faulty behavior can be observed in a freshly started "safe
> mode" instance of the FF11:
>  - Print hang: choose "Print..." from the "File" menu on the initial page,
> and leave the system dialog on the screen for a while. The unresponsive
> script dialog will come up after a bit. Prior filed as bug 718542 (and
> almost lost by duplication to bug 476541 <- opened 3 years ago)
Same as https://bugzilla.mozilla.org/show_bug.cgi?id=729328#c4

> Steven - would you be the right person to look at bug 729328 along with bug
> 718542?
> 
> Adding qawanted to get a better idea of the affected platforms/OS versions,
> whether this is a recent regression, and how long you have to wait at the
> prompt before getting a hang. This may be an unusual enough use case that we
> won't take the additional risk in Beta 5 or 6.

but keeping the two bugs separate since it's not yet clear they have the same root cause.
Assignee: nobody → smichaud
Keywords: qawanted
I can't seem to reproduce this on Windows 7 or Ubuntu 11.10 64-bit using Firefox 11.0b3. Unfortunately, I am unable to test this on Mac as I don't have access right now. Maybe Juan can help here.
Matthias is right -- the underlying bug here is bug 476541.

At least partly for political reasons, bug 476541 is going to be very
difficult to fix.  The main reason is that we've tried to impose a
Windows-and-Unix-like design for modal windows on OS X, despite the
fact that this design doesn't work properly there.  I go into much
greater detail about this at bug 478073.

In the past I've tried to hack around these difficulties, starting at
bug 395465.  But this is very tricky work, and I was never allowed to
finish it (see bug 468393).  I'm now convinced that we need to back
out my hacks, and accept that modal dialogs work differently on OS X.

More specifically, we need to change how showModalDialog is
implemented on OS X.  We could make it display a sheet or a tab-modal
dialog.  Or if we leave it a window we'd need to make it app-modal.
But it will be difficult to get consensus on these questions from the
powers that be.

However, it may also be possible to work around bug 476541 by
converting all our system modal dialogs (the file picker and the print
dialogs) to sheets instead of windows.  I'll open a new bug on this
and make it a high priority (just after topcrashers).
This and bug 729328 seem to be the same problem. In my case, on Mac OS X in Fx11b3, I only have to have the print dialog open and once the unresponsive script warning comes up, within a couple of minutes of being open, you can't cancel or print your way out of it. At that point you need to force quit.
I was able to reproduce this once on Firefox trunk on MacOSX10.5 too.

It seems like comment 8 indicates that the cause is known. Can the qawanted keyword be removed?
(Following up comment #8)

See bug 729720.
IS the main regression reported here now fixed with bug 720289 ?
Depends on: 720289
(In reply to Matthias Versen (Matti) from comment #12)
> IS the main regression reported here now fixed with bug 720289 ?

I'd like to know our feel on this as well. One way to find out will be to test the tinderbox build that's created once bug 720289 lands on beta (hopefully today). Anthony/Juan - can you help with that?
According to bug 720289 comment 10 this already landed on Beta. When/where will TB builds be available to test?
(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #14)
> According to bug 720289 comment 10 this already landed on Beta. When/where
> will TB builds be available to test?

We can use the latest mozilla-beta build at https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-beta-macosx64/1330168239/firefox-11.0.en-US.mac.dmg
Just tried this on Mac OSX 10.6 and I cannot reproduce the original issue. Someone that can reproduce it please try the build in comment 15.

Steps:
1) Open this page
2) Firefox > Print
3) PDF > Save As PDF
4) Leave the "Save" dialog open and do nothing for 5 minutes
I tried the build from comment #15 on Mac OS X 10.7.2 following the steps in comment #16 and I am still able to see the problem. I leave the Save As dialog open for a while, and then I get the unresponsive script dialog, and after that I am not able to cancel or ok the dialog and I have to force quit.
(In reply to juan becerra [:juanb] from comment #17)
> I tried the build from comment #15 on Mac OS X 10.7.2 following the steps in
> comment #16 and I am still able to see the problem. I leave the Save As
> dialog open for a while, and then I get the unresponsive script dialog, and
> after that I am not able to cancel or ok the dialog and I have to force quit.

Thanks Juan. Does this bug go as far back as with the comment in https://bugzilla.mozilla.org/show_bug.cgi?id=729328#c20?
Keywords: regressionwindow-wanted
(In reply to Alex Keybl [:akeybl] from comment #18)
> ...
> Thanks Juan. Does this bug go as far back as with the comment in
> https://bugzilla.mozilla.org/show_bug.cgi?id=729328#c20?

This also goes as far back as Fx5.0.1 (I haven't tried even older builds).
(In reply to juan becerra [:juanb] from comment #19)
> (In reply to Alex Keybl [:akeybl] from comment #18)
> > ...
> > Thanks Juan. Does this bug go as far back as with the comment in
> > https://bugzilla.mozilla.org/show_bug.cgi?id=729328#c20?
> 
> This also goes as far back as Fx5.0.1 (I haven't tried even older builds).

Thanks - in that case, untracking for FF11.
tracking-firefox11: + → -
Keywords: qawanted, regressionwindow-wanted
For the real world use case cited in bug 729624 (possible loss of financial data), this feels pretty major. Can we commit to this for 12?
tracking-firefox12: --- → ?
Summary: Regression: printing leads to "force quit" condition → printing leads to "force quit" condition
Hal, Steven summarizes the difficulty with fixing this longstanding bug in comment #12 and with Firefox 12 already on Aurora I don't think it is even safe to try to get this for Firefox 13 which will be on Aurora twelve days from now much less Firefox 12.
Robert - when to fix this is a business decision - if 12 isn't the correct release to commit, then what is? I'm open to a different commit.

Now that this is shown to not be a regression, it could (should?) be closed as a duplicate of bug 476541 (see comment #1) - which has been open and unresolved since Feb 2009 - 3 years!
Hal, it is to say the least difficult to commit to a release vehicle for this without knowing what it will take to fix it as well as not knowing what the (potential) regressions caused by fixing it will be. So no, I am not willing to give a commit to when this will be fixed. Also, as can be seen by how long bug 476541 has been open, this bug hasn't been such a major issue as to cause us to not ship a previous release.

What is being done:
I have discussed our options to get this bug fixed with Steven on two separate occassions. There is still not a clear path forward but we are close to having one.
I am trying to get another Mac OS X developer on board so Steven isn't always tapped to take this bug on (keep in mind there are crasher bugs he has been working on that Mac OS X users do complain about often).

We will decide whether to duplicate this bug to bug 476541 after we have a clear path forward.
I've got a patch and tryserver build at bug 729720 that may fix these hangs.  See bug 729720 comment #11.

Whoever can still reproduce this bug's hangs in current trunk nightlies, please try it out and let us know your results.  I'm particularly interested in hearing from Juan Becerra.
Woot! Progress! I have not yet been able to repro either print or open file hangs. Details in bug 729720 comment #16
tracking-firefox13: --- → ?
We should not track for a specific release - this is an old regression. Tracking is meant for recently critical issues or new regressions.
tracking-firefox13: ? → -
I didn't managed to reproduce this issue on the latest release(43.0.4) nor the latest Nightly(46.0a1).

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:43.0) Gecko/20100101 Firefox/43.0
Build ID: 20160105164030

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID: 20160113030208

Can you please try to reproduce this on the latest release(43.0.4) and latest Nightly(46.0a1) and provide the results?
When doing this, you could create a new clean Firefox profile, or maybe test in safe mode, as some of this issues may be caused by third party installed addons or custom settings
(https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems).

Thank you,
Vlad
Flags: needinfo?(hwine)
Could not repo in either 43.0.4 or 44.0b8 (which I had already)

Let's call this one done!
Flags: needinfo?(hwine)
Due to the fact that I cannot reproduce the issue and also the reporter cannot reproduce it, I will mark this issue as RESOLVED - WFM.
Status: REOPENED → RESOLVED
Closed: 12 years ago → 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: