1946858 - Tab selected icon is missing on current tab when the app is backgrounded and then reopened

Status: NEW

(Fenix :: Tabs, defect, P2)

Description

[Nicholas Poon [:Nick]]

Attachment: Tab selected icon missing.mp4

Steps to reproduce

Note: only reproducible intermittently but usually opening the app after some period of inactivity will allow this to be reproducible

1. Have at least 2 tabs open
2. Long tap on the selected tab

Expected behavior

The tabs tray banner changes to "X selected" where X is the number of selected tabs and the selected tabs have checkmarks overlaying the tab preview.

Actual behavior

The tabs tray banner changes to "X selected" where X is the number of selected tabs and the current tab, which is also selected does not have a checkmark overlaying the tab preview.

Device information

• Firefox version: 137
• Android device model: Smasung A35
• Android OS version: Android 14

Any additional information?

I think this may be related to the gesture rewrite in Bug 1904906 so setting that in the regressed by field but feel free to change it if this is wrong

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

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

:007, since you are the author of the regressor, bug 1904906, could you take a look?

For more information, please visit BugBot documentation.

Comment 2

[Noah Bond [:007]]

I'm not sure if this is a regression, but we should fix it either way. Adding it to our backlog

Comment 3

[Lorand Janos]

Hi,
I managed to reproduce it at first, on a Samsung Galaxy S23 Ultra (Android 14) - as the device closest to the one this was reproduced on - when I accessed a build that wasn't opened for a few days. One of the tabs selected didn't have the check mark.
Then I tried to simulate passing time by closing the app, setting the time ahead with 1 day, 3 days, 1 week, 10 days, 2 weeks, and I couldn't reproduce the issue anymore, even trying these steps multiple times, and after 2 weeks, the tabs are moved to inactive tabs sections so the configuration is different.
I then tried on the other 2 types of builds (Beta and RC after all the above was tried on Nightly) without any luck. Then I searched for other devices to reproduce on that are similar in a way or another and took all the above steps described above, also without reproducing the issue.
Could you think of any other detail that might cause this behavior on your end? Something I can use to try reproducing? Or maybe is this just so rarely reproducible, I should just have to keep trying the same way until I reproduce it? Findinf the cause to fix the issue could be very difficult this way. Thank you!

Devices used:

• Samsung Galaxy S23 Ultra (Android 14);
• Samsung Galaxy Tab A7 Lite (Android 14);
• Oneplus 12R (Android 14).

Comment 4

[Nicholas Poon [:Nick]]

Hey Lorand,
Thanks for taking a look into this! I just tried playing around with this some more. I believe I have found a reliable way to reproduce this (reproducible on Nightly 138, Beta 137, and Release 136).

1. Open the tabs tray
2. Click on the system home button / swipe up to go home
3. Open fenix (tabs tray should still be open)
4. Long click on the selected tab

At this point, you can consistently reproduce the bug by long clicking on the selected tab and pressing "x" to exit multi selection mode. I was able to reproduce this on the following devices:

• Samsung A35 (Android 14)
• Samsung S21 (Android 14)
• Pixel 8 Emulator (Android 14)

Lorand, can you please confirm if you can reproduce as well with these steps?

Comment 5

[Nicholas Poon [:Nick]]

Given that this is also reproducible on 136, this is not a regression from Bug 1904906, since that is disabled on 136.

Comment 6

[Markus Stange [:mstange]]

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

since that is disabled on 136.

Is it? The bug status doesn't reflect it; the firefox136 status field is set to "verified"

Comment 7

[Lorand Janos]

Hi, Nicholas.
Thanks very much.
Now I can also reproduce reliably using your steps, which I probably accidentally taken the first time, when I reproduced it.

Comment 8

[Lorand Janos]

Attachment: Screenshot_20250320_090333_Firefox Beta.jpg

Comment 9

[Nicholas Poon [:Nick]]

(In reply to Markus Stange [:mstange] from comment #6)

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

since that is disabled on 136.

Is it? The bug status doesn't reflect it; the firefox136 status field is set to "verified"

Hey Markus,
I'm not sure how to update the status flag there but the fix in that patch was under a feature flag that only got enabled to ride the trains in Bug 1944681 for 137