On 2016-12-15 4:46 AM, Masayuki Nakano wrote: > At investigating selection API behavior, I realized that non-Gecko > engines don't support multiple selection. > > For example, document.getSelection().addRange(somethingNewRange) does > nothing when the selection has a range. > > You can see the behavior with following testcases: > 1. in editable content: https://jsfiddle.net/d_toybox/9Lrs62po/3/ > 2. in static content: https://jsfiddle.net/d_toybox/9Lrs62po/2/ > > Personally, I like the multiple selection feature when I copy a lot of > fragments of a document. However, who needs this feature in editor? > Supporting multiple selection in editor makes our editor code > complicated. For example, when web apps try to make the text content > bold, editor needs to do it at every selection range. If selection is > modified during handling something, loop for selection ranges may cause > crash (I've seen a lot of similar crash bugs). > > So, it might be better to stop supporting multiple selection only in > editor if the feature is not so loved by users. > > I filed a bug for discussing this issue here: > https://bugzilla.mozilla.org/show_bug.cgi?id=1323681
We currently expose selections with multiple ranges at several levels: * The developer facing APIs. As you have noted above, our selection API allows you to construct and examine multi-range selections. This is something that we should fix at some point, since other browser vendors have been very clear that they won't implement this functionality (and I think that's a good idea) so we're not interoperable with them on this front. * The user facing functionality. Currently we expose multi-range selections to the user in the following ways (perhaps among others that I'm missing?): * Table cell selection (by Ctrl/Cmd-clicking on several table cells allows you to select them all) * Mouse based selection (by holding Ctrl/Cmd when selecting something on a page with another selection present) * (and perhaps touch based selection also similarly, but I don't have a device I can test that on) There is at least one good use case for this, which is copying things to the clipboard, but if we decide to keep the user facing functionality, then we should determine what to expose to developers when a multi-range selection is made by users. There are several options, such as only representing the first selection in the range, or the latest (last) one. (I also wonder how many people even know about these ways to create multi-range selections, given how undiscoverable they are! We should probably add telemetry to measure their usage.) * The interactions with the editor, which I definitely agree is a mess. I'm not sure what you specifically mean by not supporting them. Given that they are currently possible to create by the user, we need to handle them _somehow_ in the editor code. I personally think we should drop support for user made multi-range selections over editable regions to guarantee that the editor code never actually hits this case... * Gecko's internal usage of multi-range selections. We use multi-range selections to implement some other selection types, including spellcheck (which we use to mark the misspelled areas to be drawn with the red squiggly line) and find (which we use to mark highlighted areas as the result of using the find bar, which can create a multi-range selection when using the Highlight All mode.) Clearly we can't drop support for what we need to deal with spellcheck selections which are often multi-range. Have you considered this in your plans? I think we should probably ask other browser vendors about this again so that we can plan our future here better. Cheers, Ehsan _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
