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

RESOLVED FIXED in Firefox 14

Status

()

Firefox
Location Bar
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: Justin Lebar (not reading bugmail), Assigned: mak)

Tracking

({regression})

unspecified
Firefox 14
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox13-, firefox14+ verified)

Details

(Whiteboard: [qa+])

Attachments

(1 attachment)

(Reporter)

Description

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

Updated

6 years ago
Summary: Location bar folds case back to history entry, if one exists → Location bar folds case back to history entry, if there's a history entry which is case-insensitively identical to the typed URL
(Reporter)

Comment 1

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

Comment 2

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

!
(Reporter)

Updated

6 years ago
tracking-firefox14: --- → ?
Keywords: regression, regressionwindow-wanted

Comment 3

5 years ago
Until we know whether or not FF13 is affected, tracking for that release as well (it's the first release with auto-complete).
tracking-firefox13: --- → +
tracking-firefox14: ? → +
(Assignee)

Comment 4

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

Comment 5

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

Comment 6

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

Updated

5 years ago
Blocks: 725714
(Assignee)

Comment 7

5 years ago
not exactly a regression since case correction exists from when autocomplete exists, but inline autocomplete surely made it more visible/active than needed.
Blocks: 566489
Keywords: regressionwindow-wanted
(Reporter)

Comment 8

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

Comment 9

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

Comment 10

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

Updated

5 years ago
Blocks: 746572
(Assignee)

Comment 11

5 years ago
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.
Assignee: nobody → mak77
(Assignee)

Comment 12

5 years ago
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.
Attachment #616523 - Flags: review?(gavin.sharp)
(Assignee)

Updated

5 years ago
Flags: in-testsuite+
OS: Linux → All
Hardware: x86_64 → All
Attachment #616523 - Flags: review?(gavin.sharp) → review+
(Assignee)

Comment 13

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/853ae8c135f9
Target Milestone: --- → Firefox 14
https://hg.mozilla.org/mozilla-central/rev/853ae8c135f9
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Inline autocomplete was disabled for FF13 in bug 746572. No need to track for FF13.
status-firefox14: --- → fixed
tracking-firefox13: + → -
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
status-firefox14: fixed → verified
Whiteboard: [qa+]
You need to log in before you can comment on or make changes to this bug.