My homepage uses in-page scroll within the navbar and so I have anchors set within the page. The in-page nav works fine on the homepage, however, on my ‘Kids’ page when I click a navbar item that goes to an anchor on the homepage (‘You’, ‘Me’ or ‘Sessions’), I am taken to the anchor but then the page almost immediately jumps to the very top of the homepage.
I am using Limelight and in my trouble-shooting when I remove the Limelight stacks from the homepage (I left the Limelight Launcher and Limelight Menu stacks), the anchors work perfectly when clicked from the ‘Kids’ page. The page lands where it should and doesn’t jump back to the top.
I tried to determine what is causing the conflict with Limelight but was not able to. I removed the Source scroll enabler, Chroma stacks, and Magic Maker2 stacks, however, the issue still occurred. As such, I don’t know if Limelight is conflicting with something or if there is just something inherent within Limelight causing this issue.
As an aside, I am using the Magic Marker2 stacks within the Source framework as I need to define offsets since I am using a fixed Chroma for my nav. I know Magellan is Foundation only, however, when building this nav system several months ago I thought I read that the Magic Marker2 stacks can be used by themselves in other frameworks (please correct me if this is wrong). Just raising this in case it factors into this issue. It doesn’t seem like it since the issue still occurs when the Magic Marker2 stacks are removed from the site (and the issue doesn’t occur with Magic Marker2 stacks included but Limelight stacks removed). Nonetheless, trying to provide as much info as possible that may be helpful.
That’s an odd one. It does seem like there might be a couple of things battling for control of the scrolling. I’ve no idea if this would make a difference or not but do you have this option selected in LimeLight:
Strange thing re Limelight is that it is present on the homepage but the problem does not occur.
I’ve just traced the events and it looks like that after the Source smooth scroll click event then the body scroll is being intercepted by a scroll listener within the Gist JS code that is placed into that page.
Have you tried removing that script and see if the problem goes away?
I think we need to make a simple test case for this with minimal content on the page to show the problem.
MagicMarkers should be no problem in themselves. They are just dumb links with an ID.
Limelight does not watch any scroll events and only does the scroll into view thing (if it were selected) when the launch class is clicked (i.e. not an href).
smoothscroll.js (which is what Source uses) is a primitive routine that intercepts all clicks on links, finds if there is a # href and if so, animates the page to the scroll position of the element with the id matching that href. I mean primitive in the technical sense in that it is non selective and applies itself to everything on the page that is a link.
Each of the additional scroll events back to the top of the page seems to be generating a new click on the previous item as it comes into view and so the scroll animations chain until we reach the top of the page.
Things to try
Firstly, are any of your Limelights or MagicMarkers or scroll # links that are sharing the same name? If so try changing them so that they are at least slightly different.
A simple test case is therefore really the only way to solve this one. Start with just a couple of menu links a few screens worth of text. Then add in a Limelight and Chroma etc and watch carefully until the issue happens.
I will see if I can replicate the issue as soon as I get back to my computer this evening. I’m sure we’ll find the problem and get it sorted.
My Vista course demo page has a similar set up to this (with Limelight and anchor links). I’ve copied it and adapted the second page so that it links back to anchors on the first page. It all works as expected without the jump back to the top.
@tav - I did this but the issue persists (I uploaded to the test site in case this is helpful). If you have any other thoughts please let me know. Otherwise, I’ll work to isolate the conflict this afternoon and report my findings.
@lion If you can send me that page (as cut down as possible to show the problem) in a project file then I will look at Limelight in my debug mode and see what events are being triggered.
You can email it to the bwd support address.
@tav - I isolated this to one specific Limelight that contains multiple embed codes (from Acuity Scheduling). There are 4 embed codes each within their own stacks content with their own unique launch IDs. When I remove 3 and only leave 1 within the Limelight the problem resolves.
I dug into this further and separated the 4 embed codes into separate Limelights, however, the issue was the same. When there is more than 1 embed code on the page within a Limelight or across multiple Limelights the issue exists.
I then removed the embed codes from Limelight entirely and placed all 4 on the page. When I did this the issue resolved. As such, it looks like when more than 1 of these embed codes is in Limelight some conflict is happening that causes this issue.
I have emailed you the project file that is cut down as much as possible (I only kept what seems necessary to clearly see the problem in preview mode). I have removed all Limelights except for the one containing the embed codes. Also, I uploaded the cut down project to dev.kellyrosematthews.com in case this is helpful.
Thanks, I will have a look at the project as soon as I get a chance later today.
I have however just looked at the script on your cut down published page and that script is grabbing the query string from the URL and then actively scrolling the page so I think it is safe to say we have found the culprit ( https://embed.acuityscheduling.com/js/embed.js)
I also don’t think that you need multiple copies of that script on the page so the simple solution may be to just add the script to the RW page Javascript rather than add it multiple times with inline script tags.
Given what you’ve said about only having one limelight on the page, I’m guessing that just one script will sort it out. I think that multiple scripts may well be cascading the scroll repositioning.
@lion After typing my last post I decided I had to try it now before starting work - it works!
Just remove the script tags from your Coder stacks and paste the link ONCE into the page inspector Head tab.
Problem solved.
I’ll email you the fixed project back.
Just for future reference and for others reading this thread:
If you are ever injecting code from elsewhere into a page using script tags or CDN’s then please suspect this to be the cause of the problem. Stacks generally work well together, particularly well tried and tested combinations such as Limelight and Source.
