Right now, we handle resizes asynchronously, even when they're set explicitly by the user. This has observable effects for same-origin iframes, and not-interoperable behavior.

See, for example, #14556.

Right now, when the width attribute changes, we do the following:

• We run layout, build the display list, including the iframe display item, which contains the pipeline id.
• WebRender flattens the display list and, if the size changed, calls the render notifier in the compositor...
• Which sends to the constellation the resize.
• Which in turns sets the window's window_size field, and trigger a reflow.

That's (I think) fine for cross-origin iframes, since there are no visible effects from the web page's point of view (apart from a moment with the straneous styling). I'm not sure how Gecko handles cross-origin iframe resizing, maybe the resize needs to be synchronous as well? @bzbarsky may know better than I.

Concretely: what happens when an iframe is resized as a consequence of a style/layout change (e.g., because it uses a percentage width?). Is it different for same and cross-origin iframes (I guess so)? I might investigate it tomorrow, but today's christmas :)

But for same-origin iframes, it seems we can't do all this async story all that straight away.

cc @pcwalton, and also @asajeffrey and @jdm, which know about the effort that was needed to make same-origin frames share script threads, given it's probably a similar effort for layout threads.