STR: * In a new tab, visit https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=general (note lower-case "general"). * In a new tab, visit https://bugzilla.mozilla.org/enter_bug.cgi?product=Core&component=General (note upper-case "General"). Actual results: The second time, Firefox takes me to "component=general", not "component=General". Clear your history and it works. This is really incorrect behavior. The non-domain part of a URL is case-sensitive!

> In a new tab, visit I should say, copy-paste the URL into the location bar of a new tab. Things work properly if you click the links here.

This is a serious regression. For example, if I visit http://en.wikipedia.org/wiki/Rite-aid (which is a page-not-found) I can't correct it to http://en.wikipedia.org/wiki/Rite-Aid !

Until we know whether or not FF13 is affected, tracking for that release as well (it's the first release with auto-complete).

this is just a dupe of bug 725714, though since we added flags here I don't want to lose them. May someone with the proper rights move flags there and dupe this?

Also note we won't ever be able to fix past entries, cause we never tracked 404 (or similar) errors before bug 737841.

There are two separate issues here. One is that we'll auto-correct to pages which returned HTTP 4XX. The other is that we case-fold typed URLs to the history. I don't care whether or not bug 725714 is about the 4XX issue or case-folding, but I'd like this bug to be about the case-folding. If bug 725714 is about the 4XX issue, then let's not dupe, please.

not exactly a regression since case correction exists from when autocomplete exists, but inline autocomplete surely made it more visible/active than needed.

> not exactly a regression since case correction exists from when autocomplete exists, but inline > autocomplete surely made it more visible/active than needed. Well, without inline auto-complete, I could still visit component=General after visiting component=general, right? My awesomebar might have suggested component=general, but that's a lot different from actively preventing me from going to component=General. Because I can no longer access sites I used to be able to access, this is, in my mind, a (serious!) regression.

(In reply to Justin Lebar [:jlebar] from comment #6) > There are two separate issues here. One is that we'll auto-correct to pages > which returned HTTP 4XX. This is fixed in Nightly. > The other is that we case-fold typed URLs to the history. This is the default behavior of the controller, that likely is making things worse than better. We should either stop trying to fix user's casing for type-ahead results (though we can hardly tell if some type-ahead result may want it) or add a new option to disallow the controller's behavior.

A possible temporary solution for Aurora, where we could hardly backport a fix that will likely change some interface, could be to limit inline to the domain part. That would be trivial and safe to do.

So, I think the search should just be case sensitive on the path, shouldn't be a complicated fix. We'll lose some result, but that's an acceptable compromise considered the opposite issue.

This is simple enough, thus can also be backported. I'm just adding a MATCH_BEGINNING_CASE_SENSITIVE matching behavior, and lowercasing just the host part (the db uris are fixed up, so this will match properly). Fixed the testcases and added 4 more. Again I think this must be fixed search side, not controller side, cause the results usage is not predictable.

Inline autocomplete was disabled for FF13 in bug 746572. No need to track for FF13.

Verified that if there's a history entry which is case-insensitively identical with another history entry both can be opened. Verified using Firefox 14 beta 8 on Windows 7, Ubuntu 12.04 and Mac OS X 10.6: Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20100101 Firefox/14.0 Mozilla/5.0 (X11; Linux i686; rv:14.0) Gecko/20100101 Firefox/14.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:14.0) Gecko/20100101 Firefox/14.0