Open Bug 138068 Opened 22 years ago Updated 3 years ago

Impossible to access the selection controller from scripts

Categories

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

defect

Tracking

()

mozilla1.0.1

People

(Reporter: rbs, Unassigned)

Details

nsISelectionController is presently advertised as a scriptable interface:
http://lxr.mozilla.org/seamonkey/source/content/base/public/nsISelectionController.idl

However, only the presentation shell implements this interface, and the catch is
that the presentation shell isn't available/scriptable:
http://lxr.mozilla.org/seamonkey/source/docshell/base/nsIDocShell.idl#161

Actual:
  No way to access nsISelectionController from scripts

Expected:
  A way to access nsISelectionController from scripts

Additional Notes:
1. Doing a LXR search for |selectionController| shows that editor folks are
already caching the selection controller by other means, and passing it to
editor scripts.

2. This bug is affecting bug 49721 / 28809: "View Selection/Partial Source" -
The aim is to allow someone to select a piece of text, and to show the
underlying markup of the selection in the typical syntax highlighted view-source
way. (This could for example allow debugging/capturing live things generated via
JavaScript.) To get the fix requires remapping the selection to the inflated
view-source and scrolling the fabricated view-source selection into view.
However, the default behavior of the selection is to scroll at the focus node,
whereas the most user-friendly behavior in this view-source situtation is to
scroll at the anchor node. This could be done with the available function:
nsISelectionController::scrollSelectionIntoView() -- if there was a way to get
to that selection controller (hmm... paradox: public/scriptable but hidden).
As the saying goes, a picture speaks than a thousand words. Here is a screenshot
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=79770

What happens is that when the resulting view-source selection ends up large, it 
scrolls to the bottom and it isn't quite user-friendly in this situation. I have 
left the following bit of code in the patch in bug 122524 to re-scroll back to 
the top once there is a way to get hold of the selection controller:

+  // show the selection and scroll it into view
+  selection.addRange(range);
+  // the default behavior of the selection is to scroll at the end of
+  // the selection, whereas in this situation, it is more user-friendly
+  // to scroll at the beginning (XXXrbs revisit once bug 138068 is fixed)
+  // var selectionController = getBrowser().docShell.selectionController;
+  // if (selectionController)
+  //   selectionController.scrollSelectionIntoView(
+  //     selectionController.SELECTION_NORMAL,
+  //     selectionController.SELECTION_ANCHOR_REGION);

[An equivalent effect could have been achieved if there was a way to instruct 
the selection how to proceed upon getting a new range, e.g.,
selection.addRange(range, 
                   @in what is the scrol behavior w.r.t. the newly added
                       range or the selection as a whole); 
But nsISelection is already frozen].
work-around to get going: nsISelectionController inherits from
nsISelectionDisplay, and nsISelectionDisplay is now accessible (from the fix of
bug 133642). So doing the following contorsion allowed me to get that controller:

var iRequestor = getBrowser().docShell.
                 QueryInterface(Components.interfaces.nsIInterfaceRequestor);
if (iRequestor) {
  var display = iRequestor.
                getInterface(Components.interfaces.nsISelectionDisplay);
  if (display) {
    var controller = display.
                    QueryInterface(Components.interfaces.nsISelectionController);
    if (controller)
      controller.scrollSelectionIntoView(controller.SELECTION_NORMAL,
                                         controller.SELECTION_ANCHOR_REGION);
  }
}
does this fix the problem for you?
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0.1
Yep, it fixed the problem:
http://lxr.mozilla.org/seamonkey/source/xpfe/browser/resources/content/viewPartialSource.js#275

You can now see it in action by selecting something on the screen with mixed
tags, and then click on 'View Selection Source' on the context menu to see how
the selection is automatically remapped on the inflated view-source output.

Still, having docShell.getInterface(Components.interfaces.nsISelectionController)
could save others from undue hassle (my contorsion wouldn't have worked if the
back-end implementation wasn't being done by the same concrete class).
Assignee: mjudge → nobody
Status: ASSIGNED → NEW
QA Contact: tpreston → selection

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.

Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.