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)

Product:
Core
Component:
XUL
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
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.