Instead of all ViewState changes being handled by the WebPage, notify the DrawingArea & PluginView to better encapsulate.
Created attachment 220077 [details] Fix
Comment on attachment 220077 [details] Fix Attachment 220077 [details] did not pass mac-wk2-ews (mac-wk2): Output: http://webkit-queues.appspot.com/results/6287263306612736
Created attachment 220079 [details] Fix
Comment on attachment 220079 [details] Fix View in context: https://bugs.webkit.org/attachment.cgi?id=220079&action=review > Source/WebKit2/WebProcess/WebPage/WebPage.cpp:2100 > + for (auto* pluginView : m_pluginViews) > + pluginView->viewStateDidChange(changed); randomly, could viewStateDidChange execute JS? (e.g. via an event handler?)
(In reply to comment #4) > (From update of attachment 220079 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=220079&action=review > > > Source/WebKit2/WebProcess/WebPage/WebPage.cpp:2100 > > + for (auto* pluginView : m_pluginViews) > > + pluginView->viewStateDidChange(changed); > > randomly, could viewStateDidChange execute JS? (e.g. via an event handler?) Are you thinking WebPage::viewStateDidChange, or PluginView::viewStateDidChange specifically? WebPage::viewStateDidChange can cause JS execution (if the IsVisible state changes this may fire a DOM event, plus focus/blur events may fire?) – but PluginView::viewStateDidChange should just result in a couple of async messages being fired off to the plugin process.
Comment on attachment 220079 [details] Fix View in context: https://bugs.webkit.org/attachment.cgi?id=220079&action=review > Source/WebKit2/WebProcess/Plugins/PluginView.cpp:498 > + m_parameters.layerHostingMode = m_webPage->layerHostingMode(); does this need to be inside a HAVE(LAYER_HOSTING_IN_WINDOW_SERVER)?
Fixed in r161226