webapp-container

* 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

URI dispatching

The url-dispatcher service can dispatch http urls to specific webapps that declaratively "own" their domain.

1. Check the current version of the Twitter webapp which will be used as a test bed for this

click info com.ubuntu.developer.webapps.webapp-twitter

2. Make sure that the twitter webapp is not opened

3. Open a shell session on the device and run the following command:

ubuntu-app-launch com.ubuntu.developer.webapps.webapp-twitter_webapp-twitter_1.1 http://twitter.com/14075928/status/635806536795824128

(you might have to tweak the webapp version number)

Make sure that the Twitter Webapp is started at the proper URL (not the main page),

4. Browse to the Twitter homepage,

5. Redo the test described in step 3) and check the result

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