How to fire HighlightRangePointerEvents for Range/Highlight pairs

[sanketj]

The highlight events explainer (https://github.com/MicrosoftEdge/MSEdgeExplainers/blob/master/highlight/events-explainer.md#multiple-ranges-and-highlightrangegroups) describes two options for firing the HighlightRangePointerEvent.

The first option states that the event is only fired to the Range/HighlightRangeGroup pair with the highest priority. This option seems too restrictive as it means that lower priority highlights will not receive the event even though they are actually 'under' the pointer. Consider a scenario where two different applications are applying highlights to the same piece of content (ex. an extension and a web-based editor). Let's say the extension is performing spellchecking, while the editor is using highlights for find-on-page. Let's also say that the editor's highlight has higher priority. When the highlighted content receives pointer input, the editor would be able to listen for the event on its HighlightRangeGroup and in turn take an action to emphasize the highlighted text (ex. change the background color). However, if the extension also wanted to take an action in response to pointer input (ex. show a popup with spelling suggestions), it would not be able to do so because its highlights have lower priority and would not receive any pointer events.

The second option suggests firing a separate HighlightRangePointerEvent for every Range/HighlightRangeGroup pair. This would work for the example mentioned above, but isn't ideal either. Imagine a slight variation of the above scenario, where both the extension and editor want to show popups in response to pointer input. Since all hit Range/HighlightRangeGroup pairs would receive an event, both the extension and editor would get to show their popups. This could mean that one popup is rendered on top of the other, which may negatively affect the usability and/or look-and-feel of the page.

So it seems we really need a third option that fires the HighlightRangePointerEvent to multiple groups, while also providing a way to coordinate behavior between unrelated highlights. Below are two ideas that seem interesting.

(1) Define a new event path that enables a single HighlightRangePointerEvent to flow through all the hit Range/HighlightRangeGroup pairs in priority order. This would allow higher priority HighlightRangeGroups to call stopPropagation and prevent the event from reaching groups with lower priority.

(2) Define the default action of each HighlightRangePointerEvent to be the generation of the HighlightRangePointerEvent for the next Range/HighlightRangeGroup pair (in descending priority order). This way, a group can call preventDefault and prevent events from reaching subsequent HighlightRangeGroups.

Approach (2) has a potential downside in that it could make it harder to support scenarios like #102 . If we define that calling preventDefault on a HighlightRangePointerEvent will prevent selection, then stopping event flow via preventDefault will end up preventing selection as a side effect (and vice versa). Approach (1) would not have this problem, hence it feels like the preferable option to me.