472740 - window.sizeToContent() with small content causes window to progressively shrink (& disappear) on successive reloads

Status: RESOLVED DUPLICATE of bug 467853

(Firefox :: Tabbed Browser, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1: 38px wide (shrinks by ~1px each reload)

STR:
1. Open testcase
2. Reload a few times

ACTUAL RESULTS:
 - The window shrinks by a pixel on each reload
 - When the window gets small enough, it entirely disappears. (It no longer appears in alt-tab list, or in the window list on my taskbar.)  However, Firefox remains running -- just with no active windows.

EXPECTED RESULTS:
 - The window should snap to the *same* size on each reload.

I can reproduce the buggy behavior in this 1.9.1 nightly:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090108 Shiretoko/3.1b3pre

However, I get expected results in mozilla-central nightlies and in Firefox 3.0.5
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090108 Minefield/3.2a1pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.0.5) Gecko/2008121622 Ubuntu/8.10 (intrepid) Firefox/3.0.5

Hence, marking version=1.9.1

Comment 1

[Daniel Holbert [:dholbert]]

Attachment: testcase 2: 20px wide (shrinks by much more per reload)

This testcase uses a 20px-wide div (and has the "foo" text removed for simplicity). The skinnier the content, the larger the shrinkage per-reload, it seems.

Using this testcase, the window disappears entirely after initial load + 2 reloads.

Comment 2

[Daniel Holbert [:dholbert]]

Attachment: testcase 3: 39px wide -- doesn't shrink on reloads, but won't grow

This testcase doesn't show the shrinking bug, but it shows a different form of what I think is the same bug, which I'll call "EXPERIMENT B":

1. Load testcase (testcase 3 in this case)
2. Make window really skinny (skinnier than it already is)
3. Reload with Ctrl-R

EXPECTED RESULTS:
 The reload in step 3 should make the window grow (up to the content's width)

ACTUAL RESULTS:
 For testcase 3, the reload has no effect on the window width.

Comment 3

[Daniel Holbert [:dholbert]]

Attachment: testcase 4: 40px wide -- if you make it skinny, it grows 1px per reload

Performing "EXPERIMENT B" (above) on testcase 4 shows *growing* behavior -- we grow by 1px per reload.

Comment 4

[Daniel Holbert [:dholbert]]

Comment on attachment 356052 [details]
testcase 4: 40px wide -- if you make it skinny, it grows 1px per reload

(d'oh, sorry -- I meant to name that last attachment "testcase 4")

Comment 5

[Daniel Holbert [:dholbert]]

This was a little hard to find a regression-window for, because bug 455577 masks the shrinking behavior (until it became fixed on around Dec 12th).

However, using testcase 4 + "Experiment B", I was able to reproduce the window-GROWING-on-reload behavior even before bug 455577 was fixed, and I tracked down a regression window of between these builds (with revision ID as reported by about:buildconfig)

WORKING:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081125 Minefield/3.1b2pre
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f1a511d5f777

BROKEN:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20081126 Minefield/3.1b3pre
http://hg.mozilla.org/releases/mozilla-1.9.1/rev/106dc288fd5f

Regression range:
http://tinyurl.com/9hez2k

Comment 6

[Daniel Holbert [:dholbert]]

(In reply to comment #5)
> WORKING:
[snip]
> http://hg.mozilla.org/releases/mozilla-1.9.1/rev/f1a511d5f777

Note that this is the exact point at which mozilla-1.9.1 split off.  It's also visible on mozilla-central at http://hg.mozilla.org/mozilla-central/rev/f1a511d5f777

So, this became broken in one of the very first fixes to land on the mozilla-1.9.1 branch.

Comment 7

[Daniel Holbert [:dholbert]]

(In reply to comment #5)
> Regression range:
> http://tinyurl.com/9hez2k

Through "hg revert" + binary search, I narrowed this to the landing for bug 465843: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/028bbc611036

Comment 8

[Daniel Holbert [:dholbert]]

On mozilla-central, this regressed between these builds
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081120 Minefield/3.1b2pre
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b2pre) Gecko/20081121 Minefield/3.1b2pre

which includes the mozilla-central landing of the aforementioned responsible changeset 028bbc611036:
http://hg.mozilla.org/mozilla-central/rev/028bbc611036

(This has subsequently become WFM on mozilla-central, as noted in comment 0 -- I'm going to try to determine when it became fixed / what fixed it, so that the fix can be backported to 1.9.1)

Comment 9

[Daniel Holbert [:dholbert]]

This became fixed on mozilla-central between these nightly builds:

BROKEN:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090104 Minefield/3.2a1pre
http://hg.mozilla.org/mozilla-central/rev/9f497b1505d2

WORKING:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090105 Minefield/3.2a1pre
http://hg.mozilla.org/mozilla-central/rev/c04e27e056ba

Comment 10

[Daniel Holbert [:dholbert]]

Fix range: http://tinyurl.com/7mv4wg
Bug 465448 looks like a likely candidate for having fixed this on mozilla-central...

Comment 11

[Daniel Holbert [:dholbert]]

(In reply to comment #10)
> Bug 465448 looks like a likely candidate for having fixed this on
> mozilla-central...

... whose patch landed on 1.9.1 today.  d'oh.

Looks like this is basically a dupe of bug 467853 (which depends on the aforementioned bug 465448, and is probably a dupe of it).  Marking.