bug(cdk/overlay): OverlayRef.outsidePointerEvents() should not emit with mousedown inside overlay and mouseup outside it

[kyubisation]

Reproduction

Use StackBlitz to reproduce your issue:
https://stackblitz.com/edit/components-issue-iikzo4?file=src%2Fmain.ts

Steps to reproduce:

1. Click open to open overlay
2. Mousedown inside the overlay, move mouse outside overlay and release click

Expected Behavior

OverlayRef.outsidePointerEvents() does not emit, since the mouse down did originate inside the overlay.
This is useful in scenarios where users want to mark text inside and overlay and copy it, but might move the cursor outside the overlay.

Actual Behavior

OverlayRef.outsidePointerEvents() emits (see console)

Additional notes

I implemented a workaround by replacing the 'click' event with the 'mousedown'; See overlay-outside-click-dispatcher.service.ts and main.ts:37-42
It is also certainly possible to implement a workaround that does not rely on outsidePointerEvents(), but it would be far easier to use it.

Unfortunately I don't know whether the current behavior is intentional by the components team or merely an oversight.

Environment

• Angular: 12.2.5
• CDK/Material: 12.2.5
• Browser(s): Chrome
• Operating System (e.g. Windows, macOS, Ubuntu): Windows

[crisbeto]

The issue comes from the fact that we listen for click events at the body. I don't think that mousedown is a valid solution, because it won't account for touch devices.

[kyubisation]

Would additionally registering touchstart work?
This might cause the event handler to be called twice, depending on circumstances, but that should not be a problem.

[crisbeto]

I think that we could potentially use pointer events.

[kyubisation]

pointerdown seems to work with the above example.
However, I am limited in regard to testing devices.
May I create a PR? Or would you like to deal with this in a different way?

[crisbeto]

Feel free to send a PR, but I expect that this will be difficult to land in Google, because people's tests will have to be updated to dispatch the correct event.

[kyubisation]

Ah, I see. Yes, that is a potential problem.
Nevertheless, I will create a PR for this, hopefully this week.
Is there any way to test that against the internal Google code base, without breaking the projects? (I'm not directly familiar with the Google monorepo setup.)
I was thinking about creating an automatic migration, but I don't think it's (easily) possible to detect this exact scenario.

[crisbeto]

We won't merge the PR unless it passes all of the internal checks, but I was pointing it out because it could stay open for a long time.

[kyubisation]

That's understandable.
I'll still try to provide the PR and we will try to find a workaround for our use case for the moment.

[kyubisation]

Maybe a naive question; the CDK already provides/uses _isTestEnvironment for the overlay container. Would it be an option to additionally register the click event in a test environment?

[crisbeto]

We generally try not to have drastically different behavior between tests and the real component. The _isTestEnvironment is used in two very specific cases that wouldn't have an effect on the actual application.

[kyubisation]

Yeah, that's reasonable. It was a long shot.