Created attachment 338927 [details] 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:188.8.131.52) Gecko/2008090211 Ubuntu/8.10 (intrepid) Firefox/3.0.2 Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:184.108.40.206) Gecko/2008070208 Firefox/3.0.1
10 years ago
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?
10 years ago
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
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WORKSFORME
I just un-hid this bug, per bug 455573 comment #10.
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): 20081208 http://hg.mozilla.org/mozilla-central/rev/f03bb4a3ce53 20081209 http://hg.mozilla.org/mozilla-central/rev/85507cfcdda8
link to fix window: http://tinyurl.com/9onwea
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
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: 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)
Whiteboard: [fixed by bug 458898]
You need to log in before you can comment on or make changes to this bug.