Bug 11142 - Provide hooks for link click modifiers for Windows embedders
Summary: Provide hooks for link click modifiers for Windows embedders
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit API (show other bugs)
Version: 420+
Hardware: PC Windows XP
: P2 Normal
Assignee: Nobody
Depends on: 11138 11139
  Show dependency treegraph
Reported: 2006-10-03 16:42 PDT by Don Gibson
Modified: 2008-01-17 01:15 PST (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Don Gibson 2006-10-03 16:42:52 PDT
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.
Comment 1 Don Gibson 2006-10-04 17:25:55 PDT
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.
Comment 2 Don Gibson 2006-10-05 13:23:50 PDT
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
Comment 3 Eric Seidel (no email) 2008-01-17 01:15:46 PST
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.