From bryan.chan at pacbell.net Sat Aug 8 03:14:35 2015 From: bryan.chan at pacbell.net (Bryan Chan) Date: Fri, 7 Aug 2015 18:14:35 -0700 Subject: [Qtwebengine] Transport to use in JavaScript for webengine ipc Message-ID: <68BFE85E-E1FB-4EC2-9E85-6400DC30AEC4@pacbell.net> Hi, I'm trying to implement a IPC web channel connection from a qwebenginepage. On the JavaScript file what should I pass as the transport parameter in the QWebChannel class? WebKit can use something like navigator.qtwebipctransport, is there a webengine equivalent? Thanks, bryan From milian.wolff at kdab.com Sun Aug 9 22:33:13 2015 From: milian.wolff at kdab.com (Milian Wolff) Date: Sun, 09 Aug 2015 22:33:13 +0200 Subject: [Qtwebengine] Transport to use in JavaScript for webengine ipc In-Reply-To: <68BFE85E-E1FB-4EC2-9E85-6400DC30AEC4@pacbell.net> References: <68BFE85E-E1FB-4EC2-9E85-6400DC30AEC4@pacbell.net> Message-ID: <1556479.2k1eWat9XC@agathebauer> On Friday, August 07, 2015 06:14:35 PM Bryan Chan wrote: > Hi, > > I'm trying to implement a IPC web channel connection from a qwebenginepage. > On the JavaScript file what should I pass as the transport parameter in the > QWebChannel class? > > WebKit can use something like navigator.qtwebipctransport, is there a > webengine equivalent? It should be qt.webChannelTransport if I'm not mistaken! Bye -- Milian Wolff | milian.wolff at kdab.com | Software Engineer KDAB (Deutschland) GmbH&Co KG, a KDAB Group company Tel: +49-30-521325470 KDAB - The Qt Experts -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5903 bytes Desc: not available URL: From bryan.chan at pacbell.net Mon Aug 10 23:09:26 2015 From: bryan.chan at pacbell.net (Bryan Chan) Date: Mon, 10 Aug 2015 21:09:26 +0000 (UTC) Subject: [Qtwebengine] QWebengine and forcing to load from cache Message-ID: <1596964227.2374996.1439240966878.JavaMail.yahoo@mail.yahoo.com>  Our application requires the ability to run in an artificial“offline” mode (where the user chooses to be “offline” but isn’t reallydisconnected from the network)  and in that case, we’ve been usingQNetworkAccessManager to force load from the cache by setting theCacheLoadControlAttribute to QNetworkRequest::AlwaysCache.   We’re in the process of switching to QtWebEngine which Iunderstand does not interact with QNetworkAccessManager.  Is there a wayfor us to force load from the web cache? -------------- next part -------------- An HTML attachment was scrubbed... URL: From allan.jensen at theqtcompany.com Tue Aug 11 09:45:01 2015 From: allan.jensen at theqtcompany.com (Allan Sandfeld Jensen) Date: Tue, 11 Aug 2015 09:45:01 +0200 Subject: [Qtwebengine] QtWebEngine unbundled of third-party libraries on Linux Message-ID: <201508110945.01574.allan.jensen@theqtcompany.com> Hello Qt QtWebEngine and Chromium in the Qt 5.6 branch have been patched to allow linking with system libraries on Linux instead of bundled libraries. For most libraries the system library will be used if development files are detected on the system. ICU and FFMPEG however defaults to using the bundled copies and requires using qmake arguments to configure to use system versions. The required arguments are listed in qmake configure status (just delete .qmake.cache and run qmake to run the configure step again). Note that for FFMPEG, the libav libraries from the FFMPEG project are required, the libraries from the libav project does not work. I have so far only tested on Debian. If more people could test it we could also get better detection and set proper minimal versions. If you are a packager and more is required before QtWebEngine can be packaged on your distribution, please let me know. Best regards `Allan Jensen -- 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 From Kai.Koehne at theqtcompany.com Mon Aug 17 14:01:16 2015 From: Kai.Koehne at theqtcompany.com (Koehne Kai) Date: Mon, 17 Aug 2015 12:01:16 +0000 Subject: [Qtwebengine] QWebengine and forcing to load from cache In-Reply-To: <1596964227.2374996.1439240966878.JavaMail.yahoo@mail.yahoo.com> References: <1596964227.2374996.1439240966878.JavaMail.yahoo@mail.yahoo.com> Message-ID: > -----Original Message----- > From: qtwebengine-bounces+kai.koehne=theqtcompany.com at qt- > Subject: [Qtwebengine] QWebengine and forcing to load from cache > > > Our application requires the ability to run in an artificial “offline” mode > (where the user chooses to be “offline” but isn’t really disconnected from > the network) and in that case, we’ve been using QNetworkAccessManager > to force load from the cache by setting the CacheLoadControlAttribute to > QNetworkRequest::AlwaysCache. > > We’re in the process of switching to QtWebEngine which I understand does > not interact with QNetworkAccessManager. Is there a way for us to force > load from the web cache? Hi, I'm afraid there's no direct way to achieve the same in QtWebEngine. As you've noticed, QtWebEngine uses Chromiums' network stack, and there's no public API to manipulate the caching. There's also an upstream bug about an 'offline mode' which however is set to WONTFIX: https://code.google.com/p/chromium/issues/detail?id=2204 Regards Kai From me at the-compiler.org Thu Aug 20 11:21:18 2015 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 20 Aug 2015 11:21:18 +0200 Subject: [Qtwebengine] Sharing data between QWebEngineProfiles Message-ID: <20150820092118.GP729@tonks> Hi, I (from qutebrowser[1]) and Emdek (from Otter Browser[2]) discussed what's still missing for us from QtWebEngine, and one point which came up and wasn't discussed already is sharing data between multiple QWebEngineProfiles. Our use-case is to have per-domain and possibly per-tab settings, e.g. the user want to configure the user-agent differently based on the page they're visiting. This means you'll end up with having a new QWebEngineProfile for every tab - however, that also means every tab will have its own persistent storage, cookie store, and cache - right? Is it possible/planned to share data between QWebEngineProfiles so one can implement this kind of thing? I guess one possibility is to use the same storageName for all of them - but will that work? Florian [1] http://www.qutebrowser.org/ [2] http://www.otter-browser.org/ -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From me at the-compiler.org Thu Aug 20 13:52:09 2015 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 20 Aug 2015 13:52:09 +0200 Subject: [Qtwebengine] Sharing data between QWebEngineProfiles In-Reply-To: <201508201337.37718.kde@carewolf.com> References: <20150820092118.GP729@tonks> <201508201337.37718.kde@carewolf.com> Message-ID: <20150820115209.GU729@tonks> * Allan Sandfeld Jensen [2015-08-20 13:37:37 +0200]: > On Thursday 20 August 2015, Florian Bruhin wrote: > > Hi, > > > > I (from qutebrowser[1]) and Emdek (from Otter Browser[2]) discussed > > what's still missing for us from QtWebEngine, and one point which came > > up and wasn't discussed already is sharing data between multiple > > QWebEngineProfiles. > > > > Our use-case is to have per-domain and possibly per-tab settings, e.g. > > the user want to configure the user-agent differently based on the > > page they're visiting. > > > > This means you'll end up with having a new QWebEngineProfile for every > > tab - however, that also means every tab will have its own persistent > > storage, cookie store, and cache - right? > > > > Is it possible/planned to share data between QWebEngineProfiles so one > > can implement this kind of thing? > > > > I guess one possibility is to use the same storageName for all of them > > - but will that work? > > > No, that would not be how profiles are supposed to be used. If you need > different user-agent string per page, we should probably make a separate API > for that (in fact the Chromium API we use already have separate mechanisms for > overriding user-agent on a per page basis. But I wonder - what's the reason things like httpUserAgent or persistentCookiesPolicy (i.e. things you might want to set per-tab/domain/...) are in QWebEngineProfile rather than QWebEngineSettings? I guess it would be possible to control those per page using the new QWebEngineCookieStoreClient and QWebEngineUrlRequestInterceptor APIs, right? But I still feel like this kind of thing should be simpler and probably be in QWebEngineSettings which can be set per-page. Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From me at the-compiler.org Thu Aug 20 13:52:09 2015 From: me at the-compiler.org (Florian Bruhin) Date: Thu, 20 Aug 2015 13:52:09 +0200 Subject: [Qtwebengine] Sharing data between QWebEngineProfiles In-Reply-To: <201508201337.37718.kde@carewolf.com> References: <20150820092118.GP729@tonks> <201508201337.37718.kde@carewolf.com> Message-ID: <20150820115209.GU729@tonks> * Allan Sandfeld Jensen [2015-08-20 13:37:37 +0200]: > On Thursday 20 August 2015, Florian Bruhin wrote: > > Hi, > > > > I (from qutebrowser[1]) and Emdek (from Otter Browser[2]) discussed > > what's still missing for us from QtWebEngine, and one point which came > > up and wasn't discussed already is sharing data between multiple > > QWebEngineProfiles. > > > > Our use-case is to have per-domain and possibly per-tab settings, e.g. > > the user want to configure the user-agent differently based on the > > page they're visiting. > > > > This means you'll end up with having a new QWebEngineProfile for every > > tab - however, that also means every tab will have its own persistent > > storage, cookie store, and cache - right? > > > > Is it possible/planned to share data between QWebEngineProfiles so one > > can implement this kind of thing? > > > > I guess one possibility is to use the same storageName for all of them > > - but will that work? > > > No, that would not be how profiles are supposed to be used. If you need > different user-agent string per page, we should probably make a separate API > for that (in fact the Chromium API we use already have separate mechanisms for > overriding user-agent on a per page basis. But I wonder - what's the reason things like httpUserAgent or persistentCookiesPolicy (i.e. things you might want to set per-tab/domain/...) are in QWebEngineProfile rather than QWebEngineSettings? I guess it would be possible to control those per page using the new QWebEngineCookieStoreClient and QWebEngineUrlRequestInterceptor APIs, right? But I still feel like this kind of thing should be simpler and probably be in QWebEngineSettings which can be set per-page. Florian -- http://www.the-compiler.org | me at the-compiler.org (Mail/XMPP) GPG: 916E B0C8 FD55 A072 | http://the-compiler.org/pubkey.asc I love long mails! | http://email.is-not-s.ms/ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kde at carewolf.com Thu Aug 20 13:37:37 2015 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Thu, 20 Aug 2015 13:37:37 +0200 Subject: [Qtwebengine] Sharing data between QWebEngineProfiles In-Reply-To: <20150820092118.GP729@tonks> References: <20150820092118.GP729@tonks> Message-ID: <201508201337.37718.kde@carewolf.com> On Thursday 20 August 2015, Florian Bruhin wrote: > Hi, > > I (from qutebrowser[1]) and Emdek (from Otter Browser[2]) discussed > what's still missing for us from QtWebEngine, and one point which came > up and wasn't discussed already is sharing data between multiple > QWebEngineProfiles. > > Our use-case is to have per-domain and possibly per-tab settings, e.g. > the user want to configure the user-agent differently based on the > page they're visiting. > > This means you'll end up with having a new QWebEngineProfile for every > tab - however, that also means every tab will have its own persistent > storage, cookie store, and cache - right? > > Is it possible/planned to share data between QWebEngineProfiles so one > can implement this kind of thing? > > I guess one possibility is to use the same storageName for all of them > - but will that work? > No, that would not be how profiles are supposed to be used. If you need different user-agent string per page, we should probably make a separate API for that (in fact the Chromium API we use already have separate mechanisms for overriding user-agent on a per page basis. `Allan From kde at carewolf.com Thu Aug 20 15:12:14 2015 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Thu, 20 Aug 2015 15:12:14 +0200 Subject: [Qtwebengine] Sharing data between QWebEngineProfiles In-Reply-To: <20150820115209.GU729@tonks> References: <20150820092118.GP729@tonks> <201508201337.37718.kde@carewolf.com> <20150820115209.GU729@tonks> Message-ID: <201508201512.14582.kde@carewolf.com> On Thursday 20 August 2015, Florian Bruhin wrote: > * Allan Sandfeld Jensen [2015-08-20 13:37:37 +0200]: > > On Thursday 20 August 2015, Florian Bruhin wrote: > > > Hi, > > > > > > I (from qutebrowser[1]) and Emdek (from Otter Browser[2]) discussed > > > what's still missing for us from QtWebEngine, and one point which came > > > up and wasn't discussed already is sharing data between multiple > > > QWebEngineProfiles. > > > > > > Our use-case is to have per-domain and possibly per-tab settings, e.g. > > > the user want to configure the user-agent differently based on the > > > page they're visiting. > > > > > > This means you'll end up with having a new QWebEngineProfile for every > > > tab - however, that also means every tab will have its own persistent > > > storage, cookie store, and cache - right? > > > > > > Is it possible/planned to share data between QWebEngineProfiles so one > > > can implement this kind of thing? > > > > > > I guess one possibility is to use the same storageName for all of them > > > - but will that work? > > > > No, that would not be how profiles are supposed to be used. If you need > > different user-agent string per page, we should probably make a separate > > API for that (in fact the Chromium API we use already have separate > > mechanisms for overriding user-agent on a per page basis. > > But I wonder - what's the reason things like httpUserAgent or > persistentCookiesPolicy (i.e. things you might want to set > per-tab/domain/...) are in QWebEngineProfile rather than > QWebEngineSettings? > > I guess it would be possible to control those per page using the new > QWebEngineCookieStoreClient and QWebEngineUrlRequestInterceptor APIs, > right? But I still feel like this kind of thing should be simpler and > probably be in QWebEngineSettings which can be set per-page. > The profile exists because it matches a Chromium API called BrowserContext. We simply can not control many of these settings per page, but only per BrowserContext. This is supposed to replace global and static settings that used to be in QWebSettings, and you are not really expected to have more than one profile, with the except of possibly on of incognito and one normal. `Allan From kde at carewolf.com Thu Aug 20 15:12:14 2015 From: kde at carewolf.com (Allan Sandfeld Jensen) Date: Thu, 20 Aug 2015 15:12:14 +0200 Subject: [Qtwebengine] Sharing data between QWebEngineProfiles In-Reply-To: <20150820115209.GU729@tonks> References: <20150820092118.GP729@tonks> <201508201337.37718.kde@carewolf.com> <20150820115209.GU729@tonks> Message-ID: <201508201512.14582.kde@carewolf.com> On Thursday 20 August 2015, Florian Bruhin wrote: > * Allan Sandfeld Jensen [2015-08-20 13:37:37 +0200]: > > On Thursday 20 August 2015, Florian Bruhin wrote: > > > Hi, > > > > > > I (from qutebrowser[1]) and Emdek (from Otter Browser[2]) discussed > > > what's still missing for us from QtWebEngine, and one point which came > > > up and wasn't discussed already is sharing data between multiple > > > QWebEngineProfiles. > > > > > > Our use-case is to have per-domain and possibly per-tab settings, e.g. > > > the user want to configure the user-agent differently based on the > > > page they're visiting. > > > > > > This means you'll end up with having a new QWebEngineProfile for every > > > tab - however, that also means every tab will have its own persistent > > > storage, cookie store, and cache - right? > > > > > > Is it possible/planned to share data between QWebEngineProfiles so one > > > can implement this kind of thing? > > > > > > I guess one possibility is to use the same storageName for all of them > > > - but will that work? > > > > No, that would not be how profiles are supposed to be used. If you need > > different user-agent string per page, we should probably make a separate > > API for that (in fact the Chromium API we use already have separate > > mechanisms for overriding user-agent on a per page basis. > > But I wonder - what's the reason things like httpUserAgent or > persistentCookiesPolicy (i.e. things you might want to set > per-tab/domain/...) are in QWebEngineProfile rather than > QWebEngineSettings? > > I guess it would be possible to control those per page using the new > QWebEngineCookieStoreClient and QWebEngineUrlRequestInterceptor APIs, > right? But I still feel like this kind of thing should be simpler and > probably be in QWebEngineSettings which can be set per-page. > The profile exists because it matches a Chromium API called BrowserContext. We simply can not control many of these settings per page, but only per BrowserContext. This is supposed to replace global and static settings that used to be in QWebSettings, and you are not really expected to have more than one profile, with the except of possibly on of incognito and one normal. `Allan From JBack at ea.com Thu Aug 27 19:52:56 2015 From: JBack at ea.com (Back, Jonathan) Date: Thu, 27 Aug 2015 17:52:56 +0000 Subject: [Qtwebengine] QtWebEngine in 5.6 and ServiceWorkers Message-ID: 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. Also, we notice a pull of 45 happened, is 45 the target for 5.6 and we should focus on 45? Thanks in advance, -Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From allan.jensen at theqtcompany.com Thu Aug 27 22:55:45 2015 From: allan.jensen at theqtcompany.com (Allan Sandfeld Jensen) Date: Thu, 27 Aug 2015 22:55:45 +0200 Subject: [Qtwebengine] QtWebEngine in 5.6 and ServiceWorkers In-Reply-To: References: Message-ID: <201508272255.45572.allan.jensen@theqtcompany.com> 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 From myamada at ea.com Fri Aug 28 00:05:00 2015 From: myamada at ea.com (Yamada, Masami) Date: Thu, 27 Aug 2015 22:05:00 +0000 Subject: [Qtwebengine] QtWebEngine in 5.6 and ServiceWorkers In-Reply-To: <201508272255.45572.allan.jensen@theqtcompany.com> References: <201508272255.45572.allan.jensen@theqtcompany.com> Message-ID: 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 ; Yamada, Masami ; Chan, Bryan 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