Last Comment Bug 725714 - Mistype a URL Once and Autocomplete Will Forever Block You From Editing to Correct URL
: Mistype a URL Once and Autocomplete Will Forever Block You From Editing to Co...
Status: RESOLVED FIXED
:
Product: Firefox
Classification: Client Software
Component: Location Bar (show other bugs)
: Trunk
: All All
: -- normal (vote)
: Firefox 14
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
Depends on: 737841 742776
Blocks:
  Show dependency treegraph
 
Reported: 2012-02-09 10:09 PST by Damon Sicore (:damons)
Modified: 2012-04-20 14:24 PDT (History)
11 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments

Description Damon Sicore (:damons) 2012-02-09 10:09:52 PST
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).
Comment 1 Damon Sicore (:damons) 2012-02-13 13:32:25 PST
Problem still exists in 12.0a1 (2012-01-31).
Comment 2 Marco Bonardo [::mak] 2012-02-14 07:54:49 PST
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).
Comment 3 Damon Sicore (:damons) 2012-02-14 11:54:59 PST
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.
Comment 4 Damon Sicore (:damons) 2012-02-21 12:35:15 PST
This seems to be fixed in 13.0a1 (2012-02-12).
Comment 5 Damon Sicore (:damons) 2012-02-21 12:57:36 PST
And, downloaded nightly again, 13.0a1 (2012-02-21), and I cannot reproduce this.
Comment 6 Marco Bonardo [::mak] 2012-02-21 13:13:19 PST
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.
Comment 7 Johnathan Nightingale [:johnath] 2012-02-22 07:25:45 PST
(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.
Comment 8 Marco Bonardo [::mak] 2012-02-22 11:02:40 PST
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.
Comment 9 Marco Bonardo [::mak] 2012-02-22 11:05:49 PST
the pref was defaulted to off here
https://bugzilla.mozilla.org/show_bug.cgi?id=720792#c8
Comment 10 Marco Bonardo [::mak] 2012-02-22 11:08:35 PST
Actually, that was exactly on 01-31, likely after the nightly but before the merge.
Comment 11 Marco Bonardo [::mak] 2012-03-23 13:07:57 PDT
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.
Comment 12 Justin Lebar (not reading bugmail) 2012-04-10 08:18:20 PDT
> 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.
Comment 13 Justin Lebar (not reading bugmail) 2012-04-10 08:23:33 PDT
Aha:

http://en.wikipedia.org/wiki/Cat
http://en.wikipedia.org/wiki/CAT
Comment 14 Marco Bonardo [::mak] 2012-04-10 09:42:09 PDT
(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.
Comment 15 Justin Lebar (not reading bugmail) 2012-04-10 09:56:36 PDT
> 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.
Comment 16 Marco Bonardo [::mak] 2012-04-10 12:20:11 PDT
(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)
Comment 17 Marco Bonardo [::mak] 2012-04-10 12:22:07 PDT
ok, let's use this to track the issues, and your bug for case-correction.
Comment 18 Daniel Cater 2012-04-10 13:58:41 PDT
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).
Comment 19 Marco Bonardo [::mak] 2012-04-11 06:07:32 PDT
(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 :(
Comment 20 Daniel Cater 2012-04-11 08:13:23 PDT
(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.
Comment 21 :Gavin Sharp [email: gavin@gavinsharp.com] 2012-04-11 10:30:54 PDT
(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.
Comment 22 Daniel Cater 2012-04-11 16:00:55 PDT
(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.
Comment 23 Marco Bonardo [::mak] 2012-04-20 14:24:42 PDT
All the dependencies are fixed, we can consider this fixed by them.

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