Closed Bug 679971 Opened 13 years ago Closed 4 years ago

remove Navigator.taintEnabled()

Categories

(Core :: DOM: Core & HTML, defect)

defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox9 + ---
firefox10 + ---
firefox11 + ---
firefox12 - ---

People

(Reporter: gal, Assigned: matjk7)

References

Details

(Keywords: addon-compat, dev-doc-complete, site-compat, Whiteboard: [qa-])

Attachments

(4 files)

It returns false and has been unused in probably a decade.
Attached patch patchSplinter Review
Attachment #553991 - Flags: review?(bzbarsky)
Assignee: nobody → matjk7
Keywords: dev-doc-needed
OS: Mac OS X → All
Hardware: x86 → All
Version: unspecified → Trunk
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.
Attachment #553991 - Flags: review?(bzbarsky) → review+
Keywords: checkin-needed
Sent to try:
http://tbpl.allizom.org/?tree=Try&usebuildbot=1&rev=626e32292fdc

Assuming all green, will push to inbound after :-)
Status: NEW → ASSIGNED
Flags: in-testsuite-
(In case anyone pushes this to inbound before me, the r= needs correcting to =gal, rather than bz)
Target Milestone: --- → mozilla9
http://hg.mozilla.org/mozilla-central/rev/857f058efa56
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Docs updated.
Depends on: 683151
And yet some scripts use it, apparently for browser detection.
Keywords: addon-compat
Depends on: 695337
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.
Whiteboard: [qa-]
Depends on: 711955
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"
Depends on: 712805
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Depends on: 712949
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
Attachment #583959 - Flags: approval-mozilla-beta?
Attachment #583959 - Flags: approval-mozilla-aurora?
(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.
Attachment #583959 - Flags: review?(jst)
Attachment #583959 - Flags: review?(jonas)
Attachment #583959 - Flags: review?(bzbarsky)
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...
Attachment #583959 - Flags: review?(bzbarsky) → review+
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.
Attachment #583959 - Flags: review?(jst)
Attachment #583959 - Flags: review?(jonas)
Attachment #583959 - Flags: review+
(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.
Depends on: 714740
Comment on attachment 583959 [details] [diff] [review]
backout patch

un-breaking some of the web.
Attachment #583959 - Flags: approval-mozilla-beta?
Attachment #583959 - Flags: approval-mozilla-beta+
Attachment #583959 - Flags: approval-mozilla-aurora?
Attachment #583959 - Flags: approval-mozilla-aurora+
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?
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.
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.
Depends on: 717558
Depends on: 719322
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.
Depends on: 726091
We should back this out of Aurora 12.

Not sure about m-c.
Depends on: 732131
(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.
Target Milestone: mozilla9 → ---
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.
[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...
Flags: needinfo?(kohei.yoshino)
Removed the doc.
Flags: needinfo?(kohei.yoshino)
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?
Flags: needinfo?(htsai)
Better to ask a DOM peer or the owner.
Flags: needinfo?(htsai) → needinfo?(peterv)
Component: DOM → DOM: Core & HTML

Unfortunate.

Status: REOPENED → RESOLVED
Closed: 13 years ago4 years ago
Flags: needinfo?(peterv)
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.