[Webkit-unassigned] [Bug 37523] Add boolean "activate" to WindowFeatures

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=37523





--- Comment #4 from Stephan Aßmus <superstippi at gmx.de>  2010-05-09 14:41:09 PST ---
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.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.