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




Layout: R & A Pos
13 years ago
6 years ago


(Reporter: Karsten Düsterloh, Assigned: dbaron)


(Blocks: 1 bug, 5 keywords)

crash, testcase, topcrash, verified1.8.0.7, verified1.8.1
Dependency tree / graph
Bug Flags:
blocking1.8.0.7 +
in-testsuite +

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [patch], crash signature)


(3 attachments)



13 years ago
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;"/>

It got even "crashier" in this form:

<?xml version="1.0"?>
<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
<html:div style="position:fixed;"/>

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

13 years ago
Created attachment 154607 [details]
Crashing XUL file with html:div

Comment 2

13 years ago
Created attachment 154608 [details]
Crashing XUL file with x element


13 years ago
Component: Browser-General → Layout
Summary: Non-XUL-Elements with position:fixed crash/hang browser → Non-XUL-Elements with position:fixed crash/hang browser [@nsHTMLReflowState::CalculateHypotheticalBox]
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...
Assignee: general → nobody
Component: Layout → Layout: R & A Pos
OS: Windows 2000 → All
QA Contact: general → core.layout.r-and-a-pos
Hardware: PC → All
Depends on: 231776
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?
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.
Blocks: 284228

Comment 6

12 years ago
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050928

Both testcases in this bug still crash with the same signature.
Keywords: testcase

Comment 7

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

Comment 8

12 years ago
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.
Flags: blocking1.9a1?
Keywords: topcrash
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.
Blocks: 316608


12 years ago
Blocks: 316504


12 years ago
Blocks: 320699


12 years ago
Assignee: nobody → dbaron

Comment 10

12 years ago
Created attachment 206324 [details] [diff] [review]

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.
Attachment #206324 - Flags: superreview?(roc)
Attachment #206324 - Flags: review?(roc)
Attachment #206324 - Flags: approval1.8.1?


12 years ago
Whiteboard: [patch]

Comment 11

12 years ago
(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.)


12 years ago
Summary: Non-XUL-Elements with position:fixed crash/hang browser [@nsHTMLReflowState::CalculateHypotheticalBox] → position:fixed elements in XUL document crash/hang browser [@nsHTMLReflowState::CalculateHypotheticalBox]

Comment 12

12 years ago
*** Bug 316504 has been marked as a duplicate of this bug. ***
No longer blocks: 316504
Attachment #206324 - Flags: superreview?(roc)
Attachment #206324 - Flags: superreview+
Attachment #206324 - Flags: review?(roc)
Attachment #206324 - Flags: review+

Comment 13

12 years ago
Checked in to trunk, 2005-12-20 19:30 -0800.
Last Resolved: 12 years ago
Resolution: --- → FIXED
Comment on attachment 206324 [details] [diff] [review]

marking branch-1.8.1+ for dbaron who requested the approval.
Attachment #206324 - Flags: approval1.8.1? → branch-1.8.1+
Fixed on 1.8.1 branch
Keywords: fixed1.8.1

Comment 16

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


11 years ago
Flags: blocking1.9a1?
Maybe the patch is safe enough for the 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.
Flags: blocking1.8.0.6?
Attachment #206324 - Flags: approval1.8.0.7?
Flags: blocking1.8.0.7? → blocking1.8.0.7+
Comment on attachment 206324 [details] [diff] [review]

approved for 1.8.0 branch, a=dveditz for drivers
Attachment #206324 - Flags: approval1.8.0.7? → approval1.8.0.7+

Comment 19

11 years ago
Checked in to MOZILLA_1_8_0_BRANCH (merged patch from MOZILLA_1_8_BRANCH).
Keywords: fixed1.8.0.7
Blocks: 344061

Comment 20

11 years ago
v.fixed on 1.8.1 and 1.8.0 branches with 8/24 nightly builds, no crashes with XUL files.
Keywords: fixed1.8.0.7, fixed1.8.1 → verified1.8.0.7, verified1.8.1

Comment 21

8 years ago
Flags: in-testsuite+
Crash Signature: [@nsHTMLReflowState::CalculateHypotheticalBox]
You need to log in before you can comment on or make changes to this bug.