Closed Bug 1359157 Opened 7 years ago Closed 7 years ago

Support Selection.type

Categories

(Core :: DOM: Selection, enhancement)

enhancement
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla57
Tracking Status
firefox57 --- fixed

People

(Reporter: ayg, Assigned: ayg)

Details

(Keywords: dev-doc-complete)

Attachments

(1 file)

http://w3c.github.io/selection-api/#dom-selection-type
https://github.com/w3c/selection-api/issues/14

I don't see what the point of it is, but it seems to be implemented more or less interoperably by Chrome, WebKit, and Edge.  There are no tests right now, I'll write some.
Uh-oh, we already have a chrome-only property .type.  What do we do?  Can we rename the chrome-only property to selectionType or something and update all callers?  Or might this be used in extensions, etc.?  Perhaps we can expose the new property only to content and not chrome (confusing!)?
Flags: needinfo?(bugs)
By the way, I submitted tests upstream: https://github.com/w3c/web-platform-tests/pull/5683

Chrome passes all tests, and Edge/WebKit have some failures with non-collapsed selections in invisible content, but they're basically interoperable.
Yeah, I think we need to rename the chrome-only property. Please check also all the addons. If the property is used by many addons, we'll probably need to support first both the old and new name, but use of the old one would warn. And then afterwards remove the old one and add the new .type.
Flags: needinfo?(bugs)
Try run with the .type property removed entirely is green: https://treeherder.mozilla.org/#/jobs?repo=try&revision=92efece1ac90edcfb5faeb55a3d171d9bad1162a

I can't use https://dxr.mozilla.org/addons/source/ to search add-ons, because it just returns an error after a while (I assume timeout).  Anyway, it's hard to search for -- I was trying the regexp /[Ss]elect[a-zA-Z0-9_]*\.type\b/, but it will have lots of false positives and negatives.  In m-c there are no callers except layout/generic/test/frame_selection_underline.xhtml (which didn't show up on try because it's disabled on Linux, oops).

So what do you want to happen here?  Is there a way to make .type behave per spec for content and like the current .type for chrome, with a warning to move to .selectionType or whatever?  (It's not immediately obvious to me how to do this, because the attribute types are different.)
Flags: needinfo?(bugs)
I'm not aware of any sane way to make the type of the interface to be different in chrome vs content.
Using any as the type would be horrible hacky way.

https://dxr.mozilla.org/addons/search?q=selection.type&redirect=false returns some results.
Looks like code tends to expect the spec'ed behavior, meaning that maybe that code will actually break after the change? One would need to look at it closer.
Flags: needinfo?(bugs)
I understand in Firefox 57 we're dropping support for old-style extensions, so that means if try is green this can be landed in 57, correct?
Flags: needinfo?(bugs)
I think so
Flags: needinfo?(bugs)
Comment on attachment 8893401 [details]
Bug 1359157 - Support Selection.type from spec;

https://reviewboard.mozilla.org/r/164516/#review169862
Attachment #8893401 - Flags: review?(bugs) → review+
Assignee: nobody → ayg
Status: NEW → ASSIGNED
Pushed by ayg@aryeh.name:
https://hg.mozilla.org/integration/autoland/rev/faf1b9f57700
Support Selection.type from spec; r=smaug
https://hg.mozilla.org/mozilla-central/rev/faf1b9f57700
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla57
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: