Closed Bug 1932300 Opened 1 year ago Closed 10 months ago

History panel no longer shows when long-pressing system back button.

Categories

(Firefox for Android :: History, defect)

Product:
Firefox for Android
Component:
History
Version:
Firefox 134
Platform:
All
Android
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
136 Branch
Tracking Flags:
Tracking Status
firefox134 --- wontfix
firefox135 --- wontfix
firefox136 --- verified

People

(Reporter: pizzapants111, Assigned: bob+bmo)

References

(Blocks 1 open bug, Regression)

Details

(Keywords: regression, Whiteboard: [fxdroid][group4])

Attachments

(3 files, 2 obsolete files)

Screen_Recording_20241120_015002_Firefox.mp4
8.99 MB, video/mp4
Details
Bug 1932300 - Handle long back presses with predictive gestures enabled r?#android-reviewers
48 bytes, text/x-phabricator-request
Details | Review
HistoryTabFixed.mp4
802.08 KB, video/mp4
Details

User Agent: Mozilla/5.0 (Android 14; Mobile; rv:134.0) Gecko/134.0 Firefox/134.0

Steps to reproduce:

  1. Visit a site
  2. Click a link
  3. Long-press the Android back button.

Actual results:

No history panel shows up.

Expected results:

The history panel shows up with the current tab's history (and "future" if we have already gone back some), as it does on version 132 stable.

The Bugbug bot thinks this bug should belong to the 'Fenix::History' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: General → History

I was able to reproduce this as well (Samsung A35, Android 14). Note that long pressing on the backward arrow on the nav bar redesign still shows the history panel, but not when long pressing the system back button

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Whiteboard: [fxdroid][group4]

(In reply to Nicholas Poon [:Nick] from comment #2)

I was able to reproduce this as well (Samsung A35, Android 14). Note that long pressing on the backward arrow on the nav bar redesign still shows the history panel, but not when long pressing the system back button

On my phone on nightly, long pressing on the backward arrow on the nav bar redesign shows an empty panel. I'm not sure if this is related. Should I report this as a separate bug?

This bug has been marked as a regression. Setting status flag for Nightly to affected.

status-firefox134: --- → affected

(In reply to pizzapants111 from comment #3)

(In reply to Nicholas Poon [:Nick] from comment #2)

I was able to reproduce this as well (Samsung A35, Android 14). Note that long pressing on the backward arrow on the nav bar redesign still shows the history panel, but not when long pressing the system back button

On my phone on nightly, long pressing on the backward arrow on the nav bar redesign shows an empty panel. I'm not sure if this is related. Should I report this as a separate bug?

Yes, it would be great if you could report that bug under Fenix :: Toolbar and put this one in the "See Also". Thanks in advance for doing this :)

134 has become Beta, so this now affects Beta, though the workaround still works there (134.0b1 (Build #2016058295)).

The new toolbar redesign on 135 nightly (135.0a1 (Build #2016058399)) does not have back or forward buttons, so there is no workaround anymore and the tab-history panel is completely inaccessible, and there is also no way to go forward (unless there's a way to disable the toolbar redesign that I haven't found).

Disabling the "Menu Redesign" in the "Secret Settings" brings the forward and back buttons back.

That definitely sounds like a bug to me. There should be back and forward buttons on the toolbar redesign - I am unable to reproduce the issue though. I think you should file a bug under Fenix :: Toolbar and provide more information in the report (like a screenshot / video and your device information) so that the appropriate engineer can look into the issue. Thanks

While researching this, I came across this post as well:

https://support.mozilla.org/en-US/questions/1475331

Summary: History panel no longer shows when long-pressing back button. → History panel no longer shows when long-pressing system back button.
Duplicate of this bug: 1939675

Many users are creating Reddit threads about this issue this week, i.e. https://old.reddit.com/r/firefox/comments/1hzb76x/can_no_longer_go_forward_and_back_like_i_used_to/

@Bob: have you actually tried using version 135, i.e. the current Firefox Beta for Android? Because it very much works for me with that version, i.e. on my Pixel 8, both holding the "hardware" back button or holding the new back (or forward) button in the tab/menu bar below the address bar brings up the history card.

Current Beta 135.0b3 fails. Current Nightly (which is what I had/tested before going into regression tests) also fails.

It's quite possible that this has something to do with the device in use too. My repro was on a S22 Ultra SM-S908E running Android 14 (obviously, given the regression window found, it wasn't an OS update that triggered this).

Done some more specific testing and it looks like it's changeset f552948df76e516ce852ef2ac9eb719ddda40693 / bug 1898059 that causes this.

I've asked around a bit and have confirmation from a couple other Samsung users that it's broken from them, and confirmation from one other Pixel user that it works for them.

There's also this other Reddit thread with the OP reporting a Nokia X30, so it's not just Samsung.

(In reply to Bob from comment #17)

I've asked around a bit and have confirmation from a couple other Samsung users that it's broken from them, and confirmation from one other Pixel user that it works for them.

There's also this other Reddit thread with the OP reporting a Nokia X30, so it's not just Samsung.

My Cubot phone has the issue on Android 14 but my Oukitel phone on Android 10 has the history fine so if the Pixel was on an older android version it could be that

If bug 1898059 is the cause, that change is only applied on Android 13+. So far I've seen/heard Pixels specifically on Android 14 unaffected while any other brand (so far, Samsung, Nokia, Sony, now your Cubot) on 13+ is affected. All phones pre-13 are should not be affected.

Tagging @mavduevskiy as the assignee of bug 1898059. I don't have permission to edit the regression fields.

Flags: needinfo?(mavduevskiy)

If this helps: I currently have a Pixel 6, with Android 14 and Firefox 134. The long-press-back option does not work for me.

I don't have Firefox version 135b to test with on my phone, and also the phone is insistently trying to update to Android 15, so I don't know how much longer I'll have this exact configuration of versions.

Thanks for identifying the regression window, Bob! Setting regression fields based on the comments above. Mike, can you take a look please?

Keywords: regressionwindow-wanted
Regressed by: 1898059

Set release status flags based on info from the regressing bug 1898059

status-firefox136: --- → affected

Is there anything further I can do to help this along? I find myself running into this many times a day, and it's getting quite frustrating.

Can a case be made for backing out the change that causes this, until this is resolved?

Some further testing/info (via dumb log statements because I don't really have a Kotlin/Android debug environment set up):

Neither onKeyLongPress nor onKeyDown in HomeActivity.kt are ever called if the new callback is enabled in the manifest (android:enableOnBackInvokedCallback="true"). This occurs even if the new SearchDialogFragment.kt handler is not attached.

This tracks with https://developer.android.com/guide/navigation/custom-back/predictive-back-gesture#migrate-app

So it looks like with predictive gestures enabled, it is no longer possible to intercept the old key events and therefore not possible to implement a 'hold' press in that way.

What does seem possible is overriding the handleOnBackStarted/handleOnBackCancelled handlers in OnBackPressedCallback. When the navbar is in button mode, this correctly corresponds with a hold+release. The problem is, in gesture mode, this also corresponds with a drag-in+drag-out.

It looks like handleOnBackStarted passes a BackEventCompat that in Android 14 can be converted to a BackEvent that then in Android 16(!!!) can differentiate between gesture vs button.

So presumably in Android 16 it becomes possible to do the following as an alternative to the current keypress-based hold detection:

  1. Override handleOnBackStarted and handleOnBackCancelled
  2. When handleOnBackStarted is called with a button-based back, cache that somewhere
  3. When handleOnBackCancelled is called, if this back was started from a button, trigger the long-back handlers

This does leave Android 13 through 15 in a bit of a painful situation though. On pre-Android 14, by my testing, the BackEventCompat object sends a swipeEdge of 0 (corresponding to EDGE_LEFT, not 2/EDGE_NONE of Android 16). Perhaps it'd be possible to check touchX/touchY instead, which are always 0.0 from the button press and almost never 0 when using gestures (unless you somehow manage to get the top leftmost pixel exactly, very unlikely). So perhaps this approach instead:

  1. Override handleOnBackStarted and handleOnBackCancelled
  2. When handleOnBackStarted is called:
    a. If Android 16+, if event.toBackEvent().getSwipeEdge() == BackEvent.EDGE_NONE then it's from a button hold
    b. Otherwise, use if touchY == touchX == 0.0 (these are possibly NaN in Android 16!! unless that's only if you convert the event? can't test...)
  3. When handleOnBackCancelled is called, if this back was started from a button, trigger the long-back handlers

I'm not sure if it's even possible to build in the Android 16 path right now since that's still a preview version of the SDK.

I've just tried a build with those changes and it seems to work correctly, except that it triggers the history panel on release rather than after a delay as it used to do. So instead it's probably best to handle this the same way [the old 'custom' handler](https://searchfox.org/mozilla-central/source/mobile/android/fenix/app/src/main/java/org/mozilla/fenix/HomeActivity.kt#919) did, by launching a delayed task on the started handler that then gets cancelled in the cancelled or pressed handlers. 1. In handleOnBackStarted, check if it's a button not gesture, and launch a task (job? coroutine?) that triggers a long press after a delay 2. In handleOnBackPressed and handleOnBackCancelled, cancel the task because the button was a short press or otherwise released early I'm not sure what the modern way of submitting a patch is, nor how to handle changes in android-components vs fenix. And there's probably better ways to make this change, I ended up making `UserInteractionOnBackPressedCallback` open and overriding it in `HomeActivity` because I couldn't figure out how to launch a background task (coroutine?) without errors inside the callback class. But still, here's a first attempt that works quite well in my tests.
Attachment #9460106 - Attachment filename: pasted.txt → 1932300.patch
Attachment #9460106 - Attachment is patch: true

Unrelated but I also noticed while looking at this:

In UserInteractionOnBackPressedCallback, handleOnBackPressed iterates through all fragments(?) and calls onBackPressed() on all of them. Should this instead break out of the loop on first true return? Currently it sets onBackPressedHandled but continues to fire the event on the rest of the collection. UserInteractionHandler doc-comment says "Returns true if this [UserInteractionHandler] consumed the event and no other components need to be notified."

Fixed a couple inverted conditionals in the legacy keycode handlers

Attachment #9460106 - Attachment is obsolete: true

When predictive back gestures are enabled
via android:enableOnBackInvokedCallback="true"
the legacy KEYCODE_BACK events are no longer fired.
This breaks the existing long back press detection,
which prevents the history panel from showing on a long back press.

Implementing an alternative long back press via a combination of
the AndroidX OnBackPressedCallback and the previous custom delay-based
long press detection restores this functionality.

Assignee: nobody → bob+bmo
Status: NEW → ASSIGNED
Attachment #9460135 - Attachment is obsolete: true

Thank you, Bob, that's some awesome research done on your part. That's definitely a regression, there was no intention to remove the feature.

The handling of back gesture in Android is becoming too messy. It looks like there is no native support of the long press gesture in the new OnBackInvokedCallback api handling back gesture?

I tried reversing the patch 1898059, but it would break navigation in the app when using the address bar. Although the change to enableOnBackInvokedCallback sits in 1898059, the actually footwork of refactoring (removing deprecated onBackPressed) was done in 1921125. Rolling those changes back works fine for versions below API35, but breaks on Android 15.

The refactoring was initiated to properly support a core case of using the toolbar: open a page, click the toolbar, enter text, press back – user should be back at the page. If we were to rollback, we should make sure that this core case isn't broken on any versions, before cutting that code out.

I will take a closer look next week, it's a bit surprising that the android team would drop the support for tracking that gesture completely. But I can't say I am very exited to come up with hacks to mimic discontinued OS behavior, it's usually quite costly.

Flags: needinfo?(mavduevskiy)

(In reply to Mike a [:mavduevskiy] from comment #29)

Thank you for the response. I didn't fully understand the context behind that change.

Rolling those changes back works fine for versions below API35, but breaks on Android 15.

Ah, that's really unfortunate. I did test a rollback to see if that'd fix it but I only have the one Android 14 device to test on. So presumably there's no easy way out of this :(

The handling of back gesture in Android is becoming too messy. It looks like there is no native support of the long press gesture in the new OnBackInvokedCallback api handling back gesture?

[...]

I will take a closer look next week, it's a bit surprising that the android team would drop the support for tracking that gesture completely. But I can't say I am very exited to come up with hacks to mimic discontinued OS behavior, it's usually quite costly.

It actually gets slightly worse, near as I can tell the API33 OnBackInvokedCallback can't be used directly to detect start/end in this way. The derived class OnBackAnimationCallback can, but it's only supported from API34 so leaves anyone on Android 13 in a bit of a hole. The AndroidX class OnBackPressedCallback seems the only option that fully covers Android 13+ (and is already used for the back short press). It does still appear to be a fully supported/non-deprecated method, thankfully. Now that I look again, docs say handleOnBackStarted is only called on API34+ so Android 13 just has no way out.

I do understand this is a pretty hacky approach to handle something that used to be natively supported. In my defence, the delayed-job-on-down approach already existed as a compat handler to cover bugs in Android N and Huawei, I only hooked it up to the new callback :)

They are amending the events in Android 16 to explicitly differentiate between back start and cancel from button as opposed to gesture, so it does look like this is becoming an intended API for this kind of interaction? Obviously the notion of "cancelling" an action applies very differently between buttons vs gestures.

Of course the other option would be to drop this feature entirely. Though as a frequent user of it, I do hope that isn't the decision made here. Speaking of, Chrome did drop it two years ago, suspicious timing.

(I hadn't intended to become assignee when I tried to submit that sample patch, please do take it off me if it's not suitable!)

Duplicate of this bug: 1942454
Duplicate of this bug: 1943097

@mavduevskiy Sorry to be a bother, but have you had a chance to look at this yet?

I've updated the patch to only use the new callback in Android 14+ since it's not supposed to be available on Android 13. At least this won't break the legacy functionality for those on Pixel w/ Android 13 (still not sure what special sauce makes that one work, are Pixels still sending the legacy events for some reason?). Unfortunately, since the new gesture-based handling is not available on older versions, I don't think it's possible to completely rip out the old handlers since they're still required for Android <=12?

Another thing I noticed in addition to the potential issue from comment 26 (new UserInteractionOnBackPressedCallback.handleOnBackPressed fails to exit loop when back is handled/true), the change from bug 1898059 adds an additional OnBackInvokedCallback to SearchDialogFragment. Would this not be redundant with the OnBackPressedCallback immediately above it? In Android 13+, OnBackPressedCallback is implemented in terms ofOnBackInvokedCallback`.

Flags: needinfo?(mavduevskiy)

we also received the report of the issue on play store. See conversation: https://app.conversocial.com/queues/inbox/6788291253b00787ac935723
browser version. Firefox 134.0.X (android 14)

also reported here: https://app.conversocial.com/queues/inbox/67866c9b999943d7017f5a5b
Always firefox 134 and android 14

Petru, is this something that you can help review? From my quick readings, the new on back handling doesn't try to override the onLongPress handling, so we might be able to still get that are feed it into the same back handling.

Flags: needinfo?(petru)

Looked through the patch, seems nice, maybe we can simplify some things, left some suggestions.
Tested it on Android 13/14/15 devices and saw that indeed this allows getting the tab history back on Android 14+ while for Android 13 seems like we are limited by the framework support for back handling and we will not be able to support this feature.

Flags: needinfo?(petru)

(In reply to Bob from comment #26)

Unrelated but I also noticed while looking at this:

In UserInteractionOnBackPressedCallback, handleOnBackPressed iterates through all fragments(?) and calls onBackPressed() on all of them. Should this instead break out of the loop on first true return? Currently it sets onBackPressedHandled but continues to fire the event on the rest of the collection. UserInteractionHandler doc-comment says "Returns true if this [UserInteractionHandler] consumed the event and no other components need to be notified."

This is a nice optimization!
Would you want to add a separate patch for this in the current PR or for another ticket?

(In reply to Bob from comment #33)

Another thing I noticed in addition to the potential issue from comment 26 (new UserInteractionOnBackPressedCallback.handleOnBackPressed fails to exit loop when back is handled/true), the change from bug 1898059 adds an additional OnBackInvokedCallback to SearchDialogFragment. Would this not be redundant with the OnBackPressedCallback immediately above it? In Android 13+, OnBackPressedCallback is implemented in terms ofOnBackInvokedCallback`.

Think we actually need that on Android 13 and 14, Mike left a few more details about it in bug 1898059 comment 10.
The gist of it is that we want a back button press or a back gesture to close an in progress search and return the user to the browser screen and seems like that separate OnBackInvokedCallback from SearchDialogFragment is needed to get this.

Seems like the framework updates related to back handling caused issues for other applications also - https://issues.chromium.org/issues/40888322.

See Also: → https://issues.chromium.org/issues/40888322
Blocks: 1944282

Thank you for the review.

(In reply to Petru-Mugurel Lingurar [:petru] from comment #39)

(In reply to Bob from comment #33)
Think we actually need that on Android 13 and 14, Mike left a few more details about it in bug 1898059 comment 10.
The gist of it is that we want a back button press or a back gesture to close an in progress search and return the user to the browser screen and seems like that separate OnBackInvokedCallback from SearchDialogFragment is needed to get this.

Ah oops, I did not see that PRIORITY_OVERLAY was what made the difference. That all makes a lot more sense now.

(In reply to Petru-Mugurel Lingurar [:petru] from comment #38)

(In reply to Bob from comment #26)

Unrelated but I also noticed while looking at this:

In UserInteractionOnBackPressedCallback, handleOnBackPressed iterates through all fragments(?) and calls onBackPressed() on all of them. Should this instead break out of the loop on first true return? Currently it sets onBackPressedHandled but continues to fire the event on the rest of the collection. UserInteractionHandler doc-comment says "Returns true if this [UserInteractionHandler] consumed the event and no other components need to be notified."

This is a nice optimization!
Would you want to add a separate patch for this in the current PR or for another ticket?

It's a trivial change to make and I believe it better matches the doc-comment and past (theoretical?) behaviour, but I actually have no idea how to go about testing this one - in my tests, there was only ever one fragment so it never loops anyway. Perhaps this is best split into a separate bug if it's even worth changing.

Flags: needinfo?(mavduevskiy)

(In reply to Bob from comment #41)

(In reply to Petru-Mugurel Lingurar [:petru] from comment #38)

(In reply to Bob from comment #26)

Unrelated but I also noticed while looking at this:

In UserInteractionOnBackPressedCallback, handleOnBackPressed iterates through all fragments(?) and calls onBackPressed() on all of them. Should this instead break out of the loop on first true return? Currently it sets onBackPressedHandled but continues to fire the event on the rest of the collection. UserInteractionHandler doc-comment says "Returns true if this [UserInteractionHandler] consumed the event and no other components need to be notified."

This is a nice optimization!
Would you want to add a separate patch for this in the current PR or for another ticket?

It's a trivial change to make and I believe it better matches the doc-comment and past (theoretical?) behaviour, but I actually have no idea how to go about testing this one - in my tests, there was only ever one fragment so it never loops anyway. Perhaps this is best split into a separate bug if it's even worth changing.

Sounds good!
If we'd get a new ticket and a separate patch for this we'd be able to focus testing on the back button behavior across the application and look into landing the change at the beginning of a new Nightly cycle to allow more time for testing and catching any regressions.
While for the changes here the scenario is different and so will be the testing needed.

See Also: → 1944370
Pushed by plingurar@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1ee211c91fae Handle long back presses with predictive gestures enabled r=android-reviewers,petru

https://hg.mozilla.org/mozilla-central/rev/1ee211c91fae

Status: ASSIGNED → RESOLVED
Closed: 10 months ago
status-firefox136: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → 136 Branch
Flags: qe-verify+

The patch landed in nightly and beta is affected.
:bob+bmo, is this bug important enough to require an uplift?

  • If yes, please nominate the patch for beta approval.
  • If no, please set status-firefox135 to wontfix.

For more information, please visit BugBot documentation.

Flags: needinfo?(bob+bmo)

We're already close to a new beta, no need for an uplift.

status-firefox135: fix-optional → wontfix
Flags: needinfo?(bob+bmo)

As an aside, I think it actually might be possible to fix/avoid this on Android 13 by selectively enabling the enableOnBackInvokedCallback flag only on API34 (in a similar way to how Fenix already has API28/underAPI28 bools defined).

Unfortunately, I don't have an Android 13 device anywhere to test. And turning this off will likely reintroduce bug 1898059 on Android 13 (it's a bit unclear to me from the comments/review whether that bug only affected 14+ or also 13). Which then becomes the question of which fix is more important to keep?

Quick'n'dirty untested patch, to show what this might look like:

diff --git a/mobile/android/fenix/app/src/main/AndroidManifest.xml b/mobile/android/fenix/app/src/main/AndroidManifest.xml
index 008d8d980fb96..577c0c691e0a0 100644
--- a/mobile/android/fenix/app/src/main/AndroidManifest.xml
+++ b/mobile/android/fenix/app/src/main/AndroidManifest.xml
@@ -59,7 +59,7 @@
         android:supportsRtl="true"
         android:theme="@style/NormalTheme"
         android:usesCleartextTraffic="true"
-        android:enableOnBackInvokedCallback="true"
+        android:enableOnBackInvokedCallback="@bool/API34"
         tools:ignore="UnusedAttribute">

         <profileable
diff --git a/mobile/android/fenix/app/src/main/res/values-v34/bools.xml b/mobile/android/fenix/app/src/main/res/values-v34/bools.xml
new file mode 100644
index 0000000000000..3401171038312
--- /dev/null
+++ b/mobile/android/fenix/app/src/main/res/values-v34/bools.xml
@@ -0,0 +1,9 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!-- This Source Code Form is subject to the terms of the Mozilla Public
+   - License, v. 2.0. If a copy of the MPL was not distributed with this
+   - file, You can obtain one at http://mozilla.org/MPL/2.0/. -->
+<resources>
+    <bool name="API34">true</bool>
+    <bool name="underAPI34">false</bool>
+</resources>
+
diff --git a/mobile/android/fenix/app/src/main/res/values/bools.xml b/mobile/android/fenix/app/src/main/res/values/bools.xml
index 91d4bf57286c5..ea301a141d01c 100644
--- a/mobile/android/fenix/app/src/main/res/values/bools.xml
+++ b/mobile/android/fenix/app/src/main/res/values/bools.xml
@@ -6,4 +6,6 @@
     <bool name="theme_is_light">true</bool>
     <bool name="API28">false</bool>
     <bool name="underAPI28">true</bool>
+    <bool name="API34">false</bool>
+    <bool name="underAPI34">true</bool>
 </resources>
Attached video HistoryTabFixed.mp4 —

This issue was verified as fixed on Firefox Nightly 136 (2025-01-29) under Samsung Galaxy S24 Ultra (Android 14) and Google Pixel 8 (Android 14). The tab history successfully opens when long pressing on the system back button.

But it seems that other devices are still affected with both Android 13 (Samsung Galaxy A32) and Android 14 (Poco X6 Pro) for which I filled Bug 1944817.

Status: RESOLVED → VERIFIED
status-firefox136: fixed → verified
Flags: qe-verify+

(In reply to Bob from comment #47)

As an aside, I think it actually might be possible to fix/avoid this on Android 13 by selectively enabling the enableOnBackInvokedCallback flag only on API34 (in a similar way to how Fenix already has API28/underAPI28 bools defined).

Enabling that flag only on API34+ sounds like a great approach indeed!
And we now have bug 1944817 to which such a patch can be linked.
I assume you want to work on this? Let me know if not and we can find another owner.

(In reply to Bob from comment #47)

Unfortunately, I don't have an Android 13 device anywhere to test. And turning this off will likely reintroduce bug 1898059 on Android 13 (it's a bit unclear to me from the comments/review whether that bug only affected 14+ or also 13)

Testing on an emulator myself I don't see the issue from bug 1898059 if enableOnBackInvokedCallback is disabled.
Can request QA's help for a prevalidation of the patch on physical Android 13 devices before landing to be extra safe.

(In reply to Vasilica Tamas QA [:vtamas] from comment #48)

But it seems that other devices are still affected with both Android 13 (Samsung Galaxy A32) and Android 14 (Poco X6 Pro) for which I filled Bug 1944817.

Would it be possible to also test release 134 or one of the nightlies before this patch to see if Poco on Android 14 worked before? Given Pixel still fires the old key handlers I wonder if Poco is doing the same thing.

Flags: needinfo?(vtamas)

(In reply to Petru-Mugurel Lingurar [:petru] from comment #49)

And we now have bug 1944817 to which such a patch can be linked.
I assume you want to work on this? Let me know if not and we can find another owner.
[...]
Testing on an emulator myself I don't see the issue from bug 1898059 if enableOnBackInvokedCallback is disabled.
Can request QA's help for a prevalidation of the patch on physical Android 13 devices before landing to be extra safe.

Sure, I'm happy to work on it but will definitely need help with testing. Will move further Android 13 discussion over to that bug.

(In reply to Bob from comment #50)

Would it be possible to also test release 134 or one of the nightlies before this patch to see if Poco on Android 14 worked before? Given Pixel still fires the old key handlers I wonder if Poco is doing the same thing.

I tested the Firefox 134.0.2 build on the Poco device, and it’s also affected.
Additionally, I ran a regression on the Nightly and here are the results:

  • Last good build: 134.0a1 (Build #2016056106), hg-7d29edd4cb62+, GV: 134.0a1-20241114095720, AS: 134.20241109050310, 2024-11-14T13:53:07.413545876
  • First bad build: 134.0a1 (Build #2016056194), hg-0191fbfc9115+, GV: 134.0a1-20241114211619, AS: 134.20241114050344, 2024-11-15T00:02:14.728580427

(In reply to Bob from comment #51)

Sure, I'm happy to work on it but will definitely need help with testing. Will move further Android 13 discussion over to that bug.

The QA team would be happy to assist with this testing, as we have several physical devices with Android 13.

Flags: needinfo?(vtamas)

Thank you, at the very least we haven't introduced a new regression for Poco here.

Duplicate of this bug: 1953773
See Also: → 1954845
No longer duplicate of this bug: 1953773
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: