729328 - FF hangs using "Open File..." command

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Hal Wine [:hwine] use NI!]

I do not see this behavior in 10.0.2, hence "regression".

With some combination of extensions, including "Ad Block" and Mozilla supplied ones, FF can become hung, requiring a force reset (and possible loss of data).

While these hangs are the "unresponsive script" alert behind a modal dialog, they do NOT appear in FF 9 or 10. And, in some cases the "unresponsive script" display is delayed until just after the open file dialog is dismissed.

Note that all tests are done with only one window, and 3 tabs, immediately after restarting browser.

I've had a coworker try on his mac, and he got the same behavior - I believe the only extension we have in common is Adblock Plus.

FAILED means Firefox hung, and had to use force quit
Pass means Firefox did not hang.

Enabled extensions are reported as the value of extensions.enabledAddons in about:config

Starts with my full sweet of extensions, then pared down to just Mozilla created extensions, then added back.

[e-mail]:1.0.3,[e-mail]:2.7.1,[e-mail]:1.1.3,[e-mail]:0.11,[e-mail]:2.3,[e-mail]:1.2,[e-mail]:3.3,{5384767E-00D9-40E9-B72F-9CC39D655D6F}:1.4.1.1,{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}:0.9.88,{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}:2.0.3,[e-mail]:3.5.2,[e-mail]:3.0.3,{972ce4c6-7e08-4474-a285-3208198ce6fd}:11.0

^^ FAILED

[e-mail]:1.0.3,[e-mail]:1.2,{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}:0.9.88,{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}:2.0.3,{972ce4c6-7e08-4474-a285-3208198ce6fd}:11.0

^^ FAILED

[e-mail]:1.0.3,[e-mail]:1.2,{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}:0.9.88,{972ce4c6-7e08-4474-a285-3208198ce6fd}:11.0

^^ Pass - one unresponsive script dialog just after open dialog closed, but could not recreate. Difference is lack of AdBlock :(

[e-mail]:1.0.3,[e-mail]:1.2,{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}:0.9.88,{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}:2.0.3,{972ce4c6-7e08-4474-a285-3208198ce6fd}:11.0

^^ Pass - did get one unresponsive script dialog after cancel open dialog.

[e-mail]:1.0.3,[e-mail]:1.2,{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}:0.9.88,{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}:2.0.3,[e-mail]:1.3.7

^^ Pass - one unresponsive script. Activated lavafox v1-green 1.3.7, and got one unresponsive script after open dialog

[e-mail]:1.0.3,[e-mail]:1.1.3,[e-mail]:1.2,{59c81df5-4b7a-477b-912d-4e0fdf64e5f2}:0.9.88,{d10d0bf8-f5b5-c8b4-a8b2-2b9879e08c5d}:2.0.3,[e-mail]:1.3.7

^^ FAILED

Comment 1

[Aki Sasaki (not active)]

I'm able to reproduce this with OSX Nightly 13.0a1 2012-02-20, with an empty profile (no addons).

Comment 2

[Hal Wine [:hwine] use NI!]

Aki had a much nicer approach - also fails for Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0) Gecko/20100101 Firefox/11.0

Open in safe mode, then bring up "Open File" dialog, then wait. It will hang (I went for coffee - so within 15-20 minutes)

Comment 3

[Alex Keybl [:akeybl]]

Applicable info from https://bugzilla.mozilla.org/show_bug.cgi?id=729624#c0

> Two real world use cases that trigger this behavior:
>  a) Want to show s.o. a web page I'm working on; After I get the open file
> dialog, I get interrupted to stir the spaghetti, then eat dinner. Return to
> find FF hung requiring force quit (and loss of any unsaved work I may have
> had anywhere).
> 
> The underlying faulty behavior can be observed in a freshly started "safe
> mode" instance of the FF11:
> 
>  - File open hang: choose "Open File..." from the "File" menu, and leave the
> system dialog up for a bit. (You may find that you need to move the system
> dialog box on the screen to get the unresponsive script dialog.) Prior
> filing as bug 729328 (but before I realized it could be done without
> extensions).
> 
> One ray of good news - there are two user paths to the system file open
> dialog - I can only get the one above to fail, so maybe the other one's
> implementation can be instructive. The second path is: hide the navigation
> toolbar; then choose "Open Location..." from the "File" menu. That pops up a
> scriptlet entry box which has a  "Choose File..." button. Clicking that
> button leads to the same system get file dialog, but I could not get that
> path to hang.

Comment 4

[Alex Keybl [:akeybl]]

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.

Comment 5

[u279076]

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.

Comment 6

[Steven Michaud [:smichaud] (Retired)]

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

Comment 7

[juan becerra [:juanb]]

Attachment: unresponsive script warning while Open File

I tried Fx11b3 on Mac OS X and within a couple of minutes I wasn't able to Cancel away the Open File dialog.

You can also see an unresponsive script warning in Firefox. Even if you pick an item in the open file dialog, you cannot open it nor cancel.

"Script: resource:///modules/NetworkPrioritizer.jsm:175"

Comment 8

[Steven Michaud [:smichaud] (Retired)]

(Following up comment #6)

See bug 729720.

Comment 9

[Alex Keybl [:akeybl]]

I also came across bug 720289 in triage. Dupe or coincidence?

Comment 10

[Steven Michaud [:smichaud] (Retired)]

> I also came across bug 720289 in triage. Dupe or coincidence?

Not a dup, but related (and not just a cooincidence).

Without bug 720289, this bug would happen less often.  But this bug can be triggered in other ways than by an unresponsive script dialog.  I've also seen it happen with an update dialog.

Comment 11

[Justin Dolske [:Dolske]]

Did something change between 9 and 10 that makes this an easier thing to hit? Sounds like comment 0 is saying everything is a-ok on 9, whereas comment 6 says this is a long-standing problem.

Comment 12

[Alex Keybl [:akeybl]]

(In reply to Steven Michaud from comment #10)
> Without bug 720289, this bug would happen less often.  But this bug can be
> triggered in other ways than by an unresponsive script dialog.  I've also
> seen it happen with an update dialog.

To confirm that this happens less frequently after landing bug 720289, let's test  the tinderbox build that's created once bug 720289 lands on beta (hopefully today).

Comment 13

[Hal Wine [:hwine] use NI!]

This issue (open file hang) still occurs for me in the on-change build for the commit https://bugzilla.mozilla.org/show_bug.cgi?id=720289#c7

Comment 14

[u279076]

(In reply to Alex Keybl [:akeybl] from comment #12)
> To confirm that this happens less frequently after landing bug 720289, let's
> test  the tinderbox build that's created once bug 720289 lands on beta
> (hopefully today).

Looks like it did a few minutes ago. Where can I find builds?

Comment 15

[Alex Keybl [:akeybl]]

(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #14)
> (In reply to Alex Keybl [:akeybl] from comment #12)
> > To confirm that this happens less frequently after landing bug 720289, let's
> > test  the tinderbox build that's created once bug 720289 lands on beta
> > (hopefully today).
> 
> Looks like it did a few minutes ago. Where can I find builds?

The FTP server seems to be running super slow right now (so I can't find the exact path), but it should be the most recent folder under

ftp://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-beta-macosx/

in a couple of hours.

(In reply to Hal Wine [:hwine] from comment #13)
> This issue (open file hang) still occurs for me in the on-change build for
> the commit https://bugzilla.mozilla.org/show_bug.cgi?id=720289#c7

Given this, I don't believe we have a full understanding of the problem yet. To answer https://bugzilla.mozilla.org/show_bug.cgi?id=729328#c11, adding the regressionwindow-wanted keyword.

Comment 16

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #13)

Does an unresponsive script dialog open behind the File : Open filepicker?  Or is it some other kind of dialog?

Comment 17

[Hal Wine [:hwine] use NI!]

(In reply to Steven Michaud from comment #16)
> (In reply to comment #13)
> 
> Does an unresponsive script dialog open behind the File : Open filepicker? 
> Or is it some other kind of dialog?

Yes, I still get unresponsive script dialog - perhaps referencing a different script this time: resource:///modules/NetworkPrioritizer.jsm:175

Comment 18

[Steven Michaud [:smichaud] (Retired)]

(In reply to comment #17)

So it's possible that bug 720289 hasn't actually been fixed.

Comment 19

[Hal Wine [:hwine] use NI!]

(In reply to Steven Michaud from comment #18)
> (In reply to comment #17)
> 
> So it's possible that bug 720289 hasn't actually been fixed.

Or that bug 720289 was only the root cause for bug 718542, but not this bug. I can no longer repro the print problem

Comment 20

[juan becerra [:juanb]]

(In reply to Justin Dolske [:Dolske] from comment #11)
> Did something change between 9 and 10 that makes this an easier thing to
> hit? Sounds like comment 0 is saying everything is a-ok on 9, whereas
> comment 6 says this is a long-standing problem.

I've tried this on Fx 5.0.1, 7.0.1, 8.0.1, and 9.0.1, so this doesn't seem to be a recent change.

Comment 21

[Alex Keybl [:akeybl]]

(In reply to juan becerra [:juanb] from comment #20)
> (In reply to Justin Dolske [:Dolske] from comment #11)
> > Did something change between 9 and 10 that makes this an easier thing to
> > hit? Sounds like comment 0 is saying everything is a-ok on 9, whereas
> > comment 6 says this is a long-standing problem.
> 
> I've tried this on Fx 5.0.1, 7.0.1, 8.0.1, and 9.0.1, so this doesn't seem
> to be a recent change.

Untracking for FF11 in that case. This is still a reproducible pain point, so we should continue to investigate.

Comment 22

[Hal Wine [:hwine] use NI!]

Having an app hang while doing nothing but interacting with the OS in such a basic way just feels wrong. Can we commit to do something in 12?

Comment 23

[Robert Strong (they/them - no direct email)]

Hal, Steven summarizes the difficulty with fixing this longstanding bug in Bug 718542 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.

Comment 24

[Hal Wine [:hwine] use NI!]

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 - which has been open and unresolved since Feb 2009 - 3 years!

Comment 25

[Robert Strong (they/them - no direct email)]

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.

Comment 26

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 27

[Hal Wine [:hwine] use NI!]

Woot! Progress! I have not yet been able to repro either print or open file hangs. Details in bug 729720 comment #16

Comment 28

[juan becerra [:juanb]]

(In reply to Steven Michaud from comment #26)
> 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.

I haven't been able to reproduce the problem on the nightlies.

Comment 29

[Alex Keybl [:akeybl]]

https://bugzilla.mozilla.org/show_bug.cgi?id=718542#c27

Comment 30

[Mihai Morar, (:MihaiMorar)]

As Hal said in Comment 27 and Juan in Comment 28, I wasn't able to reproduce this issue on Latest Nightly (2013-01/27) and FF 19b3 on Mac OS 10.8.2 too.

I'd tried to open different html, php, xpi and pdf files from different locations, but no hangs or lags appeared, they just worked as expected and Open Dialog appeared asking me about how do I want to open that file. Based on theese verifications and on Comment 26, I think this issue should be close.

If anyone can still reproduce this issue on Latest version of Nightly, Aurora or Beta please reopen it.