Steps to reproduce

1. Open a tab in normal or private mode.
2. Change the device orientation.
3. Observe the Reader Mode icon (if available), the Reload button and the Tabs Tray button from the toolbar.

Expected behavior

All the toolbar buttons remain displayed when changing the device orientation.

Actual behavior

The Reader Mode icon, the Reload, the Tabs Tray and the Share buttons remain hanging in the previous orientation for ~5 seconds before snapping to the correct position:

• landscape to portrait: the buttons are not displayed (they are out of view), then move to left;
• portrait to landscape: the buttons remain displayed in the middle on the toolbar, then move to right;

Device information

• Firefox version: Nightly 134.0a1 from 11/01
• Android device model/Android OS version: Lenovo Yoga Tab 11 (Android 12)

Any additional information?

I was only able to reproduce this with a specific tablet, Lenovo Yoga Tab 11 (Android 12).
This issue could be partially reproduced with Nightly from 10/23, however only the moving animation was reproduced with this version, without the hanging delay.

Roger thinks this might be a tab strip bug, perhaps related to bug 1923861.

This bug is not a release blocker for the new toolbar design.

Hi Delia,
Thanks for reporting this issue. Can you try to see if you can reproduce this on the old toolbar as well, since I made the change on both the old and new toolbars?

I also want to know if this was an issue existing before the Tab Strip. Thus, I have created an APK with tab strip disabled. Can you see if you can reproduce this issue with this APK as well?

I couldn't find the CPU architecture of the tablet you used above. Thus, I have ran a try push and you can retrieve the appropriate APK by following these steps:

1. Under fenix-opt, under fenix-debug, click on "Bf"
2. Click on "Artifacts and Debugging Tools"

Hi Nick, I did some more testing and I noticed that the issue is not that easily reproducible in the latest Nightly, compared to the initial reported version, but I was still able to reproduce it with pages that take a longer time to load, like https://planet.mozilla.org/ (on this website I was able to easily see the Refresh and/or Share buttons remaining hanging in the previous orientation for ~5 seconds before snapping to the correct position). Otherwise, I mostly saw the moving animation of the Refresh and/or Share buttons.
Here are the results:

• Latest Nightly 134.0a1 from 11/07 + New toolbar: the issue can be reproduced as mentioned above
• Latest Nightly 134.0a1 from 11/07 + Old toolbar: the issue can be reproduced here as well, as mentioned above
• Debug build without Tab Strip: the issue can be reproduced here as well, as mentioned above
• I was also able to reproduce the issue on other devices as well: tablet Samsung Tab S8 Ultra 5G (Android 14) and phone Samsung Galaxy S22 Ultra (Android 14), with both new and old toolbars. (with the new toolbar I can only see the the moving animation of the Refresh and/or Share buttons.)

I've added the video recordings in this GDrive for easier access.

Hi Delia,
Thank you so much for doing further testing! I am able to reproduce it now on my phone. I also noticed that sometimes instead of sliding from the middle to the right of the toolbar, the icons slide left into position from outside of the screen.

Something that I noticed is that the 3 dot menu button is out of position (along with the share icon, etc...) ONLY when the menu redesign is enabled. Otherwise, the 3 dot menu stays in position (while the share icon, etc....) are out of position. Thus, I have a feeling that this has something to do with the weights that we are using when positioning the action buttons

Adding on to the findings above:

I am aware that we use a weight with the menu redesign button, along with the other action buttons to the right of the toolbar - The 3 dot menu becomes a part of the ActionContainer to the right of the toolbar and we don't show the original menu button. The weight determines the position of the different action buttons within the ActionContainer. However, it seems that the old menu button is positioned in xml and to the right of the ActionContainer in the toolbar [sf]. This leads me to believe that the issue lies in ActionContainer and how that is positioned on screen rotation / screen load [sf]. Note that there is an ActionContainer for the Page Actions (refresh, reader mode, etc... in new toolbar) and an ActionContainer for the Browser Actions (new tab icon, tabs tray icon, etc... on new toolbar with tab strip disabled). Since the refresh icon also appears to be in the wrong position in the videos, I think both of these ActionContainer instances have bugs.

Some further questions I have that may help with further investigation is when / how do we determine the position of the ActionContainer and when / how do we determine the position / size of the toolbar.

Adding to the findings a video recording from a custom tab, using the latest Nightly with the new toolbar (not reproducible with the old toolbar so far) on a Samsung GalaxyZ Fold 4 (Android 13) device.
I managed to catch on the video the sliding motion of the Share, Reload and Open in Firefox buttons from both sides (middle of the screen and from outside of the screen), although I believe this happens based on the previous device orientation, landscape to portrait and vice versa.

(In reply to Delia Pop from comment #7)

Created attachment 9436211 [details]
CustomTabs_NewToolbar.mp4

Adding to the findings a video recording from a custom tab, using the latest Nightly with the new toolbar (not reproducible with the old toolbar so far) on a Samsung GalaxyZ Fold 4 (Android 13) device.
I managed to catch on the video the sliding motion of the Share, Reload and Open in Firefox buttons from both sides (middle of the screen and from outside of the screen), although I believe this happens based on the previous device orientation, landscape to portrait and vice versa.

Oh, this is interesting. I also tried to reproduce this on the custom tab toolbar (both the old and new toolbar) but couldn't reproduce it on either

Device: Samsung A35 (Android 14)

Summarizing some of our findings:

• There isn't a definitive way to reproduce it. As Delia mentioned, refreshing https://planet.mozilla.org/ and then constantly rotating the screen makes the issue more easily reproducible. I've also found that starting the refresh in landscape orientation makes this issue easier to reproduce. There is not a definitive number of rotations to do while loading - sometimes the issue appears after 1 rotation and other times, it appears after multiple. You can even continue rotating the screen continuously after the page has loaded and sometimes the issue occurs afterwards
• This is not tab strip dependent. The bug can be reproduced with / without tab strip.
• This is not tablet dependent. The bug can be reproduced on both tablet and mobile.
• This is not toolbar redesign dependent. The bug can be reproduced on both the old and new toolbars.
• This is not menu redesign dependent. The bug can be reproduced with both old and new menus - I merely used the menu button as a way of testing that a specific ActionContainer is to blame for the issue.
• As Delia mentioned, this issue is present on both custom tabs toolbar and the normal fenix toolbar. It seems that it is definitely an issue on custom tabs with new toolbar but it may or may not be an issue on custom tabs with old toolbar as well.
• The toolbar is mostly made of ActionContainers. I think the action container weight for the Browser Actions is causing the problem. To be more specific, I don't think its the weight within that specific action container (browser action container) that's causing the issue but the global weight of that entire action container with respect to the rest of the action containers on the toolbar.

Could be related to Bug 1889240. Since it recovers after a certain delay. It could be a timing issue with the fix in Bug 1889240.