1328538 - Hold back button doesn't correctly display history (mainly on Samsung devices?)

Status: RESOLVED INCOMPLETE

(Firefox for Android Graveyard :: General, defect)

Description

[Martijn]

User Agent: Mozilla/5.0 (Android 6.0.1; Mobile; rv:50.0) Gecko/50.0 Firefox/50.0
Build ID: 20161208181706
Firefox for Android

Steps to reproduce:

On Android, holding the device back button displays the history only very briefly, and then displays the menu. It should display the history only - the menu should not be triggered by the back button at all.


Actual results:

Hold back button -> history displays for less than half a second -> history is hidden gain and menu is displayed.


Expected results:

The history should remain displayed.

Comment 1

[Martijn]

This is happening on (at least) the Samsung Galaxy S7, with Android 6.0.1. Firefox installed from the Play Store.

Comment 2

[Jan Henning [:JanH]]

Googling around, it seems this is because various newer Samsung devices (which have the newer Recents button in place of the old Menu button) emulate pressing the Menu button when the Back button is long-pressed.

Comment 3

[Martijn]

Aha!

Perhaps there's a way for apps to tell the OS not to enable that legacy-feature? Clearly, Firefox doesn't need it, but it does need the back button longpress.

Comment 5

[jimimaseye]

This bug (reporter) clearly states that long pressing the back button *briefly shows the history list* before then being replaced by the menu:

"Hold back button -> history displays for less than half a second -> history is hidden gain and menu is displayed."

This is, in fact, what happened also on my device when it was at Android 6 (marshmallow).

I agree that on Android 6 I was getting the same.  It ,may be that Samsung have introduced a new response code to the back button on long pressing and that maybe under android 6 (marshmallow) it had a 2-stage response

ie, 
less than 0.5 seconds = action code 1 (the default and the one which FF was coded to display the history)
more than 0.5 Second = action code 2  (a new response which FF doesnt have a specific capture for and defaults to displaying Menu)

However, following an upgrade to Android 7.0 now that long pressing the back button simply goes straight to menu and no history is shown at all (not even momentarily).  Aaybe under Nougat 7.0 there is now no longer the first action.  This means that we now dont get the history list at all.

Maybe someone someone would be able to look in to the Google code/api's or use debug for it determine this change and possible code to account for it accordingly?

(This rapid selection history list was used by me all the time and it is a big loss to my daily use.  Coupled with Nougat also messing up my chosen email clients (K9-mail) ability to work effectively in the background (auto-sync keeps disabling) Im beginning to regret allow the upgrade to Nougat.)

Comment 6

[jimimaseye]

Additional information:

I have just discovered that the Adblock Plus Browser (created by Adblock Plus to get round Google removing their adblock plus app from Google Play) is a fork of Firefox (its effectively Firefox with their Adblock software incorporated).  The latest version of their browser is dated August 2017.

I have just tested it and apart from looking and behaving like firefox and all of its features (but with a blue fleck instead of firefox orange) it behaves exactly as the firefox browser did under Marshmallow: that is that a short 'long press' shows the history rapid selection list and a long 'long press' shows the menu.  I would think that it means that their current version is based on the previous version of firefox given we have identified that this behaviour is what happened in a previous version (current production of Firefox is v56 so Im guessing theirs is a fork of FF v55 - which would also coincide with the August datestamp of their browser version).  Although not perfect (preferring to just show the history list no matter how long the button is pressed just like older versions) it shows promise that their is a code change in Firefox to differentiate the behaviour.

So maybe this gives a clue that something was coded/changed in the latest version of Firefox and that the fix or cause is there to be found.

Comment 7

[Jan Henning [:JanH]]

Ah, interesting, so there was some change in Firefox as well.

If you could try running mozregression (http://mozilla.github.io/mozregression/) to pinpoint the exact change in Firefox that caused this new behaviour it would be very helpful.

Comment 8

[jimimaseye]

Erm....

The problem is that we are trying to compare Firefox for Android  (And/or Adblock Browser for Android) and that I really am not a technical user on the Android platform.  I presume I would also need a previous version of Firefox (that used to work) to compare it to the current version that doesnt and I dont have such a previous version.  (I realloy am a base user of the android phone and apps.)

Unless you can give me some seriously clear and basic instruction and where to easily get the resources necessary Im afraid it will be very difficult for me.  But maybe amongst us there are more technically minded people that could do the comparing?

Comment 9

[jimimaseye]

I have watched the HOW TO video for the mozregression and cannot see how I am able to use it to view/test Android mobile app versions - how am I to tell whether a version of the android app at any one nightly build is good or bad.  I also doubt that the bug tracker headers for individual fixes will give clear enough clues in their descriptions - I have no idea on what the terminology is when talking about this android phone back button or how your refer to the (what I call) rapid-selection history list.

As expected this is a little out of my depth.  But Im sure that someone with 'the knowledge' (one of the developer contributors) would be able to do this and find the cause.

Comment 10

[Jan Henning [:JanH]]

With a little guidance (the main point is that for using mozregression for Android, you also need to install ADB so mozregression can talk to your phone) it's not that difficult actually, but unfortunately the current version of mozregression is still affected by bug 1367197, so using it for Android from a Windows machine is unfortunately broken. So yes, someone else needs to look at this (I don't have an affected Samsung phone, otherwise I'd have looked at it myself).
But thanks for looking at it, anyway.

To answer your questions regardless:

(In reply to jimimaseye from comment #9)
> I have watched the HOW TO video for the mozregression and cannot see how I
> am able to use it to view/test Android mobile app versions - how am I to
> tell whether a version of the android app at any one nightly build is good
> or bad.
It's simple: Mozregression downloads and installs a version of Nightly on your phone and starts it. Then, you can test that Firefox version to see whether it is affected by whatever bug your looking for (i.e. in your case whether the long-press history menu appears at least momentarily or not at all) and then you tell mozregression whether that build you've tested was indeed bad or good. Based on your answer the next build is downloaded and installed and so forth until you've reached the end of the line.

> I also doubt that the bug tracker headers for individual fixes will
> give clear enough clues in their descriptions
Guessing which changeset seems likely to have introduced a bug isn't a strictly required skill. If you have enough experience to do that, it does indeed help because you can save some time by having to test less builds, but if you've got no idea which change might have caused the regression, you can just continue using mozregression to cut down the list some mroe. At the end, the range will usually have been narrowed down to one or more changesets all belonging to the same bug.

Also, once you gotten as far as you've could, you can simply post your results here and leave others to investigate that further.

Comment 11

[jimimaseye]

Update and further proof:

The browser mentioned above in comment 6 (Adblock Browser) that is based on firefox has now also just updated based on the latest firefox.  And now it too has the same problem.  It has inherited the 'problem'.  The source and resolve is there in the Firefox code somewhere.

Comment 12

[Michael Comella (:mcomella) [NI reported issues only: ex-Mozilla]]

[triage] Bulk edit from title: this is a non-critical issue. Please remove priority if you wish this to be re-triaged.

Comment 13

[Jan Henning [:JanH]]

Could we get this whole problem complex (this bug, bug 1408645, bug 1446638 - they might all be more or less the same issue anyway) reconsidered for Softvision's attention?

Comment 14

[Jan Henning [:JanH]]

Also note that Chrome finally added an equivalent feature as well (at least on the current release version it might still have to be manually enabled through #long-press-back-for-history from chrome://flags).
At least superficially, their back button handling [1] looks quite similar to ours [2], so it might help to check whether their implementation is actually working on those devices where we have problems, and if yes, to find out where exactly their implementation differs from ours.


[1] https://cs.chromium.org/chromium/src/chrome/android/java/src/org/chromium/chrome/browser/ChromeTabbedActivity.java?l=2044&rcl=dbc27bf8879eeb43bcb86de732c37b8849bb98a4
[2] https://dxr.mozilla.org/mozilla-central/rev/c2593a3058afdfeaac5c990e18794ee8257afe99/mobile/android/base/java/org/mozilla/gecko/BrowserApp.java#585

Comment 15

[:sdaswani]

Andreas is this something we should fix?

Comment 16

[Andreas Bovens [:abovens]]

Yes, I believe this should be fixed (esp. given our considerable install base on Samsung devices).

Comment 17

[Jan Henning [:JanH]]

As per bug 1446638 comment #9, there is at least one device where our back button implementation fails, but Chrome's works.

Comment 18

[Jan Henning [:JanH]]

@Marco: I'm guessing that most likely the result would be bug 1304688 itself, although that in turn apparently did actually fix a back button problem on some devices at that time.
As I already mentioned, one possible course of action would be to investigate where precisely our implementation differs from Chrome's, as the latter apparently works even on devices where we are having problems.

Comment 19

[Eliza Balazs]

Hi!

I tested this on Samsung Galaxy S6 (Android 7.0) and I found a regression for this issue.

The results are:

Last good revision: 2114ef80f6ae (2014-11-06)
First bad revision: b62ccf3228ba (2014-11-07)
Pushlog:
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=2114ef80f6ae&tochange=b62ccf3228ba

I hope my results are helpful to continue the investigation. Thanks!

Comment 20

[BMO Automation]

We have completed our launch of our new Firefox on Android. The development of the new versions use GitHub for issue tracking. If the bug report still reproduces in a current version of [Firefox on Android nightly](https://play.google.com/store/apps/details?id=org.mozilla.fenix) an issue can be reported at the [Fenix GitHub project](https://github.com/mozilla-mobile/fenix/). If you want to discuss your report please use [Mozilla's chat](https://wiki.mozilla.org/Matrix#Connect_to_Matrix) server https://chat.mozilla.org and join the [#fenix](https://chat.mozilla.org/#/room/#fenix:mozilla.org) channel.