External link doesn't work (related to sites with "parallax" viewing?)

[kristapsdz]

Try jumping to https://divelog.blue/index.html#gear. This site uses zenscroll (otherwise, working great!) for its layout. However, the link doesn't go to the "gear" fragment. It goes... somewhere else on the page. Within the page you can jump to the fragment by selecting one of the navigation links or entering the fragment directly. But when linking from an external page, it doesn't work.

[zengabor]

Would it work if you would remove zenscroll from the page? I didn't have the time to debug this, but note that if the page is called with a hash in the URL then zenscroll is not involved in the scrolling. So this may be a problem that isn't caused by zenscroll but something else in the code.

The good news is that I plan to implement a new logic that would trigger zenscroll on first load to adjust the scrolling. This would solve this issue as well.

[tivac]

This is affecting https://www.arena.net/#careers as well, sadly.

[kristapsdz]

Oh, I thought I'd updated this. This is not zenscroll's problem. The problem is in load events causing page dimensions to change:

1. jump to #location in page when DOM content loads
2. load event (or other async) inserts content prior to the #location
3. actual location of #location is pushed "downward"

The solution is easy, fortunately. After your load, trigger a rescroll.

[tivac]

My example doesn't change size at all, I may need to investigate further then.

[marcosmbytes]

+1 for reopening this.

I'm having the exact same issue as @tivac

[zengabor]

@tivac Your situation is interesting, I will investigate why it doesn't work. I am working on Zenscroll 4.0 right now which fixes a few issues and may also include triggering the normal browser link handling, so it will most probably work in special cases as well.

For your case I can already see that if you disable CSS, it works immediately, so maybe it's related to issue #30 ?

[zengabor]

@marcosmbytes Would you mind sharing the related code or URL with me?

[marcosmbytes]

The project I’m working on is not public yet.

Here’s some sample code that displays the behavior.

Tested on OSX. Safari 10 seems to work fine but Chrome 56 has the issue.

Navigate to any link, scrolls fine. Reload the page or open the navigated link in a new window (including the hash) and it will always be at the top. It should be at the anchored item position.

For the sake of testing I added :target selectors to see if the hash change triggers a selector change.

A regular click navigation doesn’t change the selector. Refreshing (or new window) does, both on Safari and on Chrome.

test.zip

[tivac]

@zengabor Hmm, maybe. None of the sections with an id that are being used as anchors are positioned in any way.

I made as minimal a repro as possible, https://output.jsbin.com/bubabid/#tgt

It should have the green target section visible by default on load, but doesn't.

I then cloned that bin and commented out zenscroll.

https://output.jsbin.com/mulase/#tgt

Which works fine. Still haven't found time to dig into this myself, but if you don't see something obvious I'll see what I can do.

[zengabor]

@tivac and @marcosmbytes I just realized that this is a bug that I already fixed in 4.0 which is not yet released. I estimate it‘s still at least a week until I can release 4.0.

The bug is caused by setting scrollRestoration to "manual" too early, before the browser has a chance to scroll to the anchor.

I think you can already patch it by changing this piece of code:

history.scrollRestoration="manual"

to this:

setTimeout(function(){history.scrollRestoration="manual"},1)

[tivac]

@zengabor oh awesome! Any chance you'd consider a hopefully-quick 3.3.1 patch release with that fixed?

[zengabor]

Good point! I will probably do that within a day or so.

[marcosmbytes]

I just tested that line change and I still have the issue.

Here's my example, updated with the fix:
test2.zip

Checking further, I see that even removing zenscroll the value for scrollRestoration stays "manual", as if it were cached.

Adding history.scrollRestoration="auto" before the setTimeout seems to actually fix it for me.

Here's a test:
test3.zip

All my testing in Chrome 56

[zengabor]

@marcosmbytes I think this issue is related to #31 which I will implement in version 4.0 soon. I will test it thoroughly one of these days.

[zengabor]

Would you mind testing your issues with the 4.0 release candidate?

You can find it here: https://github.com/zengabor/zenscroll/tree/gh-pages

[zengabor]

@marcosmbytes you probably want to set the edge offset to zero via zenscroll.setup(null, 0) as described under 1.3 here: https://zengabor.github.io/zenscroll/#1.3.limitedsupportforthehashchangeeventandthecsspseudo:target

[tivac]

https://output.jsbin.com/sudayim#tgt is using the 4.0 RC.

Looks like it loads scrolled to #tgt (:+1:), then animates back up to the start of the page (🐛).

[zengabor]

@tivac Strange but I could not reproduce it. It works fine in all of these browsers: Chrome, Chrome Canary, Safari, Safari Technology Preview, Firefox. It doesn't "animate back up to the start of the page".

By the way, this bin's CSS enabled the native scroll-smoothing via body { scroll-behavior: smooth}, so Zenscroll doesn't load in the newest browsers.

🤔

[tivac]

Working fine from home, was being real weird in Firefox Dev Edition and Chrome Stable at work.

¯\(°_o)/¯

I'll try it out on the dev arena.net site tomorrow.

[marcosmbytes]

@zengabor working perfect!

The :target thing was just for testing, I'm not actually using it in the project I'm working on, and even if I did I'm using an offset value for it anyway so I would be out of luck.

Great work!

[tivac]

Tried it out again at home and seems fine, I'm not sure what was happening yesterday. Sorry for the false alarm!

[zengabor]

These issues are now fixed in v4.0.0