I was able to reproduce this issue on the latest Nightly build 68.0a1 with the following devices: Samsung Galaxy Note 9(A 8.1.0), Google Pixel 3XL(Android P), Google Pixel XL(Android Q), Samsung Galaxy Tab(Android 5.1.1).

Note that I used the following STR:

1. Go to imdb.com via URL bar.
2. Tap on a video.
3. Tap the device back button.

• The Back button is not working when accessing for the first time any video from imdb.com and tapping on the Back button.
  After accessing any other video, the Back button will work accordingly.

The back button not working seems fairly major.

Unassigning snorp to free up this Fennec bug for a Softvision engineer.

Able to recreate on Samsung Note 8. Looking deeper.

An addendum to the steps to recreate: I noticed that if you go to any domain, after clicking a link that stays within the domain then the back button does not work at the first attempt. After that it seems to work until you type in a new domain. If you google the same domain and click the google link to go to the same domain the browser does not seem to exhibit any issues with the back button. Appears to be related to the typing of a domain. The first link from the typed in page does not seem to go back at first attempt. Second attempt appears to work.

One additional item. The discussion above I am assuming is the back button provided by the phone. There is also a back button on the menu and when using that one there appears to be no issue and works as expected. So I am tracing the back button events from the Android OS to see where the point of failure is.

For and Android Activity you can override the onBackPressed() method to receive an event when the back button is pressed on the device. This appears to not be firing whenever the situation previously described appears to be ignoring the pressing of the back button. onBackPressed() is not firing upon the first taken link after you switch to a new domain.

I found several board messages indicating that the onBackPressed is not always reliable and there seems to be some truth to that. As a solution they recommend an older way of doing it by using the onKeyDown event and looking for the KEYCODE_BACK key.

This appears to solve the problem.

(In reply to Brad Arant from comment #17)

For and Android Activity you can override the onBackPressed() method to receive an event when the back button is pressed on the device. This appears to not be firing whenever the situation previously described appears to be ignoring the pressing of the back button. onBackPressed() is not firing upon the first taken link after you switch to a new domain.

I found several board messages indicating that the onBackPressed is not always reliable and there seems to be some truth to that. As a solution they recommend an older way of doing it by using the onKeyDown event and looking for the KEYCODE_BACK key.

Brad, should we change our Fennec code to use onKeyDown/KEYCODE_BACK instead of onBackPressed? If the back button problem is still reproducible, I don't think we should resolve this bug as "fixed". If we want to accept the current back button behavior and not make any code changes, then we can resolve this bug as "invalid".

Hi, I've just re-tested 3 times this issue following the steps from comment 11 on the latest Nightly build 68.0a1 using a Samsung Galaxy Note 9 (A 8.1.0) & a Google Pixel 3XL(Android P).
The back button works as expected on the Samsung Galaxy Note 9 (A 8.1.0) - logcat
On the other hand, the back button worked only after the second tap on the Google Pixel 3XL(Android P) - logcat

I have modified the onBackPressed() by renaming it to onBackPressedInternal() and I have inserted:

if (keyCode == KeyEvent.KEYCODE_BACK) {
onBackPressedInternal();
}

into the onKeyDown method.

This will cause the onBackPressedInternal to be called reliably.

Preparing patch for submission.

(In reply to Brad Arant from comment #20)

I have modified the onBackPressed() by renaming it to onBackPressedInternal() and I have inserted:

if (keyCode == KeyEvent.KEYCODE_BACK) {
onBackPressedInternal();
}

into the onKeyDown method.

I'm not familiar with this code, but we should be careful to check if there are special cases where the app or web page needs to handle KEYCODE_BACK is a different way. For example, Bug 1304688's KEYCODE_BACK workaround for Android N:

https://searchfox.org/mozilla-central/rev/e7d9a8749303b39dadcc0e18ea0d60a570a68145/mobile/android/base/java/org/mozilla/gecko/BrowserApp.java#586-596

We should also check if Fennec and GeckoView need separate code fixes.

Preparing patch for submission.

I think :m_kato will be the best reviewer for patches related for Android key events.

Reproducible on an Android P emulator, which means it should be possible to debug this including the framework behaviour, too (Provided you can get Android Studio to pick the correct API level when debugging framework code, grrr!). Ignore anything about domains in comment #15, though - the distinction is merely whether you navigate by typing in the URL bar and hitting Enter, or by clicking a link inside the GeckoView.
Also this issue isn't actually related to the original one from comment #0

Strangely enough, back button long press handling seems to be working normally, and apparently doesn't influences what happens with regards to a short press. I.e. I put the input focus on the URL bar, hit enter, click a link, long press Android's back button (the session history popup appears successfully), short press the back button (nothing happens, i.e. this bug), press it again (this time we go back).

The problem from bug 1278581 was that hiding the URL bar in response to a
key-down event (for the Enter key) would then lead to the corresponding key-up
event then ending up in GeckoView, thereby confusing the "last user activity"
tracking.
It appears that this is only happens with key events received through the
regular OnKeyListener, but not with events coming from the OnKeyPreImeListener.

On devices where pressing Enter in the URL bar would transmit the key event
through the latter mechanism, this means that because the key-up event we wanted
to suppress in BrowserApp never arrived, we would instead suppress whatever
other key event would arrive next, e.g. possibly a press of the back button.
This would lead to the observed behaviour where after entering an URL, the first
subsequent press of the back button might then be ignored.

https://hg.mozilla.org/mozilla-central/rev/c7feffe40029

Hi, I've retested, and everything seems to be working fine using the latest Nightly version on both Samsung Galaxy Note9 (Android 8.1.0) as well as on Mi PAD 3 Tablet (Android 7.0).

On the other hand, it failed again when testing it on Google Pixel 3 XL(Android 9), because of which I will reopen it.

Better as a separate bug, I think.

Based on comment 27 I will mark the bug as verified. Thanks!