272578 - Browser crash [@ nsFrameManager::CaptureFrameStateFor] caused by nested XUL tooltip tag

Status: RESOLVED FIXED

(Core :: XUL, defect)

Description

[Craig]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

In developing the SearchStatus extension, I encountered a mysterious and
intermittent bug that caused a program crash, especially on closing the browser.
After MUCH effort, I managed to track it down to having a nested <tooltip> tag
inside a <statusbarpanel> tag. The exception occurs in nsFrameManager, line 1728.

Here is a talkback report of an incident:
http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB2106832Q

Here is some simple XUL to demonstrate the problem:

<?xml version="1.0"?>

<?xml-stylesheet href="chrome://searchstatus/skin/searchstatus.css"
type="text/css"?> 

<overlay id="searchstatus-overlay"
xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> 

	<statusbar id="status-bar">
	
	  <hbox id="searchstatus-bar">
				<statusbarpanel class="statusbarpanel-menu-iconic" id="searchstatus-status"
tooltip="searchstatus-tooltip" context="searchstatus-popup">
					<tooltip id="searchstatus-tooltip">
					  <description id="searchstatus-tooltip-value" value="Context menu for
options" style="margin:0px;"/>
					</tooltip>					
				</statusbarpanel>
		</hbox>
	
	</statusbar>
		
</overlay> 

The bug is very intermittent and difficult to test against, but it does occur.
The URL field above points to a version of SearchStatus that exhibits the problem.

Reproducible: Sometimes
Steps to Reproduce:
1. Install an extension that uses the XUL provided
2. Open the browser and a few tabs, possibly to the chrome:// URL
3. Close the browser

Actual Results:  
Program crashed

Expected Results:  
Closed normally

Talkback: TB2106832Q
Theme: default

Comment 1

[Nickolay_Ponomarev]

"Incident Not Found.

No entry for Incident ID: 2106832 (it has been deleted from the database)

The oldest incident id currently in the database is 3711410.
If the incident you are looking for is smaller than that, it is no longer
available."

Could you try to reproduce this on recent trunk build
<http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/>,
submit a new talkback report and post its ID here?

In future, please add "talkbackid" keyword to Keywords field when posting
incident id - to increase odds of someone looking at the report before it gets
deleted.

Comment 2

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 3

[Martijn Wargers (dead)]

I can confirm the crash on shutdown with current trunk build.
Talkback ID: TB10169276H
I've tried to get a backtrace with my debug build, and it crashes alright on
shutdown, but I get no backtrace.

This bug needs a testcase that doesn't need an installed extension to see the crash.

Comment 4

[Martijn Wargers (dead)]

Attachment: testcase

Ok, this is the minimal testcase that still crashes when hovering over the
statusbar, waiting for the tooltip to appear, and then close the tab/window.

Comment 5

[Martijn Wargers (dead)]

Seems to me some sort of xbl issue.

Comment 6

[Martijn Wargers (dead)]

Attachment: backtrace

With my debug build I now get a nice backtrace for the testcase.
Looking at the backtrace, this seems similar to bug 288763.

Comment 7

[Boris Zbarsky [:bzbarsky]]

So when we get into nsMenuFrame::DestroyPopupFrames mPopupFrames.FirstChild() is
already destroyed.

Chances are, the mess that is popup frame construction fails to properly clean
up something somewhere...  I bet the xbl is only needed to trigger a frame
reconstruct.

Comment 8

[[e-mail]]

I do have to ask why you're using a statusbarpanel-menu-iconic without a submenu; the menu code then thinks that the tooltip is your submenu... d'oh!

Comment 9

[Martijn Wargers (dead)]

This is worksforme with 2006-08-04 trunk build, most likely fixed by bug 288763.