This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13974 - Allow Selections to be cloned, saved, etc.
Summary: Allow Selections to be cloned, saved, etc.
Status: NEW
Alias: None
Product: WebAppsWG
Classification: Unclassified
Component: HISTORICAL - Selection API (show other bugs)
Version: unspecified
Hardware: All All
: P2 enhancement
Target Milestone: ---
Assignee: Ryosuke Niwa
QA Contact: public-webapps-bugzilla
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-30 20:28 UTC by Aryeh Gregor
Modified: 2014-04-21 21:14 UTC (History)
5 users (show)

See Also:

Attachments

Description Aryeh Gregor 2011-08-30 20:28:13 UTC 
Currently there's exactly one Selection in existence per Document.  It would be useful to allow authors to create additional selections that don't correspond to the user-visible one.  They could then use methods like modify() on it, we could let them use execCommand() on it, etc.  We could also let them save and restore the selection this way, together with all its associated info (at least direction).

Specifically, we might want Selection.cloneSelection(), document.newSelection(), and document.replaceSelection() or something like that.
Comment 1 Ryosuke Niwa 2011-08-30 20:35:11 UTC 
We need to decide whether cloned selection should be updated upon DOM mutations like the one attached to the document/window.
Comment 2 Aryeh Gregor 2011-08-30 21:03:00 UTC 
Per spec, a Selection is just a collection of Ranges, so the constituent Ranges will be updated and therefore the Selection will be too.  WebKit doesn't behave this way, but I think this is just a WebKit bug and it needs to be fixed sooner or later.  IE and Gecko treat Selections this way, and WebKit's behavior is far more complicated, so we want to stick to the IE/Gecko way.

We discussed the possibility of wanting to save a Selection without the Ranges changing, though, for undo/redo.  I think if you don't want the Ranges to change, you should just save the boundary points, you don't need an actual Selection object.
Comment 3 Anne 2011-08-31 06:46:48 UTC 
Maybe turn it into a constructor as we are doing elsewhere?
Comment 4 Ryosuke Niwa 2011-08-31 06:56:12 UTC 
(In reply to comment #3)
> Maybe turn it into a constructor as we are doing elsewhere?

But a selection needs to be owned by some document though.
Comment 5 Anne 2011-08-31 07:11:40 UTC 
Each global object has an associated Document object so that should be easy enough to do. XMLHttpRequest has the same.
Comment 6 Aryeh Gregor 2011-09-22 19:31:36 UTC 
Moving Selection-related bugs to editing: see bug 14248, bug 14252.
Comment 7 Ben Peters 2014-04-21 21:14:37 UTC 
Moving to Selection API component.