Closed Bug 725714 Opened 12 years ago Closed 12 years ago

Mistype a URL Once and Autocomplete Will Forever Block You From Editing to Correct URL

Categories

(Firefox :: Address Bar, defect)

Product:
Firefox
Component:
Address Bar
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
Firefox 14
Tracking Flags:
Tracking Status
firefox12 - ---

People

(Reporter: damons, Unassigned)

References

Details

Nightly, 12.0a1 (2012-01-30)

Steps to reproduce:

1)  Visit https://bugzilla.mozilla.org/Form.itrequest (Note:  The uppercase 'F' is incorrect resulting in a 404).

2)  Attempt to correct by editing the URL in the location bar by replacing the 'F' with 'f'.  Autocomplete will always replace your edit with the old incorrect URL.

Expected results:  The location bar allows you to edit the URL, hold from auto-completing, and allow you to fetch the corrected URL.

Works fine in other browsers (Chrome).
Problem still exists in 12.0a1 (2012-01-31).
tracking-firefox12: --- → ?
which autocomplete? the inline one is disabled by default on 12, do you have browser.urlbar.autoFill set to true?
when does (2.) happen? while you type or on confirmation (either by Enter or other).
browser.urlbar.autoFill is set to true.  I never set it. And, it's the autocomplete that is in the url bar.  I don't know what inline means in this context.
This seems to be fixed in 13.0a1 (2012-02-12).
And, downloaded nightly again, 13.0a1 (2012-02-21), and I cannot reproduce this.
browser.urlbar.autoFill should be false by default in Firefox 12, I'm not sure why it's true in your profile, it has bugs, some of those may be fixed in Nightly.
(In reply to Marco Bonardo [:mak] from comment #2)
> which autocomplete? the inline one is disabled by default on 12, do you have
> browser.urlbar.autoFill set to true?
> when does (2.) happen? while you type or on confirmation (either by Enter or
> other).

The behaviour is still broken in Aurora with the pref flipped, but as Marco says, that pref is off by default on Aurora, so I don't think this needs to be tracked for the FF12 release.

I'd like to understand what's going on with Damon's pref, though, since he didn't intentionally flip it. 

Marco/DDahl - when did we flip the Aurora default to off? Damon said it was still happening to him on the FF12 nightly from 01-31, but that was migration day, so if the inline autocomplete was disabled on Aurora after migration day, that would explain things.

Also, David, can we get clear on which fix addressed Damon's issue, so that we know it's fixed for real? Having your typing overridden by firefox is not a pleasant experience.

Aside: sorry the triage for this nom took as long as it did - beta noms take priority over aurora noms, but even still we usually have the list cleared more quickly.
tracking-firefox12: ? → -
we flipped off the pref a couple days before the Aurora merge, in Nightly.

As far as the bug that may have fixed the problem, my first thought would be bug 720501.
Actually, that was exactly on 01-31, likely after the nightly but before the merge.
Ok, I finally tracked this as due to bug 737841. The docshell passes every url to history, included 4xx pages, and we end up autocompleting to those.
This bug happens if you delete from right to left the bogus entry, so that when you have finished editing the cursor is at the end, then inline kicks into and corrects your casing (and that's a feature!).  If you correct just the wrong letter, everything works.
We should really not suggest broken pages.
Depends on: 737841
> then inline kicks into and corrects your casing (and that's a feature!).
> We should really not suggest broken pages.

While I agree we shouldn't suggest error pages, I don't think that's the right solution here.

Outside the domain name, "foo" and "Foo" are not guaranteed to be the same page.  It seems like you're assuming that at least one of them must be an error page, but there's no reason that must be so!

I'm certain that if I tried hard enough, I could find two valid wikipedia pages which differ only in their capitalization.  But also, plenty of error pages on the web are (incorrectly) served as HTTP 200's.
OS: Mac OS X → All
Hardware: x86 → All
(In reply to Justin Lebar [:jlebar] from comment #12)
> While I agree we shouldn't suggest error pages, I don't think that's the
> right solution here.

It's the right solution for this bug, not a solution to all existing bugs.  Your point is surely valid, though it's not related to a mistyped uri, rather a case-sensitive path. Surely valid, just not the same bug.

What hurts there is the autocomplete controller trying to give you a meaningful casing, that is a "feature" that exists from a long time in autocomplete.  The problem is that the controller tries to "correct" your typed text to an existing suggestion, to avoid you hitting a 404 cause you mistyped the casing.
That's a behavior we may disable with a new input option probably (not backportable), though the downside is the user can't anymore rely on autocomplete to correct casing, so in case of that kind of mistype will just hit a 404.

> But also, plenty of error
> pages on the web are (incorrectly) served as HTTP 200's.

No way to detect misconfigured servers/pages, regardless we should not optimize for this kind of edge cases.
> Surely valid, just not the same bug.

If you want to make this about not auto-correcting error pages, that's cool.  But then we shouldn't dupe bug 742776 here, as you'd suggested.

In my mind, fixing the bogus case-folding behavior is much more important.  When we do that, we'll fix Damon's issue here, too.  Then we can worry about the edge case of not completing error pages.
(In reply to Justin Lebar [:jlebar] from comment #15)
> If you want to make this about not auto-correcting error pages, that's cool.
> But then we shouldn't dupe bug 742776 here, as you'd suggested.

Your bug was about a mistyped url, as this one, that's why I suggested duping in the first place, they were about the same thing.
I'm fine with converting this or your bug to better handle the case correction stuff. (Note though that whatever thing we do we'll lose some feature, but likely disallowing user to change casing is worse then correcting his casing typos)
ok, let's use this to track the issues, and your bug for case-correction.
A note about the pref issue: it could be down to Sync. I know I had Sync set to sync preferences, and suddenly my Firefox profile at work (release version of Fx 10.0.1 at the time) started inline-completing because I have sync setup there and on my home profile (which uses Nightly). When it defaulted to true on Nightly, Fx 10 inherited that pref.

I've since disabled syncing of preferences (this wasn't the first instance of it doing something weird).
(In reply to Daniel Cater from comment #18)
> A note about the pref issue: it could be down to Sync. I know I had Sync set
> to sync preferences, and suddenly my Firefox profile at work (release
> version of Fx 10.0.1 at the time) started inline-completing

This looks bad enough to worth a bug in Services/Sync. Could you please file it? it should not enabled features across versions :(
(In reply to Marco Bonardo [:mak] from comment #19)
> (In reply to Daniel Cater from comment #18)
> > A note about the pref issue: it could be down to Sync. I know I had Sync set
> > to sync preferences, and suddenly my Firefox profile at work (release
> > version of Fx 10.0.1 at the time) started inline-completing
> 
> This looks bad enough to worth a bug in Services/Sync. Could you please file
> it? it should not enabled features across versions :(

I don't really have time to work out which of the following is the right bug to file:

1. Don't sync the browser.urlbar.autoFill preference
2. Don't sync preferences across browser versions
3. Don't sync preferences when default value is different across platforms / versions
4. Don't sync preferences by default
5. Don't sync preferences at all
6. Something else

Perhaps it's all of them.

The problem with 1 is that people disabling autofill won't have the preference reflected in other instances. The problem with 2, 3, 4 and 5 is that prefs that would otherwise cause no problem won't be synced in some situation or another.

A different fix could be to rename the preference on trunk so that old-autofill and new-autofill don't share the same pref.

I suggest you file a bug to investigate as you know better what you think the outcome should be.
(In reply to Daniel Cater from comment #20)
> 1. Don't sync the browser.urlbar.autoFill preference

We need to start with this one. Please do go ahead and file it.

I think that in general, sync probably shouldn't be syncing prefs that aren't toggle-able using UI.
(In reply to Gavin Sharp (use gavin@gavinsharp.com for email) from comment #21)
> (In reply to Daniel Cater from comment #20)
> > 1. Don't sync the browser.urlbar.autoFill preference
> 
> We need to start with this one. Please do go ahead and file it.
> 
> I think that in general, sync probably shouldn't be syncing prefs that
> aren't toggle-able using UI.

Filed bug 744626 for that issue. After that I think the general issue of syncing preferences across versions and platforms where the default is different should be looked at.
All the dependencies are fixed, we can consider this fixed by them.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 14
You need to log in before you can comment on or make changes to this bug.