Escaping from Twitter in the Twitter WebApp

[Nicolas Delvaux]

Nexus 4, image 204.

Here is a reliable escaping walkthrough I found (it's obviously not the single one and there is probably a simpler way):

- Reset the Twitter app (rm -r /home/phablet/.local/share/com.ubuntu.developer.webapps.webapp-twitter)
- launch the Twitter app, the "Sign in" screen is displayed
- Click on "Cookie Use"
- Unfold the menu at the bottom of the page and click on "Blog"
- Click on the number next to the Tweet button at the bottom of the blog home page
- Click on the "Install app" button in the top panel
- You are now on Google play

I also noticed that it is possible to go directly to a screen with the "Install app" button by clicking on a Unity 8 notification (it may only work if you are not already logged in the twitter app)

[Olivier Tilloy (osomon)]

I can reliably reproduce following the steps described above.

Note that following a different path to the google play page from the twitter app doesn’t trigger this issue:
 - sign in to twitter
 - from the menu, sign out, you’re taken to a "sign in" screen again
 - this "sign in" screen has a "New! Download the Twitter for Android app" banner
 - click this banner, the google play link opens in the browser

[Olivier Tilloy (osomon)]

Note that the fact that you see prompts and banners to install native android apps at all is tracked by bug #1352789.

[Alexandre Abreu (abreu-alexandre)]

It is the result of a few issues:

- a faulty (fixable) url that is not addressed by the webapp confinment patterns,
- when browsing to that url, the url gets dispatched,
- the url is 'twitter.com' based (hence the fault) but does not have a subdomain,
- the twitter webapp has a url dispatcher hook on twitter.com, so then gets triggered with the transient url,
- the url actually triggers a redirect on the twitter side which is directly commited at the blink level w/o reaching the app (and being filtered),
- we end up following the url outside twitter.com,

a solution based on urlchanged handlers is not enough since we still cannot make the distinction between a valid landing url and one that could trigger a redirect and decide where to land in case of a redirect,

[Alexandre Abreu (abreu-alexandre)]

I cannot reproduce this one anymore given that we landed the new overlay window handling.