window.sizeToContent() causes segfault on positioned elements with right: or bottom: position




14 years ago
9 years ago


(Reporter: james, Unassigned)


({crash, testcase})

crash, testcase

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [reflow-refactor])


(3 attachments)



14 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

See the testcase I will attach, when the div has position:absolute;right:0px or
position:absolute;bottom:0px we experience a segfault (I have tried in firefox,
mozilla and epiphany, so must be a gecko bug I think?)

It should be noted that using top or left positioning does not cause the crash.

Reproducible: Always

Steps to Reproduce:
1. Load testcase
2. Experience segfault

Actual Results:  
Browser crashes

Expected Results:  
Browser doesn't crash

Comment 1

14 years ago
Created attachment 186716 [details]
Minimal testcase causing crash.  Warning: crashes browser!

Warning: crashes browser immediatly.

Comment 2

14 years ago
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050618

Experienced different behavior with Deer Park. When the testcase is opened the
browser does not crash. It does however display an empty content/browsing area
which is not responsive to right-clicking the mouse. It seems as if the
content/browsing area is also not repainted by gecko. I opened a notepad on top
and the content area was not repainted when I moved the notepad window. 

When the browser window is resized by the user the "BANG!" div is displayed as
expected in the upper right corner and the content-area is responsive again.

Also experienced as described with:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b2) Gecko/20050618 Firefox/1.0+

Comment 3

14 years ago
Created attachment 186723 [details]
Screenshot of DeerPark behavior

added screenshot attachment

Comment 4

14 years ago
wfm Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050618

not wfm: 
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050527 Firefox/1.0+
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050618 Firefox/1.0+

not really crashing on windows, but some funny behaviour.

JS console gives:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindow.sizeToContent]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: :: anonymous :: line 5" 
data: no]

Ever confirmed: true
Keywords: crash, testcase

Comment 5

14 years ago
Created attachment 186736 [details]
gtk1 stacktrace

Gdk-ERROR **: BadValue (integer parameter out of range for operation)
  serial 5774 error_code 2 request_code 12 minor_code 0

This only crashes with gtk1.  With gtk2, the behavior is similar to windows.

Comment 6

14 years ago
with a gtk2 debug build, I get these assertions before the JS exception
mentioned in comment 4:
###!!! ASSERTION: containing block height must be constrained:
'containingBlockHeight != NS_AUTOHEIGHT', file
mozilla/layout/generic/nsHTMLReflowState.cpp, line 1035
###!!! ASSERTION: shrink-to-fit: expected a constrained available width:
'availWidth != NS_UNCONSTRAINEDSIZE', file
mozilla/layout/generic/nsAbsoluteContainingBlock.cpp, line 529
###!!! ASSERTION: non-root frame's desired size changed during an incremental
reflow: 'first == root || (aDesiredSize.width == size.width &&
aDesiredSize.height == size.height)', file mozilla/layout/base/nsPresShell.cpp,
line 911
WARNING: NS_ENSURE_TRUE(NS_SUCCEEDED(markupViewer->SizeToContent())) failed,
file /build/andrew/moz-debug/mozilla/dom/src/base/nsGlobalWindow.cpp, line 2865
Whiteboard: [reflow-refactor]

Comment 7

9 years ago
I can't reproduce the crash gecko 1.9 nor gecko 1.9.1
Do you still experience the problem ?

Comment 8

9 years ago
It does not crash in Firefox 3.0.14 (Gecko2009090217 Ubuntu/9.04), however the sizing is wrong (or at least, not as expected), very much too small.

In Epiphany 2.26.1 (Gecko 1.9) it does not crash, but it also does not resize and the repainting is very strangely corrupted until the window is resized manually at which point the painting resumes normally.

Comment 9

9 years ago
WFM with Firefox trunk on Ubuntu 9.10.  Even the painting is fine (but that would be a different bug anyway).
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.