Escaping from Twitter in the Twitter WebApp

Bug #1360462 reported by Nicolas Delvaux on 2014-08-22
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
webbrowser-app
Invalid
High
Unassigned
webbrowser-app (Ubuntu)
High
Alexandre Abreu

Bug Description

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)

description: updated
description: updated
Olivier Tilloy (osomon) wrote :

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

Changed in unity-webapps-qml:
status: New → Confirmed
importance: Undecided → High
Olivier Tilloy (osomon) wrote :

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

Changed in unity-webapps-qml:
assignee: nobody → Alexandre Abreu (abreu-alexandre)
Changed in webbrowser-app:
status: New → Confirmed
importance: Undecided → High
assignee: nobody → Alexandre Abreu (abreu-alexandre)
no longer affects: unity-webapps-qml

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,

Olivier Tilloy (osomon) on 2015-06-08
Changed in webbrowser-app (Ubuntu):
assignee: nobody → Alexandre Abreu (abreu-alexandre)
importance: Undecided → High
status: New → Confirmed
Changed in webbrowser-app:
status: Confirmed → Invalid
assignee: Alexandre Abreu (abreu-alexandre) → nobody

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

Changed in webbrowser-app (Ubuntu):
status: Confirmed → Incomplete
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers