1392092 - Firefox 55.0 returns to the top of the page when using back button at Youtube.com new UI

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[[e-mail]]

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:55.0) Gecko/20100101 Firefox/55.0
Build ID: 20170803103124

Steps to reproduce:

Very simple: 
1) I  created a list Youtube on a subjec 'Vangelis'.
The page https://www.youtube.com/results?search_query=vangelis is opened.
2) I scrolled down (at least until the top of the page was not visible anymore) and followed a link.
3) I then hit the [Back] button to return to the previous page.

 


Actual results:

I got back at the top of the page!


Expected results:

FF should return at the point where I left the initial page.

Comment 1

[Kohei Yoshino [:kohei]]

Please troubleshoot with Safe Mode: https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode

Comment 2

[[e-mail]]

Thank you for your reply. I did that of course. This is always the first thing suggested to do for any issue ... (And it never worked *for me* in any issue that I have had with FF.) 
However, after a suggestion my a member of this group (Tooru Fujisawa [:arai]), I created a clean profile and opened Youtube in it. The Back button in Youtube (as well as Google) worked as expected! So, it's a question of preferences!

Conclusion: Trying to reproduce an problem "with a clean profile" should be always done on a persistent FF issue.

Comment 3

[Cristina Badescu [:cbadescu], Experiments QA]

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:55.0) Gecko/20100101 Firefox/55.0
Firefox: 55.0.2, Build ID: 20170814072924

Hello,

I have tested this issue on latest Firefox (55.0.2) release and could not reproduce it. Every time I hit the [Back] button, it returned to the previous page, in the same position and not at the top of the page.

Considering this and based on comment 2, I will close this issue as Resolved-WFM.
If anyone can still reproduce it on latest versions with a clean profile, feel free to reopen the issue and provide more information.

Comment 4

[[e-mail]]

I believe you! :)  As I said, it doesn't happen with a clean profile, so it is finally a matter of preferences. Only that I don't know -- who indeed knows ? -- what kind of preferences produce that! :)) They work in mysterious ways!

Close this thread as resolved? Well, as you can see, it's not resolved. It will be resolved only when the exact preference(s) are found that produce this phenomenon, won't it?  "Preferences" is only a clue to the solution.

Comment 5

[Cristina Badescu [:cbadescu], Experiments QA]

Because this issue doesn't reproduce on a clean profile, probably this is not a Firefox issue, that's why I closed the issue as "Resolved - WFM". This issue can be caused by an add-on or by some custom settings. 

For further investigations, can you please attach here your "about:support" page? You can do this by navigating to "about:support", click on "Copy raw data to clipboard" button and paste it in a ".txt". 

Thanks.

Comment 6

[[e-mail]]

IT'S DEFINETELY NOT CAUSED BY AN ADD-ON! I have already said in Comment 2 that I did that (run in Safe mode] and that this is always the first thing suggested to do for any issue! Besides, if the reason was an add-on, something that is very easy to find out, the problem would be solved! Oh, come on, it's elementary. 
 
Cristina, I don't know if you work for Firefox or you are just a moderator for you to be able to close a thread. You shouldn't be given that permission. Because you are not careful in reading all the data in the comments and/or you don't undestand what has been said, nor are you using common sense.

Comment 7

[Cristina Badescu [:cbadescu], Experiments QA]

The "about:support" page contains also any modified preferences. Forgot to mention that in my previous comment. That's why I was asking for a copy, in order to compare it with a clean new profile preferences list and not for the installed add-ons. Safe mode only disables the add-ons and plugins that you have but it does not reset the changed preferences.

However, I must indeed apologize for something, when I did the tests on my end, I haven't tried the steps with the new YouTube design. It seems that this is the cause of the issue, since I managed to reproduce it also. In order to get the YouTube new UI, you need to navigate to "https://www.youtube.com/new" page. Sorry for that.

The new YouTube design is only provided for random people since it's still in development. Probably you have the new design on the original profile, but when you tried a new profile, you didn't get the new design since it's quite random.
Considering this, I will reopen the issue since this reproduces on Firefox, but not on other verified browsers.

Thanks for insisting on this!

Comment 8

[[e-mail]]

OK, Cristina. I will wait until a Firefox browser programmer -- if I were one, I would certainly know! -- or some user knows exactly why this "loss of focus" can happen, i.e. what kind of preference (in about:config or elsewhere) can cause such a behaviour. Otherwise I'm not willing to spend more time or yours on this. Thank you for your help.

Comment 9

[Andrew Overholt [:overholt]]

I think this is something the page is doing. It seems a bit intermittent to reproduce but ATM I can reproduce it in both a clean profile and in my normal one.

STR:
- in a new profile (about:profiles is your friend), navigate to https://youtube.com/new
- click "go to youtube" and once you're redirected, verify you've got the new Polymer-based UI (the defining visual characteristic is, AFAICT, no sidebar thing)
- enter 'vangelis' in the search field and press enter
- scroll down a bit in the list of videos and click one
- use the back button to go back to the list

Expected results:
- scroll position in the search results list is retained

Actual results:
- list of results is scrolled back to its top when back navigation finishes

Jessica, you looked into a similar issue in bug 1173474. Do you have any idea what could be happening here? Is this just an under-specified area?

Comment 10

[[e-mail]]

I just tried again, and now it works! I mean, FF doesn't "loose" the location of the page left from. So, if by "intermittent" you mean that sometimes  it happens and other times not, yes, this is true. And I know that this is a nightmare for a programmer. Although, bugs can almost always be debugged and fixed. (At least I always can in my programming).

Thank you Andrew for all this! It's only that I have eaten more than enough of this and I don't want to get more disgusted by eating more. It's not a big deal, anyway. Only an annoyance. 

BTW, I am happy that this very issue has been resolved for Google. There, the annoyance is much bigger!

Comment 11

[Jessica Jong [:jessica] (inactive)]

The root cause seems different from bug 1173474, since in bug 1173474 there is an explicit call to focus() which affects the scroll restoration state. In this case, I don't see anything being focus explicitly. CCing :freesamael who is more familiar with history and bfcache.

Interestingly, I can reproduce this on Chrome in Ubuntu but not on Chrome in macOS.

Comment 12

[[e-mail]]

I just checked bug 1173474 and it seems it's about or it amounts to the same thing: When getting back (using the Back key) to a Youtube or eBay page after following a link, say at the middle of the page, FF returns -- used to return -- at the top of the page and not at the point the user left the page. (This is what I mean by "losing focus".)
BTW, I checked with eBay and there's no problem there either, at the present.

Has version 55.0.3 actually solved the problem? Or will this problem happen again at some point (under unknown conditions)?  It remains to be seen! :)

Comment 13

[[e-mail]]

I am sorry to announce, just one day after, that the issue under discussion happens again in Youtube! (Not in eBay though).
I believe that FF still has a real problem with this. It cannot be something in the HTLM code (of Youtube or whoever else). Because whatever an HTML code does, a browser can always restore the state of page with the link that was followed exactly as it was before. Internet Explorer always does. (I just checked again to be certain.) 

So, with the present message, I officially request from FF developers to find out why this is happening! It's *their* code!

Comment 14

[Samael Wang [:freesamael] (away for now)]

The page sets history.scrollRestoration to "manual", so I think it relies on popState and scrolls the page by itself.

I tried to use the built-in JS debugger on both Chrome & Firefox. It appears that desktop_polymer.js:V.YtAppBehaviorImpl.setPageOffset is the function used to scroll the page on history navigation. However, the parameter b (presumably scroll position) is always 0 on Firefox, but not so on Chrome.

So now we have to debug into the content scripts to find out why...

(In reply to [e-mail] from comment #13)
> It cannot be something in the HTLM code (of Youtube or whoever else). Because whatever an HTML code
> does, a browser can always restore the state of page with the link that was followed exactly as it was before.

Not really if the script explicitly demands the browser not to automatically restore scroll position.

Comment 15

[Samael Wang [:freesamael] (away for now)]

If anyone's interested in Youtube's code, the Polymer "yt-history-manager" is the major part we want to dig into.

Comment 16

[[e-mail]]

(In response to Comment 14 - My comment was initially rejected because of the simultaneous posting of Comment 15!!)

Wow! That's good! Are you an FF developer? (It would be good to know, if only to see that FF developers indeed care! :)

About the "browser can always restore ...", I am not aware that a script can do such a thing!! (Of course, I am not aware of a lot of things! :)  But it seems a little extravagant -- kind of "fascist" :)) -- as a demand!

BTW, "scroll position": Yes, this is a much better description. (How could I miss that? But then, I miss a lot of things! :))

***

(In response to Comment 15)
Although I am a programming addict, I wouldn't go that far! :)  Not that far even as to debug FF code ... There are FF developers to do that! (I wonder where they are though ... :))

Comment 17

[Samael Wang [:freesamael] (away for now)]

I believe the root cause is that document.body.scrollTop doesn't return the scroll position in Firefox. It seems to always return 0, at least in the Youtube page. Ain't quite familiar with this stuff. The spec is here: https://drafts.csswg.org/cssom-view/#dom-element-scrolltop

> If the element is the HTML body element, document is in quirks mode, and the element is not potentially scrollable, return the value of scrollY on window.

Humm... how do I know if a document is in quirks mode?

Comment 18

[[e-mail]]

Re:  If the element is the HTML body element, document is in quirks mode, ...

Who has posted this statement about "quirks"??? Or, if you like, Whom do you reply to about "quirks"???

Comment 19

[Samael Wang [:freesamael] (away for now)]

OK. So it's not in quirks mode, and shouldn't be, since quirks mode is for some very old broken websites (just learned that).

What youtube does is that it stores document.body.scrollTop into a hashMap, and saves a corresponding timestamp to pushState() during navigation; On popState, it uses the timestamp to find the old scrollTop value it stores, and set document.body.scrollTop as well as document.documentElement.scrollTop to restore the scroll position. 

I believe Youtube should store document.documentElement.scrollTop instead (or simply window.scrollY).

Chrome 62.0 (Canary) has the same symptom as Firefox.

Comment 20

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

Hi Mike,
Per comment 19 it's not really a compatibility issue, but perhaps your team could help reach out to youtube for the fix?

Comment 21

[Mike Taylor [:miketaylr]]

Ah, OK. They should just be using document.scrollingElement.scrollTop. It was invented to fix this issue -- the spec says the root scrolling element is documentElement in standards mode, but WebKit/Blink return body, incorrectly.

Adam, could you get in touch with YouTube about this please?


(In reply to Samael Wang [:freesamael] from comment #17)
> Humm... how do I know if a document is in quirks mode?

(Check out document.compatMode:

https://developer.mozilla.org/en-US/docs/Web/API/Document/compatMode

(or just use devtools/view-source to see if there's a doctype))

Comment 22

[Andrew Overholt [:overholt]]

Should we move this to the webcompat component?

Comment 23

[Adam Stevenson [:adamopenweb]]

Contacted via the mailing list.

Comment 24

[Adam Stevenson [:adamopenweb]]

Tested today in Firefox 59, I can't reproduce this issue. Please let me know if anyone can still reproduce it.

Comment 25

[[e-mail]]

Oh, they finally fixed it! My voice was heard!  BTW, where did you get FF 59 from? I just got FF 57.0.4 (latest) ...

Comment 26

[Mike Taylor [:miketaylr]]

(In reply to [e-mail] from comment #25)
> Oh, they finally fixed it! My voice was heard!  BTW, where did you get FF 59
> from? I just got FF 57.0.4 (latest) ...

(you can get pre-release versions from here: https://www.mozilla.org/en-US/firefox/channel/desktop/)

Comment 27

[[e-mail]]

I see. You like to be ahead of time! :))

Comment 28

[Masatoshi Kimura [:emk]]

I guess YouTube had to fix this because Chrome 61+ changed the scrolling element to documentElement and Google shot themselves in the foot :)

Comment 29

[[e-mail]]

Aha. Well, I don't know. I only know that a couple of or a few months ago, the same phonomenon (returning at the top of the page) was also happening with Google. And, from what I read in a forum, with eBay too. But then, and I have stressed another point a lot of times (but it is not heard or it is ignored): Internet Explorer had never such a problem! So, if the problem was Google's or YouTube's, how was it not happening with IE too? (I never got a reply on that. Maybe because people don't use IE anymore! But still, it's a point, isn't it?)