Closed Bug 53885 Opened 24 years ago Closed 24 years ago

Crash clicking on <tab> that has no matching <tabpanel> content

Categories

(Core :: XUL, defect, P3)

defect

Tracking

()

VERIFIED FIXED
mozilla0.8

People

(Reporter: jrgmorrison, Assigned: eric)

Details

(Keywords: crash)

The following XUL crashes, because there is no panel to correspond with the second <tab>. <?xml version="1.0"?> <?xml-stylesheet href="chrome://global/skin" type="text/css"?> <window orient="vertical" xmlns:html="http://www.w3.org/TR/REC-html40" xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> <html> Click on the second tab to crash (since there is no box to show). </html> <tabcontrol orient="vertical"> <tabbox orient="horizontal"> <tab value="Tab 1" /> <tab value="Tab Without a Panel -- crashes" /> </tabbox> <tabpanel flex="1"> <text value="Panel 1"/> </tabpanel> </tabcontrol> </window> Stack is below. I think just need a null check to prevent this. nsDeckFrame::ShowBox(nsIPresContext * 0x03463f48, nsIBox * 0x00000000) line 227 + 7 bytes nsDeckFrame::IndexChanged(nsIPresContext * 0x03463f48) line 261 nsDeckFrame::AttributeChanged(nsDeckFrame * const 0x0346b6e4, nsIPresContext * 0x03463f48, nsIContent * 0x033e4e58, int 0, nsIAtom * 0x00cace70, int 3) line 187 nsCSSFrameConstructor::AttributeChanged(nsCSSFrameConstructor * const 0x03280300, nsIPresContext * 0x03463f48, nsIContent * 0x033e4e58, int 0, nsIAtom * 0x00cace70, int 2) line 10052 + 35 bytes StyleSetImpl::AttributeChanged(StyleSetImpl * const 0x03280240, nsIPresContext * 0x03463f48, nsIContent * 0x033e4e58, int 0, nsIAtom * 0x00cace70, int -1) line 1195 PresShell::AttributeChanged(PresShell * const 0x0350f548, nsIDocument * 0x034cb450, nsIContent * 0x033e4e58, int 0, nsIAtom * 0x00cace70, int -1) line 3634 + 57 bytes nsXULDocument::AttributeChanged(nsXULDocument * const 0x034cb450, nsIContent * 0x033e4e58, int 0, nsIAtom * 0x00cace70, int -1) line 1643 nsXULElement::SetAttribute(nsXULElement * const 0x033e4e58, nsINodeInfo * 0x03267da8, const basic_nsAReadableString<unsigned short> & {...}, int 1) line 2772 nsXULElement::SetAttribute(nsXULElement * const 0x033e4e5c, const basic_nsAReadableString<unsigned short> & {...}, const basic_nsAReadableString<unsigned short> & {...}) line 1246 + 31 bytes ElementSetAttribute(JSContext * 0x030b0308, JSObject * 0x02fd0dc8, unsigned int 2, long * 0x03271094, long * 0x0012c304) line 239 + 26 bytes js_Invoke(JSContext * 0x030b0308, unsigned int 2, unsigned int 0) line 820 + 23 bytes js_Interpret(JSContext * 0x030b0308, long * 0x0012ce38) line 2621 + 15 bytes js_Invoke(JSContext * 0x030b0308, unsigned int 1, unsigned int 2) line 837 + 13 bytes js_InternalInvoke(JSContext * 0x030b0308, JSObject * 0x02fd0dc8, long 50138600, unsigned int 0, unsigned int 1, long * 0x0012d93c, long * 0x0012d93c) line 909 + 20 bytes js_SetProperty(JSContext * 0x030b0308, JSObject * 0x02fd0dc8, long 12825872, long * 0x0012d93c) line 2242 + 47 bytes js_Interpret(JSContext * 0x030b0308, long * 0x0012dac4) line 2480 + 1578 bytes js_Invoke(JSContext * 0x030b0308, unsigned int 1, unsigned int 2) line 837 + 13 bytes js_InternalInvoke(JSContext * 0x030b0308, JSObject * 0x02fd0df0, long 50138648, unsigned int 0, unsigned int 1, long * 0x0012e5c8, long * 0x0012e5c8) line 909 + 20 bytes js_SetProperty(JSContext * 0x030b0308, JSObject * 0x02fd0df0, long 54897968, long * 0x0012e5c8) line 2242 + 47 bytes js_Interpret(JSContext * 0x030b0308, long * 0x0012e750) line 2480 + 1578 bytes js_Invoke(JSContext * 0x030b0308, unsigned int 1, unsigned int 2) line 837 + 13 bytes js_InternalInvoke(JSContext * 0x030b0308, JSObject * 0x02fd0ea0, long 53439512, unsigned int 0, unsigned int 1, long * 0x0012e8e8, long * 0x0012e878) line 909 + 20 bytes JS_CallFunctionValue(JSContext * 0x030b0308, JSObject * 0x02fd0ea0, long 53439512, unsigned int 1, long * 0x0012e8e8, long * 0x0012e878) line 3181 + 31 bytes nsJSContext::CallEventHandler(nsJSContext * const 0x030b02a0, void * 0x02fd0ea0, void * 0x032f6c18, unsigned int 1, void * 0x0012e8e8, int * 0x0012e8e4, int 0) line 906 + 33 bytes nsJSEventListener::HandleEvent(nsIDOMEvent * 0x035da574) line 154 + 64 bytes nsXBLPrototypeHandler::ExecuteHandler(nsXBLPrototypeHandler * const 0x03520820, nsIDOMEventReceiver * 0x033e4dd8, nsIDOMEvent * 0x035da574) line 307 DoMouse(nsIAtom * 0x00d88d58, nsIXBLPrototypeHandler * 0x03520820, nsIDOMEvent * 0x035da574, nsIDOMEventReceiver * 0x033e4dd8) line 103 nsXBLMouseHandler::MouseClick(nsIDOMEvent * 0x035da574) line 118 + 34 bytes nsEventListenerManager::HandleEvent(nsIPresContext * 0x03463f48, nsEvent * 0x0012f410, nsIDOMEvent * * 0x0012f32c, nsIDOMEventTarget * 0x033e4dd8, unsigned int 7, nsEventStatus * 0x0012f730) line 865 + 23 bytes nsXULElement::HandleDOMEvent(nsXULElement * const 0x033e4dd0, nsIPresContext * 0x03463f48, nsEvent * 0x0012f410, nsIDOMEvent * * 0x0012f32c, unsigned int 1, nsEventStatus * 0x0012f730) line 3318 PresShell::HandleEventInternal(nsEvent * 0x0012f410, nsIView * 0x00000000, unsigned int 1, nsEventStatus * 0x0012f730) line 4255 + 47 bytes PresShell::HandleEventWithTarget(PresShell * const 0x0350f540, nsEvent * 0x0012f410, nsIFrame * 0x0346badc, nsIContent * 0x033e4dd0, unsigned int 1, nsEventStatus * 0x0012f730) line 4236 + 22 bytes nsEventStateManager::CheckForAndDispatchClick(nsEventStateManager * const 0x03472c50, nsIPresContext * 0x03463f48, nsMouseEvent * 0x0012f840, nsEventStatus * 0x0012f730) line 1854 + 61 bytes nsEventStateManager::PostHandleEvent(nsEventStateManager * const 0x03472c58, nsIPresContext * 0x03463f48, nsEvent * 0x0012f840, nsIFrame * 0x0346badc, nsEventStatus * 0x0012f730, nsIView * 0x03573d30) line 935 + 28 bytes PresShell::HandleEventInternal(nsEvent * 0x0012f840, nsIView * 0x03573d30, unsigned int 1, nsEventStatus * 0x0012f730) line 4275 + 43 bytes PresShell::HandleEvent(PresShell * const 0x0350f544, nsIView * 0x03573d30, nsGUIEvent * 0x0012f840, nsEventStatus * 0x0012f730, int 1, int & 1) line 4190 + 25 bytes nsView::HandleEvent(nsView * const 0x03573d30, nsGUIEvent * 0x0012f840, unsigned int 28, nsEventStatus * 0x0012f730, int 1, int & 1) line 379 nsViewManager2::DispatchEvent(nsViewManager2 * const 0x035bf070, nsGUIEvent * 0x0012f840, nsEventStatus * 0x0012f730) line 1429 HandleEvent(nsGUIEvent * 0x0012f840) line 68 nsWindow::DispatchEvent(nsWindow * const 0x02f9702c, nsGUIEvent * 0x0012f840, nsEventStatus & nsEventStatus_eIgnore) line 681 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f840) line 702 nsWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 3890 + 21 bytes ChildWindow::DispatchMouseEvent(unsigned int 301, nsPoint * 0x00000000) line 4100 nsWindow::ProcessMessage(unsigned int 514, unsigned int 0, long 1638505, long * 0x0012fbbc) line 2960 + 24 bytes nsWindow::WindowProc(HWND__ * 0x007c0214, unsigned int 514, unsigned int 0, long 1638505) line 950 + 27 bytes USER32! 77e13eb0() USER32! 77e1401a() USER32! 77e192da() nsAppShellService::Run(nsAppShellService * const 0x00c020b8) line 408 main1(int 1, char * * 0x00497210, nsISupports * 0x00000000) line 1004 + 32 bytes main(int 1, char * * 0x00497210) line 1185 + 37 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 77e87903()
-> Future (unless evaughan disagrees with me). This is one of a number of robustness fixes that need to happen, but not before RTM, since this is not known to affect end-users in the NS6 product. This could be fixed on the Mozilla trunk, though.
Target Milestone: --- → Future
By the way, this is an offshoot from bug 53150.
Doh! on neglecting to add corresponding tabpanel children to the tabbox tabs, but the static XUL was working. So I added code to maintain the correspondence, and still get the crash with the classic theme but not the modern theme, and found that the only way to satisfy the invariant that tabbox.childNodes.length == tabpanel.childNodes.length is to add the new tabpanel child first, then the new tab. Adding the new tab first still triggers the seg fault with the classic skin. With the modern skin no problem is observed.
*spam* adding crash keyword...
Keywords: crash
I don't understand your last comment, ericp. Your original testcase does not crash when inserting the <tab> in either skin for a build after 09/19 evening when danm checked his fix in. It does crash when you click on the tab for the reason described in this bug report, but if I modify your testcase to insert both a <tab> and a corresponding bit of content to the <tabpanel> _in_any_order_, I do not crash. I think you are confusing this bug (not fixed), and the original bug (fixed) -- the stack traces are a dead giveaway -- the crash with the classic skin when adding the <tab> was a deep recursion, this one is simply a null pointer dereference.
I neglected to point out that I've been running this stuff on build 2000091312 all this time. I'm probably way out of date now.
eric: keep in mind that all new hand-made builds have a build ID of 2000091312 (which is a separate bug)...so it might not be as old as you think...
Just to be clear: this bug is only for the case where you create a <tab> with no corresponding <tabpanel> contents. That is independent of the skin, and is in now way related to the infinitely recursive stack noted on bug bug 53150, or to the recent crash for tabcontrols noted in bug 54747.
Status: NEW → ASSIGNED
Target Milestone: Future → mozilla0.8
fixed
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
verified fixed win2k/linux 2001011021 builds (actually works quite well with a missing panel, either skin).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.