webapp-container

Differences between revisions 5 and 24 (spanning 19 versions)
Revision 5 as of 2014-04-09 15:41:12
Size: 2272
Editor: AMontsouris-653-1-56-187
Comment:
Revision 24 as of 2015-09-17 19:34:41
Size: 6888
Editor: modemcable092
Comment:
Deletions are marked like this. Additions are marked like this.
Line 17: Line 17:
 * Install latest (trusty-proposed) image on phone
 * Use citrain-{slurp,push} to make a clean install of a silo or MP set
 * Ensure that all AP tests pass on the device.
=== General verifications ===
Line 21: Line 19:
 * Launch the top-10 webapps on the desktop Apply this to one of your favorite webapp, for example Facebook:
Line 24: Line 22:
 * Verify that the use is not ejected to the browser during the normal use of a webapp. Those may indicate URL pattern issues
 * Verify that you can navigate back to a previous page inside a webapp, by surfacing the back button from the bottom toolbar
 * Verify that the user is not ejected to the browser during the normal use of a webapp. Those may indicate URL pattern issues
 * If the webapp is displaying a title bar with navigation buttons, verify that the back button is operational
 * Verify that no transparent header appears at the top of the webapp UI (https://launchpad.net/bugs/1305834)
 * Verify that the container displays an error in the absence of network; that the reload button works when the link is back (https://bugs.launchpad.net/webbrowser-app/+bug/1309138)

=== Config options ===

 * Verify that the UA override option documented in https://bugs.launchpad.net/webbrowser-app/+bug/1379497 is working. Use this test application to verify: https://code.launchpad.net/~dbarth/+junk/webbapp-whichbrowser
   * It should say that you are using an unknown browser.
   * Note: not functional currently due to https://bugs.launchpad.net/webbrowser-app/+bug/1379497

=== Desktop test cases ===
Line 36: Line 44:
 * Verify that no webapp desktop file persists in ~/.local/share/applications

=== Online Accounts Integration ===

 * Start without a Facebook account declared in System Settings
  * Open the Facebook webapp
  * Verify that the application opens an account creation prompt session to create a new account
  * Proceed with the account creation process and accept that Ubuntu be able to use the Facebook permissions summarized at the end of the account creation process
  * Verify that once done (the Trust Session Prompt closes), you are returned to the webapp and automatically logged in

 * Close the app; Re-start the Facebook webapp
 * Verify that you are automatically logged in

 * Quit the Facebook webapp
 * Go to System Settings > Accounts > Facebook > De-authorize the webapp
 * Open the Facebook webapp
 * Verify that the webapp requests your authorization to use the Facebook account

 * Suppress the Facebook account in System Settings
 * Open the Facebook webapp
 * During the account creation process that follows, select to cancel the process
 * Verify that the Facebook webapp exists and returns you to the Dash

=== Core Webapps ===

For complete regression testing, complete the Core Webapps test plan in [[Process/Merges/TestPlans/webapps]]


=== Url State Saver support ===

/!\ still not functional until the related branch lands.

Verify that a webapp does restart automatically to its last URL if ever it gets killed by the OOMKiller. See https://bugs.launchpad.net/webbrowser-app/+bug/1379428.
 * start the ebay webapp
 * navigate to a sub page, like a product detail page
 * log onto the phone with a shell; identify the webapp-container instance that runs ebays: ps ax | grep webapp-container | grep -i ebay
 * switch away from the webapp and use another app for a while (give time to the webapp to be stopped)
 * kill -9 the webapp
 * now switch back to the ebay webapp
 * the webapp should reload and get back to the same product detail page (ie, not back to the home page)

The issue was recorded as: https://bugs.launchpad.net/webbrowser-app/+bug/1379428

=== Click Hooks ===

The container has click hooks to:

* clean the application cache

* clean the application settings/resource files,

There are unittests in the webapp-container source package for those areas.

In order to manually test it, one needs a click webapp with those hooks defined.

1. create a webapp e.g. from qtcreator (or take an existing one),

2. add a webapp click hook to the manifest.json file in the appropriate section such as:

"webapp-container": "webapp-facebook.webapp"

in the list of click hooks,

3. add a webapp-facebook.webapp file (the name might obviously vary) with eg.

[{"uninstall": { "delete-cookies": true, "delete-cache": true } }]

which should trigger the (default) ~/.local/share/<app-id> ("delete-cookies" flag)
and ~/.cache/<app-id> ("delete-cache" flag) to be removed.

You can toggle each flag as needed and verify that only the right actions are
being performed (in this context, specific folder deletion).

=== Intent URI handling ===

A webapp has the capability to declare a handler for a specific intent (https://developer.chrome.com/multidevice/android/intents) URI. It can then have a 'local-scheme-filter.js' file that contains a potential small javascript snippet that is run when and intent URI it handles is receives (through the URI dispatcher):

1. install the click webapp attached in the bug report

https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1475708

2. create a simple qml app from QtCreator, just to have a simple mean to trigger a url dispatch. Open the Main.qml file, and replace the content of the BUtton onClicked's handler by:

Qt.openUrlExternally('intent://www.ubuntu.com/blabla/#Intent;scheme=http;package=com.canonical.apps.maps;end')

3. Run the application on the device and tap on the button

4. The webapp above should open and browse to google.com

* Test plan for component: webapp-container

Dependents/Clients

All webapps, on both desktop and touch, ie:

Test Plan

This test plan is not supposed to be complete; use it to guide your manual testing so they dont miss big functional areas that are part in the component; also this should be used as guideline to inspire the exploratory testing which should be adapted smartly based on the real content of a MP

General verifications

Apply this to one of your favorite webapp, for example Facebook:

  • Verify the main features for each of them: login, sending messages, browsing content, watching videos, playing music when relevant
  • Verify that links leading to external content are re-directed to the default browser application
  • Verify that the user is not ejected to the browser during the normal use of a webapp. Those may indicate URL pattern issues
  • If the webapp is displaying a title bar with navigation buttons, verify that the back button is operational
  • Verify that no transparent header appears at the top of the webapp UI (https://launchpad.net/bugs/1305834)

  • Verify that the container displays an error in the absence of network; that the reload button works when the link is back (https://bugs.launchpad.net/webbrowser-app/+bug/1309138)

Config options

Desktop test cases

  • Verify the installation of a webapp on the desktop
    • remove an existing webapp by going into FF or Chrome preferences > Installed websites > uncheck the site(s) you want to test re-installing (ideally all)

    • restart your browser
    • navigate to one of the site managed on our list of top-10 webapps
    • verify that you see a prompt to install the webapp (infobar in the browser)
    • answer yes and verify that a new icon appears on the launcher bar
    • start the webapp with the new launcher
    • verify that the launcher icon is associated with the webapp window; switch back to other app windows and back to the webapp with its launcher icon
    • stop the webapp, and restart it; verify that the icon did not disappear (ie was properly locked on your launcher bar)
  • Verify that no webapp desktop file persists in ~/.local/share/applications

Online Accounts Integration

  • Start without a Facebook account declared in System Settings
    • Open the Facebook webapp
    • Verify that the application opens an account creation prompt session to create a new account
    • Proceed with the account creation process and accept that Ubuntu be able to use the Facebook permissions summarized at the end of the account creation process
    • Verify that once done (the Trust Session Prompt closes), you are returned to the webapp and automatically logged in
  • Close the app; Re-start the Facebook webapp
  • Verify that you are automatically logged in
  • Quit the Facebook webapp
  • Go to System Settings > Accounts > Facebook > De-authorize the webapp

  • Open the Facebook webapp
  • Verify that the webapp requests your authorization to use the Facebook account
  • Suppress the Facebook account in System Settings
  • Open the Facebook webapp
  • During the account creation process that follows, select to cancel the process
  • Verify that the Facebook webapp exists and returns you to the Dash

Core Webapps

For complete regression testing, complete the Core Webapps test plan in Process/Merges/TestPlans/webapps

Url State Saver support

Warning /!\ still not functional until the related branch lands.

Verify that a webapp does restart automatically to its last URL if ever it gets killed by the OOMKiller. See https://bugs.launchpad.net/webbrowser-app/+bug/1379428.

  • start the ebay webapp
  • navigate to a sub page, like a product detail page
  • log onto the phone with a shell; identify the webapp-container instance that runs ebays: ps ax | grep webapp-container | grep -i ebay
  • switch away from the webapp and use another app for a while (give time to the webapp to be stopped)
  • kill -9 the webapp
  • now switch back to the ebay webapp
  • the webapp should reload and get back to the same product detail page (ie, not back to the home page)

The issue was recorded as: https://bugs.launchpad.net/webbrowser-app/+bug/1379428

Click Hooks

The container has click hooks to:

* clean the application cache

* clean the application settings/resource files,

There are unittests in the webapp-container source package for those areas.

In order to manually test it, one needs a click webapp with those hooks defined.

1. create a webapp e.g. from qtcreator (or take an existing one),

2. add a webapp click hook to the manifest.json file in the appropriate section such as:

"webapp-container": "webapp-facebook.webapp"

in the list of click hooks,

3. add a webapp-facebook.webapp file (the name might obviously vary) with eg.

[{"uninstall": { "delete-cookies": true, "delete-cache": true } }]

which should trigger the (default) ~/.local/share/<app-id> ("delete-cookies" flag) and ~/.cache/<app-id> ("delete-cache" flag) to be removed.

You can toggle each flag as needed and verify that only the right actions are being performed (in this context, specific folder deletion).

Intent URI handling

A webapp has the capability to declare a handler for a specific intent (https://developer.chrome.com/multidevice/android/intents) URI. It can then have a 'local-scheme-filter.js' file that contains a potential small javascript snippet that is run when and intent URI it handles is receives (through the URI dispatcher):

1. install the click webapp attached in the bug report

https://bugs.launchpad.net/ubuntu/+source/webbrowser-app/+bug/1475708

2. create a simple qml app from QtCreator, just to have a simple mean to trigger a url dispatch. Open the Main.qml file, and replace the content of the BUtton onClicked's handler by:

Qt.openUrlExternally('intent://www.ubuntu.com/blabla/#Intent;scheme=http;package=com.canonical.apps.maps;end')

3. Run the application on the device and tap on the button

4. The webapp above should open and browse to google.com

Process/Merges/TestPlan/webapp-container (last edited 2015-11-10 17:11:40 by modemcable092)