If you open a named anchor in a new tab, the browser jumps the viewport to the named anchor, then collapses all the codetabs. This makes the document scroll under the viewport as it changes size. Possible solutions: A. grab an named anchor from the url when the collapser starts, then when it finishes, jump to that named anchor again. This approach could lead to some unexpected behavior for the user when the collapser takes sufficient time that they had started scrolling before it finished. So maybe detect if the user has moved since the collapser started; although in that case it will jump anyway, because of the change in the document size. B. Don't lazy load the collapser - do it synchronously.
Fixed it by grabbing the hash from the window.url when the script starts, then scrolling to that hash once it finishes. Leads to some jumpiness when the page loads, but it's subtle, and amidst the rendering going on is not really noticeable in the tests I've run so far.
This fix serendipitously fixes a bug in Firefox behaviour: https://bugzilla.mozilla.org/show_bug.cgi?id=60307 If you open a huge html-single book to a named anchor, Firefox will scroll to the anchor *then* load the images. The result is the jump away from the anchor. It happens so fast that you usually can't see what is occurring. It's a hold-over from 10 years ago when bandwidth was the issue, and on a huge page like that the user would have manually scrolled away a long time ago. Reading through the history, they first had a bug that Firefox waited for the page to load before scrolling, and that took a long time. So they made it scroll immediately on text load. The next complaint was that it lost its place. So they made it scroll twice -once on the page initial load, then after the images loaded. Then they got a complaint that this was random-appearing behaviour when a user had scrolled manually between the text and image loads, so they turned off the second scroll. Chrome doesn't have this behaviour because it scrolls after the page loads - it was born in an age where bandwidth was not such a significant factor. The issue now is when a user does manually scroll while the page is being rewritten. Is there a way to detect if the page has been manually scrolled? If so, we can conditionalize the rejump on that. We're in a similar issue. Bandwidth and image loading is not our constraint, but the processing and rewriting of the DOM. The javascript is asynchronous to not make the page load time increase, however it leads to rewriting of the page while the user is looking at it. We might look at doing some things asynchronously, and others synchronously. Or displaying an overlay while we do intensive recomputation of the page.