oxide team mailing list archive

[Olivier Tilloy <olivier.tilloy@xxxxxxxxxxxxx>]

On Wed, Mar 26, 2014 at 12:37 AM, Chris Coulson <chrisccoulson@xxxxxxxxxx>wrote:

> Hi,
>
> We currently have a boolean setting for controlling popup blocking -
> WebPreferences.popupBlockerEnabled, which is a per-WebView property.
> However, this currently only affects calls to window.open() and is
> blocked inside blink.
>
> There are other mechanisms that can open windows that don't use this
> setting. Chromium provides a central location to block window open
> requests on the browser side, by implementing
> ContentBrowserClient::CanCreateWindow(), and it looks like Chromium uses
> this for doing its popup blocking. However, this is called on Chromium's
> IO thread, and it's currently very difficult to map IPC messages to a
> specific WebView when not on the main thread (in this case, we don't
> even get a frame routing ID so we don't have the information available
> to do that anyway). It's easy to map them to a specific WebContext
> though (as that's associated with a RenderProcess).
>
> I want a single boolean property for controlling all popup blocking, but
> does anybody object if this isn't controllable for individual WebView's
> (ie, making it a property on WebContext)?
>

Well, in theory an application that instantiates several WebViews
(typically, a browser) could also instantiate a separate WebContext for
each view, if it really wanted to control popup blocking at the view level.
But I can’t think of a use case for that off the top of my head, so anyway
I think a boolean property on the context is good enough.

Cheers,

 Olivier