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
Added a test expectation in https://trac.webkit.org/r145177.
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.
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?
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().
(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.
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.
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
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
Committed r145869: <http://trac.webkit.org/changeset/145869>