Closed
Bug 484458
Opened 16 years ago
Closed 15 years ago
body onload="alert(1)" crashes Firefox after reload
Categories
(Core :: Widget: Gtk, defect)
Tracking
()
VERIFIED
FIXED
People
(Reporter: brewsterdesigns, Assigned: karlt)
References
Details
(Keywords: crash, testcase, verified1.9.0.11, Whiteboard: [sg:dupe 451341][fixed in bug 451341])
Attachments
(2 files)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009030422 Ubuntu/8.10 (intrepid) Firefox/3.0.7 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.7) Gecko/2009030422 Ubuntu/8.10 (intrepid) Firefox/3.0.7 Including ANY javascript in the body onload attribute causes Firefox to crash when reloaded a few times. Original problem was I had a page which opened another page in a new window that printed automatically (onload="window.print() ). If I reloaded that page, firefox would immediately crash. This was reproducible every time. Reproducible: Always Steps to Reproduce: 1) Create html page with dynamic content such as below php: <html> <body onload="window.alert('a')"> <?=rand(0,100);?> </body> </html> 2) Have some javascript run for the body onload event (alert() or print() ) 3) Load the page, wait 10 seconds, press reload. Repeat until crashes - usually only takes 1 or 2 times.. Actual Results: Firefox crashes immediately Expected Results: The page to load normally In my tests the actual javascript is irrelevant. The dynamic content seems important. Waiting the 5-10 seconds between reloads seems important (maybe when the cache expires or something??) Reproducible on multiple computers, including fresh install of ubuntu 8.10 and latest firefox.
Updated•15 years ago
|
Component: General → DOM: Core & HTML
Keywords: crash,
testcase-wanted
Product: Firefox → Core
QA Contact: general → general
Comment 1•15 years ago
|
||
So far haven't been able to reproduce using 1.9.0.x. But I'm not sure I'm using the right testcase: <html> <body onload="window.alert('a')"> alert test </body> </html> Is the <?=rand(0,100);?> relevant here? Are you using Firefox downloaded from Mozilla, or build provided by Ubuntu?
Comment 2•15 years ago
|
||
The random content will be generated by the server so what Firefox gets should be equivalent to the statis text in comment 1, but maybe it triggers PHP to send different headers that are relevant to this bug. It might be headers specific to your server setup, even. Could you give us a link to a test page that you see the problem with?
Comment 3•15 years ago
|
||
This issue might be related to Linux, I can reproduce this on Foresight Linux (Firefox 3.0.7) and Fedora 10 (Firefox 3.0.7). I'm using the following local file /tmp/test.html: <html> <body onload="window.alert('a')"> </body> </html> And opened firefox using: firefox /tmp/test.html Using a 10 sec interval reload (Ctrl-R) will crash firefox in about 2 tries.
Comment 4•15 years ago
|
||
(In reply to comment #1) > So far haven't been able to reproduce using 1.9.0.x. This testing was done one a Fedora-based x86_64 Linux. Will test on 32bit Fedora 10.
Comment 6•15 years ago
|
||
I can reproduce this on Fedora 10.
Updated•15 years ago
|
Status: UNCONFIRMED → NEW
Component: DOM: Core & HTML → Widget: Gtk
Ever confirmed: true
QA Contact: general → gtk
Comment 7•15 years ago
|
||
Could anyone try to find the regression range? http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/
Comment 8•15 years ago
|
||
Though, perhaps this is a regression in gtk2.
Comment 9•15 years ago
|
||
This is a backtrace from gdb by using a core dump.
Assignee | ||
Comment 10•15 years ago
|
||
Thanks for the helpful backtrace. This has the same cause (and fix) as bug 451341. The crash is trying to AddRef an nsWindow. 0x00000000000002f1 in ?? () (gdb) up #1 0x00007f06c4fbfaa1 in nsRefPtr (this=0x7fffdada9000, aRawPtr=0x247c420) at ../../../dist/include/xpcom/nsAutoPtr.h:980 980 mRawPtr->AddRef(); (gdb) up #2 0x00007f06c4fbac08 in leave_notify_event_cb (widget=0x20bfaa0, event=0x2d60c20) at /home/karl/moz/cvs/mozilla/widget/src/gtk2/nsWindow.cpp:4636 4636 nsRefPtr<nsWindow> window = get_window_for_gdk_window(event->window); The nsWindow comes from a destroyed (but not deleted) GdkWindow. (gdb) p event->window $1 = (GdkWindow *) 0x2c98000 (gdb) p *(GdkWindowObject*)event->window $2 = {parent_instance = {parent_instance = {g_type_instance = { g_class = 0x1f52dd0}, ref_count = 3, qdata = 0x2d53e00}}, impl = 0x2c980a0, parent = 0x0, user_data = 0x0, x = 0, y = 0, extension_events = 0, filters = 0x0, children = 0x0, bg_color = {pixel = 0, red = 0, green = 0, blue = 0}, bg_pixmap = 0x2, paint_stack = 0x0, update_area = 0x0, update_freeze_count = 0, window_type = 2 '\002', depth = 24 '\030', resize_count = 0 '\0', state = GDK_WINDOW_STATE_WITHDRAWN, guffaw_gravity = 0, input_only = 0, modal_hint = 0, composited = 0, destroyed = 1, accept_focus = 1, focus_on_map = 1, shaped = 0, event_mask = 176902, update_and_descendants_freeze_count = 0, redirect = 0x0} (gdb) p event->window->parent_instance.qdata $3 = (GData *) 0x2d53e00 gdb) x /4a 0x2d53e00 0x2d53e00: 0x299bfa0 0x33 0x2d53e10: 0x2a7ff40 0x7f06cec480ca <weak_refs_notify> (gdb) x /4a 0x299bfa0 0x299bfa0: 0x2956c80 0x34b 0x299bfb0: 0x2975200 0x0 (gdb) p ((char*(*)())g_quark_to_string)(0x34b) [Thread 0x5d5a6950 (LWP 5461) exited] $4 = 0x2351c80 "mozdrawingarea" (gdb) x /4a 0x2956c80 0x2956c80: 0x0 0x34a 0x2956c90: 0x247c420 0x0 (gdb) p ((char*(*)())g_quark_to_string)(0x34a) $5 = 0x2351030 "nsWindow" The nsWindow looks like it has been destroyed, and most likely deleted too (though mRefCnt is still 1 due to Mozilla's ref counting leaving a refcnt of 1 on deleted objects. http://hg.mozilla.org/mozilla-central/annotate/7348ed185ae2/xpcom/glue/nsISupportsImpl.h#l311) (gdb) p *(nsWindow*)0x247c420 $6 = {<nsCommonWidget> = {<nsBaseWidget> = {<nsIWidget> = {<nsISupports> = { _vptr.nsISupports = 0x2d23780}, mFirstChild = { mRawPtr = 0x7f06cddb1d40}, mLastChild = 0x0, mNextSibling = { mRawPtr = 0x0}, mPrevSibling = 0x0}, mRefCnt = {mValue = 1}, _mOwningThread = {mThread = 0x1f2aa20}, mClientData = 0x0, mEventCallback = 0x7f06c26f97ea <HandleEvent>, mContext = 0x0, mToolkit = 0x0, mMouseListener = 0x0, mEventListener = 0x0, mBackground = 36073648, mForeground = 0, mCursor = eCursor_standard, mWindowType = eWindowType_child, mBorderStyle = eBorderStyle_default, mIsShiftDown = 0 '\0', mIsControlDown = 0 '\0', mIsAltDown = 0 '\0', mIsDestroying = 0 '\0', mOnDestroyCalled = 1 '\001', mBounds = {x = 0, y = 0, width = 1091, height = 605}, mOriginalBounds = 0x0, mZIndex = 0, mSizeMode = nsSizeMode_Normal}, mParent = {mRawPtr = 0x0}, mIsTopLevel = 0 '\0', mIsDestroyed = 1 '\001', mNeedsResize = 0 '\0', mNeedsMove = 0 '\0', mListenForResizes = 0 '\0', mIsShown = 1 '\001', mNeedsShow = 0 '\0', mEnabled = 1, mCreated = 0, mPlaced = 1, mPreferredWidth = 0, mPreferredHeight = 0}, <nsSupportsWeakReference> = {<nsISupportsWeakReference> = {<nsISupports> = {_vptr.nsISupports = 0x7f06d18c3770}, <No data fields>}, mProxy = 0x0}, <nsIKBStateControl> = {<nsISupports> = { _vptr.nsISupports = 0x7f06c5239aa0}, <No data fields>}, mOldFocusWindow = 0, mIMEData = 0x0, mShell = 0x0, mContainer = 0x0, mDrawingarea = 0x0, mWindowGroup = 0x0, mContainerGotFocus = 0, mContainerLostFocus = 0, mContainerBlockFocus = 0, mIsVisible = 1, mRetryPointerGrab = 0, mActivatePending = 0, mRetryKeyboardGrab = 0, mTransientParent = 0x0, mSizeState = 0, mPluginType = nsWindow::PluginType_NONE, mTransparencyBitmapWidth = 0, mTransparencyBitmapHeight = 0, mThebesSurface = {mRawPtr = 0x0}, mRootAccessible = {mRawPtr = 0x0}, mIsTransparent = 0, mTransparencyBitmap = 0x0, mDragMotionWidget = 0x0, mDragMotionContext = 0x0, mDragMotionX = 0, mDragMotionY = 0, mDragMotionTime = 0, mDragMotionTimerID = 0, mDragLeaveTimer = { mRawPtr = 0x0}, mKeyDownFlags = {0, 0, 0, 0, 0, 0, 0, 0}}
Assignee: nobody → mozbugz
Depends on: 451341
Assignee | ||
Updated•15 years ago
|
Version: unspecified → 1.9.0 Branch
Updated•15 years ago
|
Group: core-security
Flags: wanted1.9.0.x+
Flags: blocking1.9.0.10+
Whiteboard: [sg:dupe 451341]
Comment 11•15 years ago
|
||
This testcase is based on the description in the comments, but I can't test the crash on my mac. If this doesn't reproduce the crash for those who have been able to see it please let me know so we can mark this obsolete and try again. Hopefully meta-refresh isn't any different than a manual Ctrl-r for this case -- keyboard events don't seem to be involved anywhere.
Updated•15 years ago
|
Keywords: testcase-wanted → testcase
Comment 12•15 years ago
|
||
The testcase indeed aborts Firefox on Fedora 10.
Assignee | ||
Comment 13•15 years ago
|
||
The crash is only reproducible if the pointer is over the child window for the document (as it is likely to be after clicking the alert). The crash doesn't occur when the mouse is over any chrome around the document.
Assignee | ||
Updated•15 years ago
|
Status: NEW → RESOLVED
Closed: 15 years ago
Keywords: fixed1.9.0.10
Resolution: --- → FIXED
Whiteboard: [sg:dupe 451341] → [sg:dupe 451341][fixed in bug 451341]
It doesn't affect 1.8 line.
Flags: wanted1.8.1.x-
Comment 15•15 years ago
|
||
Verified fixed in 1.9.0.11 with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.11pre) Gecko/2009051104 GranParadiso/3.0.11pre. I verified the crash with 1.9.0.10 first.
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.0.11 → verified1.9.0.11
Updated•14 years ago
|
Group: core-security
You need to log in
before you can comment on or make changes to this bug.
Description
•