202 bytes, application/vnd.mozilla.xul+xml
144 bytes, application/vnd.mozilla.xul+xml
10.10 KB, patch
|Details | Diff | Splinter Review|
Opening this XUL file suffices to crash or hang Mozilla (see attchment): <?xml version="1.0"?> <window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"> <x style="position:fixed;"/> </window> It got even "crashier" in this form: <?xml version="1.0"?> <window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" xmlns:html="http://www.w3.org/1999/xhtml" > <html:div style="position:fixed;"/> </window> Either Mozilla crashes directly or it claims to be still loading, but does not finish. Exiting closes open windows, but Mozilla still keeps running and has to be |kill|ed by hand resp. TaskManager. Mozilla 1.8a2 nightlies (2004-07-28, 2004-04-14) and 1.7 releases crash most of the time (an open sidebar seems to "help" crashing, but isn't necessary), 1.6 and 1.4.1 and even Firefox 0.9.1 hang and have to shot. I wasn't able to trigger Talkback with anything newer than 1.7de-AT (Talkback incident is TB435422G).
The crash happens because aBlockFrame is null in CalculateHypotheticalBox(). That happens because there is in fact no block or area frame that's an ancestor of the placeholder...
I believe the following HTML also demonstrates this crash without using XUL <ACRONYM STYLE="position:fixed; display:table;"></ACRONYM> Perhaps the summary should be updated to show that this doesn't just affect XUL if this is in fact the same cause for the crash? http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=TB1585669K
The table crash is bug 231776, which this bug is marked dependent on. They are in fact different bugs; it's quite possible to fix one without fixing the other.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050928 Firefox/1.6a1 Both testcases in this bug still crash with the same signature.
Adding topcrash keyword to get this on the radar. blcary's automation is indeed hitting this crash a lot, so let's use that data to figure out what's going on and hopefully get a fix on the Trunk.
We know exactly what's happening in this bug -- fixed position is not supported in XUL. Note that similar stacks could happen for various other reasons, none related to this bug.
Created attachment 206324 [details] [diff] [review] patch This isn't that hard to make not crash, and actually display the content and what's likely to be at least a somewhat reasonable place. GetNearestContainingBlock is only used for passing stuff to CalculateHypotheticalBox, so I just needed to make it handle non-block frames.
(Note that the other possibility here is to use 0 rather than the placeholder's offset. I almost prefer that since it's much easier to define in specifications, although less compatible with the current spec.)
Checked in to trunk, 2005-12-20 19:30 -0800.
Comment on attachment 206324 [details] [diff] [review] patch marking branch-1.8.1+ for dbaron who requested the approval.
Fixed on 1.8.1 branch
*** Bug 284228 has been marked as a duplicate of this bug. ***
Maybe the patch is safe enough for the 126.96.36.199 branch? It doesn't seem to have caused any regressions at least for the 6 months it is on trunk and 1.8.1 branch.
Comment on attachment 206324 [details] [diff] [review] patch approved for 1.8.0 branch, a=dveditz for drivers
Checked in to MOZILLA_1_8_0_BRANCH (merged patch from MOZILLA_1_8_BRANCH).
v.fixed on 1.8.1 and 1.8.0 branches with 8/24 nightly builds, no crashes with XUL files.
content/xul/content/crashtests/253479-1.xul content/xul/content/crashtests/253479-2.xul http://hg.mozilla.org/mozilla-central/rev/b0337b6287f3