WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
194325
Forward Ad Click Attribution data from HTMLAnchorElement::handleClick() to WebKit::NavigationActionData
https://bugs.webkit.org/show_bug.cgi?id=194325
Summary
Forward Ad Click Attribution data from HTMLAnchorElement::handleClick() to We...
John Wilander
Reported
2019-02-05 19:15:26 PST
We should pipe through any Ad Click Attribution data to WebKit::NavigationActionData where we can keep track of it across a complete navigational load.
Attachments
Patch
(22.28 KB, patch)
2019-02-05 19:43 PST
,
John Wilander
no flags
Details
Formatted Diff
Diff
Patch
(22.20 KB, patch)
2019-02-06 11:20 PST
,
John Wilander
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2019-02-05 19:16:00 PST
<
rdar://problem/47840283
>
John Wilander
Comment 2
2019-02-05 19:43:21 PST
Created
attachment 361268
[details]
Patch
Chris Dumez
Comment 3
2019-02-06 09:57:32 PST
Comment on
attachment 361268
[details]
Patch View in context:
https://bugs.webkit.org/attachment.cgi?id=361268&action=review
> Source/WebCore/loader/AdClickAttribution.h:183 > + AdClickAttribution attribution { Campaign { campaignId.value() }, Source { sourceRegistrableDomain.value() }, Destination { destinationRegistrableDomain.value() } };
Should probably use WTFMove() more here, e.g. WTFMove(*compaignId).
> Source/WebCore/loader/AdClickAttribution.h:209 > + return Conversion { data.value(), Priority { priority.value() } };
Ditto about WTFMove().
> Source/WebCore/loader/FrameLoader.cpp:407 > + loadFrameRequest(WTFMove(frameRequest), triggeringEvent, { }, (m_frame.isMainFrame() ? WTFMove(adClickAttribution) : WTF::nullopt));
parentheses are not needed. Also, why do we need the isMainFrame() check here since you're already doing it later in loadURL()?
> Source/WebCore/loader/FrameLoader.h:383 > + void loadURL(FrameLoadRequest&&, const String& referrer, FrameLoadType, Event*, RefPtr<FormState>&&, Optional<AdClickAttribution>&& = WTF::nullopt, CompletionHandler<void()>&& = [] { });
Since everybody should provide a completion handler (AFAIK), I don't think we should add default parameter values here.
> Source/WebCore/loader/NavigationAction.h:138 > + Optional<AdClickAttribution> adClickAttribution() { return m_adClickAttribution; };
should return a const Optional<AdClickAttribution>&.
> Source/WebCore/loader/NavigationAction.h:139 > + void setAdClickAttribution(AdClickAttribution adClickAttribution) { m_adClickAttribution = adClickAttribution; };
Couldn't this take a AdClickAttribution&& in parameter? Assuming you can WTFMove() at the call site, which I think you can.
> Source/WebKit/Shared/NavigationActionData.h:64 > + Optional<WebCore::AdClickAttribution> adClickAttribution;
I would do the API::Navigation object initialization on the UIProcess side in the same patch too. It's just a few more lines and it is still merely about plumbing the value through to the UIProcess.
John Wilander
Comment 4
2019-02-06 09:59:17 PST
(In reply to Chris Dumez from
comment #3
)
> Comment on
attachment 361268
[details]
> Patch > > View in context: >
https://bugs.webkit.org/attachment.cgi?id=361268&action=review
> > > Source/WebCore/loader/AdClickAttribution.h:183 > > + AdClickAttribution attribution { Campaign { campaignId.value() }, Source { sourceRegistrableDomain.value() }, Destination { destinationRegistrableDomain.value() } }; > > Should probably use WTFMove() more here, e.g. WTFMove(*compaignId). > > > Source/WebCore/loader/AdClickAttribution.h:209 > > + return Conversion { data.value(), Priority { priority.value() } }; > > Ditto about WTFMove(). > > > Source/WebCore/loader/FrameLoader.cpp:407 > > + loadFrameRequest(WTFMove(frameRequest), triggeringEvent, { }, (m_frame.isMainFrame() ? WTFMove(adClickAttribution) : WTF::nullopt)); > > parentheses are not needed. Also, why do we need the isMainFrame() check > here since you're already doing it later in loadURL()? > > > Source/WebCore/loader/FrameLoader.h:383 > > + void loadURL(FrameLoadRequest&&, const String& referrer, FrameLoadType, Event*, RefPtr<FormState>&&, Optional<AdClickAttribution>&& = WTF::nullopt, CompletionHandler<void()>&& = [] { }); > > Since everybody should provide a completion handler (AFAIK), I don't think > we should add default parameter values here. > > > Source/WebCore/loader/NavigationAction.h:138 > > + Optional<AdClickAttribution> adClickAttribution() { return m_adClickAttribution; }; > > should return a const Optional<AdClickAttribution>&. > > > Source/WebCore/loader/NavigationAction.h:139 > > + void setAdClickAttribution(AdClickAttribution adClickAttribution) { m_adClickAttribution = adClickAttribution; }; > > Couldn't this take a AdClickAttribution&& in parameter? Assuming you can > WTFMove() at the call site, which I think you can. > > > Source/WebKit/Shared/NavigationActionData.h:64 > > + Optional<WebCore::AdClickAttribution> adClickAttribution; > > I would do the API::Navigation object initialization on the UIProcess side > in the same patch too. It's just a few more lines and it is still merely > about plumbing the value through to the UIProcess.
Thanks, Chris! I'll have a look at all of these comments. And also figure out what Windows is complaining about.
John Wilander
Comment 5
2019-02-06 11:20:00 PST
Created
attachment 361309
[details]
Patch
John Wilander
Comment 6
2019-02-06 11:20:56 PST
Fixed everything but the API::Navigation object initialization. Per Arne had an idea of how to fix the Windows issue. Waiting for EWS.
Chris Dumez
Comment 7
2019-02-06 13:00:40 PST
(In reply to John Wilander from
comment #6
)
> Fixed everything but the API::Navigation object initialization. Per Arne had > an idea of how to fix the Windows issue. Waiting for EWS.
Why not?
John Wilander
Comment 8
2019-02-06 13:12:54 PST
(In reply to Chris Dumez from
comment #7
)
> (In reply to John Wilander from
comment #6
) > > Fixed everything but the API::Navigation object initialization. Per Arne had > > an idea of how to fix the Windows issue. Waiting for EWS. > > Why not?
I wanted to discuss that part with you but also see if I had a fix for the Windows issue.
John Wilander
Comment 9
2019-02-06 13:23:22 PST
I discussed with Chris and we agree next steps fit well in a follow-up patch. Probably a getter on API::Navigation similar to currentRequestIsRedirect().
John Wilander
Comment 10
2019-02-06 13:37:18 PST
Comment on
attachment 361309
[details]
Patch mac-debug's tree seems red and the test failures on win are unrelated.
WebKit Commit Bot
Comment 11
2019-02-06 14:02:21 PST
Comment on
attachment 361309
[details]
Patch Clearing flags on attachment: 361309 Committed
r241049
: <
https://trac.webkit.org/changeset/241049
>
WebKit Commit Bot
Comment 12
2019-02-06 14:02:23 PST
All reviewed patches have been landed. Closing bug.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug