On 2016/12/17 2:32, Ehsan Akhgari wrote:
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...
My original idea was, to stop supporting multiple selection in editor
completely. I.e., users cannot add selection range by mouse operation
nor authors cannot add range like other browsers.
However, indeed, if user edits table, multiple selection might be
useful. Hmm...
* 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'm talking about only nsISelectionController::SELECTION_NORMAL. Other
selections need multiple selection.
The reason why our editor code becomes complicated is, multiple normal
selection ranges become "edit targets". For example, when you type a
character when there are multiple selection ranges, current editor
removes all ranges first. Then, inserts the character at first or last
range (I forgot which range is focused range).
At this time, we need to create loop for deleting all selection ranges,
but the ranges may be changed/removed during handling other selection
ranges. We don't have any spec how do we behave in such case.
I think we should probably ask other browser vendors about this again so
that we can plan our future here better.
I agree.
--
Masayuki Nakano <masay...@d-toybox.com>
Manager, Internationalization, Mozilla Japan.
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
