Bug 115199 – When updating geometry, send JavaScript resize before before layout/paint.

• Status: RESOLVED
• Resolution: FIXED
• Component: Layout and Rendering

[Andreas Kling]

<rdar://problem/13735535>

[Andreas Kling]

Created attachment 199742 [details]
Snack for EWS

[Build Bot]

Comment on attachment 199742 [details]
Snack for EWS

Attachment 199742 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.appspot.com/results/202104

New failing tests:
fast/replaced/frame-removed-during-resize.html
fast/replaced/frame-removed-during-resize-smaller.html

[Build Bot]

Created attachment 199758 [details]
Archive of layout-test-results from webkit-ews-12 for mac-mountainlion-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: webkit-ews-12  Port: mac-mountainlion-wk2  Platform: Mac OS X 10.8.2

[Build Bot]

Comment on attachment 199742 [details]
Snack for EWS

Attachment 199742 [details] did not pass mac-ews (mac):
Output: http://webkit-queues.appspot.com/results/220288

New failing tests:
fast/events/resize-subframe.html
fast/dynamic/paused-event-dispatch.html
fast/frames/flattening/iframe-flattening-crash.html
fast/replaced/frame-removed-during-resize-smaller.html

[Build Bot]

Created attachment 199764 [details]
Archive of layout-test-results from webkit-ews-05 for mac-mountainlion

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: webkit-ews-05  Port: mac-mountainlion  Platform: Mac OS X 10.8.2

[Andreas Kling]

Created attachment 199837 [details]
Patch

[Geoffrey Garen]

What do you make of these failures?

Regressions: Unexpected text-only failures (3)
  editing/execCommand/copy-without-selection.html [ Failure ]
  editing/pasteboard/copy-two-pasteboard-types-both-work.html [ Failure ]
  editing/pasteboard/pasting-empty-html-falls-back-to-text.html [ Failure ]

Also, do we need some kind of rate limiting for this event? -- i.e., send now, but only if enough time has passed since the last send, and set a timer to send one final event after resizing has stopped?

[Andreas Kling]

(In reply to comment #7)
> What do you make of these failures?
> 
> Regressions: Unexpected text-only failures (3)
>   editing/execCommand/copy-without-selection.html [ Failure ]
>   editing/pasteboard/copy-two-pasteboard-types-both-work.html [ Failure ]
>   editing/pasteboard/pasting-empty-html-falls-back-to-text.html [ Failure ]

Looks like EWS goofery. It's green now, and I can't repro any failures locally.

> Also, do we need some kind of rate limiting for this event? -- i.e., send now, but only if enough time has passed since the last send, and set a timer to send one final event after resizing has stopped?

That's the $1.99 question; if we rate limit it, we still get JS-layout FOUCs, but will obviously alleviate some CPU churn.

One problem I've noticed when rate limiting is that some resize handlers do stuff like "if (window.outerWidth % 4 != 0) return;" to kind-of manually rate limit themselves. Of course, we don't end up sending resize events for every single pixel anyway, so that's not the best solution. And if we start rate limiting the events, it's even less likely that the resize event handler ever does *anything* on such pages.

[Geoffrey Garen]

Comment on attachment 199837 [details]
Patch

OK, well, the patch looks correct to me, so I guess the next step is to try it out.

[WebKit Commit Bot]

Comment on attachment 199837 [details]
Patch

Clearing flags on attachment: 199837

Committed r149287: <http://trac.webkit.org/changeset/149287>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.

[Alexey Proskuryakov]

> fast/frames/flattening/iframe-flattening-crash.html

This test looks like it actually regressed, filed bug 115386.