Closed
Bug 310308
Opened 19 years ago
Closed 14 years ago
Schubert|it PDF plugin crashes browser when viewing about window
Categories
(Core Graveyard :: Plug-ins, defect)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: englabenny, Unassigned)
References
()
Details
(Whiteboard: [closeme 2011-03-01][needs retesting on Mac with Schubert|it PDF plugin])
Attachments
(2 files)
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 4•19 years ago
|
||
*** This bug has been marked as a duplicate of 183586 ***
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → DUPLICATE
Comment 5•19 years ago
|
||
This is not bug 183586: the stack is totally different.
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
Comment 6•19 years ago
|
||
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•19 years ago
|
||
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).
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 8•19 years ago
|
||
(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•15 years ago
|
||
Ulrik or Manfred, can you retest with Firefox 3.5 (and a current version of this plugin) to determine whether this bug still exists?
Whiteboard: [needs retesting on Mac with Schubert|it PDF plugin]
Comment 10•14 years ago
|
||
(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?
Whiteboard: [needs retesting on Mac with Schubert|it PDF plugin] → [closeme 2011-03-01][needs retesting on Mac with Schubert|it PDF plugin]
Comment 11•14 years ago
|
||
No response to needed information. -> incomplete report
Status: NEW → RESOLVED
Closed: 19 years ago → 14 years ago
Resolution: --- → INCOMPLETE
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•