742776 - Location bar folds case back to history entry, if there's a history entry which is case-insensitively identical to the typed URL

Status: RESOLVED FIXED

(Firefox :: Address Bar, defect)

Description

[Justin Lebar (not reading bugmail)]

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!

Comment 1

[Justin Lebar (not reading bugmail)]

> 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.

Comment 2

[Justin Lebar (not reading bugmail)]

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

!

Comment 3

[Alex Keybl [:akeybl]]

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

Comment 4

[Marco Bonardo [:mak]]

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?

Comment 5

[Marco Bonardo [:mak]]

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

Comment 6

[Justin Lebar (not reading bugmail)]

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.

Comment 7

[Marco Bonardo [:mak]]

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

Comment 8

[Justin Lebar (not reading bugmail)]

> 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.

Comment 9

[Marco Bonardo [:mak]]

(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.

Comment 10

[Marco Bonardo [:mak]]

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.

Comment 11

[Marco Bonardo [:mak]]

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.

Comment 12

[Marco Bonardo [:mak]]

Attachment: patch v1.0

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.

Comment 13

[Marco Bonardo [:mak]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/853ae8c135f9

Comment 14

[(no longer active)]

https://hg.mozilla.org/mozilla-central/rev/853ae8c135f9

Comment 15

[Alex Keybl [:akeybl]]

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

Comment 16

[Simona Badau, Desktop QA]

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