Bug 37523 – Add boolean "activate" to WindowFeatures

• Status: UNCONFIRMED
• Component: Page Loading

[Stephan Aßmus]

The motivation for this change is that in my browser implementation, I could not figure out when to open a new window (tab) in the background and when to activate it. The most straight forward solution seemed to add the information to WindowFeatures, which is passed to ChomeClient::createWindow(). The implementor can then chose to open a new tab in the background. No idea if this is the best solution, please advice. :-)

[Stephan Aßmus]

Created attachment 53282 [details]
Patch implementing the feature.

[Stephan Aßmus]

BTW, I don't know if the patch introduces binary compatibility issues in some ports, but the ChromeClient implementation and WindowFeatures are hopefully not be exposed.

[Eric Seidel (no email)]

Comment on attachment 53282 [details]
Patch implementing the feature.

I don't understand.  Why do we want this?  What does this do?  Who would use this?  Why don't other ports need this?  Also typo: "actiavte"

[Stephan Aßmus]

Like I've already explained in the first comment... I needed a way to distinguish the need to "activate" a new window that is opened via ChromeClient::createWindow(). In Firefox, when I use the context menu to open a link in a new tab, the tab opens "in the background", i.e. the current page stays visible, a new tab opens "behind it" and the linked page loads there "in the background". In WebKit, all I see is that ChromeClient::createWindow() is called, I have no way to know if this window (respectively page) should be activated, or not disturb the currently loaded page. When I click on a link with the primary mouse button for example, and the link opens a new window/tab, then usually I want it activated. If I click the same link with my tertiary mouse button, I want a new tab in the background, the current page stays in front, just like in Firefox. For the tertiary or primary click, I can determine the event in FrameLoaderClient::dispatchDecidePolicyForNewWindowAction() and look up the mouse button that was used. The context menu event however which is used to open a link in a new window, is completely lost, there is no way for the client code to know the new window was requested by context menu. The patch simply introduces a property to the window features that allows WebKit to transport the intention not to activate the new window automatically. I have no idea how other ports handle this, maybe they don't, maybe there is already a mechanism that they explore to look up the event that caused ChromeClient::createWindow() to be called, if so, I'd be glad to learn about it.