1756970 - url change not affecting page content on youtube

Status: RESOLVED WONTFIX

(Web Compatibility :: Site Reports, defect)

Description

[Dan]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:

visit https://www.youtube.com/
enter a video search-term (or terms)
hit "seach" (then a URL like "https://www.youtube.com/results?search_query=your+search+terms" appears)
quickly press "go back one page" button

Actual results:

URL changes back to https://www.youtube.com/, but page content does not change back.

Expected results:

Page content should refresh and display previous page content

Comment 1

[Dan]

Here 3 profiles, Firefox, Web Developer and Graphics modes.
https://share.firefox.dev/3Hfcv3u
https://share.firefox.dev/3JWl84N
https://share.firefox.dev/3pbUfSu

Comment 2

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

The Bugbug bot thinks this bug should belong to the 'Core::Audio/Video: Playback' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 3

[Kershaw Chang [:kershaw]]

I've seen no networking request created when clicking Back button.
I think this might be more related to B/F Cache.

Comment 4

[Dan]

Thank you for checking and correcting so soon after my post, Kershaw! :)

Comment 5

[Mirko Brodesser (:mbrodesser-Igalia)]

Couldn't reproduce the issue with Ubuntu 20.04.

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Dan, does the issue happen with and without fission.autostart pref being true?
You can set that in about:config page.

(Making this to block bug 1749517, just in case this has something to do with Fission)

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Also, could you try if the addons affect to this. Looks like at least uBlock and 'app.telemetry Page Speed Monitor' do something during a page load.

And does it matter if you wait a bit before clicking back or not?

So far I haven't managed to reproduce this.

Comment 8

[Dan]

(In reply to Olli Pettay [:smaug] from comment #6)

Dan, does the issue happen with and without fission.autostart pref being true?
You can set that in about:config page.

(Making this to block bug 1749517, just in case this has something to do with Fission)

Affirmative!!

(In reply to Olli Pettay [:smaug] from comment #7)

Also, could you try if the addons affect to this. Looks like at least uBlock and 'app.telemetry Page Speed Monitor' do something during a page load.

And does it matter if you wait a bit before clicking back or not?

So far I haven't managed to reproduce this.

Yes Olli, even appears in firefox safe mode! Yes it matters if you wait a bit! Here super detailed steps to reproduce:

1. open youtube.com
2. enter search term "firefox"
3. hit enter, and WHILE red bar is loading (youtube loading bar on top), click "back" key (on mouse or in browser) and wait
4. click "forward" key and INSTANTLY "back" key again, while it is loading, then wait
5. now you can click "forward" key again, URL will change again to youtube.com/results?search_query=firefox, BUT page content stays on YouTube.com default page.
6. now you can click back and forward again as fast as you want, it'll only change URL, but NOT page content.....

Thanks for your feedback guys! Hope this can finally be fixed. Been a frustrating bug since over 1 year now from my experience, and lost many "recommended" videos on youtube homepage because of not being able to go back 1 page from a YouTube search to the "recommended videos" page.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

(In reply to Dan from comment #8)

(Making this to block bug 1749517, just in case this has something to do with Fission)

Affirmative!!

....

Thanks for your feedback guys! Hope this can finally be fixed. Been a frustrating bug since over 1 year now from my experience, and lost many "recommended" videos on youtube homepage because of not being able to go back 1 page from a YouTube search to the "recommended videos" page.

I don't know what "Affirmative" means in this context. Especially given the comment "over 1 year". Fission was enabled late last year, so it shouldn't have affected release builds a year ago.
So, could you clarify if fission.autostart affects the behavior here, thanks.

(Note, Youtube itself has issues with session history handling. It gets broken every now and then in all the browsers, but it is very possible that Firefox has some specific issues too)

Comment 10

[Dan]

Affirmative meant "yes, the issue happens with and without fission.autostart pref being true".

Comment 11

[Olli Pettay [:smaug][[e-mail]]]

Oh, also without fission.

Comment 12

[Olli Pettay [:smaug][[e-mail]]]

One thing, after modifying the pref one needs to restart the browser.

Comment 13

[Dan]

Ah, okay. But yes, still reproducable without fission.

Comment 14

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

The severity field is not set for this bug.
:edgar, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 15

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

(In reply to Dan from comment #13)

Ah, okay. But yes, still reproducable without fission.

(In reply to Dan from comment #8)

(In reply to Olli Pettay [:smaug] from comment #6)

Dan, does the issue happen with and without fission.autostart pref being true?
You can set that in about:config page.

(Making this to block bug 1749517, just in case this has something to do with Fission)

Affirmative!!

(In reply to Olli Pettay [:smaug] from comment #7)

Also, could you try if the addons affect to this. Looks like at least uBlock and 'app.telemetry Page Speed Monitor' do something during a page load.

And does it matter if you wait a bit before clicking back or not?

So far I haven't managed to reproduce this.

Yes Olli, even appears in firefox safe mode! Yes it matters if you wait a bit! Here super detailed steps to reproduce:

1. open youtube.com
2. enter search term "firefox"
3. hit enter, and WHILE red bar is loading (youtube loading bar on top), click "back" key (on mouse or in browser) and wait
4. click "forward" key and INSTANTLY "back" key again, while it is loading, then wait
5. now you can click "forward" key again, URL will change again to youtube.com/results?search_query=firefox, BUT page content stays on YouTube.com default page.
6. now you can click back and forward again as fast as you want, it'll only change URL, but NOT page content.....

I can reproduce this, not 100% reproducible but quite reliably, I think.
The trick here is "to wait for 1-2 sec" for the "wait" action in every step.

Thanks for your feedback guys!

I appreciate your report. However, "guys" isn't a gender-neutral language. I encourage everyone pays more attention on using the gender-neutral language in this public space. https://heyguys.cc/ is a useful reference. :)

Hope this can finally be fixed. Been a frustrating bug since over 1 year now from my experience, and lost many "recommended" videos on youtube homepage because of not being able to go back 1 page from a YouTube search to the "recommended videos" page.

Comment 16

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

This issue is reproducible on Chrome, too. So I think this is more a Youtube's issue, as comment 9 guessed.

Comment 17

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

FWIW, I already reported this to YouTube .

Comment 18

[Dan]

(In reply to Hsin-Yi Tsai [:hsinyi] from comment #17)

FWIW, I already reported this to YouTube .

Awesome, thank you so much! And thank you peeps! [thx for pointing it out! So far never had imagined sb. could feel excluded by it. ]

Comment 19

[Dan]

Seems they fixed it, worked nicely a few times now already :) For you aswell?

Comment 20

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

(In reply to Dan from comment #19)

Seems they fixed it, worked nicely a few times now already :) For you aswell?

No, I still see this issue on both Firefox and Chrome.
I haven't received any update on the internal mailing list with Youtube folks, either.

Comment 21

[Dan]

(In reply to Dan from comment #19)

Seems they fixed it, worked nicely a few times now already :) For you aswell?

No, I still see this issue on both Firefox and Chrome.
Can confirm. Now it's also just as bad again as during my initial report 3 months ago.(In reply to Hsin-Yi Tsai [:hsinyi] from comment #20)

I haven't received any update on the internal mailing list with Youtube folks, either.
oh that's a shame. :/ Could you please consider pointing it out, there, one last time?

Comment 22

[Dan]

Sorry for broken quoting, should be fine here now:
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #20)

No, I still see this issue on both Firefox and Chrome.

Can confirm. Now it's also just as bad again as during my initial report 3 months ago.

I haven't received any update on the internal mailing list with Youtube folks, either.

oh that's a shame. :/ Could you please consider pointing it out, there, one last time?

Comment 23

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

(In reply to Dan from comment #22)

Sorry for broken quoting, should be fine here now:
(In reply to Hsin-Yi Tsai [:hsinyi] from comment #20)

No, I still see this issue on both Firefox and Chrome.

Can confirm. Now it's also just as bad again as during my initial report 3 months ago.

I haven't received any update on the internal mailing list with Youtube folks, either.

oh that's a shame. :/ Could you please consider pointing it out, there, one last time?

Thanks for confirming. Will follow up :)

Comment 24

[Dan]

Anything new yet by chance?

Comment 25

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

(In reply to Dan from comment #24)

Anything new yet by chance?

Hey, sorry that I didn't have updates from YouTube in our internal email thread.
I think as this is a general issue on Youtube, I think it'd be great that your report can filed under their feedback form https://support.google.com/youtube/answer/4347644?hl=en&co=GENIE.Platform%3DDesktop to get more Youtube team's attraction.

Comment 26

[Raul Bucata]

We appreciate your report. I was able to reproduce the issue following the steps to reproduce. The URL path changes, but the page stays on the search results page:

https://prnt.sc/FM1cvPqfLe5k

Tested with:

Browser / Version: Firefox Release 101.0.1 (64-bit)/ Firefox Nightly 103.0a1 (2022-06-26) (64-bit) / Chrome Version Version 103.0.5060.53 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64

Notes:

1. Reproducible regardless of the status of ETP.
2. Reproducible on the latest build of Firefox Nightly and Release.
3. Works as expected using Chrome.

Comment 27

[Dan]

FF 106 is affected.

Comment 28

[Dan]

Oh, we should probably report this bug on the webcompat website to finally get it fixed once and for all, or?

Comment 29

[Raul Bucata]

Hello Dan, I am part of the webcompat team. I was able to reproduce the issue on the latest Firefox Release, but not on Firefox Nightly. Can you please confirm that?

For this project, we perform testing on Firefox Nightly's latest version. Since the issue is not reproducible using Firefox Nightly, this will be closed as "Won't fix"
We apologize for the inconvenience, but if the issue only occurs on the Release/Beta version most likely it will be fixed on the next Release version. Please re-open the issue or comment on this issue if the issue is still reproducible on the next release and we will gladly investigate this further.

Tested with:

Browser / Version: Firefox Release 106.0.4 (64-bit)/ Firefox Nightly 108.0a1 (2022-11-03) (64-bit)
Operating System: Windows 10 PRO x64

Comment 30

[Dan]

Thanks so much Raul!!! I still can reproduce in Firefox Nightly 108.0a1 (2022-11-05) (64-bit) while being logged in to my YouTube account, I just tested, it breaks easily quite fast again.
I'm on Win 10 Home x64

Comment 31

[Raul Bucata]

Thanks for the update, Dan. I was still unable to reproduce the issue: https://screenrec.com/share/WPAnQ8CMEg. Can you please provide a screen recording of the issue happening on Firefox Nightly?

Tested with:

Browser / Version: Firefox Release 106.0.5 (64-bit)/ Firefox Nightly 108.0a1 (2022-11-09) (64-bit) /Chrome Version Version 107.0.5304.107 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64

Comment 32

[Raul Bucata]

Update: it seems that the issue is reproducible when logged in and if just a single search query is made. Making a fresh second one (closing the tab, opening the page, and performing a new search) will not reproduce the issue: https://screenrec.com/share/zIQWXNB0CG

Tested with:

Browser / Version: Firefox Release 106.0.5 (64-bit)/ Firefox Nightly 108.0a1 (2022-11-09) (64-bit) / Chrome Version Version 107.0.5304.107 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64

Notes:

1. Reproducible regardless of the status of ETP.
2. Reproducible on the latest build of Firefox Nightly and Release.
3. Works as expected using Chrome.

Comment 33

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

Attachment: youtubue_navigation_Chrome.gif

FWIW, I still see this issue on Chrome v107. I am on Windows.

Comment 34

[Olli Pettay [:smaug][[e-mail]]]

I was debugging this a bit, since I happened to notice this. First I wondered if there was something wrong with session history, but everything looked fine there and history.state is updated correctly. Then I noticed there is a timestamp attached to the state. I assumed it is coming from performance.now().
Whenever two consecutive session history entries had history.state.entryTime set to same value, back button didn't seem to work.
Then I tried to make that happen less likely by always returning unclamped value in https://searchfox.org/mozilla-central/rev/2fc2ccf960c2f7c419262ac7215715c5235948db/dom/performance/Performance.cpp#129-130,137 and that seemed to help quite a bit (well, always in my testing). Chrome seems to more often return also decimal values.

tjr, could we possibly tweak performance.now() behavior?

But if my debugging is correct and youtube really relies on performance.now() in that way, it does feel like an site issue.
Ksenia, could we perhaps contact Youtube about this issue (if we haven't done it already)

MDN does document quite well that the accuracy of performance.now() may vary https://developer.mozilla.org/en-US/docs/Web/API/Performance/now#reduced_time_precision
And looks like setting privacy.reduceTimerPrecision to false in about:config changes the behavior for me.

Comment 35

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

I just sent another email to Youtube with the new info from comment 34.

@Dan, Olli also shared with me that, flipping the preference privacy.reduceTimerPrecision to false helped "mitigate" this issue. This could be considered a workaround on your side for now. Thank you for your patience and the report again.

Comment 36

[Ksenia Berezina [:ksenia]]

Thanks for contacting them, Hsin-Yi Tsai!

Comment 37

[Olli Pettay [:smaug][[e-mail]]]

Or maybe I should have been more precise. privacy.reduceTimerPrecision == false makes this happen less likely, I think. Nothing still guarantees that performance.now() couldn't return the same value multiple times.

Comment 38

[Tom Ritter [:tjr] (OOTO until mid-August)]

(In reply to Olli Pettay [:smaug][[e-mail]] from comment #34)

I was debugging this a bit, since I happened to notice this. First I wondered if there was something wrong with session history, but everything looked fine there and history.state is updated correctly. Then I noticed there is a timestamp attached to the state. I assumed it is coming from performance.now().
Whenever two consecutive session history entries had history.state.entryTime set to same value, back button didn't seem to work.
Then I tried to make that happen less likely by always returning unclamped value in https://searchfox.org/mozilla-central/rev/2fc2ccf960c2f7c419262ac7215715c5235948db/dom/performance/Performance.cpp#129-130,137 and that seemed to help quite a bit (well, always in my testing). Chrome seems to more often return also decimal values.

tjr, could we possibly tweak performance.now() behavior?

We could increase the precision to make it less likely that two consecutive calls have the same value; but if the consecutive calls are really close together, we'd have to increase the precision quite a bit I imagine. We are currently at a precision of 1ms. Chrome appears to be at .1ms or 100usec. Unsure about Safari.

I've been suggesting that increasing the precision should only be done if there is a valid web use case to do so, but outside that, keeping it less precise is still serving as a stopgap measure to keep a wide variety of timing attacks (not just Spectre) less likely to work in real-world conditions and in academic conditions make the tradeoff of longer runtimes vs being less accurate (especially relative to other browsers where we usually get compared to in the papers.)

Other than increasing the precision, I'm not sure exactly how to tweak it. I suppose we could do something particularly ugly where for every subsequent call that's within the same rounded value we increment it by 1usec or something but that seems like something that would have unexpected consequences somewhere else on the web.

And looks like setting privacy.reduceTimerPrecision to false in about:config changes the behavior for me.

This will change the rounding* from 1ms to 20 usec; so it will much much more precise and less likely to occur.

* I say rounding, but to be pedantic, we are still jittering, so don't think of it as normal rounding where 0-.4999... goes to 0 and .5-.99... goes to 1

Comment 39

[Ksenia Berezina [:ksenia]]

We could increase the precision to make it less likely that two consecutive calls have the same value; but if the consecutive calls are really close together, we'd have to increase the precision quite a bit I imagine. We are currently at a precision of 1ms. Chrome appears to be at .1ms or 100usec. Unsure about Safari.

We can try adding an intervention tweaking the precision of performance.now() that will be limited only to youtube, to match either Chrome's behavior (100usec) or 20 usec? I filed bug1803976 and will test it this week.

Comment 41

[Ksenia Berezina [:ksenia]]

The intervention has landed in today's Nightly (109.0a1 (2022-12-09) ) in bug1776678. I confirmed that it fixes issues described in comment 0 and bug1803919.

Dan, Hsin-Yi or Olli wonder if you could check whether it's fixed in the recent Nightly for you, please?

Comment 42

[Olli Pettay [:smaug][[e-mail]]]

Works fine here now

Comment 43

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

Works for me, too.

Comment 44

[Dan]

(In reply to Ksenia Berezina [:ksenia] from comment #41)

The intervention has landed in today's Nightly (109.0a1 (2022-12-09) ) in bug1776678. I confirmed that it fixes issues described in comment 0 and bug1803919.

Dan, Hsin-Yi or Olli wonder if you could check whether it's fixed in the recent Nightly for you, please?

Works indeed when only doing the steps once! But I noticed that when going one step forward (arrow right) again and quickly "go back one page" again, it is still occuring, on latest nightly. However I'd say this secondary issue now is quite low priority, but maybe anyone would like to check anyways?

Comment 45

[Dan]

Clearly Ksenia is unable to fix this very frustrating regularly-encountered bug. Can this seriously not be fixed in Firefox and do we seriously have to start using Chromium-powered browsers that are at least working reliable on one of the most famous websites out there? (if not -the- most famous website (youtube)). How disappointing. Edge seems to be the browser to go for, nowadays. At least Edge seems to be less privacy-concerning than Chrome browser (which used to scan the entire PC contents for installed software or even all files, in the past.). Edge it is!!

Comment 46

[Olli Pettay [:smaug][[e-mail]]]

The bug we know about is on Youtube's side. They are aware of the issue.
I haven't seen issues with Youtube after bug1776678 landed.

Comment 47

[Ksenia Berezina [:ksenia]]

(In reply to Dan from comment #44)

(In reply to Ksenia Berezina [:ksenia] from comment #41)

The intervention has landed in today's Nightly (109.0a1 (2022-12-09) ) in bug1776678. I confirmed that it fixes issues described in comment 0 and bug1803919.

Dan, Hsin-Yi or Olli wonder if you could check whether it's fixed in the recent Nightly for you, please?

Works indeed when only doing the steps once! But I noticed that when going one step forward (arrow right) again and quickly "go back one page" again, it is still occuring, on latest nightly. However I'd say this secondary issue now is quite low priority, but maybe anyone would like to check anyways?

Thanks for checking. I can't reproduce the issue with one step forward following these steps:

1. Enter search term, see results
2. Step back (arrow left)
3. Step forward (arrow right) and then quickly step back (arrow left)

Comment 48

[Raul Bucata]

The issue is still reproducible

Tested with:

Browser / Version: Firefox Release 109.0 (64-bit)/ Firefox Nightly 111.0a1 (2023-01-31) (64-bit) / Chrome Version 109.0.5414.120 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64

Notes:

1. Reproducible regardless of the status of ETP.
2. Reproducible on the latest build of Firefox Nightly and Release.
3. Works as expected using Chrome.

Comment 49

[Dan]

Yes still happening. Any ideas?

Comment 50

[Thomas Wisniewski [:twisniewski]]

We unshipped our intervention for this in Firefox 115 in bug 112730, as this appears to no longer be an issue.

Comment 51

[Dan]

Interesting, this bug now even occurs in Chromium-based browsers (Brave in this case), so YouTube definitely is broken, that's disappointing.