Closed
Bug 474181
Opened 16 years ago
Closed 15 years ago
Crash (too much recursion in BindToTree) with XBL, SVG, GC
Categories
(Core :: XBL, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 460876
People
(Reporter: jruderman, Assigned: smaug)
References
Details
(Keywords: crash, testcase)
Attachments
(2 files, 1 obsolete file)
|
(deleted),
image/svg+xml
|
Details | |
|
(deleted),
patch
|
Details | Diff | Splinter Review |
testcase (can crash Firefox when loaded)
Steps:
1. Temporarily install https://www.squarefree.com/extensions/quitter.xpi so the testcase's gc() function will work.
2. Load the testcase.
Result: Crash due to too much recursion in BindToTree functions.
Expected: "Node cannot be inserted at the specified point in the hierarchy"
|
Reporter | |
Comment 1•16 years ago
|
||
The testcase must be local to crash. When I load the testcase from Bugzilla, I get "document.getAnonymousNodes(d) is null". I guess that means onload fired before the -moz-binding finished loading. Is that a bug?
yeah, we probably don't use a Loadgroup when loading xbl which is bad.
|
Assignee | |
Updated•16 years ago
|
Assignee: nobody → Olli.Pettay
|
||
Comment 3•16 years ago
|
||
We sure do use a loadgroup when loading XBL. We use the loadgroup of the first bound document that triggered the network load.
|
|
||
Comment 4•16 years ago
|
||
@onload on SVG elements fires when we parse the close tag, sorta per SVG spec. Not at all like the <body>'s @onload in HTML.
Attachment #357528 -
Attachment is obsolete: true
|
|
||
Updated•16 years ago
|
Attachment #357675 -
Attachment is patch: false
Attachment #357675 -
Attachment mime type: text/plain → image/svg+xml
|
|
||
Comment 5•16 years ago
|
||
OK, with "using the right onload" I get:
JavaScript error: , line 0: uncaught exception: [Exception... "Node cannot be inserted at the specified point in the hierarchy" code: "3" nsresult: "0x80530003 (NS_ERROR_DOM_HIERARCHY_REQUEST_ERR)" location: "https://bugzilla.mozilla.org/attachment.cgi?id=357675 Line: 26"]
on current trunk.
|
|
||
Comment 6•16 years ago
|
||
Same thing with the original testcase if I save it to a file.
|
|
Assignee | |
Comment 7•16 years ago
|
||
I can reproduce the crash (I tried only the first testcase), and the
reason why we crash is that unbinding anonymous content doesn't clear
parentNode's child list.
Patch coming once I've tested it a bit more.
|
|
Assignee | |
Comment 8•16 years ago
|
||
I'm not too happy with change to the assertion.
|
|
||
Comment 9•16 years ago
|
||
What about some sort of back-door method to just clear the child list?
Alternately, what about not using a node to keep track of the kids to start with? A bigger change, but possibly more sanity involved...
|
|
Assignee | |
Comment 10•16 years ago
|
||
(In reply to comment #9)
> Alternately, what about not using a node to keep track of the kids to start
> with? A bigger change, but possibly more sanity involved...
Yeah, that might be better. A lot better.
nsCOMArray<nsIContent> or something similar to keep nodes alive.
|
|
Reporter | |
Comment 11•15 years ago
|
||
WFM, I think. This line now triggers an error:
d.appendChild(r);
Error: uncaught exception: [Exception... "Operation is not supported" code: "9" nsresult: "0x80530009 (NS_ERROR_DOM_NOT_SUPPORTED_ERR)" location: "a.svg Line: 24"]
|
|
Reporter | |
Comment 12•15 years ago
|
||
... which is the same thing that made the crash in bug 460876 go away.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•