Bug 145280

Summary: WebKit policy delegate should suggest if a navigation should be allowed to open URLs externally
Product: WebKit Reporter: Brady Eidson <beidson>
Component: WebKit APIAssignee: Brady Eidson <beidson>
Status: RESOLVED FIXED    
Severity: Normal CC: achristensen, ggaren, mitz, sam
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Bug Depends on: 145281, 145417    
Bug Blocks: 147678    
Attachments:
Description Flags
Patch v1
beidson: review-
Patch v2
none
Patch v3 - More build fixing
none
Patch v4 - More correct build fixing achristensen: review+

Description Brady Eidson 2015-05-21 13:18:34 PDT
WebKit policy delegate should indicate ongoing user navigations.

This includes carrying the "was this load the result of a user gesture?" carrying forward over redirects and subsequent main frame navigations.

<rdar://problem/21025301>
Comment 1 Brady Eidson 2015-05-27 15:37:32 PDT
Title change:
WebKit policy delegate should suggest if a navigation should be allowed to open URLs externally
Comment 2 Brady Eidson 2015-05-27 15:41:44 PDT
Two further patches:

1 - Add a "should open URLs externally" flag to DocumentLoader. The flag gets there from FrameLoadRequest. The flag is propagated out to WebKit navigation delegate API. In step 1, the flag will only ever be set from the WKWebView loadRequest: API

2 - Propagate that flag from one DocumentLoader to its descendant DocumentLoader under certain circumstances. Also, WebCore will sometimes decide to set the flag on a DocumentLoader by itself when a navigation meets certain criteria (Such as the navigation is in the main frame, and is the result of a user gesture)
Comment 3 Brady Eidson 2015-05-27 15:45:05 PDT
Step 1 mentioned above tracked in https://bugs.webkit.org/show_bug.cgi?id=145417
Comment 4 Brady Eidson 2015-06-01 15:30:47 PDT
Created attachment 254018 [details]
Patch v1
Comment 5 Brady Eidson 2015-06-01 16:10:16 PDT
Comment on attachment 254018 [details]
Patch v1

Nevermind on the review for now - Obviously the tests aren't in good shape yet.
Comment 6 Alex Christensen 2015-06-01 16:29:56 PDT
Comment on attachment 254018 [details]
Patch v1

View in context: https://bugs.webkit.org/attachment.cgi?id=254018&action=review

This is missing a change to Source/WebKit/ios/WebView/WebPDFViewPlaceholder.mm and this patch causes lots of crashes.  You're probably dereferencing a null pointer somewhere.

> Source/WebCore/loader/FrameLoader.cpp:1326
>      RefPtr<DocumentLoader> loader = m_client.createDocumentLoader(request, defaultSubstituteDataForURL(request.url()));

Does createDocumentLoader always succeed?

> Source/WebCore/page/DOMWindow.cpp:2139
> +    Frame* activeFrame = activeWindow.frame();
> +    if (!activeFrame)
> +        return nullptr;

This isn't used.  Is it helpful to return early if there is no active frame?
Comment 7 Brady Eidson 2015-06-01 16:55:11 PDT
(In reply to comment #6)
> Comment on attachment 254018 [details]
> Patch v1
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=254018&action=review
> 
> This is missing a change to
> Source/WebKit/ios/WebView/WebPDFViewPlaceholder.mm and this patch causes
> lots of crashes.  You're probably dereferencing a null pointer somewhere.

That's why I pulled it from review :)

> 
> > Source/WebCore/loader/FrameLoader.cpp:1326
> >      RefPtr<DocumentLoader> loader = m_client.createDocumentLoader(request, defaultSubstituteDataForURL(request.url()));
> 
> Does createDocumentLoader always succeed?

Yup.
Comment 8 Brady Eidson 2015-06-01 17:15:03 PDT
Created attachment 254030 [details]
Patch v2

This is for EWS and, if it passes, for review.

But not yet for landing, as I haven't updated the ChangeLogs yet.
Comment 9 Brady Eidson 2015-06-01 21:31:15 PDT
Messed up the iOS build fix, and now that windows EWS is finally helping, will fix that one too.

Rest of the patch is still reviewable at this point.
Comment 10 Brady Eidson 2015-06-02 10:08:03 PDT
Created attachment 254070 [details]
Patch v3 - More build fixing
Comment 11 Brady Eidson 2015-06-02 10:44:58 PDT
Created attachment 254073 [details]
Patch v4 - More correct build fixing
Comment 12 Alex Christensen 2015-06-02 11:31:14 PDT
r=me.  Media and font test failures are unrelated.
Comment 13 Brady Eidson 2015-06-02 11:32:05 PDT
The test failures on mac/mac-wk2 are unrelated (Those tester bots are in a non-green status right now, anyways)

I'll fix up the ChangeLogs then land.
Comment 14 Brady Eidson 2015-06-02 11:43:54 PDT
http://trac.webkit.org/changeset/185111
Comment 15 Geoffrey Garen 2015-06-02 11:58:45 PDT
Comment on attachment 254073 [details]
Patch v4 - More correct build fixing

Other interesting test cases:

(1) Do a top-level (Safari-like) navigation that sets the flag to true, then another that sets it to false. Flag should be false.

(2) Do a top-level (Safari-like) navigation that sets the flag to false, then another that sets it to true. Flag should be true.

(3) Do a top-level (Safari-like) navigation that sets the flag to false, then a programmatic click event on a link. Flag should be false.
Comment 16 Brady Eidson 2015-06-02 12:13:26 PDT
(In reply to comment #15)
> Comment on attachment 254073 [details]
> Patch v4 - More correct build fixing
> 
> Other interesting test cases:
> 
> (1) Do a top-level (Safari-like) navigation that sets the flag to true, then
> another that sets it to false. Flag should be false.
> 
> (2) Do a top-level (Safari-like) navigation that sets the flag to false,
> then another that sets it to true. Flag should be true.
> 
> (3) Do a top-level (Safari-like) navigation that sets the flag to false,
> then a programmatic click event on a link. Flag should be false.

Great suggestions.

Following up in https://bugs.webkit.org/show_bug.cgi?id=145558