561144 - Startup issue: “Firefox is open but not responding” alert [meta]

Status: RESOLVED DUPLICATE of bug 401301

(Firefox :: General, defect)

Description

[Alex Limi (:limi) — Firefox UX Team]

(Note: this is filed as a meta bug as part of the “Paper Cut” bugs since we assume that there are multiple existing bugs related to this behavior. Please make them block this bug.)

In the Reddit thread, several users cited this as the reason they switched to Chrome. 

Probably related to bug 239223.

Recommendation:
Can we do something about this? Kill the process, a dialog that offers to kill it? Something else?

Comment 1

[[:Cww]]

This can also be "missing profile".  If the Firefox profile which you're trying to use is locked (.parentlock file in there) or if it's completely missing (deletion, broken profile.ini file) then you get this message EVEN IF Firefox isn't a running process.  This makes it a huge pain to troubleshoot.

Comment 2

[Gary Johnson]

I vote for Alexander L. recommendation.  Offer a dialog that offers to kill the process.  Killing the process with some kind of mini dump of system state, last window/tabs open etc might be useful

Comment 3

[Dave Garrett]

Actually, I don't think going purely the dialog route is ideal. It still would mean a zombie process in the background until a user gets around to relaunching Firefox and hitting the dialog. If it was zombified due to a stall this could be hurting performance without the user seeing a reason why, not to mention sucking up memory in the meantime.

Idealy we'd want a stricter shutdown sequence that asks nicely for everything to close out but gives up after a few minutes and self-terminates. If a user tries to relaunch during that window then a warning prompt could ask to wait, and afterwards kill it if needed.

Comment 4

[Dave Garrett]

By the way, I think this particular issue is more than just a "paper cut" bug. The term implies something that's irritating but not fatal, unless the instance of "death by a thousand paper cuts". This issue is frequently hit by people who simply lack the basic computer skills to get around it (i.e. kill process or reboot) not to mention don't fully investigate the problem so it gets fixed.

Of all the bugs most commonly reported by users, and cited as a common reason to ditch Firefox, I think this may have the lowest attention to damage ratio.

See also bug 546366 for a theory of some of the potential the causes here.

Comment 5

[Alex Faaborg [:faaborg] (Firefox UX)]

>Of all the bugs most commonly reported by users, and cited as a common reason
>to ditch Firefox, I think this may have the lowest attention to damage ratio.

I agree that this is much larger than a papercut (but got filed that way since it came out of feedback from the reddit thread on issues people are having).  Do we have a good way of gauging a bug's attention to damage ratio?  I'm actually not that familiar with how information transfers from support to Bugzilla to changes in the product.

Comment 6

[Dave Garrett]

(In reply to comment #5)
> Do we have a good way of gauging a bug's attention to damage ratio?

I'm not aware of any good way to quantify this. Bugzilla used to have a most duped bug top list which was helpful, but I don't know what became of that, and many on this topic don't get duped anywhere anyway. In the past there have been addons that have been identified as the culprit. (ex: bug 538160; see also bug 543732) There are plenty of unconfirmed reports filed that get a reply with troubleshooting steps to find a similar cause and go nowhere. I usually don't handle them, but I'm quite used to seeing them in the list of new bugs. All I know is that this particular (class of) problem is a not uncommon bug report and has been for quite some time, more so in the past year I think.

A search of SUMO turns up quite a few of these too, but you'd have to ask someone from there how common it has been lately. I would expect the rate to be higher there, but I could be wrong on that.

Comment 7

[u88484]

(In reply to comment #6)
> (In reply to comment #5)
> > Do we have a good way of gauging a bug's attention to damage ratio?
> 
> I'm not aware of any good way to quantify this. Bugzilla used to have a most
> duped bug top list which was helpful, but I don't know what became of that, 
https://bugzilla.mozilla.org/enter_bug.cgi?product=Firefox&format=guided

Comment 8

[Dave Garrett]

Ah, thanks Kurt. It used to be linked to from Home. List for -2w:
https://bugzilla.mozilla.org/duplicates.cgi?product=Toolkit&product=Core&product=Firefox&format=simple&sortby=delta&reverse=1&maxrows=100&changedsince=14

For -1y:
https://bugzilla.mozilla.org/duplicates.cgi?product=Toolkit&product=Core&product=Firefox&format=simple&sortby=delta&reverse=1&maxrows=100&changedsince=365

As I said though, this topic has a bunch of no-replies not duped. One of us should probably troll through the remaining ones and dupe them somewhere so they can be better counted.

Comment 9

[Alex Faaborg [:faaborg] (Firefox UX)]

Interesting, I had actually never encountered those lists before.

Comment 10

[Dave Garrett]

(apparently you can ditch the format=simple for a simpler to read table)

https://bugzilla.mozilla.org/duplicates.cgi?sortby=delta&maxrows=20&changedsince=14

https://bugzilla.mozilla.org/duplicates.cgi?sortby=delta&maxrows=100&changedsince=365