Closed Bug 340945 Opened 19 years ago Closed 19 years ago

<svg style="display:table"> causes crash [@ nsSVGCoordCtxProvider::GetContextX]

Categories

(Core :: SVG, defect)

defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: jruderman, Assigned: bernd_mozilla)

References

Details

(Keywords: crash, regression, testcase)

Crash Data

Attachments

(5 files)

Attached image testcase
Blocks: 340946
on Windows I just get a alert saying "pure virtual call" and then exit. talkback didn't even come up Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060608 Minefield/3.0a1 ID:2006060804 [cairo]
Summary: <svg display:table> causes crash [@ nsSVGCoordCtxProvider::GetContextX] → <svg style="display:table"> causes crash [@ nsSVGCoordCtxProvider::GetContextX]
Regression range: Mac trunk nightly 2006-06-01 doesn't crash. Mac trunk nightly 2006-06-02 crashes. Regression from bug 338301, maybe?
Keywords: regression
So somehow an nsSVGInnerSVGFrame instead of an nsSVGOuterSVGFrame is constructed for the SVG element?
OS: Mac OS X 10.4 → All
Hardware: Macintosh → All
Attached patch possible patchSplinter Review
docElemIsTable is true in nsCSSFrameConstructor::ConstructDocElementFrame so rather than creating an outer SVG frame there we call ConstructDocElementTableFrame. When we try to create the SVG frame within this it decides we are an inner frame and our outer frame parent is ourself. Is this the right fix? It seems to work OK for <svg> <svg> with inner <svg> and <html> with <svg> in it.
Assignee: general → longsonr
Status: NEW → ASSIGNED
Attachment #225440 - Flags: review?(tor)
Wouldn't this still break for <html><svg style="display:table"></svg></html>?
Attached file example
In the attached example you get an outer SVG frame and an inner SVG frame regardless of whether or not you have the patch. Isn't this what we want? The outer frame's parent is the html frame and that fails the namespace = SVG namespace test so you get an outer frame. The inner frame's parent is the outer frame and so passes the namespace test.
Comment on attachment 225440 [details] [diff] [review] possible patch Tor suggested an alternate reviewer might be better.
Attachment #225440 - Flags: review?(tor) → review?(dbaron)
<svg style="display:table"> should be a no op with respect to the display statement. IsSpecialContent should return true for a svg tag: if (aNameSpaceID == kNameSpaceID_SVG && nsSVGUtils::SVGEnabled()) return aTag == nsSVGAtoms::svg || I suspect that the patch fixes the issue but is not at the right place.
PRBool docElemIsTable = display->mDisplay == NS_STYLE_DISPLAY_TABLE; is wrong it should take is IsSpecialContent into account. patch coming.
taking
Assignee: longsonr → bernd_mozilla
Status: ASSIGNED → NEW
Attachment #225440 - Flags: review?(dbaron)
Attached patch patchSplinter Review
Boris thats the bug that I asked you to review but the patch was wrong IMHO. So now its for me a typical IsSpecialContent case. Btw it does not crash with current trunk but the current code is wrong anyway.
Attachment #237614 - Flags: superreview?(bzbarsky)
Attachment #237614 - Flags: review?(bzbarsky)
Comment on attachment 237614 [details] [diff] [review] patch Makes sense.
Attachment #237614 - Flags: superreview?(bzbarsky)
Attachment #237614 - Flags: superreview+
Attachment #237614 - Flags: review?(bzbarsky)
Attachment #237614 - Flags: review+
fixed on trunk
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Crashtest checked in.
Flags: in-testsuite+
Crash Signature: [@ nsSVGCoordCtxProvider::GetContextX]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: