Closed
Bug 81818
Opened 24 years ago
Closed 24 years ago
content-type header and content mismatch causes crash in gkcontent - Trunk [@ nsImageDocument::UpdateTitle]
Categories
(Core :: DOM: HTML Parser, defect)
Core
DOM: HTML Parser
Tracking
()
VERIFIED
FIXED
mozilla0.9.1
People
(Reporter: ferdinandw+bmo, Assigned: jst)
References
()
Details
(Keywords: crash, regression, topcrash)
Crash Data
Attachments
(1 file)
|
953 bytes,
patch
|
Details | Diff | Splinter Review |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9+) Gecko/20010519
BuildID: cvs 2001190508
when opening a page that has image/gif as content-type in http header, while it
actually is html, mozilla crashes.
Reproducible: Always
Steps to Reproduce:
1. Open the url (which gives image/gif header on text/html file)
2. mozilla crashes instantly in gkcontent
Actual Results: crash
Expected Results: some better way to deal with this...
i understand its weird server behaviour, but crashing is bad.
php code that will cause crash too:
<?php
header("Content-Type: image/gif");
echo "<html><body></body></html>\n";
?>
Here is the stack trace:
nsImageDocument::UpdateTitle() line 501 + 11 bytes
nsImageDocument::EndLayout(nsISupports * 0x00000000, unsigned int 0) line 436
ImageListener::OnStopRequest(ImageListener * const 0x00718800, nsIRequest *
0x007153c0, nsISupports * 0x00000000, unsigned int 0) line 187
nsDocumentOpenInfo::OnStopRequest(nsDocumentOpenInfo * const 0x0247a7e0,
nsIRequest * 0x007153c0, nsISupports * 0x00000000, unsigned int 0) line 255
nsStreamListenerTee::OnStopRequest(nsStreamListenerTee * const 0x02390810,
nsIRequest * 0x007153c0, nsISupports * 0x00000000, unsigned int 0) line 25
nsHttpChannel::OnStopRequest(nsHttpChannel * const 0x007153c4, nsIRequest *
0x0247ca80, nsISupports * 0x00000000, unsigned int 0) line 2038
nsOnStopRequestEvent::HandleEvent() line 159
nsARequestObserverEvent::HandlePLEvent(PLEvent * 0x023a6074) line 64
PL_HandleEvent(PLEvent * 0x023a6074) line 590 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x0124ba90) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x00080394, unsigned int 49451, unsigned in
Johnny, this could be related to your recent change!
---> if (!valUni[0]) {
key.AssignWithConversion("ImageTitleWithoutDimensions");
rv = bundle->GetStringFromName(key.GetUnicode(), getter_Copies(valUni));
}
Reassigning to jst.
Assignee: harishd → jst
|
Assignee | |
Comment 2•24 years ago
|
||
|
|
Assignee | |
Comment 3•24 years ago
|
||
The patch I just attached fixes this crash that was introduced by scc's string
renaming changes (chcecked in from my account, see checkin comment), this is a
crash that needs to be fixed and the fix is easy and safe, there's no reason not
to check this in for mozilla0.9.1, nominating.
The attached patch also contains one minor optimization that avoids one alloc,
string copy and free operation when setting the title of an image document.
scc, sr=?
Status: NEW → ASSIGNED
Keywords: regression
OS: Windows ME → All
Hardware: PC → All
Target Milestone: --- → mozilla0.9.1
|
||
Comment 4•24 years ago
|
||
a=chofmann
|
||
Comment 5•24 years ago
|
||
sr=scc, nice catch jst ... and sorry for the trouble
|
|
Assignee | |
Comment 6•24 years ago
|
||
np
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
*** Bug 82742 has been marked as a duplicate of this bug. ***
Verified on
build: 2001-05-29-20-Trunk
platform: Win NT
The browser does not crashes.
Status: RESOLVED → VERIFIED
|
||
Comment 9•24 years ago
|
||
Adding topcrash keyword and Trunk [@ nsImageDocument::UpdateTitle] to summary
for tracking. This *was* a topcrasher according to Talkback, but to confirm the
verified fixed status and resolution, this crash last occurred with build
2001052622.
Keywords: topcrash
Summary: content-type header and content mismatch causes crash in gkcontent → content-type header and content mismatch causes crash in gkcontent - Trunk [@ nsImageDocument::UpdateTitle]
|
||
Updated•14 years ago
|
Crash Signature: [@ nsImageDocument::UpdateTitle]
You need to log in
before you can comment on or make changes to this bug.
Description
•