The default bug view has changed. See this FAQ.

Crash when window gets destroyed on SVGZoom event




11 years ago
24 days ago


(Reporter: Martijn Wargers (dead), Assigned: smaug)


(4 keywords)

Windows XP
crash, fixed1.8.0.12, testcase, verified1.8.1.4
Bug Flags:
blocking1.8.1.4 +
blocking1.8.0.12 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [sg:critical?])


(4 attachments)



11 years ago
See upcoming testcase, which crashes Mozilla on load. Also crashes in Firefox1.5.0.3.
Marking security sensitive, just to be sure.

Talkback ID: TB18394613W
nsSVGSVGElement::DidModifySVGObservable   nsSVGValue::NotifyObservers   nsSVGValue::DidModify   XPTC_InvokeByIndex   XPCWrappedNative::CallMethod

Comment 1

11 years ago
Created attachment 221163 [details]
testcase, crashes on load

The iframe with the svg has this code:

<script xmlns="">
window.addEventListener('SVGZoom', doe, true);
function doe(e) {
var x= parent.document.getElementsByTagName('iframe')[0];
setTimeout(doe2, 1000);

function doe2() {
document.documentElement.currentScale = 2;

Comment 2

11 years ago
Created attachment 221164 [details]
Backtrace from debug build

Comment 3

11 years ago
Created attachment 221166 [details]

Same crash seems to happen with SVGScroll event.

Comment 4

10 years ago
This now got worksforme between 2007-01-04 and 2007-01-05:
It seems that this was somehow fixed by bug 333078?
So I guess this bug can be resolved then, right?
I don't think so.  If it's just something that's hidden because of when the cycle collector happens to run or not run, that's not really good enough.  In my opinion, of course.

In any case, the fix for this bug is obvious.  DO NOT hold a weak ref to an object you're dispatching an event on.  Just don't do it.  So fix nsSVGSVGElement::DidModifySVGObservable to hold a strong ref to the presshell.  ;)  And then probably audit the rest of the code that calls that method.
Flags: blocking1.9?
Whiteboard: [sg:critical?]
Created attachment 256027 [details] [diff] [review]
proposed patch

Keep strong ref to presShell.
Went quickly through the code and this really should be enough.
The patch applies to branch and trunk.
Attachment #256027 - Flags: superreview?(tor)
Attachment #256027 - Flags: review?(tor)
Assignee: general → Olli.Pettay


10 years ago
Attachment #256027 - Flags: superreview?(tor)
Attachment #256027 - Flags: superreview+
Attachment #256027 - Flags: review?(tor)
Attachment #256027 - Flags: review+
Checked in
Last Resolved: 10 years ago
Resolution: --- → FIXED
Attachment #256027 - Flags: approval1.8.1.3?
Flags: blocking1.9?
Flags: blocking1.8.1.4?
Flags: blocking1.8.0.12?
Comment on attachment 256027 [details] [diff] [review]
proposed patch

Is this patch appropriate for 1.8.0 as well? Firefox 1.5.0.x is also affected by this bug.
Attachment #256027 - Flags: approval1.8.0.12?
Flags: blocking1.8.1.4?
Flags: blocking1.8.1.4+
Flags: blocking1.8.0.12?
Flags: blocking1.8.0.12+
Comment on attachment 256027 [details] [diff] [review]
proposed patch

approved for and, a=dveditz for release-drivers
Attachment #256027 - Flags: approval1.8.1.4?
Attachment #256027 - Flags: approval1.8.1.4+
Attachment #256027 - Flags: approval1.8.0.12?
Attachment #256027 - Flags: approval1.8.0.12+
Keywords: fixed1.8.0.12, fixed1.8.1.4
verified on the 1.8 branch using Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/2007050804 BonEcho/ No crash for me, but i do still see the iframe in the page. Martijn attributes that to a test case error. Adding branch fixed keyword.
Keywords: fixed1.8.1.4 → verified1.8.1.4
Group: security

Comment 11

8 years ago
crash test landed
Flags: in-testsuite+
The crashtest seems like a no-op to me: it finishes after 500ms, but the subframe doesn't do its dirty work until 1s after its code runs... So the test is not exercising the code.
You need to log in before you can comment on or make changes to this bug.