1914555 - Some websites are skipped while navigating in a tab (back/forward buttons) in which multiple websites were loaded

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect)

Description

[Bogdan Maris, Desktop Test Engineering]

Attachment: Gif showing the issue

Found in

• Nightly 131.0a1

Affected versions

• Nightly 131.0a1

Tested platforms

• Affected platforms: Windows 11, macOS 13.6 and Ubuntu 22.04
• Unaffected platforms: none

Preconditions

• Have browser.navigation.requireUserInteraction pref set to true

Steps to reproduce

1. Navigate in the same tab on a few websites
   eg. youtube, facebook, wikipedia, reddit, twitter
2. Use the back button to navigate until it reaches the first visited website
3. Use the forward button to navigate until it reaches the last visited website

Expected result

• Every website visited in a tab is revisited while using back/forward navigation buttons.

Actual result

• Some websites are skipped while navigation though the visited websites in a tab.

Regression range

• Will look for a regression asap, although this pref is available back to Firefox 79 in bug 1515073 so it could probably be that old.

Additional notes

• In the Gif attached, reddit page is skipped while navigating. Switching the pref from the precondition to False will fix it.

Comment 1

[Bogdan Maris, Desktop Test Engineering]

(In reply to Bogdan Maris, Desktop Test Engineering from comment #0)

Regression range

• Will look for a regression asap, although this pref is available back to Firefox 79 in bug 1515073 so it could probably be that old.

It looks that this is not a regression, using the first build when this pref was enabled in bug 1515073 this is still reproducible and worse.

Comment 2

[Hsin-Yi Tsai (she/her) [:hsinyi]]

The feature will remain disable on Fx 131.

A build containing patches in bug 1734181 seems to resolve this issue for me. Let's ensure to confirm after bug 1734181 lands. Good testing observation, thank you :bmaris!

Comment 3

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi :bmaris!
Now that bug 1734181 was landed. Can you please test again to see if this is resolved along by that bug? If not, I would set a high priority and work with Adam to fix this, given your suggested S2 severity. Thanks!

Comment 4

[Bogdan Maris, Desktop Test Engineering]

(In reply to Hsin-Yi Tsai (she/her) [:hsinyi] from comment #3)

Hi :bmaris!
Now that bug 1734181 was landed. Can you please test again to see if this is resolved along by that bug? If not, I would set a high priority and work with Adam to fix this, given your suggested S2 severity. Thanks!

It appears that this is not happening anymore so it seems that the fix from bug 1734181 did the job. I'll close this bug for now and will reopen it in the future if need be. I tested using the latest Nightly 131.0a1 across platforms (Windows 11, macOS 13 and Ubuntu 22.04).

Comment 5

[Bogdan Maris, Desktop Test Engineering]

I think I'll reopen this one since I can reproduce using a few microsoft websites (that without the pref would hijack the back button) and the rest of the steps from comment 0.

eg of websites:

1. https://answers.microsoft.com/en-us/msoffice/forum/all/account-locked-for-weeks-no-reasonnotice-and-no/04bc4b41-a70d-4b5a-b494-
2. https://support.microsoft.com/en-us/topic/windows-10-update-assistant-3550dfb2-a015-7765-12ea-fba2ac36fb3f
3. https://support.microsoft.com/en-us/windows/manage-background-activity-for-apps-in-windows-4f32dffe-b97c-40e8-a790-3ca10373a1ef

An interesting thing is that if the above websites are opened in the same tab, the back button will be hijacked right at the start, although if opened in different tabs the back button will work from the start.

Comment 6

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Thanks for the further results. Adam was able to verify various webcompat reports with the fixes in bug 1734181 , but he is still seeing unexpected behaviors mostly on the microsoft site. Investigation is in progress.

Comment 7

[Bogdan Maris, Desktop Test Engineering]

Attachment: Affected website and reload.gif

Even though bug 1917369 has been fixed I can still reproduce but a little bit different. A reload is necessary on a page from microsoft and the back button will not work, the forward button is disabled and two entries are seen in the back button history as in bug 1718106.

Comment 8

[Bogdan Maris, Desktop Test Engineering]

(In reply to Bogdan Maris, Desktop Test Engineering from comment #7)

Created attachment 9424640 [details]
Affected website and reload.gif

Even though bug 1917369 has been fixed I can still reproduce but a little bit different. A reload is necessary on a page from microsoft and the back button will not work, the forward button is disabled and two entries are seen in the back button history as in bug 1718106.

Another website that can reproduce this every time is x.com

1. Visit x.com
2. Visit wikipedia.org
3. Click the back button

AR: The forward button is disabled and the history from the back button shows two x.com websites.

Looks like Chrome has the same issue as we do with x.com though.

Comment 9

[Adam Vandolder [:avandolder]]

(In reply to Bogdan Maris, Desktop Test Engineering from comment #7)

Created attachment 9424640 [details]
Affected website and reload.gif

Even though bug 1917369 has been fixed I can still reproduce but a little bit different. A reload is necessary on a page from microsoft and the back button will not work, the forward button is disabled and two entries are seen in the back button history as in bug 1718106.

I've been testing this myself, and I think this issue only happens in a couple cases:

1. You right-click and open the link in a new tab or browser, in which case it becomes the first history entry before performing the redirect. Currently, we always act as though the very first history entry has an interaction status, and so you will be able to navigate back, just to immediately trigger the redirect again.
2. You interact with the page before doing the reload. When the reload occurs, the page will once again perform a redirect, except now the initiating page is marked as having been interacted with and so keeps its history entry.

(In reply to Bogdan Maris, Desktop Test Engineering from comment #8)

Another website that can reproduce this every time is x.com

1. Visit x.com
2. Visit wikipedia.org
3. Click the back button

AR: The forward button is disabled and the history from the back button shows two x.com websites.

Looks like Chrome has the same issue as we do with x.com though.

This seems to be an unfortunate, but unavoidable, situation. x.com performs a redirect when you navigate to it, including when you go back to it via your history - in which case that redirect wipes out your forward history. And since the first x.com page was interacted with, it will remain in history, along with the new page it redirected you to.

Comment 11

[Adam Vandolder [:avandolder]]

The main case of this bug was fixed in bug 1917369, and the remaining case (the first-entry not being checked for user interaction) is being handled in bug 1924861.

Comment 12

[Hsin-Yi Tsai (she/her) [:hsinyi]]

(In reply to Adam Vandolder [:avandolder] from comment #11)

The main case of this bug was fixed in bug 1917369, and the remaining case (the first-entry not being checked for user interaction) is being handled in bug 1924861.

Agreed with Adam that the main case of this bug, which originally warrants S2 severity was fixed. That is, the real S2 part was that some websites that users explicitly interacted with/navigated through (not by a script) are skipped while navigation through the visited websites in a tab.

I am going to close this bug, and we will use bug 1924861 for the remaining and different scenarios.

Comment 13

[Timea Zsoldos [:zstimi/tzsoldos], Desktop QA]

Tested using latest Nightly Firefox 135.0a1 on Windows 10, macOS 12 and Ubuntu 22, works as expected, if not using twitter.com or any misbehavior site, which behaves the same on chrome.