429242 - browser's HTML pane hangs if a PDF link is clicked and aborted via escape key before it finishes loading (Adobe Reader 8.1.2)

Status: RESOLVED INCOMPLETE

(Plugins Graveyard :: PDF (Adobe), defect)

Description

[Leo Lipelis]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041506 Minefield/3.0pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041506 Minefield/3.0pre

Browser's HTML pane hangs if a PDF link is clicked and aborted via escape key before it finishes loading.

Reproducible: Always

Steps to Reproduce:
1. Go to http://www.domassistant.com/documentation/
2. Click "DOMAssistant documentation in English" link and...
3. Immediately abort loading by hitting ESC key
Actual Results:  
The HTML pane appears frozen and the browser in general exhibits weird behavior.  You have to see it to understand how weird it is. :)  For example the cursor's shape gets frozen if you cross the window boundary (the cursor doesn't revert back to an arrow), and there are other effects.  But the browser itself is not totally hung because it is still possible to click the "back" button and to use the menu, etc.

Expected Results:  
Loading the linked PDF should abort and the HTML pane should remain fully functional.

Comment 1

[Leo Lipelis]

Correction: in step 3, don't hit ESC too fast.  I think the word "immediately" in step 3 is a little too strong.  Maybe a better word would be "quickly".  I can still reproduce it every time on the latest nightly.

Comment 2

[Leo Lipelis]

Attachment: a screenshot of a frozen html pane

Comment 3

[Leo Lipelis]

I was trying to duplicate this bug without the Download Statusbar extension, and I cannot.  So this might be a bug in the Download Statusbar.  Without the Download Statusbar, I couldn't abort the download via ESC, once started, at least on a Mac.

Comment 4

[Leo Lipelis]

I could still duplicate this condition on a clean profile on Windows.  So I still think it may be a bug.  I'm attaching another screenshot that shows vanilla profile being used on the latest nightly Minefield.

Comment 5

[Leo Lipelis]

Attachment: the bug happening on a clean profile

Comment 6

[WADA:World Anti-bad-Duping Agency]

(Q1) Which version of Adobe Reader & Adobe Reader pdf plugin is used?
     You can check version and library from where plugin is loaded.
      about:config, plugin.expose_full_path=true, about:plugins
     (after check, plugin.expose_full_path=false for safety)
(Q2) Problem occurs with the specific site/specific pdf you mentioned only?
(Q3) When hang occurs, stand alone Adobe Reader works well?
  1. Hang occurs on Firefox.
  2. Start Task Manager. (AcroRd32.exe with no window is probably active)
  3. Start stand alone Adobe Reader application, and view some pdf files.
  4. Terminate standalone Adobe Reader.
  5. If warning of "other oen is active" or something appears, reply "OK".
  6. Check Task Manager. AcroRd32.exe disappears?
  7. If AcroRd32.exe is still active, kill AcroRd32.exe via Task Manager.
  What will happen on Firefox who hanged at step (1)?
(Q4) Problem can be re-produced with -safe-mode and with new profile?

Comment 7

[WADA:World Anti-bad-Duping Agency]

FYI.
As I wrote in Bug 274077 Comment #42, "PDF related hang/freeze/crash still remains even after Adobe Reader 8" seems to be limited in special situations.
I could find only following three reports of "PDF related hang/freeze/crash even 
after Adobe Reader 8".
 1. Bug 383826(PDF download error) then Bug 368821(Crash),
    when test case of Bug 368821(very many IFRAMEs with PDF).
 2. Bug 274077 Comment #40 case :
    Hang when "scroll down the document before it finishes loading". 
 3. Bug 429242(your this bug) : Hang when quick cancel after PDF link click.
See dependency tree for Bug 336184, please.

Comment 8

[Leo Lipelis]

Attachment: the same bug on a different site with a different PDF

Comment 9

[Leo Lipelis]

Attachment: the same bug happening with -safe-mode and a new profile

Comment 10

[Leo Lipelis]

(A1) C:\Program Files\Adobe\Reader 8.0\Reader\browser\nppdf32.dll (version 8.1.2 from "Help/About..." of the stand-alone reader)

(A2) I duplicated it on an apple's manual site.  It took 2 tries, I had to time hitting the escape button just right: I started hitting escape button not too soon after I start the download and then I continued to hit ESC button rapidly to get the condition to occur.  With a lucky ESC it's possible to get it in one keystroke.  If I hit the ESC too soon after clicking on the pdf link, it doesn't create the buggy condition.  It seems like the pdf download must already be in progress for this to happen.  Please see attachment.

(A3) When I follow these steps, what happens is that there is indeed an AcroRd32.exe process there.  Then when I start a stand-alone reader instance, it runs fine, without warnings.  When I close the stand-alone instance, the AcroRd32.exe process disappears and the FF3 HTML panel inside the tab appears to be unfrozen and working as expected, except that it's blank (which is normal, since the download was aborted half-way, unless I misunderstand what the ESC key does).

(A4) Yes, I reproduced the problem with -safe-mode and a new profile.  Please see attachment.

Comment 11

[Leo Lipelis]

I just want to make it clear that so far I was not able to reproduce this on a Mac build of Minefield, but it is easy for me to reproduce it on Windows XP SP2.  I can reproduce it pretty much on demand, on Windows.  I believe anyone with a reasonably slow connection or a reasonably large PDF link should be able to reproduce it in the same way that I have.

Comment 12

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #10)
> (A3)
> When I close the stand-alone instance, the AcroRd32.exe process disappears
> and the FF3 HTML panel inside the tab appears to be unfrozen and working
> as expected, except that it's blank.

Sounds to be error in "communication between PDF plugin and AcroRd32.exe".
  PDF plugin was waiting for response from AcroRd32.exe, but AcroRd32.exe
  didn't respond or PDF plugin failed to detect response, then waited forever.
  And, PDF plugin quited from wait status by termination of AcroRd32.exe.
As usual, workaround is to disable "Display PDF in Browser" option of Adobe Reader.

Comment 13

[Leo Lipelis]

WADA, thank you for all your help.  Your analysis of the situation sounds right to me, but I don't know enough to say for sure.  Should this bug be forwarded to Adobe?  Does Adobe read these bug reports?

If I understand correctly, there is nothing that Firefox can do to help with this, except maybe to wait to load the entire PDF file before transferring control over to the PDF plug-in.  I believe, such approach would create more usability issues than solve.

Comment 14

[WADA:World Anti-bad-Duping Agency]

> Should this bug be forwarded to Adobe?
I think so. If you know contact point of Adobe, please report this issue to Adobe.

> wait to load the entire PDF file before transferring control over to the PDF plug-in

Adobe Reader already has similar mechanism/options(==behavior of older versions). 
> Enable  : (A) Display PDF in Browser
> Disable : (B) Allow fast web view
> Disable : (C) Allow speculative downloading in the background
Enabling of (B) and/or (C) produced many hang/freeze/crash problems in the past.
I think your problem is a remaining issue in special situation when (A)/(B) are enabled.
Can "disabling of (B) & (C)" reduce probability/frequency of your hang problem? 

Comment 15

[timeless]

i know this is a different plugin, but could you please find a contact? thanks,

Comment 16

[Leo Lipelis]

(In reply to comment #14)
> Can "disabling of (B) & (C)" reduce probability/frequency of your hang problem? 

I tried disabling both (B) and (C), and I can still get the problem to occur, even with -safe-mode and a clean profile.

Comment 17

[Rudi Sherry]

(In reply to comment #14)
> > Should this bug be forwarded to Adobe?
> I think so. If you know contact point of Adobe, please report this issue to
> Adobe.

I can take a look at this early next week (I'm at WWDC right now and I have a very slow connection to my Windows machine which means I can't hit ESC fast enough over RDC).

Does anyone know if this is reproducible in Firefox 2?

Comment 18

[Wayne Mery (:wsmwk)]

Leo do you still crash? 

WFM Mozilla/5.0 (Windows NT 6.0; rv:2.0b12pre) Gecko/20110214 Firefox/4.0b12pre and reader 9.4.2

Comment 19

[Benjamin Smedberg]

Closing old bugs in the Plugins component. We aren't going to track issues in 3rd-party plugins in the Mozilla bug tracker. In addition, support for NPAPI plugins will be removed at the end of this year; for more details see the post at https://blog.mozilla.org/futurereleases/2015/10/08/npapi-plugins-in-firefox/

If there is a serious bug in Firefox, it needs to be filed in the "Core" product, "Plug-Ins" component.