The default bug view has changed. See this FAQ.

remove Navigator.taintEnabled()

REOPENED

Status

()

Core
DOM
REOPENED
6 years ago
a year ago

People

(Reporter: gal, Assigned: Matheus Kerschbaum)

Tracking

({addon-compat, dev-doc-complete, site-compat})

Trunk
addon-compat, dev-doc-complete, site-compat
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -

Firefox Tracking Flags

(firefox9+, firefox10+, firefox11+, firefox12-)

Details

(Whiteboard: [qa-])

Attachments

(4 attachments)

(Reporter)

Description

6 years ago
It returns false and has been unused in probably a decade.
(Assignee)

Comment 1

6 years ago
Created attachment 553991 [details] [diff] [review]
patch
Attachment #553991 - Flags: review?(bzbarsky)

Updated

6 years ago
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
(Reporter)

Comment 3

6 years ago
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+
(Assignee)

Updated

6 years ago
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)
http://hg.mozilla.org/integration/mozilla-inbound/rev/857f058efa56
Keywords: checkin-needed
Whiteboard: [inbound]
Target Milestone: --- → mozilla9
http://hg.mozilla.org/mozilla-central/rev/857f058efa56
Status: ASSIGNED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Docs updated.
Keywords: dev-doc-needed → dev-doc-complete

Updated

6 years ago
Depends on: 683151
And yet some scripts use it, apparently for browser detection.
Keywords: addon-compat

Updated

6 years ago
Depends on: 695337

Comment 10

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

Comment 11

6 years ago
The release calendar says "Mozilla 9".
Adding "dev-doc-needed" keyword to clarify.
Keywords: dev-doc-complete → dev-doc-needed
Note moved to Firefox 9 for developers.
Keywords: dev-doc-needed → dev-doc-complete

Comment 13

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

Updated

6 years ago
tracking-firefox9: --- → ?
(Reporter)

Comment 14

6 years ago
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.

Comment 15

6 years ago
> 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".

Comment 17

6 years ago
> 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.

Updated

5 years ago
status-firefox9: --- → fixed
tracking-firefox9: ? → +
Code cleanup, QA doesn't need to verify this fix.
Whiteboard: [qa-]

Updated

5 years ago
Depends on: 711955

Comment 20

5 years ago
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.

Comment 21

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

Comment 22

5 years ago
> At least jquery 1.6.2 uses  navigator.taintEnabled

That was wrong. It is "jQuery UI 1.8.4"

Updated

5 years ago
Depends on: 712805

Comment 23

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

Comment 24

5 years ago
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 → ---
(Reporter)

Comment 25

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

Comment 26

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

Updated

5 years ago
tracking-firefox10: --- → ?
tracking-firefox11: --- → ?
(Reporter)

Updated

5 years ago
status-firefox9: fixed → ---
tracking-firefox9: + → ?

Comment 27

5 years ago
(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

Comment 28

5 years ago
(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

Updated

5 years ago
tracking-firefox10: ? → +
tracking-firefox11: ? → +
tracking-firefox9: ? → +
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.

Updated

5 years ago
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.
Created attachment 583959 [details] [diff] [review]
backout patch
Don't we want to add a warning?

Comment 37

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

Updated

5 years ago
Keywords: #relman/triage/defer-to-group

Comment 38

5 years ago
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 40

5 years ago
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
Created attachment 584865 [details] [diff] [review]
for aurora
Created attachment 584866 [details] [diff] [review]
for beta

Comment 46

5 years ago
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.

Updated

5 years ago
Depends on: 714740

Comment 51

5 years ago
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?
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.

Updated

5 years ago
Depends on: 717558

Updated

5 years ago
Depends on: 719322

Updated

5 years ago
status-firefox11: --- → fixed
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.
tracking-firefox12: --- → +
Depends on: 726091
We should back this out of Aurora 12.

Not sure about m-c.

Updated

5 years ago
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.
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
status-firefox11: fixed → ---
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.
Backout merged:
https://hg.mozilla.org/mozilla-central/rev/db122c1048d7
[Triage Comment]
Thanks for backing out, no longer tracking for 12.
tracking-firefox12: + → -
(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".

Comment 73

2 years ago
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.

Comment 74

2 years ago
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.
Comment hidden (obsolete)
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)
You need to log in before you can comment on or make changes to this bug.