It returns false and has been unused in probably a decade.

A decade ago was 2001. Netscape 3's experimental (opt-in via envar) data tainting security model was not carried into Nescape 4, so more like 14 years. /be

Comment on attachment 553991 [details] [diff] [review] patch Stealing. Lets land it early in the cycle and watch for web compatibility regressions.

Sent to try: http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=626e32292fdc Assuming all green, will push to inbound after :-)

(In case anyone pushes this to inbound before me, the r= needs correcting to =gal, rather than bz)

Docs updated.

And yet some scripts use it, apparently for browser detection.

It's documented in https://developer.mozilla.org/en/Firefox_8_for_developers but "Target Milestone" is Mozilla 9. What's right?

The release calendar says "Mozilla 9". Adding "dev-doc-needed" keyword to clarify.

Note moved to Firefox 9 for developers.

This breaks some older MediaWiki installations (bug 695337 and bug 683151). Probably enough to backout for now?!

This is not a high value patch, so I am not opposed to backing out, but it would be nice to retire this and I don't see any way doing that thats not a little bit painful and involves evangelism to get sites to stop using it.

> I don't see any way doing that thats not a little bit painful > and involves evangelism to get sites to stop using it. Add a fat warning, wait some month and remove it then would at least give them a chance to realize it before last-minute. (And would increase probability that old MediaWiki pages had updated anyway meanwhile) Note these bug reports are for Auroa. Would expect much more for Beta and final release.

Our experience is generally that people just ignore the warnings. The only value that they add is us being able to say "hey, we warned you".

> Our experience is generally that people just ignore the warnings I'v seen other opinions (eg bug 585877 comment 23)

Not my experience either; facebook stopped using getAttributeNode shortly after we started to warn about it, for example.

Code cleanup, QA doesn't need to verify this fix.

Why the hell this wasn't this backed out for at least one year or so? It strikes back now: At least jquery 1.6.2 uses navigator.taintEnabled for browser detection, see bug 711955.

[take the tracking-firefox9 flag and stick it on your Christmas tree]

> At least jquery 1.6.2 uses navigator.taintEnabled That was wrong. It is "jQuery UI 1.8.4"

Probably breaks a top 10 page in Poland (http://nk.pl/)

As stupid this is, we might have to punt on this removal considering the web compatibility implications. Shame on jquery, seriously.

I filed http://bugs.jquery.com/ticket/11095 for this.

> Shame on jquery, seriously. The nk.pl case is not jquery UI, might be MooTools (and page breaks completely)

(In reply to Andreas Gal :gal from comment #25) > I filed http://bugs.jquery.com/ticket/11095 for this. The bug is in jquery UI 1.8.4, thats a different library than jquery. Bug tracker is here: http://bugs.jqueryui.com/ Might be fixed in jquery UI 1.8.6

(In reply to j.j. from comment #26) > The nk.pl case is not jquery UI, might be MooTools The browser detection with "taintEnabled()" is not in the MooTools part, it's own code of nk.pl

Is there any possibility for a workaround that can be communicated through evangelism to the top 10 Polish site nk.pl? See bug 712805 for more background.

A simple codesearch query seems to suggest that this is a pretty popular UA sniffing tool unfortunately <http://www.google.com/codesearch#search/&q=navigator.taintEnabled&type=cs>. We could potentially enable checks for existence of this function but prevent scripts from calling it for a while, but I suspect that the required evangelism effort might not justify the gain. :(

the nk.pl has been fixed today, but they're still detecting browsers basing on this attribute. If we can get MooTools and jQuery UI to fix this we should be good. I can't find any other top website that would be affected by this change.

Current MooTools 1.4.2 don't use taintEnabled. Some older version did, though.

If we decide to back this out, some one needs to prepare a patch which has a new interface which nsNavigator implements. The interface would contain only taintEnabled(). That way we don't break any binary addons. The interface name could be hopefully something like nsINavigator_9_0_2. Anyone willing to prepare such patch. (I would do it, but unfortunately I'm in a place with unreliable network connection.)

Another class of sites that get broken due to taintEnabled used as a lame way to distinguish between Gecko and WebKit are pre-1.16 MediaWiki instances such as in bug 695337 and bug 683151. An example of a popular site like this would be www.wikitravel.org.

Don't we want to add a warning?

> are pre-1.16 MediaWiki instances That's the crux with this bug, known since October (see comment 13)

Comment on attachment 583959 [details] [diff] [review] backout patch [Approval Request Comment] Regression caused by (bug #): N/A User impact if declined: Older jquery and mediawiki installations will stay broken Testing completed (on m-c, etc.): Not tested Risk to taking this patch (and alternatives if risky): Doesn't look too risky, adds a new interface to not break binary add-ons

(In reply to Zbigniew Braniecki [:gandalf] from comment #36) > Don't we want to add a warning? I think we do.

Comment on attachment 583959 [details] [diff] [review] backout patch Can we get the backout patch reviewed as well? It isn't a straight backout...

Comment on attachment 583959 [details] [diff] [review] backout patch I don't know who is on vacation.

Oh, hmm, the backout is for 9.0.x, do we want to take it to Aurora/Beta too? For those backing out the original patch should be enough.

Or not quite. I'll upload a patch for Aurora/Beta backout

I think at the very least we want it for beta. We need to figure out what to do / how to kill the property for good (or if it is even worthwhile anymore, that much isn't clear).

Comment on attachment 583959 [details] [diff] [review] backout patch r=me. We should probably try to escalate this to the specs one way or another.... In practice, any UA that sniffs like Gecko or WebKit and does not have this property needs to include some WebKit bugs, so once WebKit fixes those bugs it may have to implement this property as well...

OK, so taintEnabled is back, I take it? As of which release? Is it back in 11 or did it make it back in time for 10?

Comment on attachment 583959 [details] [diff] [review] backout patch r=jst too, and sicking is on vacation IIRC.

(In reply to Ehsan Akhgari [:ehsan] from comment #30) > A simple codesearch query seems to suggest that this is a pretty popular UA > sniffing tool unfortunately > <http://www.google.com/codesearch#search/&q=navigator.taintEnabled&type=cs>. Oddly, properly escaping the regexp wildcard '.' returns around ten times as many hits, instead of fewer (3800 vs. 440). http://www.google.com/codesearch#search/&q=navigator\.taintEnabled plain taintEnabled returns over 600K hits on codesearch. Use it now before Google shuts it down.

Comment on attachment 583959 [details] [diff] [review] backout patch un-breaking some of the web.

I heard that the previous backout patch didn't transplant cleanly to beta. smaug/bz - Could you prepare new patches for aurora/beta? They can be considered pre-approved and landed once ready. Thanks!

The "for beta" patch certainly does apply cleanly to beta. I'll land it soon.

Do we need to create new interfaces for beta/aurora?

https://hg.mozilla.org/releases/mozilla-aurora/rev/2b28a99028ae https://hg.mozilla.org/releases/mozilla-beta/rev/6833fb080f78

Should we back this out from trunk?

Oops, the patches didn't work on branches after all, and it is too late for me to fix. (Fix is trivial). Backing out for now, and I'll land tomorrow fixed patches.

Hopefully better luck this time :) https://hg.mozilla.org/releases/mozilla-beta/rev/582a82656e0c https://hg.mozilla.org/releases/mozilla-aurora/rev/f75d64d28603

I assume given the timestamp this did not make the cut for 10.0b3, will make the cut for 10.0b4?

(In reply to Anthony Hughes, Mozilla QA (irc: ashughes) from comment #59) > I assume given the timestamp this did not make the cut for 10.0b3, will make > the cut for 10.0b4? The fix in Comment 58 will be available in 10.0b4.

From my read of things, this is still present on FF12. What's the plan moving forward? Without outreach, I think we should back this out of m-c/Aurora 12.

We should back this out of Aurora 12. Not sure about m-c.

(In reply to Olli Pettay [:smaug] from comment #56) > Should we back this out from trunk? Olli - can we perform this backout on both Aurora 12 and m-c? I don't think code cleanup like this is worth continuously backing out unless we want to perform outreach to the sites listed in comment#50 soon. Thanks in advance.

Backed out of aurora and beta: https://hg.mozilla.org/releases/mozilla-aurora/rev/f1135f99a0e4 https://hg.mozilla.org/releases/mozilla-beta/rev/49cca9941155 And I went ahead and backed this out of inbound as well, as lame as that is: https://hg.mozilla.org/integration/mozilla-inbound/rev/db122c1048d7

One way forward might be to add a warning any time someone even checks if this function exists. I.e. if someone does if (navigator.taintEnabled) { ... or if ("taintEnabled" in navigator) { ... As well as add telemetry. Then leave it in that state until we see the telemetry dropping "low enough". Not sure if it's worth the effort though.

Yeah, agreed. We could add code in the resolve hook for navigator that would warn in the error console any time someone resolves taintEnabled, should not be hard to do at all.

I would have been happy to see it die, but I'm not sure if this is a battle we should concentrate on. If we don't, though, we do need to get it into a spec. (HTML, I guess.)

(In reply to Ms2ger from comment #67) > I would have been happy to see it die, but I'm not sure if this is a battle > we should concentrate on. If we don't, though, we do need to get it into a > spec. (HTML, I guess.) If that's spec'ed, other browsers will have to implement this empty function. Then, they may be misidentified as Firefox. Spec'ing this will not improve interoperability.

Backout merged: https://hg.mozilla.org/mozilla-central/rev/db122c1048d7

[Triage Comment] Thanks for backing out, no longer tracking for 12.

(In reply to Jonas Sicking (:sicking) from comment #65) > One way forward might be to add a warning any time someone even checks if > this function exists. I.e. if someone does > > if (navigator.taintEnabled) { ... > > or > > if ("taintEnabled" in navigator) { ... > > As well as add telemetry. Then leave it in that state until we see the > telemetry dropping "low enough". > > Not sure if it's worth the effort though. I would really like to see this possible so that we can make informed judgments about other features we might want to drop, such as .isSupported() etc. If we're going to try removing old features that we hope not many pages use, we should have a reliable way of telling whether it's safe, not just wait to break pages and back out.

It is really easy to hook things up to telemetry. See bug 717711 for an example. You have to add something to TelemetryHistograms.h, then add a call to Telemetry::Accumulate somewhere. For this, I'm not sure if you'd want "total times we've ever seen a page with this", or just "have ever seen a page with this during the current telemetry session".

We had a look at implementing navigator.taintEnabled() in Blink but reopened the spec bug instead: https://www.w3.org/Bugs/Public/show_bug.cgi?id=22555#c3 Please help us figure out what the spec should say.

It was proposed to add a warning more than 3 years ago (comment 15, comment 39, comment 71, etc.) Shouldn't it be don now?

Adding a warning naively won't help because people aren't calling the function, just checking that it exists.... We could make this a replaceable attribute instead, and warn in the getter, I guess.

Is the removal actually in progress? If it is removed, please file a bug at https://whatwg.org/newbug so that we can remove it from the HTML spec as well.

I am not aware of any plans to remove it at this time, and I'm not sure why we're bothering with adding it to the compat doc...

Removed the doc.

This is now part of the standards https://html.spec.whatwg.org/multipage/system-state.html#dom-navigator-taintenabled So this should probably be closed now?

Better to ask a DOM peer or the owner.