On Android we are soon enabling touch-dragging following a long-press, which could subtly affect custom context-menu closing behavior in certain websites. We are not exposing any events that didn't exist before but we are changing when these events may fire on some devices/content. This can cause two changes in observable behavior in Chrome for Android:
Elements with a draggable attribute would start responding to touch-drag interaction.
Custom context-menu may co-exist with an ongoing drag.
On mobile we never supported drag-and-drop, so draggable elements (like those in this demo) never really responded to touch-drags. More precisely, we fired neither drag nor dragend events after a dragstart event, and in many cases we couldn’t fire even a dragstart event because a long-press would invoke a modal context menu which blocks all events from the page behind.
This upcoming change would expose correct firing of dragstart, drag and dragend events to the page, and any draggable element would start responding.
The upcoming change would possibly provide an awkward experience on sites that draw a custom context-menu. Certain types of target elements would now receive both dragstart and contextmenu events, so some of these sites would continue to show a custom context-menu while a drag-and-drop is ongoing. But any reasonable custom context-menu is expected to close on a tap outside the menu, and that would be an easy and intuitive “fix” for the user. So in the end, this would feel like a bad UI experience instead of a broken site.
Longer term, we are proposing to enhance custom context-menu support in the Web platform through a new event:
Github discussion: https://github.com/w3c/uievents/issues/309
Integration with popup: https://github.com/openui/open-ui/issues/426
Chrome bug: https://crbug.com/1243718