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.
Please troubleshoot with Safe Mode: https://support.mozilla.org/kb/troubleshoot-firefox-issues-using-safe-mode
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.
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.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → WORKSFORME
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.
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.
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.
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!
Status: RESOLVED → REOPENED
status-firefox55: --- → affected
status-firefox56: --- → affected
status-firefox57: --- → affected
Component: Untriaged → Document Navigation
Ever confirmed: true
OS: Unspecified → All
Product: Firefox → Core
Hardware: Unspecified → x86_64
Resolution: WORKSFORME → ---
Summary: Firefox 55.0 returns to the top of the page when using back button at Youtube.com → Firefox 55.0 returns to the top of the page when using back button at Youtube.com new UI
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.
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?
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!
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.
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! :)
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!
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 email@example.com 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.
If anyone's interested in Youtube's code, the Polymer "yt-history-manager" is the major part we want to dig into.
(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 ... :))
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?
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"???
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.
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?
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))
Flags: needinfo?(miket) → needinfo?(astevenson)
Should we move this to the webcompat component?
Contacted via the mailing list.
Component: Document Navigation → Desktop
Product: Core → Tech Evangelism
Version: 55 Branch → Firefox 55
You need to log in before you can comment on or make changes to this bug.