Open Bug 1722732 Opened 1 year ago

Cleanup the AutoScroll window actor

Categories

(Core :: Panning and Zooming, task)

task

Tracking

()

People

(Reporter: u608768, Unassigned)

References

Details

This came up while working on bug 1718761. This actor is doing more than it needs to and can be simplified.

From https://phabricator.services.mozilla.com/D120766#3924847:

Note that looking at the JS code here naively, I actually don't understand why the code passes browsingContext around between AutoScrollChild and AutoScrollParent. Both actor instances are associated with a single browsing context anyway, which can always be accessed via properties on the actor itself (getting either the child or parent variety of the browsing context - see e.g. https://firefox-source-docs.mozilla.org/dom/ipc/jsactors.html#how-jswindowactors-differ-from-the-frame-message-manager ) - it doesn't need to be passed via messages.

and from https://phabricator.services.mozilla.com/D120766#3932686:

I'm even thinking maybe (almost?) all of this could live in native code, without the need for the JS actors. Looking for instance at what causes calls to stopScroll, https://searchfox.org/mozilla-central/search?q=.stopScroll%28&path=&case=false&regexp=false shows it's either pagehide or a message from the parent, which is tripped by the user clicking. I suspect we could push everything but the initial "is this middle click supposed to initialize autoscroll" and perhaps the final "the user clicked so we should end autoscroll" into native code (ie including the child-side mouse handling once autoscroll is active). Though it also makes me wonder if we should be using pointer capture for autoscroll... anyway. Doesn't all need to happen here.

You need to log in before you can comment on or make changes to this bug.