Remove angular.uppercase/lowercase

[Narretz]

What kind of change does this PR introduce? (Bug fix, feature, docs update, ...)
fix/refactor

What is the current behavior? (You can also link to an open issue here)
we expose lowercase/uppercase on the public angular object

Does this PR introduce a breaking change?
yes

Please check if the PR fulfills these requirements

• The commit message follows our guidelines: https://github.com/angular/angular.js/blob/master/CONTRIBUTING.md#commit-message-format
• Tests for the changes have been added (for bug fixes / features)
• Docs have been added / updated (for bug fixes / features)

Other information:

[mgol]

Why keep the service, even as a private one? String.prototype methods should be enough.

[Narretz]

I just noticed that angular.lowercase / uppercase is overwritten with a manual version that handles Turkish i:

angular.js/src/Angular.js

Lines 210 to 232 in 19bc521

	var manualLowercase = function(s) {
	/* eslint-disable no-bitwise */
	return isString(s)
	? s.replace(/[A-Z]/g, function(ch) {return String.fromCharCode(ch.charCodeAt(0) | 32);})
	: s;
	/* eslint-enable */
	};
	var manualUppercase = function(s) {
	/* eslint-disable no-bitwise */
	return isString(s)
	? s.replace(/[a-z]/g, function(ch) {return String.fromCharCode(ch.charCodeAt(0) & ~32);})
	: s;
	/* eslint-enable */
	};
	// String#toLowerCase and String#toUpperCase don't produce correct results in browsers with Turkish
	// locale, for this reason we need to detect this case and redefine lowercase/uppercase methods
	// with correct but slower alternatives. See https://github.com/angular/angular.js/issues/11387
	if ('i' !== 'I'.toLowerCase()) {
	lowercase = manualLowercase;
	uppercase = manualUppercase;
	}

So in core, we use a "safe" version. But we don't want anyone else to use it? I guess we don't want anyone to use the special version when usually the prototype functions are enough.

[mgol]

jQuery doesn't have any logic like that in its lowercasing and we haven't heard any complaints related to Turkish keyboards. Given jQuery's popularity I'd assume this code is no longer needed, especially that ES5 (!) mandates no such differences so I doubt any relatively recent browser would still have whatever issue existed (if it ever has).

I'd remove the "manual" functions as well. This is security-related code, though, so a this requires some consideration, though.

[petebacondarwin]

LGTM - keeping the private methods for the time being.

[Narretz]

K. FWIW, the "problem" still exists in modern browsers: http://plnkr.co/edit/cQHWgcqTLfZZ2LZXQQqG?p=preview
I can't really test toLocaleLowerCase correctly because the browser must be turkish ...

Pete said to keep the private fns for now

[mgol]

@Narretz I don't see a problem in your fiddle. toLowerCase should always work in the same way so the Turkish lower "i" won't be the same as lowercased regular uppercase "I"; that seems expected.

[Narretz]

Hm. So if we use regular lowercase, then theoretically there could be a case where we lowercase some developer / user provided value, which is then sent to a server and arrives "incorrectly" lower cased when compared to the expected lower case string on the server. I believe we do this to http headers, for example.

[mgol]

The manualLowercase function won't help in such a case either as it only lowercases Latin letters (from A to Z). This is, BTW, different from the native String#toLowerCase:
http://plnkr.co/edit/dZr9bnG8nIboMjwpgMpW?p=preview

So if there is any browser that violates ES5 and with Turkish locale has 'i' !== 'I'.toLowerCase() then we'll use a lowercasing function that doesn't convert lots of letters that we convert otherwise. Wouldn't it cause issues?