REGRESSION (r145169): [Mac] [WebKit2] http/tests/security/cross-frame-access-put.html fails

• Component: WebKit2
• Status: RESOLVED FIXED

[Ryosuke Niwa]

http://test-results.appspot.com/dashboards/flakiness_dashboard.html#group=%40ToT%20-%20webkit.org&tests=http%2Ftests%2Fsecurity%2Fcross-frame-access-put.html

e.g.
http://build.webkit.org/results/Apple%20MountainLion%20Release%20WK2%20(Tests)/r145172%20(6678)/results.html

[Ryosuke Niwa]

Added a test expectation in https://trac.webkit.org/r145177.

[Andreas Kling]

Created attachment 192352 [details]
Proposed patch

First stab at solving this. Add bundle API to control whether cached window frames can be used or not.

[Simon Fraser (smfr)]

Comment on attachment 192352 [details]
Proposed patch

View in context: https://bugs.webkit.org/attachment.cgi?id=192352&action=review

> Source/WebKit2/ChangeLog:11
> +        if there's a custom implementation of getWindowFrame() in place that returns something
> +        other than the "real" window frame.

Could this same information be passed back in the reply to the window creation message?

[Andreas Kling]

Comment on attachment 192352 [details]
Proposed patch

After discussing this with Anders we agreed that it would be better if clients overriding getWindowFrame() on the UIProcess side can also get notified when a new window frame is received from the window server, and then optionally set an override frame.

This override would then be respected by WebChromeClient::windowRect().

[Andreas Kling]

(In reply to comment #4)
> (From update of attachment 192352 [details])
> After discussing this with Anders we agreed that it would be better if clients overriding getWindowFrame() on the UIProcess side can also get notified when a new window frame is received from the window server, and then optionally set an override frame.
> 
> This override would then be respected by WebChromeClient::windowRect().

Oh, and this notification should happen on the WebProcess side, since that's where the cached frame is stored.

[Andreas Kling]

Created attachment 193205 [details]
Proposed patch

Here's something way simpler.
Have WebPageProxy::windowAndViewFramesChanged() call getWindowFrame() before sending the frames over to the web process.
This lets the UI client override the window frame in its getWindowFrame() callback, fixing the issue.
Because WindowAndViewFramesChanged happens below the PlatformWebView constructor in WTR, we need a little hack there to ensure the UI client is initialized when the message is sent.

[EFL EWS Bot]

Comment on attachment 193205 [details]
Proposed patch

Attachment 193205 [details] did not pass efl-ews (efl):
Output: http://webkit-commit-queue.appspot.com/results/17195054

[Early Warning System Bot]

Comment on attachment 193205 [details]
Proposed patch

Attachment 193205 [details] did not pass qt-wk2-ews (qt):
Output: http://webkit-commit-queue.appspot.com/results/17218082

[Andreas Kling]

Committed r145869: <http://trac.webkit.org/changeset/145869>