User-Agent: Mozilla/5.0 (X11; Linux i686; rv:2.0b6pre) Gecko/20100912 Firefox/4.0b6pre Build Identifier: Mozilla/5.0 (X11; Linux i686; rv:2.0b6pre) Gecko/20100912 Firefox/4.0b6pre If I open http://js1k.com/demo/38 in a background tab, i.e, by middle clicking(and many other apps using canvas) the canvas doesnt get resized. If I reload the page, they do. Reproducible: Always Steps to Reproduce: open the provided url using middle click Actual Results: the canvas doesnt get resized. Expected Results: they should get resized.

s/If I reload the page, they do./If I reload the page after making it active, they do./

this is doing something like: a.width = window.innerWidth; a.height = window.innerHeight; inside a <script> tag that comes after a <canvas>. Additionally, the document is being loaded inside an iframe, e.g.: <frameset id="myNastyFrameSet" rows="30px,*"> <frame name="nav" id="nav_frame" src="/nav/38" marginwidth="0px" marginheight="0px" frameborder="0" noresize="no" /> <frame name="demo" id="demo_frame" src="/pleaseDontHotlinkMe/38" marginwidth="0px" marginheight="0px" frameborder="0" noresize="no" /> </frameset> in the demo_frame. <canvas> doesn't have width/height, so should be getting the default (which I believe is 300x200), but the iframe isn't getting resized (and I believe the canvas then is staying small, since it's getting the iframe's size?)

Oh okie, so the bad guy is iframe?. Well, all I can confirm is that the iframe/canvas get resized properly in Firefox 3.6.3 .

This should work. When did it break? Is the frameset actually relevant?

I suspect, given comment 2, that this is not a canvas problem.

Regression range seems to be http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=75cc425bbaf0&tochange=e1d55bbd1d1d This seems to be fallout from bug 586201 somehow. If I make the throttled rate 60Hz, the problem goes away.

So in the failing case what happens is that we do all of the subdocument frame reflowing before it ever tries to show its viewer. So we never size the docshell to the right size (since that's done in the post-reflow callback only if mFrameLoader), and then when we finally set up mFrameLoader we just leave it at the default 10px by 10px size. Is there a reason we're not checking FrameLoader() in the post-reflow callback? If so, is there a reason to nor just size the frameloader to our then-current size (perhaps only if we're not dirty) when we first set mFrameLoader?

(In reply to comment #7) > So in the failing case what happens is that we do all of the subdocument frame > reflowing before it ever tries to show its viewer. So we never size the > docshell to the right size (since that's done in the post-reflow callback only > if mFrameLoader), and then when we finally set up mFrameLoader we just leave it > at the default 10px by 10px size. So this is a dup of bug 605481. > Is there a reason we're not checking FrameLoader() in the post-reflow callback? No idea. > If so, is there a reason to nor just size the frameloader to our then-current > size (perhaps only if we're not dirty) when we first set mFrameLoader? Don't know. I started to look at bug 60548, but could get the iframe to resize correctly.

(In reply to comment #8) > I started to look at bug 60548, but could get the iframe to resize > correctly. er, couldn't get...

This seems to have gotten fixed at least in the most recent nightly(not sure if it was earlier than that). The Canvas/Iframe seem to be already the right size when I switch to the tab opened in the background.

Fixed by checkin for bug 605481.