Cms: Allow Live Preview's Preview Targets to obey #anchor URLs

[proimage]

Description

I've got a site with some job listings that only show up towards the bottom of a longish About page. The Job Listings are their own entries, but they don't have dedicated "Single Entry" pages. So, in the Preview Targets for the Job Listing section, I want to add something like about#jobs to the URL Format. When I do this, however, it seems to just get ignored; the Preview pane remains at the top.

I've tried to be a smartypants and work around the issue by changing the URL Format to about/jobs, adding the route needed to point that URL to the same template, manually assigning the entry variable if it's undefined, and finally adding some scripting to jump to the Jobs element when that URL is detected:

{% if craft.app.request.getSegment(2) == 'jobs' %}
<script>
    $(document).ready(function()
    {
        $('#jobs')[0].scrollIntoView();
    });
</script>
{% endif %}

While this does work initially, after a few seconds the preview pane jumps back up to the top of the page. :-/ Not sure what that's about.

Steps to reproduce

1. Create a long (scrollbar-triggering) template, with an anchor target towards the bottom (<div id="jobs">...</div>)
2. Create a section in the backend that uses that template for its Live Preview, and add #jobs to the "Preview Targets" -> "URL Format" field.
3. Post an entry to the section, and try the Live Preview feature. The preview doesn't scroll down to the #jobs element.

Additional info

• Craft version: Craft CMS 3.3.18.1

[brandonkelly]

This is fixed for the next release!

To get the fix early, change your craftcms/cms requirement in composer.json to:

"require": {
  "craftcms/cms": "dev-develop#4abecc542a9ea579745b0a80b345d943bc14ecbe as 3.3.19",
  "...": "..."
}

Then run composer update. Once that’s done, you should be able to change your preview target URL back to about#jobs and remove your scrolling JS.

[proimage]

Hmm. I've tried it, and while it does seem to make the page jump to the indicated anchor, there's still the issue of the page jumping back up to the top within seconds, if not immediately. :-/

I've commented-out all JS on the site to make sure it's not being caused by that, but it doesn't fix the issue.

Not sure if it helps any, but in the console, there's a warning logged about non-unique IDs:

redactor.js:888 [Violation] Added non-passive event listener to a scroll-blocking 'touchstart' event. Consider marking event handler as 'passive' to make the page more responsive. See https://www.chromestatus.com/feature/5745543795965952
(anonymous) @ redactor.js:888
each @ redactor.js:245
on @ redactor.js:879
_loop @ redactor.js:11048
_init @ redactor.js:11033
init @ redactor.js:10779
$R.create @ redactor.js:1502
_buildEvents @ redactor.js:10613
start @ redactor.js:10516
callInstanceMethod @ redactor.js:2369
_startStop @ redactor.js:10365
onstart @ redactor.js:10333
callMessageHandler @ redactor.js:2257
broadcast @ redactor.js:2276
start @ redactor.js:2118
App @ redactor.js:2110
RedactorApp @ redactor.js:1400
jQuery.fn.redactor @ redactor.js:1379
initRedactor @ RedactorInput.js:110
init @ RedactorInput.js:94
constructor @ garnish.js:768
s.constructor @ garnish.js:40
s.constructor @ garnish.js:40
(anonymous) @ 150-project-manager:756
e @ jquery.js:3557
t @ jquery.js:3625
150-project-manager?draftId=35:1 [DOM] Found 10 elements with non-unique id #: (More info: https://goo.gl/9p2vKq)

...and then it proceeds to list all the inputs of the Craft CP edit entry form.

[brandonkelly]

That should be fixed now as well. Swap over to commit 7846a406ec0016aa78e937dd54a78c583e1f93dc in composer.json and run composer update again, and let me know if that helps.

[proimage]

Still jumping to the top after a second or three, unfortunately.

I've again commented out all site JS to make sure it's not anything non-Craft interfering, I've cleared template caches and compiled templates, and I've verified that when using "Share" instead of "Live Preview", the page scrolls to the intended anchor on the page and remains there.

[brandonkelly]

Hm, must still be a bug there but not really sure what else it could be. For context, the anchor should only really be applied the first time you open Live Preview; after that, each time the content changes, Craft should be capturing the preview frame’s current scroll position, then reloading the iframe, then reapplying the previous scroll position on window load.

[brandonkelly]

Also worth mentioning – maintaining the scroll position between iframe refreshes is only possible if the preview target’s URL is using the same host name as the main control panel request. Otherwise cross-domain restrictions prevent Craft from accessing/updating the iframe’s scroll position.

[proimage]

Yeah, it's properly maintaining the scroll position after the initial load. It's just that initial load where it's jumping to the top after the page was already scrolled to the correct position.

Would having backend access help you troubleshoot this?

[brandonkelly]

It's just that initial load where it's jumping to the top after the page was already scrolled to the correct position.

Ahhh, I didn’t realize that it was happening on the initial load. Should definitely be fixed now. Swap over to commit bd226b5e6f8bb07de2687e03a09a91d18affbaa7 in composer.json and run composer update.

[proimage]

That did it! You rock. :)

[brandonkelly]

Awesome! We just released 3.3.20 and 3.4.0-RC1 with these fixes.