:Ms2ger (he/him; ⌚ UTC+1/+2) Reporter
	Description • 9 years ago

We might want to warn first.

	Boris Zbarsky [:bzbarsky]
	Comment 1 • 9 years ago

This is not very viable anytime in the foreseeable future due to the slow W3C action on this API and the bikeshedding that was involved.

For example, jQuery versions before 2.1.1 and 1.11.1 have code like this:

	if ( (support.matchesSelector = rnative.test( (matches = docElem.webkitMatchesSelector ||
		docElem.mozMatchesSelector ||
		docElem.oMatchesSelector ||
		docElem.msMatchesSelector) )) ) {

and will fall back to something slower if none of those are defined.  So until all sites using jQuery update to 2.1.1/1.11.1 or newer, we're sort of stuck with mozMatchesSelector.

Adding the warning might help, since at least all sites using the old library versions will warn....

	Mike Taylor [:miketaylr]
	Comment 2 • 9 years ago

webkitMatchesSelector is also very popular, foolip has opened an issue on the compat spec for it. Blink won't be removing it for a very long time, if ever: https://github.com/whatwg/compat/issues/3

	Boris Zbarsky [:bzbarsky]
	Comment 3 • 9 years ago

Once bug 1216193 lands, we can probably do this.  Just need to remove chrome/extension uses....

	Mike Taylor [:miketaylr]
	Comment 4 • 9 years ago

I'll write patches for the chrome/extension uses, there aren't that many.

	Kohei Yoshino [:kohei]
	Comment 5 • 9 years ago

Posted the site compatibility doc: https://www.fxsitecompat.com/en-US/docs/2015/element-mozmatchesselector-will-be-removed/

	ExE Boss
	Comment 6 • 6 years ago

(In reply to Mike Taylor [:miketaylr] from comment #4)
> (In reply to Boris Zbarsky [:bz] from comment #3)
> > Once bug 1216193 lands, we can probably do this.
> > Just need to remove chrome/extension uses....
> 
> I'll write patches for the chrome/extension uses, there aren't that many.

I found this last remaining non‑test non-third party library instance by using DXR Search¹:
- https://dxr.mozilla.org/mozilla-central/source/browser/base/content/browser-places.js#175

Also, now that legacy extensions are unsupported, I don’t think we need to worry about breaking those.

---------

¹ https://dxr.mozilla.org/mozilla-central/search?q=mozMatchesSelector&redirect=false

	Boris Zbarsky [:bzbarsky]
	Comment 7 • 6 years ago

> I found this last remaining non‑test non-third party library instance by using DXR Search

We need to fix the test ones too, of course.  But it's not a big deal.

> Also, now that legacy extensions are unsupported, I don’t think we need to worry about breaking those.

Unfortunately, the API is exposed to webextensions, right?  Do we have a way to check for uses in those?

	ExE Boss
	Comment 8 • 6 years ago

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] (no decent commit message means r-) from comment #7)
> > Also, now that legacy extensions are unsupported, I don’t think we need to worry about breaking those.
> 
> Unfortunately, the API is exposed to webextensions, right?

But WebExtensions have had access to the unprefixed `Element.matches(…)` ever since they were first implemented in Firefox (`Element.matches(…)` was released in Firefox 34, and WebExtensions have began being implemented in Firefox 42, and released in Firefox 48, which puts them in a different situation than legacy extensions)

> Do we have a way to check for uses in those?

That, I don’t really know, but any WebExtensions not using the unprefixed versions are doing things wrong.

---------

# See also:
- https://developer.mozilla.org/docs/Web/API/Element/matches#Browser_compatibility

	Boris Zbarsky [:bzbarsky]
	Comment 9 • 6 years ago

Right, but doing things wrong doesn't necessarily mean we get to break them.  :(

That said, we could plausibly restrict to webextension scopes if needed.

	Mike Taylor [:miketaylr]
	Comment 10 • 6 years ago

Guess I missed that one(In reply to ExE Boss from comment #6)
> (In reply to Mike Taylor [:miketaylr] from comment #4)
> > (In reply to Boris Zbarsky [:bz] from comment #3)
> > > Once bug 1216193 lands, we can probably do this.
> > > Just need to remove chrome/extension uses....
> > 
> > I'll write patches for the chrome/extension uses, there aren't that many.
> 
> I found this last remaining non‑test non-third party library instance by
> using DXR Search¹:
> -
> https://dxr.mozilla.org/mozilla-central/source/browser/base/content/browser-
> places.js#175

Looks like that was added 1+ years after my comment:

https://searchfox.org/mozilla-central/diff/fdfcbce1e7c49dd3bbf55f6532241824897f60f9/browser/base/content/browser-places.js#178

I filed Bug 1482498.

	Tim Nguyen :ntim
	Comment 11 • 6 years ago

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] (vacation Aug 16-27) from comment #7)
> > Also, now that legacy extensions are unsupported, I don’t think we need to worry about breaking those.
> 
> Unfortunately, the API is exposed to webextensions, right?  Do we have a way
> to check for uses in those?

You can probably ask the AMO team for this data.