Closed Bug 244490 Opened 22 years ago Closed 22 years ago

[FIX]Crash when ":before" having URL with wrong document base element [@ nsCSSFrameConstructor::CreateGeneratedFrameFor ]

Categories

(Core :: CSS Parsing and Computation, defect, P1)

Product:
Core
Component:
CSS Parsing and Computation
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.8alpha2

People

(Reporter: volkmar, Assigned: bzbarsky)

References

(
URL
)

Details

(4 keywords)

Crash Data

Attachments

(2 files)

Stacktrace Mozilla debug Linux 20040519
7.85 KB, text/plain
Details
Fix
1.25 KB, patch
dbaron
: review+
dbaron
: superreview+
asa
: approval-aviary+
asa
: approval1.7.5+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040522 Firefox/0.8.0+ Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8a2) Gecko/20040522 Firefox/0.8.0+ Firefox crashes when pseudo elements ":before" or ":after" have content "URL" and document's base element is nonsense. 1: <?xml version="1.0" encoding="UTF-8"?> 2: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 3: "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> 4: <html xml:lang="de" xmlns="http://www.w3.org/1999/xhtml"> 5: <head> 6: <title>Crash Test</title> 7: <base href="D:\CSS Test Files\" /> 8: <style type="text/css"> 9: p { border: 1px red solid } 10: p:before { content: url("images/quote_end.png") } 11: </style> 12: </head> 13: <body> 14: <p>Did it crash?</p> 15: </body> 16: </html> Reproducible: Always Steps to Reproduce: 1. Try to view "http://home.arcor.de/plsdontreply/crashtest.html" Actual Results: Firefox crashes Expected Results: Just ignore nonsense in <base/> element. Reference: http://forums.mozillazine.org/viewtopic.php?t=79058&sid=a881c8e5a30ec1487b84264c1b001cd7
Hangs SeaMonkey 1.8a1 PC/WinXP ->Browser
Assignee: firefox → general
Severity: normal → critical
Status: UNCONFIRMED → NEW
Component: General → Browser-General
Ever confirmed: true
Keywords: crash, hang
OS: Linux → All
Product: Firefox → Browser
QA Contact: general
Version: unspecified → Trunk
After a hang, it actually did crash the browser on exit. TB58230M
Whiteboard: TB58230M
Trying Style System
Assignee: general → dbaron
Component: Browser-General → Style System (CSS)
QA Contact: general → ian
will try to get more local variables if it helps. #0 0x411615e6 in nsCSSFrameConstructor::CreateGeneratedFrameFor(nsIPresContext*, nsIDocument*, nsIFrame*, nsIContent*, nsStyleContext*, nsStyleContent const*, unsigned, nsIFrame**) (this=0x87b67d0, aPresContext=0x8809628, aDocument=0x8830108, aParentFrame=0x87e885c, aContent=0x88779b8, aStyleContext=0x87e8894, aStyleContent=0x87e880c, aContentIndex=0, aFrame=0xbfffe4a4) at nsCSSFrameConstructor.cpp:1380 1380 data.mContent.mURL->GetSpec(spec); // XXXldb Ugh. (gdb) p data $1 = (const nsStyleContentData &) @0x8749a54: {mType = eStyleContentType_URL, mContent = {mString = 0x0, mURL = 0x0}}
Keywords: testcase
Summary: Crash when ":before" having URL with wrong document base element → Crash when ":before" having URL with wrong document base element [@ nsCSSFrameConstructor::CreateGeneratedFrameFor ]
Flags: blocking1.8a2?
TB58230M gives same stack crashing in nsCSSFrameConstructor::CreateGeneratedFrameFor
Keywords: hang → clean-report
Whiteboard: TB58230M
Attached patch Fix — — Splinter Review
Assignee: dbaron → bzbarsky
Status: NEW → ASSIGNED
Olivier, thanks for the debugger data! Made fixing this a whole lot faster.
Priority: -- → P1
Summary: Crash when ":before" having URL with wrong document base element [@ nsCSSFrameConstructor::CreateGeneratedFrameFor ] → [FIX]Crash when ":before" having URL with wrong document base element [@ nsCSSFrameConstructor::CreateGeneratedFrameFor ]
Target Milestone: --- → mozilla1.8alpha2
Comment on attachment 149478 [details] [diff] [review] Fix David, would you review?
Attachment #149478 - Flags: superreview?(dbaron)
Attachment #149478 - Flags: review?(dbaron)
Attachment #149478 - Flags: superreview?(dbaron)
Attachment #149478 - Flags: superreview+
Attachment #149478 - Flags: review?(dbaron)
Attachment #149478 - Flags: review+
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Flags: blocking1.8a2?
Flags: blocking-aviary1.0?
Same crash again with Aviary build 27-Jul-2004 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040727 Firefox/0.9.1+
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
OS: All → Linux
Flags: blocking-aviary1.0PR?
This was checked in on trunk way after aviary branched. It couldn't possibly be fixed there. DO NOT REOPEN TRUNK BUGS BECAUSE OF BRANCH ISSUES!
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → FIXED
Good keywords, good bug, good patch, trunk baking => aviary1.0+. /be
Flags: blocking-aviary1.0? → blocking-aviary1.0+
Oh, and Volkmar? Don't change the OS field to be wrong in the future, please.
OS: Linux → All
Hardware: PC → All
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-
Comment on attachment 149478 [details] [diff] [review] Fix Putting on approval radar. Also asking 1.7.3 to prevent forking.
Attachment #149478 - Flags: approval1.7.3?
Attachment #149478 - Flags: approval-aviary?
Comment on attachment 149478 [details] [diff] [review] Fix a=asa for aviary checkins.
Attachment #149478 - Flags: approval1.7.x?
Attachment #149478 - Flags: approval1.7.x+
Attachment #149478 - Flags: approval-aviary?
Attachment #149478 - Flags: approval-aviary+
Checked in on branches.
Keywords: fixed-aviary1.0, fixed1.7.x
layout/base/crashtests/244490-1.html http://hg.mozilla.org/mozilla-central/rev/b0337b6287f3
Flags: in-testsuite+
Crash Signature: [@ nsCSSFrameConstructor::CreateGeneratedFrameFor ]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: