All users were logged out of Bugzilla on October 13th, 2018

Going to one of the url's and then clicking on File>Close of the window crashes the browser

VERIFIED FIXED in mozilla0.9



18 years ago
10 years ago


(Reporter: Balwinder.Sohi, Assigned: jst)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [HAVE FIX] suntrak-n6-highp, URL)


(3 attachments)



18 years ago
1.The above mentioned urls are under DOM-Html tests.Click on either one of these
urls or goto tests under HTMLModElement link .The tests for properties 'cite' or
''date/time' when clicked open up a window displaying a result.
2.When this new window is clicked closed from File>Close , whole of the browser
components (if open) are pulled down ie the browser crashed.If the crash does
not occur the first time , second time it will surely do.Just repeat the steps.


18 years ago
Whiteboard: suntrak-n6-highp

Comment 1

18 years ago
I don't see this problem here, what version of mozilla are you using? Can you
provide a stack trace of the crash?


18 years ago
Keywords: crash

Comment 2

18 years ago
Worksforme, we need more info to resolve this, please reopen and supply more
info if this still happens.
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 3

18 years ago
This bug happens for me using:
Mozilla/5.0 (X11; U; SunOS 5.7 sun4u; en-US; m18) Gecko/2000120721

I can get mozilla to crash by loading and reloading multiple times this url:
It will also crash sometimes if I close the window from the same url.
I will include the stack trace for each case

Comment 4

18 years ago
Created attachment 20692 [details]
stack trace for window close crash

Comment 5

18 years ago
Created attachment 20693 [details]
stack trace for reload crash

Comment 6

18 years ago
Ok, now I also see the problem after reloading the page about 5 times. I found
the problem and I'll attach a diff in a while.
Resolution: WORKSFORME → ---

Comment 7

18 years ago
Created attachment 20736 [details] [diff] [review]
Proposed fix

Comment 8

18 years ago
So, the problem was that the content sink ended up creating the wrong type of
element objects when it saw the <del> and <ins> elements (the sink ended up
creating a span element). Later on when mozilla tried to create a script object
for those elements it tried to QI into nsIDOMHTML{Del,Ins}Element and that
failed so we never got the script object but we still did an AddNamedReference()
but since there was no script object we never did a RemoveReference() so the we
crashed in the JS GC referencing deleted memory.

Brendan, sr=? (PS. There's a minor cleanup in the end of the patch that is not
required, I just forgot to remove it. That cleanup could go in anyway, lemme
know if there's a reason not to check that in.)
OS: Solaris → All
Hardware: Sun → All
Target Milestone: --- → mozilla0.9


18 years ago
Whiteboard: suntrak-n6-highp → [HAVE FIX] suntrak-n6-highp

Comment 9

18 years ago
Brendan, never mind, so scc sr'd this and ben reviewed so this is checked in now.
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED
*** Bug 46030 has been marked as a duplicate of this bug. ***
*** Bug 46003 has been marked as a duplicate of this bug. ***
Wow! I just found that this bug was the cause of 2 bugs on joki's list - events
not working for DEL & INS element. I just marked them dupes. 3 dead bugs in one

When you verify, please test those bugs as well (they have testcases, but note
that key events should NOT work even though the testcases include them).

Comment 13

18 years ago
*** Bug 62608 has been marked as a duplicate of this bug. ***
Component: DOM Level 1 → DOM HTML

Comment 14

18 years ago
QA contact Update
QA Contact: janc → desale

Comment 15

18 years ago
Updating QA contact to Shivakiran Tummala.
QA Contact: desale → stummala

Comment 16

18 years ago
does not crash anymore ---verified 


10 years ago
Component: DOM: HTML → DOM: Core & HTML
QA Contact: stummala → general
You need to log in before you can comment on or make changes to this bug.