253479 - position:fixed elements in XUL document crash/hang browser [@nsHTMLReflowState::CalculateHypotheticalBox]

Status: RESOLVED FIXED

(Core :: Layout: Positioned, defect)

Description

[Karsten Düsterloh]

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).

Comment 1

[Karsten Düsterloh]

Attachment: Crashing XUL file with html:div

Comment 2

[Karsten Düsterloh]

Attachment: Crashing XUL file with x element

Comment 3

[Boris Zbarsky [:bzbarsky]]

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...

Comment 4

[Robert Strong (they/them - no direct email)]

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

Comment 5

[Boris Zbarsky [:bzbarsky]]

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.

Comment 6

[Jesse Ruderman]

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.

Comment 7

[Jesse Ruderman]

Automated testing hits this crash often (mozqa:rs, see bug 306939).

Comment 8

[Jay Patel [:jay]]

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.

Comment 9

[Boris Zbarsky [:bzbarsky]]

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.

Comment 10

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Attachment: 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.

Comment 11

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

(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.)

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

*** Bug 316504 has been marked as a duplicate of this bug. ***

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Checked in to trunk, 2005-12-20 19:30 -0800.

Comment 14

[Benjamin Smedberg]

Comment on attachment 206324 [details] [diff] [review]
patch

marking branch-1.8.1+ for dbaron who requested the approval.

Comment 15

[Boris Zbarsky [:bzbarsky]]

Fixed on 1.8.1 branch

Comment 16

[timeless]

*** Bug 284228 has been marked as a duplicate of this bug. ***

Comment 17

[Martijn Wargers (dead)]

Maybe the patch is safe enough for the 1.8.0.6 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 18

[Daniel Veditz [:dveditz]]

Comment on attachment 206324 [details] [diff] [review]
patch

approved for 1.8.0 branch, a=dveditz for drivers

Comment 19

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Checked in to MOZILLA_1_8_0_BRANCH (merged patch from MOZILLA_1_8_BRANCH).

Comment 20

[Jay Patel [:jay]]

v.fixed on 1.8.1 and 1.8.0 branches with 8/24 nightly builds, no crashes with XUL files.

Comment 21

[Bob Clary [:bc] (inactive)]

content/xul/content/crashtests/253479-1.xul
content/xul/content/crashtests/253479-2.xul
http://hg.mozilla.org/mozilla-central/rev/b0337b6287f3