256773 - Gecko should support highlighting of multiple ranges that are not the selection (multiple styleable selections)

Status: NEW

(Core :: DOM: Selection, enhancement, P5)

Description

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Gecko should support highlighting of multiple DOM ranges that are not the
selection.  This is needed for things that want to highlight terms without
manipulating the page's DOM, e.g., the Find toolbar in Firefox (currently branch
only, ugh!) or the Google toolbar extension.

I'm not exactly sure about the details here, but we may want some sort of API
for associating style with ranges.

Note that this bug is different from bug 73373, which is about having multiple
selections.  However, both may depend on common infrastructure work.

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

If we fixed this, then selection could use it and a lot of special-purpose
selection drawing code could go away.

One obvious approach would be to have a new CSS selector :-moz-range(blah) and
be able to give a range the name "blah"; anything in the range matches the
selector. One problem with that is that *:-moz-range(blah) doesn't match text
nodes, and in fact our code assumes in various places that text nodes are not
individually stylable. We'd have to be very careful about performance impact if
we tried to relax that assumption. But I think we could pull it off if we had an
extension to CSS syntax that matched text nodes and didn't violate any standards.

I think the basic code changes with that approach would have to be:
-- changes to the bounds of named ranges would have to trigger reframes of the
content over which the bounds changed
-- constructing frames for text nodes would have to split frames at named range
boundaries
-- frame construction would have to very efficiently identify the named ranges
applying to content and hand them to the style system at style resolution time
-- we'd have to make sure we resolve style for text nodes when named ranges apply

That'd be a pretty big project.

Comment 2

[Hixie (not reading bugmail)]

::-moz-range(blah) could work like ::-moz-selection, presumably.

Comment 3

[Peter Kasting]

I intend to fix bug 263683 by doing something like this bug but simpler: add a new selection type, much like how inline spellchecking is done.  This doesn't require any of the crazy style system wizardry in comment #1.  I suppose one could provide an API for this if needed.

Comment 4

[Robert O'Callahan (:roc) (email my personal email if necessary)]

A lot of what I wrote in comment #1 was bogus. We already support many selection types; making that indefinitely extensible shouldn't be hard.

pkasting: for your needs, feel free to go ahead and add one more selection type. When that's done, you might have some ideas for how to make it truly extensible :-).

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+2] (away 07/21 - 08/08)]

Any status update for this bug?

Comment 6

[Martijn Wargers (dead)]

It seems to me this is "-- an API for extensible selection types" in list of the items to work on post-1.9.1, that was discussed in the layout meeting at the summit: http://groups.google.com/group/mozilla.dev.tech.layout/browse_thread/thread/3421bf91696f4b08#

Comment 7

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority.

If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.

Comment 8

[Eyal Rozenberg]

Highlighting non-selection ranges on a page would be pretty useful and impactful - at the very least for find results, like the initial comment suggests. Also, for implementing things like the text editor component of IDEs, which have non-selection highlights as well.

... but here I'm not sure enough of the statement above to change the severity myself, so let others chime in or do it.