User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a3pre) Gecko/20070216 SeaMonkey/1.5a Build Identifier: sizeToContent() raises NS_ERROR_FAILURE I use sizeToContent() in a small extension, and was testing it on Gran Paradiso. The same code run perfectly on Firefox 2. Reproducible: Always Steps to Reproduce: 1. Get a nsIDOMWindow 2. Call yourwindow.sizeToContent() 3. Take a look at Error Console Actual Results: Error: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIDOMWindow.sizeToContent]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: chrome://websize/content/websize.js :: setProgressWinValue :: line 49" data: no] Source File: chrome://websize/content/websize.js Line: 49 Expected Results: The Window should be fitted to content size. Just before the sizeToContent() call, I set a label value in the nsIDOMWindow. bug 367184 might be linked to this one.

I see this exception occuring when calling window.sizeToContent() multiple times.

Also in this case, when calling sizeToContent() directly, I hit this error.

The second testcase is also occuring in branch builds. The first testcase only seems to happen on trunk builds.

Just retested against Firefox 3.0 beta 1, still error : Erreur : 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=276997 :: <TOP_LEVEL> :: line 10" data: no] I tested using the testcase2.

I don't see an exception with either testcase on Linux. Platform specific maybe?

David, wanna look at this? You mentioned this might be a regression from the reflow branch in bug 367184 comment 12

Loading the first testcase on Win32 throws, but the window does resize. The testcase calls sizeToContent() a couple of times, and it's the 3 or fourth that throws. The error comes from this code: nsRect shellArea = presContext->GetVisibleArea(); if (shellArea.width == NS_UNCONSTRAINEDSIZE || shellArea.height == NS_UNCONSTRAINEDSIZE) { // Protect against bogus returns here return NS_ERROR_FAILURE; } shellArea.height looks like it's NS_UNCONSTRAINEDSIZE, but .width is not.

Hi. This bug is blocking an extension update (bug 411811). Will it be fixed for Fx3? Or should we encourage the add-on developer to create a work around?

Yes, this bug has blocking1.9+ set, so it will automatically be fixed before Fx3.

Bumping the priority then to raise the awareness of this.

This test case simulates accurately how I get this bug.

alex: how important is this? dbaron: are you going to get to this?

(--> P2, there is no P3)

How am I supposed to load these testcases? They don't seem like they do much when loaded as content.

(If I load them with -chrome, I'm not sure how I'm supposed to see the JS console -- but on Linux I neither see any resizing nor any JS errors output to stdout.) (If this bug is Windows-only, I'd expect the testcases to work correctly on Linux, not do nothing.)

> How am I supposed to load these testcases? They don't seem like they do much > when loaded as content. > sizeToContent will not simply fail, it will throw exceptions when run from a privileged location. Simply try sizeToContent multiple times will trigger the error. Tested with FX 2.0.0.12 (result: OK) and latest nightly (result: FAILED: 9)

(In reply to comment #15) > How am I supposed to load these testcases? They don't seem like they do much > when loaded as content. just open the attachment on a new window make sure bugzilla.mozilla.org is allowed to resize windows, adding it on move resize exceptions (preferences window > content panel > advanced > exceptions)

(In reply to comment #16) > (If I load them with -chrome, I'm not sure how I'm supposed to see the JS > console -- but on Linux I neither see any resizing nor any JS errors output to > stdout.) > > (If this bug is Windows-only, I'd expect the testcases to work correctly on > Linux, not do nothing.) > Nope, it is linux too. Just tested with the testcase I gave on FX2.0.0.12 and latest trunk nightly under ubuntu gutsy

This fixes the bug. Two separate fixes were needed: (1) changing PresShell::ResizeReflow to ensure it doesn't leave an unconstrained height as the pres context's visible area (2) changing ViewportFrame::Reflow so it doesn't return an unconstrained height as the frame's height when its child doesn't need reflow (when sizing to content) I also made the error return we were hitting in SizeToContent use NS_ENSURE_TRUE so it's clearer what's happening if this happesn again. This fixes attachment 276818 [details] and attachment 304326 [details] so the exception doesn't get thrown; it still happens in attachment 276997 [details], but that's not a regression.

Er, sorry, the first change in ResizeReflow was an attempt to fix a bug that was already fixed; reverted that and added a comment.

Fix checked in to trunk, 2008-03-12 15:04 -0700.