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

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

STEPS TO REPRODUCE:
 1. Load testcase.

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

ACTUAL RESULTS:
 (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 :: https://bugzilla.mozilla.org/attachment.cgi?id=338920 :: 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:1.9.0.2) Gecko/2008090211
Ubuntu/8.10 (intrepid) Firefox/3.0.2
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.0.1) Gecko/2008070208
Firefox/3.0.1

Comment 1

[Martijn Wargers (dead)]

I filed bug 392417 some time ago, which seems similar to this bug.

Comment 2

[Daniel Holbert [:dholbert]]

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

Comment 3

[Johnny Stenback (:jst)]

Why is this a security sensitive bug?

This fails inside the content viewers SizeToContent() and asserts all over layout it seems. Over to layout...

Comment 4

[Daniel Holbert [:dholbert]]

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

Comment 5

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

Do we have a regression range?

Comment 6

[Daniel Holbert [:dholbert]]

FWIW, this bug's testcase now hangs mozilla-central builds.  I've filed bug 472730 on the hang.

Comment 7

[Daniel Holbert [:dholbert]]

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

Comment 8

[Daniel Holbert [:dholbert]]

I just un-hid this bug, per bug 455573 comment #10.

Comment 9

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

Might the fix window have matched bug 469203?

Comment 10

[Daniel Holbert [:dholbert]]

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

Comment 11

[Daniel Holbert [:dholbert]]

(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):
20081208  http://hg.mozilla.org/mozilla-central/rev/f03bb4a3ce53
20081209  http://hg.mozilla.org/mozilla-central/rev/85507cfcdda8

Comment 12

[Daniel Holbert [:dholbert]]

link to fix window: http://tinyurl.com/9onwea

Comment 13

[Daniel Holbert [:dholbert]]

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

http://hg.mozilla.org/mozilla-central/rev/7c5b6ac942e0

Comment 14

[Daniel Holbert [:dholbert]]

(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:
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/378bf43994fa

(I confirmed that the 1.9.1 fix-window includes that landing -- it's fixed between the 20081211 and 20081212 builds)