Bug 11142 – Provide hooks for link click modifiers for Windows embedders

• Status: ASSIGNED
• Component: WebKit API

[Don Gibson]

Safari[/Firefox/etc.] has the ability to control whether pages open in new foreground or background tabs, windows, etc.  This is generally exposed by various modifier keys with a left click, or by reacting differently on middle click.

The WebKit Windows port seems to lack any hooks for Spinneret or other embedders to control how link targets are opened in this way (or I overlooked the hooks).  In HTMLAnchorElement::defaultEventHandler(), middle clicks cause the link's target to be set to "_blank".  It seems like instead, clicks on links in general should ask the embedder what to do; the embedder can then target the link appropriately.

I'm vague on the details here; I don't have a concrete design for how this should work.  Input welcome.

[Don Gibson]

It looks like maybe the right way to go here is to add code to WebKit/COM/WebFrame.cpp to call off to checkNavigationPolicyForRequest().  Then embedders will have to implement IWebPolicyDelegate, and in this action, decide how to handle such calls (perhaps by creating another instance and displaying it somewhere appropriate, and telling the original instance to do nothing?).  The Mac version of this code is a bit convoluted, so it's still not totally clear to me where exactly the frame should be making this call.

[Don Gibson]

Looks like Dex Deacon is also wanting to hook up PolicyDelegate stuff in bug 11139, so there's going to be overlap between this bug and that

[Eric Seidel (no email)]

I'm not sure this bug is very useful, given the lack of concrete forward direction.  I think it's a good idea to unify this sort of click/keyboard handling logic, at least where it affects navigation.  It's possible this could be pushed into a platform-specific class, or even the Chrome client.  Without a specific proposal for which hooks you'd like to see though, I'm not sure it's worth keeping this bug around.