310308 - Schubert|it PDF plugin crashes browser when viewing about window

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[Ulrik Sverdrup]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20050924 Camino/1.0a1+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20050924 Camino/1.0a1+

It is possible to crash both Camino (24/9 nightly) and Firefox (1.5b1) with the
Schubert PDF plugin, provided that links are prevented from opening in new windows.

Reproducible: Always

Steps to Reproduce:
Set 'browser.link.open_newwindow' to 1 to block links opening in new windows

1. View  a pdf file with the Schubert PDF plugin installed
2. Choose "Go to Schubert|it Website" in the gear menu
3. Before the website has loaded, choose "About the PDF Browser Plugin" in the
same menu.
4. Crash before the about panel is shown

If the timing is just right, the about panel might show and the site will load.
However, when dismissing the about panel, the application stalls.

Actual Results:  
Crash

Expected Results:  
The about window should close as soon as the new page is shown.

Talkback with Camino: TB9821711E

Comment 1

[Ulrik Sverdrup]

Attachment: Camino nightly crash log

Attaching Camino crash log

Comment 2

[Ulrik Sverdrup]

Attachment: Firefox 1.5b1 crash log

Attaching Firefox crash log

Comment 3

[Simon Fraser [no longer active]]

It's crashing inside the plugin.

Comment 4

[Adam Guthrie]

*** This bug has been marked as a duplicate of 183586 ***

Comment 5

[Simon Fraser [no longer active]]

This is not bug 183586: the stack is totally different.

Comment 6

[Manfred Schubert]

It looks like the same issue to me. In both cases the plug-in is destroyed under its back while it is still 
handling an event. Of course then it's crashing. It should be the browsers responsibility to avoid this. The 
browser needs to somehow like retain the plug-in when it calls into it and release afterwards to avoid it 
being deleted while it's running.

Comment 7

[Simon Fraser [no longer active]]

I think the steps to get into this state are different enough to warrant keeping
this bug open (this one isn't about re-entering the plugin via a PLEvent).

Comment 8

[Manfred Schubert]

(In reply to comment #7)
> I think the steps to get into this state are different enough

The steps are exactly the same. In both cases you can select another web-site from the bookmarks bar (or 
some other place) and then quickly bring up the plug-in context menu. Same steps. Also crashes the 
QuickTime and Real plug-ins.

> (this one isn't about re-entering the plugin via a PLEvent).

Both are about destroying the plug-in while it is handling events.

Comment 9

[Jesse Ruderman]

Ulrik or Manfred, can you retest with Firefox 3.5 (and a current version of this plugin) to determine whether this bug still exists?

Comment 10

[Wayne Mery (:wsmwk)]

(In reply to comment #9)
> Ulrik or Manfred, can you retest with Firefox 3.5 (and a current version of
> this plugin) to determine whether this bug still exists?

is this seen with current version PDF and firefox?

Comment 11

[Stephanie Daugherty [:sdaugherty]]

No response to needed information. -> incomplete report