Scroll position not retained in Firefox, IE

[digitalCitizen]

Previous (closed) issue with recent update here: #80

The issue is that after a change in the code, the page refresh causes the scroll location to be set to the top of the page. This happens in Firefox 37.0.2, and in Firefox Developer Edition 40.0a2 (2015-05-19) and IE 11.

In Chrome everything works nicely.

[faergeek]

Unfortunately, I can't test it in IE11 right now.
@shakyShane can you try to remove forceReload from window.location.reload calls and test it?
It fixes issue for Firefox.

I mean change

window.location.reload(true);

to

window.location.reload();

[Siilwyn]

Can confirm this also happens on Firefox 38.0 on Ubuntu 14.04.
@faergeek I would be happy to test but can't find the above snippets of code in the source...

[faergeek]

It's in browser-sync-client repo
https://github.com/BrowserSync/browser-sync-client/blob/master/lib/code-sync.js#L226
https://github.com/BrowserSync/browser-sync-client/blob/master/lib/browser.utils.js#L121
It solves issue in Firefox, not sure about IE.

[Siilwyn]

I wasn't aware that browser-sync is split up.
Unfortunately removing the forceReload doesn't fix this issue in Firefox 38.0 on Ubuntu 14.04.

[faergeek]

@Siilwyn, did you run gulp build before testing?

[Siilwyn]

@faergeek oh I also missed that it was being build with gulp, thanks for bearing with me. That indeed fixed it. Should I open a pull request changing the code to detect Firefox and pass false to the reload function?

[faergeek]

I think there's no reason to detect Firefox or IE, equally as no reason to pass false there, it is false by default. It's because I think that caching should be disabled for development anyway.
What do you think, @shakyShane?

[shakyShane]

@faergeek - without passing true, many browsers will not send a new request & whilst you may be able to disable caching in your devtools or whatever, how will it affect devices you're also testing on?

[faergeek]

I mean you can disable caching on server

[faergeek]

Another workaround is to disable UA detection when save/restore scroll position from cookies.

[shakyShane]

I've just some testing on Chrome, Firefox, iOS, IE9 etc and all send to still perform the request

Because of this I'm happy to remove the true argument from reloading. Any cache preventing can always be done on a project specific basis, by using headers etc,

[digitalCitizen]

I must be doing something wrong... If I remove the "true" in the files as specified by @faergeek, the browser (Firefox Developer edition 40.0a2) still pops back to the top after a sync reload. The disable cache setting is turned on in devtools.

[shakyShane]

How are you running Browsersync with the modified script?

[shakyShane]

Hmm, yeah I see the same problem in IE11

[shakyShane]

Wow, just learned about window.name - Seems a perfect candidate for this
https://en.wikipedia.org/wiki/HTTP_cookie#Alternatives_to_cookies

[digitalCitizen]

@shakyShane: I forced an update to the latest version of browserSync, made the changes in the files, ran gulp build and then started gulp.

[faergeek]

@shakyShane, window.name is cool, but what if it's already used by app somehow?

[shakyShane]

Can we not just namespace writes to it?

There's a tradeoff for any approach though.

1. Cookies are sent over the wire with every request - bad
2. Local storage persists across all open tabs in same browser - bad

[faergeek]

I don't think we can use namespaces there, it's just a string.

[faergeek]

I think we can prepend our data to window.name on beforeunload and then remove it after read, but it should be done as early as possible, before any other script on the page.

[shakyShane]

Any examples of frameworks/apps that actually use window.name? I don't think I've ever seen it.

Either way, my thoughts are that we default to it (works great in my tests) but allow users to use the cookie drop instead via an option.

[faergeek]

MDN lists some usages https://developer.mozilla.org/en-US/docs/Web/API/Window/name

[shakyShane]

Please all try 2.7.11

I have tested in all browsers back to IE8 and it's working great now.

I'm aware that using window.name may have an impact re: conflicts with other libs - but I think this is so unlikely that i'm happy to risk it for now & users can opt-out easily if needed.

[digitalCitizen]

Yes, supersweet. This works for me! Tested in Firefox, Firefox Developer Edition, IE 11.
Thanks :)

[shakyShane]

@digitalCitizen Thanks for reporting

[Siilwyn]

Really nice! It even seems to work better now, the browser window doesn't flash at the refresh like it did before. @shakyShane thank you!

[shakyShane]

@Siilwyn - Yeah I made a couple of other improvements whilst there :p

Also, if you are pleased with the support we give, you could extend your thanks by voting for us

:)

[benjaminkitt]

A quick note about a conflict I found:

Protractor uses an Angular feature called Deferred Bootstrap that uses window.name and conflicts with BrowserSync. From the AngularJS Docs:

This feature enables tools like Batarang and test runners to hook into angular's bootstrap process and sneak in more modules into the DI registry which can replace or augment DI services for the purpose of instrumentation or mocking out heavy dependencies.

If window.name contains prefix NG_DEFER_BOOTSTRAP! when angular.bootstrap is called, the bootstrap process will be paused until angular.resumeBootstrap() is called.

If Browsersync overwrites that window.name value before it gets caught by Angular, Angular will not defer its Bootstrap and Protractor will subsequently not be able to find the resumeBootstrap function because it won't exist.

Switching to the cookie drop resolves this issue, but took me a long time to troubleshoot!

[socheon]

Hi. I am using [email protected] and Google Chrome (v43.0.2357.130) on Ubuntu. The scroll position, say after using for 5 minutes, starts to jump to another position when reload. When I restart the browser, the problem seems to go away again. Is there a way to check what's wrong? Or something I can run on the browser console, so that I don't have to close all my tabs and restart the browser?

[bjornhanson]

Is this problem back? I'm testing with several browsers on several platforms, using BroswerSync 2.14.0. When I scroll in Chrome, I see other Chrome, Safari, and Edge windows scroll together, but not Firefox or IE 11. If I scroll in Firefox, I see Firefox and IE 11 windows scroll together.

[digitalCitizen]

This issue was not about scroll syncing in different browsers, but about the scroll position popping back to top after a code change/auto refresh.

[MariuszDabrowski]

Having the same issue, on every refresh the page starts back at the top.

OSX El Capitan
Chrome Version 51.0.2704.103 (64-bit)

[testgit-1]

Have the same problem.
Firefox 55.0.2 (32-bit).