Closed Bug 1359157 Opened 3 years ago Closed 3 years ago
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!)?
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.
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.)
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.
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?
I think so
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 firstname.lastname@example.org: https://hg.mozilla.org/integration/autoland/rev/faf1b9f57700 Support Selection.type from spec; r=smaug
I've made sure the support status of this is up to date on: https://developer.mozilla.org/en-US/docs/Web/API/Selection https://developer.mozilla.org/en-US/docs/Web/API/Selection/type And added a note to the Fx57 rel notes: https://developer.mozilla.org/en-US/Firefox/Releases/57#DOM
You need to log in before you can comment on or make changes to this bug.