[Qtwebengine] QtWebEngine in 5.6 and ServiceWorkers

[Yamada, Masami]

Hello Allan --

Thank you for your response. Here is the issue that I've encountered.

Our SPA calls  navigator.serviceWorker.register(...), and that works fine when the SPA is loaded via Chrome.

When the SPA is loaded within qwebengineview, the register fails, however, due to this code snippet, in ServiceWorkerDispatcherHost::OnRegisterServiceWorker

  // TODO(ksakamoto): Currently, document_url is empty if the document is in an
  // IFRAME using frame.contentDocument.write(...). We can remove this check
  // once crbug.com/439697 is fixed.
  if (provider_host->document_url().is_empty()) {
    Send(new ServiceWorkerMsg_ServiceWorkerRegistrationError(
        thread_id, request_id, WebServiceWorkerError::ErrorTypeSecurity,
        base::ASCIIToUTF16(kServiceWorkerRegisterErrorPrefix) +
            base::ASCIIToUTF16(kNoDocumentURLErrorMessage)));
    return;
  }

I looked at the chrome code and noticed that document_url is set as a result of service_worker interceptor being called from their custom protocol handler.
QtWebEngine uses the default protocol handler for https and doesn't seem to have any interaction with the service_worker interceptor.

I'd like to experiment with bringing over the custom protocol handler into qtwebengine.

Alternatively, I don't know if the chrome bug mentioned (https://code.google.com/p/chromium/issues/detail?id=439697) would fix our issue -- I wasn't sure if loading our SPA into a qwebengineview constitutes as an IFRAME?

Thank you,

Masami

-----Original Message-----
From: Allan Sandfeld Jensen [mailto:allan.jensen at theqtcompany.com] 
Sent: Thursday, August 27, 2015 1:56 PM
To: qtwebengine at qt-project.org
Cc: Back, Jonathan <JBack at ea.com>; Yamada, Masami <myamada at ea.com>; Chan, Bryan <bryanchan at ea.com>
Subject: Re: [Qtwebengine] QtWebEngine in 5.6 and ServiceWorkers

On Thursday 27 August 2015, Back, Jonathan wrote:
> Hello,
> 
> We are developers working on a web application that requires it to 
> function while the user is offline. 
> http://www.w3.org/TR/service-workers/  seems the best way to proceed, 
> and we were excited that 5.6 (which we are targeting for our release) was pulling in 44 / 45 version of Blink.
> However it seems that although Service Workers functions with 44 
> Chrome browser it does not function with QtWebEngine 5.6. We 
> investigated and the custom protocol handlers that Chrome installs to 
> handle Service Worker is not included in the pull from Blink. We are 
> currently working on trying to pull that into a version of 5.6 that we are building.
> 
> I wanted to ping this list as both a heads up and as a request for 
> help / information on any reasons why the Service Worker portions were excluded.
> Any information / thoughts are appreciated.
Thank you. Can you post an example of what doesn't work, and what code we didn't include into our snapshot?

> 
> Also, we notice a pull of 45 happened, is 45 the target for 5.6 and we 
> should focus on 45?
> 
Yes, I originally tried to rebase on Chromium 45 in June, but it was not stable enough to be useful for even a dev-branch so we rebased on 44 instead with an eye open for merging in 45 later if it looked to be simple and painfree. QtWebEngine 5.6 is now based on 45 and will stay on that (44 to 45 was a very small chromium update, only plus/minus a million lines of code in the parts we import).

Chromium 47 or 48 going into the dev branch for Qt 5.7 sometime late this year, but again QtWebEngine 5.7 might end up with a newer version of Chromium than the first version it is rebased on (ideally whatever branch is on release track around the time of the Qt 5.7 alpha). Since there seems to be a lot of work by outside parties going on on QtWebEngine now, I will try to keep the list informed of merging plans in the future.

Best regards
`Allan

-- 
 
The Qt Company
Rudower Chausse 13, 12489 D-Berlin
 
The Qt Company is a group company of Digia Plc, Valimotie 21, FI-00380 Helsinki Finland