This might be a load race, possibly due to how sessionstore reloads tabs? I just did the steps in your excellent comment 1 STR and easily reproduced. I then brought up devtools and did: ```document.getElementById('62') <div id="62" class="goto">``` That "goto" thing is our synthetic anchor which is what makes the browser able to jump to the right position including the scrolling position padding (which we can switch to using https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-padding now that 68 is in release). This magic is more essential for cases like "#68-70" where the browser could never do that even if we changed our anchors so that the line numbers were "68" instead of "l68". So the question is why we're not jumping to that anchor. I'd guess we're creating the div too late. Or sessionstore is betraying us. I'm cc'ing bz for his interest and wisdom in this scenario previously in case there's something more subtle we should know about with how the anchor seeking works.
Bug 1561900 Comment 2 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
This might be a load race, possibly due to how sessionstore reloads tabs? I just did the steps in your excellent comment 1 STR and easily reproduced. I then brought up devtools and did: ``` document.getElementById('62') <div id="62" class="goto"> ``` That "goto" thing is our synthetic anchor which is what makes the browser able to jump to the right position including the scrolling position padding (which we can switch to using https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-padding now that 68 is in release). This magic is more essential for cases like "#68-70" where the browser could never do that even if we changed our anchors so that the line numbers were "68" instead of "l68". So the question is why we're not jumping to that anchor. I'd guess we're creating the div too late. Or sessionstore is betraying us. I'm cc'ing bz for his interest and wisdom in this scenario previously in case there's something more subtle we should know about with how the anchor seeking works.
This might be a load race, possibly due to how sessionstore reloads tabs? I just did the steps in your excellent comment 1 STR and easily reproduced. I then brought up devtools and did: ``` document.getElementById('62') <div id="62" class="goto"> ``` That "goto" thing is our synthetic anchor which is what makes the browser able to jump to the right position including the scrolling position padding (which we can switch to using https://developer.mozilla.org/en-US/docs/Web/CSS/scroll-padding now that 68 is in release). This magic is more essential for cases like "#68-70" where the browser could never do that even if we changed our anchors so that the line numbers were "68" instead of "l68". So the question is why we're not jumping to that anchor given that the magic does seem to be trying to do the right thing. I'd guess we're creating the div too late. Or sessionstore is betraying us. I'm cc'ing bz for his interest and wisdom in this scenario previously in case there's something more subtle we should know about with how the anchor seeking works.