Bugzilla

My testcase dispatches ScrollTo syncrhonously, too. They trigger a call to ScrollTo with nsIScrollableFrame::INSTANT, and I think that's the key thing here for the making the scrolling happen synchronously, via this check:
https://searchfox.org/mozilla-central/rev/2c912888e3b7ae4baf161d98d7a01434f31830aa/layout/generic/nsGfxScrollFrame.cpp#2259-2263

That flag makes us complete the scroll right away -- though any scroll-triggered JS still happens in a delayed way via PostScrollEvent, as I discussed above, which is why my testcase doesn't explode.

(Perhaps SCROLL_SYNCHRONOUS is just one way of getting that ::INSTANT flag to be set. I'm not sure. In any case, though, even though the scroll itself is sync, the scroll **event** is async in the sense that its handler's JS doesn't get run immediately during the C++ ScrollTo call.)

Anyway -- the code-comments about PresShell-destruction-during-scrolling seem to date back to this comment and its attachment: bug 898871 comment 2 -- and the attachment there does seem to have PresShell destruction during ScrollTo (though it's from ~7 years ago so things may have changed) Anyway, hopefully Mats remembers enough context around that bug to be able to weigh in here.

My testcase dispatches ScrollTo synchronously, too. It triggers a call to ScrollTo with nsIScrollableFrame::INSTANT, and I think that's the key thing here for the making the scrolling happen synchronously, via this check:
https://searchfox.org/mozilla-central/rev/2c912888e3b7ae4baf161d98d7a01434f31830aa/layout/generic/nsGfxScrollFrame.cpp#2259-2263

That flag makes us complete the scroll right away -- though any scroll-triggered JS still happens in a delayed way (which I hand-wavily referred to as "async-ness") via "PostScrollEvent()", as I discussed above, which is why my testcase doesn't explode.  The scroll itself is still sync, though.

(Perhaps SCROLL_SYNCHRONOUS is just one way of getting that ::INSTANT flag to be set. I'm not sure. In any case, though, even though the scroll itself is sync, the scroll **event** is async in the sense that its handler's JS doesn't get run immediately during the C++ ScrollTo call.)

Anyway -- the code-comments about PresShell-destruction-during-scrolling seem to date back to this comment and its attachment: bug 898871 comment 2 -- and the attachment there does seem to have PresShell destruction during ScrollTo (though it's from ~7 years ago so things may have changed) Anyway, hopefully Mats remembers enough context around that bug to be able to weigh in here.

My testcase dispatches ScrollTo synchronously, too. It triggers a call to ScrollTo with nsIScrollableFrame::INSTANT, and I think that's the key thing here for making the scrolling happen synchronously, via this check:
https://searchfox.org/mozilla-central/rev/2c912888e3b7ae4baf161d98d7a01434f31830aa/layout/generic/nsGfxScrollFrame.cpp#2259-2263

That flag makes us complete the scroll right away -- though any scroll-triggered JS still happens in a delayed way (which I hand-wavily referred to as "async-ness") via "PostScrollEvent()", as I discussed above, which is why my testcase doesn't explode.  The scroll itself is still sync, though.

(Perhaps SCROLL_SYNCHRONOUS is just one way of getting that ::INSTANT flag to be set. I'm not sure. In any case, though, even though the scroll itself is sync, the scroll **event** is async in the sense that its handler's JS doesn't get run immediately during the C++ ScrollTo call.)

Anyway -- the code-comments about PresShell-destruction-during-scrolling seem to date back to this comment and its attachment: bug 898871 comment 2 -- and the attachment there does seem to have PresShell destruction during ScrollTo (though it's from ~7 years ago so things may have changed) Anyway, hopefully Mats remembers enough context around that bug to be able to weigh in here.

My testcase dispatches ScrollTo synchronously, too. It triggers a call to ScrollTo with nsIScrollableFrame::INSTANT, and I think that's the key thing here for making the scrolling happen synchronously, via this check:
https://searchfox.org/mozilla-central/rev/2c912888e3b7ae4baf161d98d7a01434f31830aa/layout/generic/nsGfxScrollFrame.cpp#2259-2263

That flag makes us complete the scroll right away -- though any scroll-triggered JS still happens in a delayed way (which I hand-wavily referred to as "async-ness") via "PostScrollEvent()", as I discussed above, which is why my testcase doesn't explode.  The scroll itself is still sync, though.

(Perhaps SCROLL_SYNCHRONOUS is just one way of getting that ::INSTANT flag to be set. I'm not sure. In any case, though, even though the scroll itself is sync, the scroll **event** is async in the sense that its handler's JS doesn't get run immediately during the C++ ScrollTo call.)

Anyway -- the code-comments about PresShell-destruction-during-scrolling seem to date back to this comment and its attachment: bug 898871 comment 2 -- and the attachment there does seem to have PresShell destruction during ScrollTo (though it's from ~6 years ago so things may have changed) Anyway, hopefully Mats remembers enough context around that bug to be able to weigh in here.

My testcase dispatches ScrollTo synchronously, too. It triggers a call to ScrollTo with nsIScrollableFrame::INSTANT, and I think that's the key thing here for making the scrolling happen synchronously, via this check:
https://searchfox.org/mozilla-central/rev/2c912888e3b7ae4baf161d98d7a01434f31830aa/layout/generic/nsGfxScrollFrame.cpp#2259-2263

That flag makes us complete the scroll right away -- though any scroll-triggered JS still happens in a delayed way (which I hand-wavily referred to as "async-ness") via "PostScrollEvent()", as I discussed above, which is why my testcase doesn't explode.  The scroll itself is still sync, though.

(Perhaps SCROLL_SYNCHRONOUS is just one way of getting that ::INSTANT flag to be set. I'm not sure. In any case, though, even though the scroll itself is sync, the scroll **event** is async in the sense that its handler's JS doesn't get run immediately during the C++ ScrollTo call, based on my observations during my debugging session just now.)

Anyway -- the code-comments about PresShell-destruction-during-scrolling seem to date back to this comment and its attachment: bug 898871 comment 2 -- and the attachment there does seem to have PresShell destruction during ScrollTo (though it's from ~6 years ago so things may have changed) Anyway, hopefully Mats remembers enough context around that bug to be able to weigh in here.

My testcase dispatches ScrollTo synchronously, too. It triggers a call to ScrollTo with nsIScrollableFrame::INSTANT, and I think that's the key thing here for making the scrolling happen synchronously, via this check:
https://searchfox.org/mozilla-central/rev/2c912888e3b7ae4baf161d98d7a01434f31830aa/layout/generic/nsGfxScrollFrame.cpp#2259-2263

That flag makes us complete the scroll right away -- though any scroll-triggered JS still happens in a delayed way (which I hand-wavily referred to as "async-ness") via "PostScrollEvent()", as I discussed above, which is why my testcase doesn't explode.  The scroll itself is still sync, though.

(Perhaps SCROLL_SYNCHRONOUS is just one way of getting that ::INSTANT flag to be set. I'm not sure. In any case, though, even though the scroll itself is sync, the scroll **event** is async in the sense that its handler's JS doesn't get run immediately during the C++ ScrollTo call, based on my observations during my debugging session just now.)

Anyway -- the code-comments about PresShell-destruction-during-scrolling seem to date back to this comment and its attachment: bug 898871 comment 2 -- and the attachment there does seem to have PresShell destruction during ScrollTo (though it's from ~6 years ago so things may have changed, e.g. the patches that landed as part of that old bug). Anyway, hopefully Mats remembers enough context around that bug to be able to weigh in here.