2.09 KB, application/x-xpinstall
80 bytes, text/css
720 bytes, application/vnd.mozilla.xul+xml
2.85 KB, patch
|Details | Diff | Splinter Review|
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050207 Firefox/1.0+ Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050207 Firefox/1.0+ In the FoxyTunes extension (http://www.foxytunes.org) there is a button (the button with a musical note) which when hovered over displays a popup. In the latest Firefox nightlies this causes a crash. The crash can be easily reproduced if you hover over the button several times. Reproducible: Always Steps to Reproduce: 1. Install FoxyTunes 1.1 from http://www.foxytunes.org 2. Hover over the 'info' button for a few times Actual Results: Browser crash
currently #3 on the talkback topcrasher list. http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=1&searchby=stacksig&match=contains&searchfor=+nsIView%3A%3AGetOffsetTo+3412f9d4&vendor=All&product=All&platform=All&buildid=&sdate=&stime=&edate=&etime=&sortby=bbid I'm pretty certain that this is the wrong component.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: talkbackid, topcrash
Summary: Firefox crashes when trying to display a popup element → Crash in nsIView::GetOffsetTo (stack signature nsIView::GetOffsetTo 3412f9d4)
Created attachment 174012 [details] minimal test case extension Created a minimal (anything less doesn't cause a crash for me) test case. 1. Install the testcase.xpi extension 2. A button with a question mark will appear on the status bar 3. Hover over this button to get the crash The things that cause the crash (removing one of them causes the crash to stop happening): 1. A button that has an onmouseover handler 2. This handler calls showPopup on some popup element 3. This popup element has a onpopupshowing handler 4. In that handler get the "directory_service" service 5. On top of that the button has the following CSS style: - by default it has opacity of 0.99 - on hover it has opacity of 1 It is of course possible that many additional scenarios will lead to the same crash.
Assignee: jag → roc
Component: XP Toolkit/Widgets → Layout: View Rendering
QA Contact: jrgmorrison → ian
Summary: Crash in nsIView::GetOffsetTo (stack signature nsIView::GetOffsetTo 3412f9d4) → Crash in nsIView::GetOffsetTo [@ nsIView::GetOffsetTo 3412f9d4]
Does it have to be an extension? Or will a file:// XUL page (which requests UniversalXPConnect privileges so it can get the service) reproduce it too? A XUL page version of the testcase would make it a lot easier to debug this...
There is also another (easier way IMHO) to reproduce this, also it doesn't crash all the time: 1. Open http://www.heise.de/newsticker/meldung/56281 (or another page with a link, i used this) 2. Click on the link "Novell" in the article (first line) 3. When the new window appears, the site begins to load (Transfering from ....) and the progress bar already appeared, press ESC to cancel the page load.
This regressed between 2004-02-03-06 and 2004-02-04-06, Bonsai link: http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=SeaMonkeyAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-02-03+05%3A00%3A00&maxdate=2005-02-04+07%3A00%3A00&cvsroot=%2Fcvsroot
Make that 2005- :)
Possible fallout from Bug 268352, that checkin looks suspicious to me?
(In reply to comment #3) > Does it have to be an extension? Or will a file:// XUL page (which requests > UniversalXPConnect privileges so it can get the service) reproduce it too? A > XUL page version of the testcase would make it a lot easier to debug this... I have only been able to reproducte this in an overlay. Why would a XUL page make it easier to debug than an extension (maybe I can provide a better test case)?
Component: Layout: View Rendering → XP Toolkit/Widgets
Because I'm not willing to install extensions.
Created attachment 174056 [details] Testcase This testcase is derived from the "minimal test case extension" It crashes for me when I hover over the "?"
It doesn't crash for me with the build where I've backed out the first patch from bug 268352 ("Fix coordinate systems").
Created attachment 174063 [details] [diff] [review] Fix The problem is that event dispatch can destroy aView, so we can't use it after we've called HandleDOMEvent, say... Note that I'm assuming that GetCurrentEventFrame() will return null any time after the presshell is destroyed, so we won't hit the code where we adjust the offset when there is no viewmanager.
Assignee: roc → bzbarsky
Component: XP Toolkit/Widgets → Layout: View Rendering
Priority: -- → P1
Summary: Crash in nsIView::GetOffsetTo [@ nsIView::GetOffsetTo 3412f9d4] → [FIX]Crash in nsIView::GetOffsetTo [@ nsIView::GetOffsetTo 3412f9d4]
Target Milestone: --- → mozilla1.8beta1
Nominating for 1.8b1 blocking, since this is pretty easy to trigger and we have a fix in hand....
Flags: blocking1.8b2? → blocking1.8b?
OS: Windows XP → All
Hardware: PC → All
*** Bug 281891 has been marked as a duplicate of this bug. ***
Comment on attachment 174063 [details] [diff] [review] Fix I think we should take this for beta... It's a pretty safe crash fix for what may turn out to be a common crash that's a recent regression...
Attachment #174063 - Flags: approval1.8b?
Comment on attachment 174063 [details] [diff] [review] Fix a=asa for 1.8b checkin
Attachment #174063 - Flags: approval1.8b? → approval1.8b+
Checked in for 1.8b1.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b) Gecko/20050214 Firefox/1.0+ confirming FIXED using latest beast with patch
Crash Signature: [@ nsIView::GetOffsetTo 3412f9d4]
You need to log in before you can comment on or make changes to this bug.