Fenix: [Bug] Back navigation sometimes breaks

[lnicola]

Steps to reproduce

Use Fenix as your main browser for a while.

Actual behavior

Sometimes back navigation stops working -- the back gesture has no effect. I'm not sure, but I think that when it happens the back button doesn't even show up in the menu.

Killing and restarting Fenix makes it work again, even in the restored tabs.

Device information

• Android device: OnePlus 6T / Android 10
• Fenix version: Nightly

[opusforlife2]

I think this is a regression introduced in v3.2.1. In my case, though, tapping the address bar restores back button functionality without any issues.

Another thing of concern is that Fenix seems to 'consume' these back button taps, or hide them from the OS somehow, as rapid back button taps don't let you exit to the home screen, which is a safety feature of Android. I forgot what it's called.

[staktrace]

I see this quite frequently, where the back button just doesn't do anything even though I know there are pages in history. Most recently (and generally quite frequently) I see it on Hacker News - go from the home page to an article page, go to the linked article, go back to read comments, and then going back to the front page doesn't work

[kbrosnan]

I see this occasionally as well. This is rather annoying that basic functionality of a browser breaks.

[mikeGolf08]

I found some comments relating this behavior on other webpages and I am occasionally facing this bug as well.

Can somebody take a look at this please?

_Nightly 200506 06:01 (Build #21270610)
41.0.20200505190119, cb5fb4ca9
GV: 77.0a1-20200504093644
AS: 0.58.2_

[sflorean]

Tested on the latest Nightly build and couldn't reproduce the issue on the following devices: Samsung Galaxy Note 10 (Android 10), Nokia 6 (Android 7.1.1), Samsung Galaxy S9 (Android 8) Google Pixel 3 XL (Android 9), Huawei MediaPad M2 (Android 5.1.1).
Sites used for testing:

• https://news.ycombinator.com/, https://thehackernews.com/
  
  
  
  • Wikipedia, cnn.com, medium.
    
    @lnicola this is still reproducible for you?
  
  

[lnicola]

@sflorean I don't know. It was pretty hard to reproduce in the first place and I don't think I've seen it lately. Let's close it to keep things neat and reopen if it happens again.

[opusforlife2]

I encounter this issue frequently on 5.0 as well, so it is definitely not fixed. It is just not reproducible on command. The workaround I mentioned above still works and is still needed.

[lnicola]

@opusforlife2 just to make sure, can you try on Nightly?

[opusforlife2]

I'd have to set up Nightly all over again and use it as my main browser for who knows how long... I'm reluctant to do that, sorry. I'll make sure to report after testing 5.1, though.

[ekager]

Comment from @SS1113 in #10972

1. Go here: https://www.indiatoday.in/india/story/air-india-passenger-tests-coronavirus-positive-1682333-2020-05-27

2. Scroll to the bottom of the page, and to the top again. And stay there for a few seconds (3 to 4 seconds would be enough)

3. Press the back button, observe that it take more than a single press to go back and sometimes it just refuses to go back and sometimes it takes several clicks before it works.

I tried to reopen the existing issue for this but it didn't work.

Edit: If it doesn't work on the first try then try it again.

[lnicola]

I can't reproduce it with the STR above, but point taken, it still happens to people.

[ghost]

@lnicola @ekager I can reproduce it everytime on my device, if you tell me how to get the logs, perhaps that'll help.

Device: Motorola One Power, Android 10.
Fenix: Nightly 200527 06:01 and 5.1.0-beta.2

[ekager]

I can reproduce with the STR above on https://www.indiatoday.in/india/story/air-india-passenger-tests-coronavirus-positive-1682333-2020-05-27

[ekager]

But I can reproduce the same issue on Chrome :/ so this is likely just a sketchy website behavior and there is also likely nothing the Fenix team can do about it.

Edit: I thought I did once and now I can't again 🤔

[ekager]

@opusforlife2 @staktrace @lnicola have any of you noticed this on any other specific sites or generally lately (on Nightly or 5.1)?

If it's just that one weird site that's still reproducing, we could bump this down in priority.

[ghost]

@ekager I cannot reproduce the issue on Chrome 83.0.4103.96 but I can reproduce it everytime on Firefox 77.0.0-beta.1 and Nightly 200603 06:00.

there is also likely the nothing the Fenix team can do about it.

But do you really think that websites should be allowed to do this type of behaviour?

I have seen this behaviour randomly appear regularly. It reproduces on a particular website sometimes and sometimes it doesn't. You're likely never going to reproduce this if you are seeking a particular website since it appears randomly everywhere. This was even happening while I was browsing GitHub sometimes.

And I have seen this behaviour in recent builds as well.

[ekager]

No, all I meant was this specific website bug would likely need to be handed off to another team within Mozilla

[lnicola]

It still happens to me in 5.1.0 after opening GitHub links from Gmail and navigating around.

[ghost]

@ekager Thanks for the clarification!

[ekager]

Okay thanks @lnicola we will try to look into that.

I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1643554 about the indiatoday.in issue specifically, but I don't think it's related to other issues discussed here.

[lnicola]

I don't know if it matters, but I'm using custom tabs (in Gmail), uBlock Origin and Dark Reader. I wasn't using Dark Reader when I originally reported this.

[snorp]

This is an abuse (or misuse) of the history API. The page is putting several entries into the history stack in order to prevent the back button from immediately navigating away. It should be possible to mitigate this by inspecting the history list and skipping to the next entry that has a different URL.

In GeckoView, this list should be delivered to the app via HistoryDelegate.onHistoryStateChange(), but I'm not sure how (or if) it's exposed in a-c.

[snorp]

Also I can't reprorduce this with uBlock enabled, so presumably it's some kind of ad producing the bad behavior.

[staktrace]

There's certainly some instances where this is caused by the webpage abusing the history API. But there are also instances that are a bug in the browser. In those cases (which are intermittent) I usually have to click on the tab counter, re-select the tab, and then my back button works again. So I suspect some internal state is getting out of sync and re-selecting the tab fixes it.

[snorp]

Ah yeah I was specifically responding to the indiatoday.in case. We should probably break that out of this issue and keep this one for the intermittent wonkyness.

[ekager]

@lnicola thank you!

@kbrosnan do you have any hunches a trend of the intermittent issue since you've seen this?

Not sure if it's a ublock issue, custom tab issue, external link issue etc, but it does sound like we're eating the back press somehow sometimes.

[lnicola]

I'll check again next time, but I don't think it's losing the back press. The back button in the menu is gone, as if the history gets lost.

[opusforlife2]

This happens to me randomly on several websites I regularly visit, including Github. It is more frequent on "bad" websites like that Indian news website which load a huge bunch of 3rd party domains and probably do abuse the history API, but it also happens almost reliably when using Startpage's Anonymous Mode, so much so that it has become a habit for me to close those tabs by using the workaround, without even checking if they close normally.

Edit: This is the problem I was talking about in my first comment right under OP: https://www.xda-developers.com/android-7-1-has-a-panic-detection-mode-that-detects-frantic-back-button-presses/

This bug breaks this functionality.

[miDeb]

STR I found:
Long tap somewhere empty (so that nothing is selected). For some reason, canClearSelection then returns true and trying to clear that selection is what repeatedly consumes the back button press.

[ghost]

Wow! This really seems to work across the sites. I never thought I would get the STR since I'm observing and trying the get the STR from months now! I have tried with some websites including YouTube and I can confirm that this STR seems to work on almost every site. Thanks a lot for finding it! Do you think this is the root cause of the bug?

[ekager]

Omg great find! Thanks for the STR I'll take a look ASAP

[ekager]

I've traced back this bug (at least the STR we know) to using our custom DefaultSelectionActionDelegate instead of the BasicSelectionActionDelegate from GV (this adds the normal and private search buttons to the menu)

[opusforlife2]

Confirmed as well! What a rare find.

[ekager]

STR I found:
Long tap somewhere empty (so that nothing is selected). For some reason, canClearSelection then returns true and trying to clear that selection is what repeatedly consumes the back button press.

Let's QA these steps, and if any of you find more STR or are still seeing this, please open a new issue!

[ekager]

Going to keep https://github.com/mozilla-mobile/fenix/issues/8282 open for possibly site specific issues (like wikipedia, google images) and bugzilla.mozilla.org/show_bug.cgi?id=1643554 open about the history API abuse

[abodea]

I'm still able to reproduce this issue on the latest Nightly build 6/19 with Google Pixel 4 XL (10) following these steps:

1. Go here: https://www.indiatoday.in/india/story/air-india-passenger-tests-coronavirus-positive-1682333-2020-05-27

2. Scroll to the bottom of the page, and to the top again. And stay there for a few seconds (3 to 4 seconds would be enough)

3. Press the back button, observe that it take more than a single press to go back and sometimes it just refuses to go back and sometimes it takes several clicks before it works.

I tried to reopen the existing issue for this but it didn't work.

Edit: If it doesn't work on the first try then try it again.

and

Long tap somewhere empty (so that nothing is selected). For some reason, canClearSelection then returns true and trying to clear that selection is what repeatedly consumes the back button press.

I will remove the eng:qa:needed until further notice.

[ekager]

Hi @abodea ! Sorry I should have been more clear. To verify this ticket we just want to QA these steps on any website _except_ indiatoday.in (because that website has its own particular issue)

STR I found:
Long tap somewhere empty (so that nothing is selected). For some reason, canClearSelection then returns true and trying to clear that selection is what repeatedly consumes the back button press.

[AndiAJ]

Hi @ekager , I've just checked this matter on the latest Nightly Build 200624 from 6/24 using the following devices:
• Google Pixel 3a (Android 10)
• OnePlus A3 (Android 6.0.1)

Didn't manage to reproduce the problem using the suggested STR (Long tap somewhere empty (so that nothing is selected) + back button) on neither of these websites:
https://www.espn.com/
https://www.90min.com/
https://amp.sportsmole.co.uk/
https://m.sport.ro/
https://m.digisport.ro/
https://www.cbssports.com/
https://edition.cnn.com/
https://www.bbc.com/
https://www.theguardian.com/international
https://www.ft.com/
https://www.nytimes.com/
https://www.theverge.com/
https://www.cnet.com/
https://www.digitaltrends.com/
https://www.amazon.com
https://www.ebay.com/
https://www.bestbuy.com/
https://www.netflix.com/ro-en/
https://www.hulu.com/welcome
https://hbogo.ro/
https://m.youtube.com/
https://vimeo.com/
https://www.dailymotion.com/us
https://m.soundcloud.com/
https://audiomack.com/
https://music.youtube.com/
https://m.facebook.com/
https://www.instagram.com/
https://www.linkedin.com/
https://mobile.twitter.com/
https://www.youtube.com/

► Video

❗ However, I've noticed similar back button navigation issues with the one from www.indiatoday.in. on https://www.nike.com/ro/ and https://www.asics.com/gb/en-gb/

► Video

Please review and advise. ☺️
I'll remove the QA needed label.

[kbrosnan]

Looks like the work here is done. If people encounter new ways to trigger this open a new issue.