Bug 201642 – [GTK][WPE] Add WebKitWebView:page-id property

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Carlos Garcia Campos]

The page ID of a WebKitWebView can now change, so we need a way to get notified when it changes.

[Carlos Garcia Campos]

Created attachment 378459 [details]
Patch

[Alex Christensen]

Comment on attachment 378459 [details]
Patch

I'm assuming this allows you to fix the gtk applications that were broken by Chris's change.  This isn't so bad, but could we instead work towards not exposing identifiers at all?  They're an internal implementation detail.

[Carlos Garcia Campos]

(In reply to Alex Christensen from comment #2)
> Comment on attachment 378459 [details]
> Patch
> 
> I'm assuming this allows you to fix the gtk applications that were broken by
> Chris's change.

Exactly. because now the page ID can change. Unfortunately, apps will have to adapt to the new behavior.

>  This isn't so bad, but could we instead work towards not
> exposing identifiers at all?  They're an internal implementation detail.

It's too late for that, they are already part of our public stable API. But I'm open to find a different solution instead of adding this property, and deprecate the existing APIs exposing IDs. We basically need a way to identify the web process attached to a web view to be able to start a communication channel with the injected bundle.

Whatever we decide to do, we need to do it as soon as possible to give applications time to adapt to it before the next stable release (in ~6 months)

[Carlos Garcia Campos]

When we designed the WebKit2 API we decided not to expose any API to share user messages between the UI process and the injected bundle in the web process. I don't remember exactly why (I think we wanted to make sure user messages don't affect the internal IPC traffic), but I see Apple ports don't expose it either. We might reconsider it and expose it now (users can still use their own way). With API for that, users no longer need to worry about what process to talk too, webkit_web_view_send_message() and webkit_web_page_send_message() (or whatever they are called) will always do the right thing. We would need a message-received signal in both WebKitWebView and WebKitWebPage too.

[Carlos Garcia Campos]

Created attachment 379625 [details]
Rebased patch

[EWS Watchlist]

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

[Michael Catanzaro]

Comment on attachment 379625 [details]
Rebased patch

Exposing the messaging APIs sounds like a good idea to me, since using page IDs feels fragile now that we have PSON.

Still, removing page IDs completely from the API is not possible unless we totally give up on any pretense of backwards-compatibility and bump the API version. Deprecating these APIs and making them return, say, 0 would break too many apps. Having changing page IDs is risky enough as it is.

Anyway, hopefully we never have to do that. Even if we somebody have to, adding it as a property until then has no downsides. So r=me, except owner approval is required for PageClient.h and WebPageProxy.cpp.

[Adrian Perez]

(In reply to Michael Catanzaro from comment #7)
> Comment on attachment 379625 [details]
> Rebased patch
> 
> Exposing the messaging APIs sounds like a good idea to me, since using page
> IDs feels fragile now that we have PSON.
> 
> Still, removing page IDs completely from the API is not possible unless we
> totally give up on any pretense of backwards-compatibility and bump the API
> version. Deprecating these APIs and making them return, say, 0 would break
> too many apps. Having changing page IDs is risky enough as it is.
>
> […]

I think for the WPE port we could afford an API bump for 2.28, provided
that it's limited to a few selected changes (like this one), and that
the rest of the API remains backwards compatible. For the GTK port…
well, as you point out it's definitely trickier and I would not push
for it until a more suitable moment. I have been hoping that at some
point we are able make an API for GTK4. True, we will have to maintain
the existing code paths working as long as GTK3 remains supported, but
at least we will have a path sunsetting usage of page IDs.

Anyway, that is just a bit of a braindump which deserves more planning
and discussion. If something is clear is that we cannot afford to break
GTK applications anytime soon.

[Carlos Garcia Campos]

(In reply to Michael Catanzaro from comment #7)
> Comment on attachment 379625 [details]
> Rebased patch
> 
> Exposing the messaging APIs sounds like a good idea to me, since using page
> IDs feels fragile now that we have PSON.
>
> Still, removing page IDs completely from the API is not possible unless we
> totally give up on any pretense of backwards-compatibility and bump the API
> version. Deprecating these APIs and making them return, say, 0 would break
> too many apps. Having changing page IDs is risky enough as it is.
> 
> Anyway, hopefully we never have to do that. Even if we somebody have to,
> adding it as a property until then has no downsides. So r=me, except owner
> approval is required for PageClient.h and WebPageProxy.cpp.

Alex?

[Carlos Garcia Campos]

Ping owners

[Chris Dumez]

Comment on attachment 379625 [details]
Rebased patch

Cross-platform WK2 bits LGTM.

[Carlos Garcia Campos]

Committed r250645: <https://trac.webkit.org/changeset/250645>