Re: [w3c/editing] Firefox: event.getTargetRanges() in beforeinput not consistent with window.getSelection() (Issue #493)

michael left a comment (w3c/editing#493)

> I don't think this is a bug of Firefox unless it outputs different range than actually deleted later.

Maybe I have some misunderstandings here, but at the onbeforeinput stage, I'd expect only ranges that represent the state before anything was added/deleted etc. This is crucial for me because I "remember" the range at the very start of an input so I can replace that range in my internal model at the very end of the input (in case of composition inputs, a lot can change in the process).

> If they should always be same as Selection, why does getTargetRanges() is required for beforeinput? The answer should be that the range should be extended to the range where actually deleted soon. So, they can be different.

From my understanding they are the same almost all of the time. But one case I'm aware of where they differ is on Samsung-Android. E.g. when you put the cursor at the end of a word, a composition ist started that spans that whole word (the word becomes underlined). So when a new character is inserted I need to replace that range with the new input, hence in my editor always relies on getTargetRanges() (when available) instead of the selection.

Here's the relevant code in my editor for context: https://github.com/michael/svedit/blob/7c7d4671f5908949d0461044ce9cf58be99e77e2/src/lib/Svedit.svelte#L94-L99

> I think you wrote opposite result. Firefox selects all things of the editing host and getTargetReanges() return shrunken range to leaves if there are.

True, in the repro it's correct, but I confused the order in the issue (now fixed).

Thank you @masayuki-nakano for the explanation. While I don't understand all the details, I agree this might technically not be a bug. However it is an inconsistency compared to the other browsers (Chrome/Safari) that return the text node for `event.getTargetRanges()[0].startContainer` in the scenario of my repro. My editor implementation currently relies on that assumption, and hence this leads to broken editing behavior on FF.

@johanneswilm I guess we need to determine what the correct output of getTargetRanges() should be in this scenario? And if it's not clearly defined refine the spec?

-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/editing/issues/493#issuecomment-3651477866
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/editing/issues/493/3651477866@github.com>