Merge lp:~abreu-alexandre/webbrowser-app/fix-url-pattern-patching-overrides-and-google-patterns into lp:webbrowser-app
Status: | Merged | ||||
---|---|---|---|---|---|
Merged at revision: | 471 | ||||
Proposed branch: | lp:~abreu-alexandre/webbrowser-app/fix-url-pattern-patching-overrides-and-google-patterns | ||||
Merge into: | lp:webbrowser-app | ||||
Diff against target: |
450 lines (+306/-46) 8 files modified
src/app/webcontainer/CMakeLists.txt (+1/-1) src/app/webcontainer/WebApp.qml (+23/-5) src/app/webcontainer/url-pattern-utils.cpp (+129/-0) src/app/webcontainer/url-pattern-utils.h (+32/-0) src/app/webcontainer/webapp-container.cpp (+11/-40) tests/unittests/CMakeLists.txt (+1/-0) tests/unittests/container-url-patterns/CMakeLists.txt (+10/-0) tests/unittests/container-url-patterns/tst_ContainerUrlPatterns.cpp (+99/-0) |
||||
To merge this branch: | bzr merge lp:~abreu-alexandre/webbrowser-app/fix-url-pattern-patching-overrides-and-google-patterns | ||||
Related bugs: |
|
Reviewer | Review Type | Date Requested | Status |
---|---|---|---|
PS Jenkins bot | continuous-integration | Approve | |
Alberto Mardegan (community) | Approve | ||
David Barth | Pending | ||
Ubuntu Phablet Team | Pending | ||
Review via email:
|
Commit message
There are 2 ways for the webapp-container to receive a list of patterns to filter url browsing in a webapp container: through the manifest.json file that comes with a given (named) webapp, or through the command line.
At the moment, the 2 mechanisms are exclusive in the sense that from the webapp-container's perspective it only considers one or another when filtering navigation (the webapp manifest one being preferred) but they are NOT semantically equivalent. The list of url patterns in the manifest.json file is use as a mean to filter the urls that are being browsed to, but ALSO in the chromium & FF browsers to know if a webapp is to be installed/enabled when browsing in a given url.
For example, for Gmail, the hostname mail.google.com is used as a trigger to ask the user for an installation/
The issue is that for applications like google services, the authentication mechanism is common. So when launched in the container, the user will be redirected to e.g. https:/
So, the manifest.json cannot be modified to account for those, since we dont want to install a webapp from those URLs but we need a way to add extra navigation url patterns to allow google service webapps to be redirected to e.g. https:/
We provide here 2 things:
- an way for the url patterns passed down from the command line to be also considered in the navigation filtering,
- a way to simplify url patterns for google apps
Description of the change
There are 2 ways for the webapp-container to receive a list of patterns to filter url browsing in a webapp container: through the manifest.json file that comes with a given (named) webapp, or through the command line.
At the moment, the 2 mechanisms are exclusive in the sense that from the webapp-container's perspective it only considers one or another when filtering navigation (the webapp manifest one being preferred) but they are NOT semantically equivalent. The list of url patterns in the manifest.json file is use as a mean to filter the urls that are being browsed to, but ALSO in the chromium & FF browsers to know if a webapp is to be installed/enabled when browsing in a given url.
For example, for Gmail, the hostname mail.google.com is used as a trigger to ask the user for an installation/
The issue is that for applications like google services, the authentication mechanism is common. So when launched in the container, the user will be redirected to e.g. https:/
So, the manifest.json cannot be modified to account for those, since we dont want to install a webapp from those URLs but we need a way to add extra navigation url patterns to allow google service webapps to be redirected to e.g. https:/
We provide here 2 things:
- an way for the url patterns passed down from the command line to be also considered in the navigation filtering,
- a way to simplify url patterns for google apps
PASSED: Continuous integration, rev:456 jenkins. qa.ubuntu. com/job/ webbrowser- app-ci/ 621/ jenkins. qa.ubuntu. com/job/ generic- mediumtests- trusty/ 3739 jenkins. qa.ubuntu. com/job/ generic- mediumtests- trusty- touch/3328 jenkins. qa.ubuntu. com/job/ webbrowser- app-trusty- amd64-ci/ 123 jenkins. qa.ubuntu. com/job/ webbrowser- app-trusty- armhf-ci/ 123 jenkins. qa.ubuntu. com/job/ webbrowser- app-trusty- armhf-ci/ 123/artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ webbrowser- app-trusty- i386-ci/ 123 jenkins. qa.ubuntu. com/job/ autopilot- testrunner- otto-trusty/ 3287 jenkins. qa.ubuntu. com/job/ generic- mediumtests- builder- trusty- amd64/3744 jenkins. qa.ubuntu. com/job/ generic- mediumtests- builder- trusty- amd64/3744/ artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ generic- mediumtests- builder- trusty- armhf/3330 jenkins. qa.ubuntu. com/job/ generic- mediumtests- builder- trusty- armhf/3330/ artifact/ work/output/ *zip*/output. zip jenkins. qa.ubuntu. com/job/ generic- mediumtests- runner- mako/5698 s-jenkins. ubuntu- ci:8080/ job/touch- flash-device/ 4559
http://
Executed test runs:
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
deb: http://
SUCCESS: http://
SUCCESS: http://
Click here to trigger a rebuild: s-jenkins. ubuntu- ci:8080/ job/webbrowser- app-ci/ 621/rebuild
http://