window.sizeToContent() fails in trunk (causing graphical corruption)




10 years ago
9 years ago


(Reporter: dholbert, Unassigned)


({fixed1.9.1, regression, testcase})

fixed1.9.1, regression, testcase
Bug Flags:
wanted1.9.1 +
in-testsuite ?

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [fixed by bug 458898], URL)


(2 attachments)

Created attachment 338927 [details]
testcase 1

 1. Load testcase.

 Firefox window shrinks to be just big enough to fit "foo" plus a bit of padding.

 (a) Firefox window stays the same size.
 (b) On Linux, the viewport area outside of the content area is filled with random garbage.  On Windows, that area is just black. (You may need to reload to make it black)
 (c) This appears in JS Error Console:
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindow.sizeToContent]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: :: onload :: line 1"  data: no]

NOTE: Result (b) is basically just bug 455573, compounded because of result (a) (the window's failure to shrink).

I'm filing this bug specifically for the sizeToContent() failure.  Let's deal with the graphical corruption issues in bug 455573.

These builds show ACTUAL RESULTS:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b1pre) Gecko/20080915020438 Minefield/3.1b1pre
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b1pre) Gecko/20080916043910 Minefield/3.1b1pre

These builds show EXPECTED RESULTS (with a bit of corruption due to bug 455573):
Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2008090211
Ubuntu/8.10 (intrepid) Firefox/3.0.2
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv: Gecko/2008070208
Flags: blocking1.9.1?
I filed bug 392417 some time ago, which seems similar to this bug.
Similar, but still different bugs.  

On bug 392417, it sounds like the issue was that (e.g. in Firefox 3.0.1) the Firefox window shrinks, but to the wrong size.

This bug, on the other hand, is about a more recent regression, which prevents the Firefox window from shrinking *at all* in trunk builds (including on bug 392417's testcase).
Why is this a security sensitive bug?

This fails inside the content viewers SizeToContent() and asserts all over layout it seems. Over to layout...
Component: DOM: Core & HTML → Layout
QA Contact: general → layout
Created attachment 340248 [details]
screenshot of testcase 1 under Linux (shows bug)

(In reply to comment #3)
> Why is this a security sensitive bug?

I filed it as security sensitive because it looked like the graphical corruption was showing random memory, at least on Linux. (see the screenshot that I'm attaching).  I'd thought those sorts of bugs are security-sensitive, so I marked it as such, to be safe -- feel free to open it if you think it's appropriate, though.
Do we have a regression range?
Flags: blocking1.9.1? → wanted1.9.1+
FWIW, this bug's testcase now hangs mozilla-central builds.  I've filed bug 472730 on the hang.
I just tested a mozilla-central build from a few days ago (before the bug 472730 hang mentioned in comment 6), and this bug here appears to be WORKSFORME aside from a tiny sliver of graphical corruption, which is bug 455573.  The "ACTUAL RESULTS" from comment 0 are all fixed.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090105 Minefield/3.2a1pre

It's also fixed in 1.9.1 nightlies, though it's been replaced there by another bug, which I'll file shortly.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090108 Shiretoko/3.1b3pre
Group: core-security
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
Might the fix window have matched bug 469203?
(In reply to comment #7)
> It's also fixed in 1.9.1 nightlies, though it's been replaced there by another
> bug, which I'll file shortly.

I filed the new 1.9.1 bug as bug 472740.
(In reply to comment #9)
> Might the fix window have matched bug 469203?

No -- fix window is between these nightlies (& corresponding changesets from about:buildconfig):
My bet is bug 458898 fixed this.  Checkin comment was: "Make sizeToContent work for HTML documents by ensuring CanvasFrame converts an UNCONSTRAINEDSIZE computed height into its actual desired height."
Depends on: 458898
(In reply to comment #13)
> My bet is bug 458898 fixed this.

Also -- that patch landed on 1.9.1 (and fixed this bug) as:

(I confirmed that the 1.9.1 fix-window includes that landing -- it's fixed between the 20081211 and 20081212 builds)
Keywords: fixed1.9.1
Keywords: regressionwindow-wanted
Whiteboard: [fixed by bug 458898]
You need to log in before you can comment on or make changes to this bug.