I don't think we should fire auxclick in that scenario. Browser has taken over the action and not only we don't fire auxclick but also we don't open a link in a new tab. So all related actions with respect to click is going to be hidden. Is there a particular usecase that you need both auto scroll as well as auxclick?

The main concern here is for the web developer that forgets, or simply does not know to implement a handler on the mousedown event to cancel the event.

This leaves that code with an edge-case bug that the poor users can't work-around.

So no, there isn't a use-case that you need both auto-scroll and auxclick, but it would be better for the code to fail by having both events occur, than to completely prevent the auxclick event from firing at all.

Consider that from the developer's point-of-view, the scroll behaviour may arise in situations that could be edge cases (such as a zoomed window).

In the current scenario, the user has no work-around to activate the auxclick behaviour if the container becomes scrollable. In the proposed scenario, the unexpected scrolling behaviour is an annoyance.

Let us not forget, the user may not make the connection between the appearance of the scroll behaviour and the expected middle-click behaviour not functioning, and there's no guarantee that aforementioned web developer will test on the exact same screen layout that the "bug" is encountered.

So this is not an argument about how the browser should behave in a perfect world, because that's assuming every developer has absolute knowledge of behavioural disparities between browsers. Rather, this is an argument for practicality.

I'm cc'ing bokan@ here as he knows more about the auto scroll feature. bokan@ do you know whether we can do anything about this?

However, in general I cannot buy what you are saying.
The same argument you are making holds for virtually every other browser behavior. For example if a developer forgets to have a dragstart handler and preventDefault on that user may start drag and as a result you are going to miss all the mouse events for the rest of the duration of the drag. The same for normal scrolling say with touch. If they forget to prevent default touchstart (or set a touch-action:none) browser starts scrolling and you are not going to get the rest of the pointerevent stream for that finger.

I totally agree though that in the case of scrollable pages it might be more invisible to the development team while testing the feature. One thing we try to

I agree with nzolghadr@ here. It doesn't make much sense to activate both autoscrolling (what you call omniscroll) and execute an auxclick action - it should do one or the other. You could argue that we shouldn't activate autoscroll if there's an auxclick handler registered but that might be surprising and I'm not sure we'd prioritize something like that.

IMHO, if the container shouldn't be scrollable, the page should specify that using overflow: hidden.