FireFox becomes 'Not Responding' on network access stalls with MIME type plugins such as Adobe Acrobat.

RESOLVED INCOMPLETE

Status

()

Core
Plug-ins
RESOLVED INCOMPLETE
10 years ago
6 years ago

People

(Reporter: Stephen Phillips, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0

If a web page or MIME linked plugin (Example viewing a PDF file in which site access halts during or before execution).  FireFox halts. My guess is this is a thread issue, and FireFox is running everything in the same thread.  If anything such as Java Javascript and Adobe Acrobat stalls FireFox stalls and does not respond. This wasn't so bad in FireFox 2.0 where you could just close the tab and then reload the offending page. With FireFox 3 it has become chronic and halts ALL viewing pages and the primary execution thread of firefox.  Any network access stall acts like a blocking stall in the entire primary Application thread of Firefox it appears as well as any extension/plugin such as Adobe Acrobat or Flash Player.

This doesn't crash the application, it does shut it down completely the only cure is killing the application from the task manager and restarting.

Reproducible: Always

Steps to Reproduce:
1. Pick a Site that is known to be extremely slow
2. Select a PDF off the site and click on it.
3. Try using Adobe Acrobat OLE to load the PDF if the network connection stalls so does ALL of Firefox.
Actual Results:  
FireFox must be killed and restarted.

Expected Results:  
Network time out asserted?.  Remaining tabs should be functioning while tab for loading PDF is awaiting data.

Comment 1

10 years ago
http://developer.mozilla.org/en/docs/How_to_get_a_stacktrace_with_WinDbg
!analyze -v -hang

note: the ui has always been single threaded, and plugins have always had to run on the ui thread, so if they decided to hang, we always hung. none of this has changed in ff3, we do have an RFE to change this, but it requires reworking a significant portion of gecko.
To Stephen Phillips(bug opener):

FYI. There are already opened bug's for problems you are talking.

(A) There are at least three bug reports for "tolerance with plugin problem".
> Bug 156493 Browser should tolerate plug-in (plugin) malfunctions, like with a separate (own) process
> Bug 253117 Slow-loading plugins (Acrobat 6/7, Java) cause Mozilla to freeze while they load
> Bug 330184 Acrobat Reader blocked by Firewall -> Seamonkey hangs up 
(These bugs are already listed in Dependency Tree for Meta Bug 336184)

(B) And, there is a Meta bug for specific issues due to Adobe Reader's problem or Adobe Reader's PDF plugin's problem.
> Bug 336184 [Meta] Freeze,Hang/Hung/Wait,Almost 100% CPU/Loop,Crash while viewing PDF (Adobe Reader/Acrobat plugin related issues)
Sorry but I don't know central bug for problems caused by other plugins.

Updated

9 years ago
Component: General → Plug-ins
Product: Firefox → Core
QA Contact: general → plugins

Comment 3

6 years ago
Do you still see this?
URL?
Whiteboard: [closeme 2012-07-08]

Comment 4

6 years ago
Resolved per whiteboard
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → INCOMPLETE
Whiteboard: [closeme 2012-07-08]
You need to log in before you can comment on or make changes to this bug.