Web Inspector: Drag onto Web Inspector to open in Inspected Target

• Component: Web Inspector
• Status: NEW ---

[Joseph Pecoraro]

Often when I want to debug an url / archive / html page on iOS I want a way to quickly load it in the inspected target. Being able to drag and drop right onto the inspector would make this pretty easy.

I worked through an initial version of this.

[Radar WebKit Bug Importer]

<rdar://problem/14947760>

[Joseph Pecoraro]

Created attachment 211085 [details]
[PATCH] Attempt 1

So this was my first attempt. To just load the content inside of WebCore. This successfully handles loading the content, but doesn't deal with the back/forward list as nicely as I would like.

Supports:

  - URLs (e.g. from Safari's address bar, or dragging a hyperlink)
  - .html, .txt, and other file types that show up in MIMETypeRegistry::getMIMETypeForExtension
  - .webarchives special path
  - .webloc plist files (e.g a URL dragged from Safari to Desktop)

Issues:

  - Opening a page through this method replaces the existing back/forward history item instead of making a new item
    - this means if you select the URL in the back/forward list, the URL will be loaded instead of the substitute content we provided
  - The dragged page doesn't have a nice URL, currently I'm using about:blank
  - Testing via inspector-protocol is not possible yet, the frontend is, cleverly, opened inside of a window.open(…) Page, so after navigating the original page the frontend goes away and all test control of the frontend is lost =)

The advise I was given was to instead switch to custom protocol handlers. That should be able to fix the non-test issues, but also means by moving code out of WebCore into port specific territory we lose a cross platform implementation.

[Joseph Pecoraro]

Created attachment 211087 [details]
[IMAGE] Screenshot

This is what it looks like. Very basic. The dropAttachment on OS X actually adds a green (+) on the dragging file icon, but taking a screenshot apparently got rid of that part.

[BJ Burg]

I think it would be preferable to initiate the load from WebKit2 so that it doesn't get confused about what's going on with the load. So for all the places where we call the main frame loader, we should hand off the request to the WebInspectorClient or make it appear as if the navigation was initiated from within the outgoing page. I think there is a special code path for web archives, so that might be a good reason to go out to the WK API.