Closed Bug 253117 Opened 20 years ago Closed 7 years ago

Slow-loading plugins (Acrobat, Java) cause Mozilla to freeze while they load.

Categories

(Core Graveyard :: Plug-ins, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: target, Unassigned)

References

Details

(Keywords: perf)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040616

The entire browser freezes while loading plugins. Normally this is fast enough
to not be a problem, but some plugins are getting really bloated or misbehaved
and can freeze the browser for extended periods of time.

Acrobat 6 is the worst offender, in my experience. It's gotten very large and
takes a while to load even on a 2GHz machine w/SATA drives. It also puts the
browser on hold while it checks for updates. Those two delays are long enough
that Mozilla must miss an important signal or something, because it often does
not recover and requires a restart.

Even with the plugin "tamed" to not seek updates, the delay's still awfully long
and the browser can't be used while waiting.

I'd suggest loading plugins in separate threads/processes if they aren't already.

Reproducible: Always
Steps to Reproduce:
1. Install Acrobat Reader 6+
2. Load a PDF in a new window/tab
3. Attempt to use any browser facilities while waiting for the plugin to load

Actual Results:  
Browser's frozen while the plugin loads. Sometimes so long that the browser
never recovers.

Expected Results:  
Load the plugin in the background and allow continued usage of the browser.
Loading plugins in separate processes is bug 156493.
I've never had Moz lock up on me when loading Acrobat 6 but it does take
forever.  You can decrease the time it takes to load by moving all the plugins
except 
EWH32.api  Search.api  printme.api
out of 
Adobe/Acrobat\ 6.0/Reader/plug_ins
*** Bug 293336 has been marked as a duplicate of this bug. ***
I can confirm this behaviour for at least FireFox 1.0.1 and 1.0.3 (and possibly
others), running on Windows XP Professional SP2. It appears that all of the
FireFox windows are 'waiting' and/or 'blocking' until a plugin is (fully)
started, causing all FireFox windows to become unresponsive during that period.
One the plug-in is started, all FireFox windows resume to normal behaviour and
become responsive again.

Adobe Acrobat Reader 6 is indeed a good example of this behaviour, but so is
Sun's Java Plug-in. I can confirm this with at least Sun Java Plug-in 1.5.0_02
(but possibly others as well).

Is it as bad in Acrobat 7?  So I can confirm.
No, it's not as bad for Acrobat Reader v7 as it is for v6, but it is very bad 
for for Sun's Java Plug-in 1.5.0_02 as well so it's not just 'an Adobe Acrobat 
issue' either ;).
*** Bug 305463 has been marked as a duplicate of this bug. ***
This bug should really be marked as NEW or VERIFIED.

I read a lot of reports in pdf format and this problem is really annonying.
Plugins should be loaded by a different thread and should notify the main
application when the loading is finish so the rendering could beginning without
freezing.
Should probably depend on bug 156493 - "Browser should tolerate plug-in (plugin)
malfunctions, like with a separate (own) process"
Depends on: 156493
*** Bug 270006 has been marked as a duplicate of this bug. ***
*** Bug 330422 has been marked as a duplicate of this bug. ***
Summary: Rather bloated plugins like Acrobat 6 can cause Mozilla to freeze while they load. → Slow-loading plugins (Acrobat 6, Java) cause Mozilla to freeze while they load.
Bugzilla Bug 337271
since update to 1.5.0.3 Firefox hangs when a PDF file is to be loaded for Adobe reader 7.0.7
(In reply to comment #12)
Worcester12345, don't confuse different issues, please.
 (1) "freeze, hang, wait or loop forever" issues due to mainly Adobe's software
     problem.
 (2) "not forever freeze, but too long to wait every day for human beings"
     problem, due to (a) "lo---ng start up time of Adobe Reader or Sun Java VM"
     and (b) problem in Mozilla family's design of plugin control mechanism
     - not tolerate with not-so-well-designed plugins(and related softwares).
This bug is not for (1), although (2)-(b) is involved in both issues.
Summary: Slow-loading plugins (Acrobat 6, Java) cause Mozilla to freeze while they load. → Slow-loading plugins (Acrobat 6/7, Java) cause Mozilla to freeze while they load.
In what way is this different from bug 156493, running plugins in a separate process? Do we really need a separate bug for just the loading aspect? 
I believe this would be better duped to bug 156493, and add a few comments noting that along with merely running separately, even the loading state should not hang the browser (not automatically true).
is this seen with current version PDF and firefox?
Keywords: perf
Whiteboard: [closeme 2011-03-01]
Yes, of course. Acrobat startup is still really slow and the code architecture hasn't changed.
Whiteboard: [closeme 2011-03-01]
I'm not able to reproduce this problem anymore on my netbook with Firefox 4 beta 11, Adobe Reader X, Windows 7. This seems strange to me since Adobe Reader X doesn't run in a seperate process. Could somebody who is able to reproduce the bug post links to websites with embedded plugins which cause the browser to hang?
Not sure if this qualifies as a plugin, but what about skimlink scripts? Those seem to constantly cause problems.
Summary: Slow-loading plugins (Acrobat 6/7, Java) cause Mozilla to freeze while they load. → Slow-loading plugins (Acrobat, Java) cause Mozilla to freeze while they load.
I can confirm this bug using Firefox Nightly 2011-06-20 and Adobe Reader X 10.1.0 , while Chrome (12.0.742.100) doesn't have this problem.
(I used the sample PDF from:
http://www.stluciadance.com/prospectus_file/sample.pdf)

Can you take another look at this bug for the following reasons?

1. This is not an Adobe Reader problem because it doesn't freeze with Google Chrome
2. Out Of Process plugins is already implemented but the problem still exists, so it is not because OOP is not implemented as previous comments claimed.
I'm marking this bug as WONTFIX per bug #1269807.

For more information see - https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.