Last Comment Bug 742776 - Location bar folds case back to history entry, if there's a history entry which is case-insensitively identical to the typed URL
: Location bar folds case back to history entry, if there's a history entry whi...
Status: RESOLVED FIXED
[qa+]
: regression
Product: Firefox
Classification: Client Software
Component: Location Bar (show other bugs)
: unspecified
: All All
: -- normal (vote)
: Firefox 14
Assigned To: Marco Bonardo [::mak]
:
: Marco Bonardo [::mak]
Mentors:
Depends on:
Blocks: 566489 725714 746572
  Show dependency treegraph
 
Reported: 2012-04-05 10:14 PDT by Justin Lebar (not reading bugmail)
Modified: 2012-06-22 06:29 PDT (History)
10 users (show)
mak77: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
+
verified


Attachments
patch v1.0 (8.82 KB, patch)
2012-04-19 05:10 PDT, Marco Bonardo [::mak]
gavin.sharp: review+
Details | Diff | Splinter Review

Description Justin Lebar (not reading bugmail) 2012-04-05 10:14:14 PDT
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) 2012-04-05 10:18:00 PDT
> 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) 2012-04-05 23:30:52 PDT
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] 2012-04-09 15:36:47 PDT
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] 2012-04-10 07:24:56 PDT
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] 2012-04-10 07:27:38 PDT
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) 2012-04-10 10:04:35 PDT
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] 2012-04-10 12:23:13 PDT
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) 2012-04-10 12:25:38 PDT
> 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] 2012-04-10 12:27:43 PDT
(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] 2012-04-10 12:31:00 PDT
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] 2012-04-18 12:04:37 PDT
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] 2012-04-19 05:10:28 PDT
Created attachment 616523 [details] [diff] [review]
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 15 Alex Keybl [:akeybl] 2012-05-01 10:38:34 PDT
Inline autocomplete was disabled for FF13 in bug 746572. No need to track for FF13.
Comment 16 Simona B [:simonab ] 2012-06-22 06:29:07 PDT
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

Note You need to log in before you can comment on or make changes to this bug.