B is already the current behaviour for middle click and autoscroll, so that would seem consistent to me.

doesn't the OS send back/forward command to the browser in this case, so there isn't really much pointer events related happening? (I should re-check the implementation.)

Chrome gets regular mouse events from OS but back/forward button presses are not forwarded to the content layer.

@smaug---- I believe on Windows you get a XBUTTON event if you don't indicate it is handled then it will send you an APPCOMMAND. Chrome doesn't follow this mode for context menus and I'm proposing Chrome doesn't follow it for these buttons either. This would be similar to how it works on X11.

See https://msdn.microsoft.com/en-us/library/windows/desktop/ms645601(v=vs.85).aspx#_win32_XBUTTONs

Where should the default action occur. I agree with that option B is the less likely to cause the context menu issues all over again.

I can't test current behavior right now but IIRC the default action of left click happens on button up rather than button down, which conceptually makes more sense to me given that just pushing the button down doesn't necessarily mean that that alone is the expected to do anything, I may push the button down, do a move operation followed by an eventual button up as opposed to actually clicking. Same argument could be had for X1 and X2, even if those are of course far less commonly used buttons...

In general there isn't really consistency when default handling of mouse "actions" happens.
contextmenu for example is platform specific. On Windows it happens on mouseup, elsewhere it is mousedown. At least web extension authors prefer the Windows model.
If default action for pointerdown [buttons 4 or 5] was navigation, pointerup would easily end up to a different page (especially on browsers which have bfcache). So perhaps default action on *up would be better.
...but I was told that at least on Linux default action happens on button down.
And on Win7 button up, on FF and IE

Personally I'd prefer to make this a default action of the auxclick as opposed to mouseup but I guess there are situations that the auxclick doesn't get dispatched? like if the clicked node is removed from the tree and is no longer connected to the document? Perhaps we do want that behavior?

Navigation being a default action in pointerdown or pointerup narrows down the "scope" of canceling navigations, which could be better in terms of not breaking current users' expectations. Otherwise, navigation would be cancelled through canceling any of {pointerdown, pointerup, auxclick}.

Between pointerdown and pointerup, pointerup seems a safer choice because it's perhaps reasonable to assume that canceling pointerdown is more common than canceling pointerup.

Do we have any data on how popular "forward/back buttons for navigation" is? Or what fraction of websites cancel pointerup events? If the product of these two numbers is small, the change should be safe.

I think we need to update the UIEvent spec to contain these button definitions. And I don't see why putting it on pointerup is any better than mouseup. Cancelling the pointerup will still prevent the default behavior.

@dtapuska mentions the UIEvent spec...is this a case where we can/should defer decisions here to that spec (i.e. not something to define directly in PE)?

Discussed in PEWG today. Decided to close this for now, as this feels out of scope purely for PE. There's inconsistency at the moment between platforms on when things happen when these buttons are pressed (on the down, or on the up), and they don't currently fire any other events like mouse events(?). So this needs to be discussed more fundamentally first (in UI Events?). If something comes from discussion there, we can revisit to see if events should be pointer events or not (or some more high-level abstract event like contextmenu)