Focus-android: Pop-up issue with no possibility to hit "back"

[bbinto]

via email convo with @antlam

I've seen this mostly on websites that are "shady", like Sports live streaming websites.

• Essentially, the user is loading a web page they want, then the "invasive ad" takes over and they're on a web page they didn't ask to load.
• Then they hit "back" in our UI but get caught in this loop that just reloads the ad (web page redirect). This is quite frustrating indeed, and I usually just tap the back button like crazy - which usually puts be back at web page where I got the live streaming link.
• Note: I'm unsure how much of this is a web-compat issue versus something we can do as the browser?

[pocmo]

It's quite hidden and therefore maybe not the best solution.. however in Fennec you can long-press the back button (like on desktop) and a list of all websites visited in this tab pops up. With that you can decide to go back to a specific page.

[antlam]

Yeah, I keep thinking I can trigger that does it in Focus too, but it doesn't...

But yeah, discoverability is the second part of this problem. But it's also obviously not common issue people run into so maybe discoverability is not that big of an issue.

[bbinto]

@brampitoyo do you have time looking into this issue for our 4.2 version? (next 2 weeks)

[brampitoyo]

I would really love it if we have a way to know know when these page-reload loops are happening, because fixing the core problem then becomes simpler.

For instance, our logic can look like this:

On touch Back button, go back one page
If page automatically redirects to another page <-- This signals that the page catches user in a loop
Then on touch Back button, go back two pages

We can also implement the solution that Fennec has: long-press the Back button to show the list of websites opened in the tab. But this relies on the user selecting the right page to go back to – and I have a hunch that it won’t have a high success rate at fixing the problem.

@pocmo I worry that my logic 1) takes a lot of resource to run, and 2) is way too general. What do you think?

[brampitoyo]

The alternative to implementing a go-back-two-pages feature is by doing what Fennec and other browsers do: on long-press, show a list of visited websites in the tab. In other words, let the users solve their own problem.

However, I’m concerned that we won’t have time to do this in time for 4.2.

[pocmo]

However, I’m concerned that we won’t have time to do this in time for 4.2.

I think this is fine. We moved this into the 4.2 sprint tentatively. Maybe we can start with the UX in this sprint and get to the implementation in the next one?

[brampitoyo]

@pocmo Sounds good. I know that @boek is having a look at this – whether a double-back button makes sense as a solution, or whether we’d like to have a tab history view like Fennec and other browsers.

[boek]

So I've been thinking about this and I think there might be a couple of challenges with implementing a double-back.

1. We're taking a best-guess at when we should double-back which isn't totally transparent to the user potentially leading to unexpected results.
2. This whole redirection loop is a dark pattern that isn't implemented consistently across the web. What happens if you're in a triple redirect loop? You're back to smashing the back button.

This leads me to lean towards a backstack list from a UX perspective.

An interesting thought that I had as well was what if we could pause the redirect while the user is in a backward navigation state. Maybe with a toast or something saying "We noticed the page trying to redirect. Would you like to continue?" This will allow them to keep navigating backwards while giving them the option to follow the redirect.

Thoughts? cc: @brampitoyo @pocmo

[brampitoyo]

A thought I had – which plays off your idea – is to trigger the Redirect Blocker when the user taps back and the page tries to send them somewhere else.

A toast will say “Focus has stopped this site from sending you to another page”. You’d get an option to follow the redirect, but our default is to block it by default to keep you safe.

[brampitoyo]

@boek and I had a 1:1 meeting about this. He has kindly offered to try out a solution that’s triggered by the back button, and that will stop redirect by default.

This leaves user free to decide: do they want to tap the back button once more (solving the problem) or remain on the same page (in case it is useful). Or go forward normally, or even follow the redirect to whatever link it takes them to.

We had both agreed that implementing a backstack list would also mean listing the user’s visit history – something that feels less appropriate for a privacy-centred app.

One thing we have to be careful about is to block only the dark pattern redirects, but keep redirects that are helpful – e.g. URL shortener, Google search results. @boek reckons that JavaScript-mediated redirects are behind a lot of the ‘evil’ ones, so we may start with that.

Our request to the rest of the team: could you send us URLs that contain dark pattern redirects, so we can test our upcoming solution against them?