[webkit-dev] feature proposal: restricting window.blur/focus
Hey, Firefox restricts the use of window.blur() and window.focus() (by default). window.blur() is just doing nothing, and window.focus() only works if the caller is running in the same window. Should we implement similar rules for WebKit? The purpose of this is to make pop-unders more difficult to achieve. I think this can be implemented in such a way the the chrome implementation which is doing the actual focusing/bluring anyway has enough information to let each port control what they want to do. wdyt? -jochen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] feature proposal: restricting window.blur/focus
I am all for this change, but a not insubstantial part of that is my general hate for anything other than me ever changing the focused window and/or element. --Oliver On Apr 4, 2012, at 1:31 AM, Jochen Eisinger wrote: Hey, Firefox restricts the use of window.blur() and window.focus() (by default). window.blur() is just doing nothing, and window.focus() only works if the caller is running in the same window. Should we implement similar rules for WebKit? The purpose of this is to make pop-unders more difficult to achieve. I think this can be implemented in such a way the the chrome implementation which is doing the actual focusing/bluring anyway has enough information to let each port control what they want to do. wdyt? -jochen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] feature proposal: restricting window.blur/focus
Matching Firefox behavior likely means that we won't have to worry about breaking sites. We may have to worry about breaking Chrome Extensions or other browser-specific content. -Darin On Wed, Apr 4, 2012 at 1:31 AM, Jochen Eisinger joc...@chromium.org wrote: Hey, Firefox restricts the use of window.blur() and window.focus() (by default). window.blur() is just doing nothing, and window.focus() only works if the caller is running in the same window. Should we implement similar rules for WebKit? The purpose of this is to make pop-unders more difficult to achieve. I think this can be implemented in such a way the the chrome implementation which is doing the actual focusing/bluring anyway has enough information to let each port control what they want to do. wdyt? -jochen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] feature proposal: restricting window.blur/focus
On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher da...@chromium.org wrote: Matching Firefox behavior likely means that we won't have to worry about breaking sites. We may have to worry about breaking Chrome Extensions or other browser-specific content. We could add a method to ChromeClient that would enable an embedder to override the restriction under certain circumstances -jochen -Darin On Wed, Apr 4, 2012 at 1:31 AM, Jochen Eisinger joc...@chromium.orgwrote: Hey, Firefox restricts the use of window.blur() and window.focus() (by default). window.blur() is just doing nothing, and window.focus() only works if the caller is running in the same window. Should we implement similar rules for WebKit? The purpose of this is to make pop-unders more difficult to achieve. I think this can be implemented in such a way the the chrome implementation which is doing the actual focusing/bluring anyway has enough information to let each port control what they want to do. wdyt? -jochen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] feature proposal: restricting window.blur/focus
On Wed, Apr 4, 2012 at 10:58 AM, Jochen Eisinger joc...@chromium.orgwrote: On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher da...@chromium.org wrote: Matching Firefox behavior likely means that we won't have to worry about breaking sites. We may have to worry about breaking Chrome Extensions or other browser-specific content. We could add a method to ChromeClient that would enable an embedder to override the restriction under certain circumstances Or, perhaps something like UserGestureIndicator. I'm not sure which is better. -Darin -jochen -Darin On Wed, Apr 4, 2012 at 1:31 AM, Jochen Eisinger joc...@chromium.orgwrote: Hey, Firefox restricts the use of window.blur() and window.focus() (by default). window.blur() is just doing nothing, and window.focus() only works if the caller is running in the same window. Should we implement similar rules for WebKit? The purpose of this is to make pop-unders more difficult to achieve. I think this can be implemented in such a way the the chrome implementation which is doing the actual focusing/bluring anyway has enough information to let each port control what they want to do. wdyt? -jochen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] feature proposal: restricting window.blur/focus
On Wed, Apr 4, 2012 at 8:01 PM, Darin Fisher da...@chromium.org wrote: On Wed, Apr 4, 2012 at 10:58 AM, Jochen Eisinger joc...@chromium.orgwrote: On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher da...@chromium.org wrote: Matching Firefox behavior likely means that we won't have to worry about breaking sites. We may have to worry about breaking Chrome Extensions or other browser-specific content. We could add a method to ChromeClient that would enable an embedder to override the restriction under certain circumstances Or, perhaps something like UserGestureIndicator. I'm not sure which is better. Not sure I understand? Are you suggesting to allowing focusing/blurring in response to a user action? I think that's undesirable, as the site that wants to pop-under a window probably stole a click to be able to run window.open already. -jochen -Darin -jochen -Darin On Wed, Apr 4, 2012 at 1:31 AM, Jochen Eisinger joc...@chromium.orgwrote: Hey, Firefox restricts the use of window.blur() and window.focus() (by default). window.blur() is just doing nothing, and window.focus() only works if the caller is running in the same window. Should we implement similar rules for WebKit? The purpose of this is to make pop-unders more difficult to achieve. I think this can be implemented in such a way the the chrome implementation which is doing the actual focusing/bluring anyway has enough information to let each port control what they want to do. wdyt? -jochen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] feature proposal: restricting window.blur/focus
On Wed, Apr 4, 2012 at 11:17 AM, Jochen Eisinger joc...@chromium.orgwrote: On Wed, Apr 4, 2012 at 8:01 PM, Darin Fisher da...@chromium.org wrote: On Wed, Apr 4, 2012 at 10:58 AM, Jochen Eisinger joc...@chromium.orgwrote: On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher da...@chromium.org wrote: Matching Firefox behavior likely means that we won't have to worry about breaking sites. We may have to worry about breaking Chrome Extensions or other browser-specific content. We could add a method to ChromeClient that would enable an embedder to override the restriction under certain circumstances Or, perhaps something like UserGestureIndicator. I'm not sure which is better. Not sure I understand? Are you suggesting to allowing focusing/blurring in response to a user action? I think that's undesirable, as the site that wants to pop-under a window probably stole a click to be able to run window.open already. No, no... sorry for being unclear. I meant that you could have a global state variable (allow focusing / blurring) that gets controlled by a scoped helper class. This is an alternative to having a ChromeClient callback. -Darin -jochen -Darin -jochen -Darin On Wed, Apr 4, 2012 at 1:31 AM, Jochen Eisinger joc...@chromium.orgwrote: Hey, Firefox restricts the use of window.blur() and window.focus() (by default). window.blur() is just doing nothing, and window.focus() only works if the caller is running in the same window. Should we implement similar rules for WebKit? The purpose of this is to make pop-unders more difficult to achieve. I think this can be implemented in such a way the the chrome implementation which is doing the actual focusing/bluring anyway has enough information to let each port control what they want to do. wdyt? -jochen ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
