browser crashes when executing document.write(varibale)

VERIFIED WORKSFORME

Status

()

P3
major
VERIFIED WORKSFORME
19 years ago
18 years ago

People

(Reporter: czhang, Assigned: hjtoi-bugzilla)

Tracking

({crash})

Trunk
x86
Windows NT
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

19 years ago
load 5/30 build
1. go to http://cathyz2/sameori/dom/getAttr.html
2. click the first button
expect to see the word of "button" displayed in the page
result: browser crashes, or back and forth the browser crashes finally

the code is :
 <HTML>
<HEAD>
<TITLE></TITLE>
<script>
  function getattr1() {
    document.write(document.f0.e0.getAttribute("type"));
  }
</script>
</HEAD>
<BODY>

<FORM NAME="f0">

<INPUT TYPE="button"
       NAME="e0"
       VALUE="type"
       onClick="getattr1()">

</FORM>

</BODY>
</HTML>

Comment 1

18 years ago
Adding crash to keyword field.
Keywords: crash

Updated

18 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

18 years ago
Created attachment 9818 [details]
testcase

Comment 3

18 years ago
Does not crash on Win98 using build 2000060809.
(Reporter)

Comment 4

18 years ago
it happens on 6/08 M16 build NT 4.0

Comment 5

18 years ago
I don't get any crash, either on Linux or WinNT.
Using: Linux and Windows tip builds made on 06/26/00.

Marking WORKSFORME -
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 6

18 years ago
it is not happening on 6/27 NT build
Status: RESOLVED → VERIFIED

Comment 7

18 years ago
OOPS!!!  I don't crash merely by clicking the "type" button, but ....

Reopening - if I go to the attachment, click the button marked "type",
then click the Back button on the browser, I crash on WinNT with the 
stack trace below. I do not crash on Linux. Note: before I click the 
Back button, there are no JavaScript errors in the JavaScript console.

I should note, if I open the attachment in NN4.7 and click the "type"
button, I don't crash, but the word "button" is not displayed. 
Instead, I get the following error:

JavaScript Error:
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=9818, line 6:

document.f0.e0.getAttribute is not a function.


STACK TRACE FOR MOZILLA ON WINNT
(clicking "type" button, and then Back button on browser):

nsGenericElement::HandleDOMEvent(nsIPresContext * 0x032eb2c0, nsEvent * 
0x0012ef28, nsIDOMEvent * * 0x0012eaa8, unsigned int 1, nsEventStatus * 
0x0012ef4c) line 1369 + 33 bytes
nsHTMLInputElement::HandleDOMEvent(nsHTMLInputElement * const 0x033776dc, 
nsIPresContext * 0x032eb2c0, nsEvent * 0x0012ef28, nsIDOMEvent * * 0x00000000, 
unsigned int 1, nsEventStatus * 0x0012ef4c) line 813 + 31 bytes
nsEventStateManager::PreHandleEvent(nsEventStateManager * const 0x038e8418, 
nsIPresContext * 0x037d2800, nsEvent * 0x0012f1e8, nsIFrame * 0x02d1feac, 
nsEventStatus * 0x0012f150, nsIView * 0x03980500) line 356
PresShell::HandleEventInternal(nsEvent * 0x0012f1e8, nsIView * 0x03980500, 
nsEventStatus * 0x0012f150) line 3896 + 43 bytes
PresShell::HandleEvent(PresShell * const 0x037d3c04, nsIView * 0x03980500, 
nsGUIEvent * 0x0012f1e8, nsEventStatus * 0x0012f150, int & 1) line 3837 + 23 
bytes
nsView::HandleEvent(nsView * const 0x03980500, nsGUIEvent * 0x0012f1e8, unsigned 
int 8, nsEventStatus * 0x0012f150, int & 1) line 782
nsView::HandleEvent(nsView * const 0x037d22b0, nsGUIEvent * 0x0012f1e8, unsigned 
int 28, nsEventStatus * 0x0012f150, int & 1) line 755
nsViewManager2::DispatchEvent(nsViewManager2 * const 0x037d24f0, nsGUIEvent * 
0x0012f1e8, nsEventStatus * 0x0012f150) line 1389
HandleEvent(nsGUIEvent * 0x0012f1e8) line 69
nsWindow::DispatchEvent(nsWindow * const 0x039803d4, nsGUIEvent * 0x0012f1e8, 
nsEventStatus & nsEventStatus_eIgnore) line 560 + 10 bytes
nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f1e8) line 581
nsWindow::DispatchFocus(unsigned int 105) line 3825 + 15 bytes
nsWindow::ProcessMessage(unsigned int 7, unsigned int 16451088, long 0, long * 
0x0012f52c) line 2887 + 19 bytes
nsWindow::WindowProc(HWND__ * 0x002f06b4, unsigned int 7, unsigned int 16451088, 
long 0) line 829 + 27 bytes
USER32! 77e719d0()
USER32! 77e71982()
NTDLL! 77f763a3()
nsView::~nsView() line 161
nsView::`scalar deleting destructor'(unsigned int 1) + 15 bytes
nsView::Destroy(nsView * const 0x0332b120) line 259 + 34 bytes
nsFrame::Destroy(nsFrame * const 0x02c06de0, nsIPresContext * 0x032eb2c0) line 
425
nsContainerFrame::Destroy(nsContainerFrame * const 0x02c06de0, nsIPresContext * 
0x032eb2c0) line 99
ViewportFrame::Destroy(ViewportFrame * const 0x02c06de0, nsIPresContext * 
0x032eb2c0) line 144
FrameManager::~FrameManager() line 383
FrameManager::`scalar deleting destructor'(unsigned int 1) + 15 bytes
FrameManager::Release(FrameManager * const 0x0332a1a0) line 362 + 157 bytes
PresShell::~PresShell() line 1099 + 27 bytes
PresShell::`scalar deleting destructor'() + 15 bytes
PresShell::Release(PresShell * const 0x0332aa70) line 1015 + 158 bytes
nsCOMPtr<nsIPresShell>::~nsCOMPtr<nsIPresShell>() line 490
DocumentViewerImpl::~DocumentViewerImpl() line 439 + 97 bytes
DocumentViewerImpl::`scalar deleting destructor'(unsigned int 1) + 15 bytes
DocumentViewerImpl::Release(DocumentViewerImpl * const 0x032f8740) line 348 + 
154 bytes
nsCOMPtr<nsIContentViewer>::assign_assuming_AddRef(nsIContentViewer * 
0x00000000) line 472
nsCOMPtr<nsIContentViewer>::assign_with_AddRef(nsISupports * 0x00000000) line 
849
nsCOMPtr<nsIContentViewer>::operator=(nsIContentViewer * 0x00000000) line 584
nsDocShell::SetupNewViewer(nsDocShell * const 0x03980c30, nsIContentViewer * 
0x033a7c90) line 2282
nsWebShell::SetupNewViewer(nsWebShell * const 0x03980c30, nsIContentViewer * 
0x033a7c90) line 560 + 13 bytes
nsDocShell::CreateContentViewer(nsDocShell * const 0x03980c30, const char * 
0x0012fb04, nsIChannel * 0x0339f980, nsIStreamListener * * 0x0012fb58) line 2171 
+ 24 bytes
nsDSURIContentListener::DoContent(nsDSURIContentListener * const 0x03980910, 
const char * 0x0012fb04, int 0, const char * 0x1009ebe0 gCommonEmptyBuffer, 
nsIChannel * 0x0339f980, nsIStreamListener * * 0x0012fb58, int * 0x0012fae8) 
line 100 + 33 bytes
nsDocumentOpenInfo::DispatchContent(nsIChannel * 0x0339f980, nsISupports * 
0x00000000) line 357 + 109 bytes
nsDocumentOpenInfo::OnStartRequest(nsDocumentOpenInfo * const 0x0339e780, 
nsIChannel * 0x0339f980, nsISupports * 0x00000000) line 231 + 16 bytes
nsFileChannel::OnStartRequest(nsFileChannel * const 0x0339f988, nsIChannel * 
0x0337c1c0, nsISupports * 0x00000000) line 615
nsOnStartRequestEvent::HandleEvent(nsOnStartRequestEvent * const 0x0337b7a0) 
line 210 + 26 bytes
nsStreamListenerEvent::HandlePLEvent(PLEvent * 0x0337b510) line 97 + 12 bytes
PL_HandleEvent(PLEvent * 0x0337b510) line 575 + 10 bytes
PL_ProcessPendingEvents(PLEventQueue * 0x01478660) line 520 + 9 bytes
_md_EventReceiverProc(HWND__ * 0x117c0104, unsigned int 49351, unsigned int 0, 
long 21464672) line 1032 + 9 bytes
USER32! 77e71820()
01478660()
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---

Comment 8

18 years ago
Cathy, does this happen to you, too? 

 
 
Component: Javascript Engine → Event Handling

Comment 9

18 years ago
Still crashing on WinNT, but not Linux. Tip builds from 6/27, 7PM Pacific.
To reproduce: open the attachment in Mozilla, and click the "type" button.
Then click the Back button on the browser; crash. The line that's crashing is: 

if (mParent) {
    // Pass off to our parent.
    mParent->HandleDOMEvent(aPresContext, aEvent, aDOMEvent,                                                                                                                                                                                                                                             
                                 NS_EVENT_FLAG_CAPTURE, aEventStatus);


Reassigning to Event Handling; doesn't appear to be a JS Engine issue -
Assignee: rogerl → joki
Status: REOPENED → NEW
QA Contact: pschwartau → janc

Comment 10

18 years ago
We have another bad mParent pointer.  These are supposed to get nulled out when 
they go bad.  Not sure why this one isn't.
Status: NEW → ASSIGNED
Is this supposed to be fixed by bug 44266 ?
If so, then this should work in 7/12 and later builds.
I am starting to handle joki's bugs while he is away...
Assignee: joki → heikki
Status: ASSIGNED → NEW
I just pulled and did a fresh build (NT). I don't get a crash with the 
test case (press button, back, forward). So it looks like the fix to bug 44266 
fixed this too.

Marking worksforme.
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 14

18 years ago
Mass update:  changing qacontact to ckritzer@netscape.com
QA Contact: janc → ckritzer

Comment 15

18 years ago
Marking VERIFIED WORKSFORME on:
- LinuxRH62 2000-09-08-08-M18 Commercial
- Win98     2000-09-08-08-M18 Mozilla
- MacOS86   2000-09-07-04-M18 Commercial
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.