Closed Bug 233084 Opened 22 years ago Closed 20 years ago

Reloading a pdf file that is in a frameset crashes Browser (All Gecko based Browsers)

Categories

(Core Graveyard :: Plug-ins, defect)

Product:
Core Graveyard
Component:
Plug-ins
Platform:
x86
All
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: smungi, Assigned: peterlubczynski-bugs)

References

(
URL
)

Details

(Keywords: crash, qawanted)

User-Agent: Build Identifier: Mozilla/5.0 I am trying to access pdf files (user guides) for our Toshiba support site in a frameset with two frames. Top frame shows the userguide and an invisible frame shows a page that is used for statistics....I have narrowed it down to these combinations. A pdf file(only ones that are on our content server) accessed in a frame in frameset when reloaded hangs the browsers ( All Gecko based browsers Netscape 6.1 and higher including 7.1, Mozilla 1.4 and 1.6 - First time it loads fine). Here is a sample code of the frameset file. Copy this code to a local temp file and load it. It loads fine the first time but when you reload it it crashes the browser. I tested it on Adobe reader 4.x and 6.0, 6.1. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <html> <head> <title>Untitled</title> </head> <frameset rows="80%, 20%" frameborder="0" framespacing="0" border="0" noresize> <frame name="main" src="http://cdgenp01.csd.toshiba.com/content/support/manuals/userguides/su520627 /sat_p25s609_ug_20030729.pdf#page=113" marginwidth="10" marginheight="10" scrolling="auto" frameborder="0" border="0" noresize> <frame name="mozilla" src="http://www.mozilla.org" marginwidth="10" marginheight="10" scrolling="auto" frameborder="0" border="0" noresize> </frameset> </html> Reproducible: Always Steps to Reproduce: 1. Copy the html that I have to a temp file say frameset.html 2. Load the file in Gecko based browser 3. Loads fine the first time. Now refresh it and it hangs the browser. Actual Results: It hangs the browser and I have to kill Acrobat reader process and browser process using Task Manager. Expected Results: reloaded the frameset.
And this is related to DOM Load and Save how? ;) On Linux, at least, it looks like the plugin itself goes into an infinite select() loop for some reason; maybe it's expecting something from us and not getting it? Oddly enough, I can't reproduce this with an iframe or full-page plugin....
Assignee: general → peterlubczynski-bugs
Component: DOM: Load and Save → Plug-ins
Keywords: qawanted
(In reply to comment #1) > And this is related to DOM Load and Save how? ;) > On Linux, at least, it looks like the plugin itself goes into an infinite > select() loop for some reason; maybe it's expecting something from us and not > getting it? > Oddly enough, I can't reproduce this with an iframe or full-page plugin.... Hi Boris, I was trying to add this bug to the component that I thought might be the best fit. It this bug does not belong to "DOM Load and Save" please move it to appropriate component. This works fine in all versions of Internet Explorer and Netscape 4.x but does not work on Gecko Based browsers. You can also reach me at subba.mungi@tais.toshiba.com or 949-461-4804(W) if you have any questions. I really appreciate you taking a look at it. Thanks, Subba Mungi
I see this on LInux 2004022608 Added url using testcase from comment 0.
URL: 20%" frameborder="0" framespacing="0"...
OS: Windows 2000 → All
WFM, 1.7b on Linux.
WFM, on Win2000 (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040316)
WFM Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040413 Firefox/0.8.0+ Microsoft Windows 2000 Pro 5.00.2195 SP4
Subba Mungi: Could you reproduce this bug with Mozilla 1.7.5 or 1.8 beta 1 or actual nightbuild? Could you provide Talkback incident ID of you crash?
Keywords: crash
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → EXPIRED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.