Bug 189505 - [WPE][GTK] API documentation is unclear about how to modify requests before sending them
Summary: [WPE][GTK] API documentation is unclear about how to modify requests before s...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit API (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Adrian Perez
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2018-09-11 09:48 PDT by Adrian Perez
Modified: 2018-09-13 09:50 PDT (History)
10 users (show)

See Also:


Attachments
Patch (5.94 KB, patch)
2018-09-11 09:52 PDT, Adrian Perez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Adrian Perez 2018-09-11 09:48:04 PDT
There are two places where a WebKitURIRequest can be inspected
before it is sent over the network, and it is not clear in the
documentation in which case the modifications apply to it will
be reflected in the actual data sent over the network:

 - Signal handlers for WebKitWebView::decide-policy
   Modifications *ARE NOT* sent over the network.

 - Signal handlers for WebKitPage::send-request (in a Web extension)
   Modifications *ARE* sent over the network.

It would be useful if the API documentation was explicit about
this.
Comment 1 Adrian Perez 2018-09-11 09:52:47 PDT
Created attachment 349403 [details]
Patch
Comment 2 EWS Watchlist 2018-09-11 09:55:01 PDT
Thanks for the patch. If this patch contains new public API please make sure it follows the guidelines for new WebKit2 GTK+ API. See http://trac.webkit.org/wiki/WebKitGTK/AddingNewWebKit2API
Comment 3 Michael Catanzaro 2018-09-11 10:10:50 PDT
Comment on attachment 349403 [details]
Patch

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

I've been confused by this before too. Thanks.

> Source/WebKit/UIProcess/API/glib/WebKitNavigationAction.cpp:128
> + * Modifications to the returned object are <emphasis>not</emphasis> taken

Hm, gtk-doc removed support for XML a long time ago. Are you sure this is actually going to work? I suspect the output will literally say <emphasis>not</emphasis>. Do you have some recent HTML example of this working?

I think it's supposed to be markdown instead?
Comment 4 Adrian Perez 2018-09-11 10:48:37 PDT
(In reply to Michael Catanzaro from comment #3)
> Comment on attachment 349403 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=349403&action=review
> 
> I've been confused by this before too. Thanks.
> 
> > Source/WebKit/UIProcess/API/glib/WebKitNavigationAction.cpp:128
> > + * Modifications to the returned object are <emphasis>not</emphasis> taken
> 
> Hm, gtk-doc removed support for XML a long time ago. Are you sure this is
> actually going to work? I suspect the output will literally say
> <emphasis>not</emphasis>. Do you have some recent HTML example of this
> working?

Carlos García figured out that <emphasis> works in his patch for bug #188742

> I think it's supposed to be markdown instead?

Apparently DocBook is still being used, but in versions ≥1.20 it is
also possible to use Markdown intermixed with DocBook. Or at least
that's what I understand from reading here:

  https://developer.gnome.org/gtk-doc-manual/stable/documenting_syntax.html.en

  “While markdown is now preferred one can mix both. One limitation here
   is that one can use docbook xml within markdown, but markdown within
   docbook xml is not supported.”

¯\_(ツ)_/¯
Comment 5 WebKit Commit Bot 2018-09-11 12:26:56 PDT
Comment on attachment 349403 [details]
Patch

Clearing flags on attachment: 349403

Committed r235909: <https://trac.webkit.org/changeset/235909>
Comment 6 WebKit Commit Bot 2018-09-11 12:26:57 PDT
All reviewed patches have been landed.  Closing bug.
Comment 7 Radar WebKit Bug Importer 2018-09-11 12:27:38 PDT
<rdar://problem/44352135>
Comment 8 Carlos Garcia Campos 2018-09-12 00:05:18 PDT
Comment on attachment 349403 [details]
Patch

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

> Source/WebKit/UIProcess/API/glib/WebKitNavigationAction.cpp:130
> + * into account when the request is sent over the network, and is intended
> + * only to aid in evaluating whether a navigation action should be taken or

This is not accurate either. NavigationAction is used in policy decisions, but also in create signal. It's not intended to decide whether the action should be taken or not, it's just information, the intentation of that information depends on the caller rather tahn the action object itself. I would add this comment to decide-policy signal, to clarify that you can ignore/download/use, but request can't be modified at that point.

> Source/WebKit/UIProcess/API/glib/WebKitResponsePolicyDecision.cpp:121
> + * Return the #WebKitURIRequest associated with the response decision.
> + * Modifications to the returned object are <emphasis>not</emphasis> taken
> + * into account when the request is sent over the network, and is intended
> + * only to aid in evaluating whether a response decision should be taken or
> + * not. To modify requests before they are sent over the network the

It makes more sense here in this context, but maybe we can add a single comment in the signal description, you are suggesting to use a different signal in the end.
Comment 9 Adrian Perez 2018-09-13 09:50:47 PDT
(In reply to Carlos Garcia Campos from comment #8)
> Comment on attachment 349403 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=349403&action=review
> 
> > Source/WebKit/UIProcess/API/glib/WebKitNavigationAction.cpp:130
> > + * into account when the request is sent over the network, and is intended
> > + * only to aid in evaluating whether a navigation action should be taken or
> 
> This is not accurate either. NavigationAction is used in policy decisions,
> but also in create signal. It's not intended to decide whether the action
> should be taken or not, it's just information, the intentation of that
> information depends on the caller rather tahn the action object itself. I
> would add this comment to decide-policy signal, to clarify that you can
> ignore/download/use, but request can't be modified at that point.
> 
> > Source/WebKit/UIProcess/API/glib/WebKitResponsePolicyDecision.cpp:121
> > + * Return the #WebKitURIRequest associated with the response decision.
> > + * Modifications to the returned object are <emphasis>not</emphasis> taken
> > + * into account when the request is sent over the network, and is intended
> > + * only to aid in evaluating whether a response decision should be taken or
> > + * not. To modify requests before they are sent over the network the
> 
> It makes more sense here in this context, but maybe we can add a single
> comment in the signal description, you are suggesting to use a different
> signal in the end.

Thanks for the feedback, I'll make a follow-up patch soon to further
improve the documentation taking it into account :-)