Closed
Bug 294630
Opened 19 years ago
Closed 19 years ago
Crash when closing tab with picture -Trunk [@ nsImageDocument::Destroy][@ nsImageDocument::scalar]
Categories
(Core :: Layout: Images, Video, and HTML Frames, defect)
Core
Layout: Images, Video, and HTML Frames
Tracking
()
VERIFIED
FIXED
People
(Reporter: stevee, Assigned: bryner)
References
()
Details
(4 keywords)
Crash Data
Attachments
(3 files)
27.54 KB,
image/jpeg
|
Details | |
1.10 KB,
patch
|
Details | Diff | Splinter Review | |
1.71 KB,
patch
|
bryner
:
review+
bryner
:
superreview+
dbaron
:
approval1.8b2+
|
Details | Diff | Splinter Review |
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050518 Firefox/1.0+ ID:2005051803 1. New profile, start firefox. 2. Open http://rotter.name/User_files/nor/42879aa4433c24e7.jpg in a new tab. 3. Wait for the picture to display 4. Close the tab with the picture in Actual: CRASH Expected: No crash. This works fine in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.8) Gecko/20050509 Firefox/1.0.4 TBID: TB5929760W
Reporter | ||
Comment 1•19 years ago
|
||
Reporter | ||
Comment 2•19 years ago
|
||
Works in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050517 Firefox/1.0+ (official nightly) Crashes in Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b2) Gecko/20050518 Firefox/1.0+ ID:2005051803 Checkin Range http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=PhoenixTinderbox&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-05-17+06%3A00%3A00&maxdate=2005-05-18+03%3A00%3A00&cvsroot=%2Fcvsroot
Reporter | ||
Updated•19 years ago
|
Severity: normal → critical
I'm requesting blocking for 1.1a because this is going to be a top crasher very soon... and it's easy to reproduce.
Flags: blocking1.8b2?
Comment 4•19 years ago
|
||
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050518 Mnenhy/0.7 Talkbacks: TB5934188K, TB5934177W, TB5934014G https://bugzilla.mozilla.org/mozilla-banner.gif Just use the banner image, right-click ViewImage, then click Back button ... or go to another tab, use 'Close Other Tabs' to crash.
Comment 5•19 years ago
|
||
We're probably calling Destroy() twice on the same document, and nsImageDocument doesn't null-check the |target| if mImageResizingEnabled. It should...
Comment 6•19 years ago
|
||
(In reply to comment #4) > Just use the banner image, right-click ViewImage, then click Back button ... > or go to another tab, use 'Close Other Tabs' to crash. Confirmed doing the same actions, Talkback ID: TB5943928G Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050518 Firefox/1.0+ ID:2005051813
*** Bug 294711 has been marked as a duplicate of this bug. ***
Comment 8•19 years ago
|
||
The testcase crash Firefox on Mac OS X as well. Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050518 Firefox/1.0+
Comment 9•19 years ago
|
||
I can't actually reproduce this crash myself, so if someone who can would test...
Attachment #183979 -
Flags: superreview?(bryner)
Attachment #183979 -
Flags: review?(bryner)
Comment 10•19 years ago
|
||
It did help in my build.
Comment 11•19 years ago
|
||
I reproduced this bug with automatic image resizing, whereas no problem under the setting without automatic image resizing.
Comment 12•19 years ago
|
||
Patch is working too here on my homemade build under OS-X Tiger. Great ;) Auto resizing works too.
Comment 13•19 years ago
|
||
(In reply to comment #9) > Created an attachment (id=183979) [edit] > Might fix this It does. > I can't actually reproduce this crash myself, so if someone who can would > test... Problem is that mImageContent is null, so an early check for that instead?
Attachment #183996 -
Flags: superreview?(bryner)
Attachment #183996 -
Flags: review?(bryner)
Comment 14•19 years ago
|
||
(In reply to comment #11) > I reproduced this bug with automatic image resizing, whereas no problem under > the setting without automatic image resizing. Yes, that is how I am able to reproduce this bug: -Go to Options | Advanced | Browsing -Select the check box for "Resize large images to fit in the browser window" -Okay/exit the Options dialog -visit http://www.ibiblio.org/wm/paint/auth/caravaggio/emmaus.jpg -Then click "Back" or close the tab the image is in. Crash If the the pref changed above is left unchecked, visiting then closing the emmaus.img page doesn't crash. This is already a topcrasher on Firefox trunk.
Keywords: topcrash
Summary: Crash when closing tab with picture [@ nsImageDocument::Destroy] → Crash when closing tab with picture -Trunk [@ nsImageDocument::Destroy]
Updated•19 years ago
|
OS: Windows 2000 → All
Hardware: PC → All
Comment 15•19 years ago
|
||
Crashes in 2005051808 build of Camino too.
Comment 16•19 years ago
|
||
*** Bug 294755 has been marked as a duplicate of this bug. ***
Assignee | ||
Updated•19 years ago
|
Attachment #183996 -
Flags: superreview?(bryner)
Attachment #183996 -
Flags: superreview+
Attachment #183996 -
Flags: review?(bryner)
Attachment #183996 -
Flags: review+
Comment 17•19 years ago
|
||
Comment on attachment 183996 [details] [diff] [review] Patch with early check regression fix
Attachment #183996 -
Flags: approval1.8b2?
Comment 18•19 years ago
|
||
*** Bug 294807 has been marked as a duplicate of this bug. ***
Why is it null? Are we calling Destroy twice? Did something else break?
Comment 20•19 years ago
|
||
> Why is it null? Are we calling Destroy twice? Yes. Once when we Close() the viewer, and once when the viewer is destroyed. > Did something else break? Not really. We just need to Destroy() documents in nsDocumentViewer::Close() when we're not stashing them in the bfcache to fix bug 294258. We also still need to Destroy() them when the viewer goes away (for cases when bfcache is actually on)...
Attachment #183996 -
Flags: approval1.8b2? → approval1.8b2+
Comment 21•19 years ago
|
||
Adding zt4newcrash keyword to make sure we fix this regression asap. It is currently the #1 active topcrasher on the Trunk.
Keywords: zt4newcrash
Summary: Crash when closing tab with picture -Trunk [@ nsImageDocument::Destroy] → Crash when closing tab with picture -Trunk [@ nsImageDocument::Destroy][@ nsImageDocument::scalar]
Assignee | ||
Comment 22•19 years ago
|
||
checked in.
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Updated•19 years ago
|
Attachment #183979 -
Flags: superreview?(bryner)
Attachment #183979 -
Flags: review?(bryner)
Comment 23•19 years ago
|
||
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050519 Firefox/1.0+ ID:2005051917 (20-May-2005 00:51) I am still seeing this crash...
Comment 24•19 years ago
|
||
(In reply to comment #23) > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050519 > Firefox/1.0+ ID:2005051917 (20-May-2005 00:51) > > I am still seeing this crash... Confirmed here with build: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050519 Firefox/1.0+ ID:2005051917
Comment 25•19 years ago
|
||
2005051917 --- Additional Comment #22 From Brian Ryner 2005-05-19 18:31 PDT [reply] --- Please do the math.
Comment 26•19 years ago
|
||
I confirmed the fix of latest firefox-pacifica-trunk under the setting of auto rsizing.
Comment 27•19 years ago
|
||
*** Bug 294865 has been marked as a duplicate of this bug. ***
Comment 28•19 years ago
|
||
*** Bug 294870 has been marked as a duplicate of this bug. ***
Comment 29•19 years ago
|
||
*** Bug 295082 has been marked as a duplicate of this bug. ***
Comment 30•19 years ago
|
||
*** Bug 290849 has been marked as a duplicate of this bug. ***
Comment 31•19 years ago
|
||
verified fixed using 2005052305-trunk firefox bits on linux fc3. also confirm that I no longer see this crash crop up in the Talkback taopcrash reports for the last three days.
Status: RESOLVED → VERIFIED
Updated•13 years ago
|
Crash Signature: [@ nsImageDocument::Destroy]
[@ nsImageDocument::scalar]
Updated•6 years ago
|
Product: Core → Core Graveyard
Updated•6 years ago
|
Product: Core Graveyard → Core
You need to log in
before you can comment on or make changes to this bug.
Description
•