[webkit-dev] feature proposal: restricting window.blur/focus

Darin Fisher darin at chromium.org
Wed Apr 4 11:19:06 PDT 2012


On Wed, Apr 4, 2012 at 11:17 AM, Jochen Eisinger <jochen at chromium.org>wrote:

>
>
> On Wed, Apr 4, 2012 at 8:01 PM, Darin Fisher <darin at chromium.org> wrote:
>
>> On Wed, Apr 4, 2012 at 10:58 AM, Jochen Eisinger <jochen at chromium.org>wrote:
>>
>>>
>>> On Wed, Apr 4, 2012 at 7:53 PM, Darin Fisher <darin at 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 <jochen at 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 at lists.webkit.org
>>>>> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>>>>>
>>>>>
>>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20120404/4edb61c9/attachment.html>


More information about the webkit-dev mailing list