233229 - Location Bar uses http when auto-completing https URLs

Status: RESOLVED FIXED

(SeaMonkey :: Location Bar, defect)

Description

[louis bennett]

When auto-completing an address like "paypal.com" [1], Mozilla's auto-completion
drop-down shows only https:// URLs, but if you just hit Return it goes to
http://paypal.com/

My settings are:
- Autocomplete enabled
- Autocomplete best match as you type
- Show list of matching results
- Show internet search engine (if that matters)
- Internet keywords and domain guessing are disabled

[1] This assumes that you've never been to http://www.paypal.com/, only to its
https counterpart.

Comment 1

[Boris Zbarsky [:bzbarsky]]

If you just hit enter we assume you didn't want any of the urls in the dropdown
(if you had, you would have hit down to the one you wanted, then enter), so we
take the string you did type and perform fixups on it.....

Comment 2

[louis bennett]

ah, but you can hit enter after mozilla has auto-completed the URL for you.
(hence, the importance of "Autocomplete best match as you type" being enabled.)
if mozilla is going to show a URL that you've been to previously, it should get
the protocol right, no?

Comment 3

[louis bennett]

Attachment: screenshot of (misleading?) behavior described

Comment 4

[Jesse Ruderman]

See also bug 305186, a similar problem that happens even when "autocomplete best
match as you type" is not enabled.

Comment 5

[Andrew Schultz]

==> me

Comment 6

[Andrew Schultz]

Attachment: hack

This is a hack, but "best match" is already a hack in that it doesn't use >> (like addresses in composition).  It should use the actual URI from history if the user hits return immeadiately after typing.  If the user hits anything other than hitting enter, the old behavior should be maintained.

Comment 7

[[e-mail]]

Hmm... it also loses the www. prefix too... not good :-/

Comment 8

[[e-mail]]

Eww, and ftp: prefixes too :-(

Comment 9

[[e-mail]]

Comment on attachment 204855 [details] [diff] [review]
hack

This is quite good but I spotted an optimization - this.mDefaultMatchFilled is equivalently almost always only set by autoFillInput.

Comment 10

[Andrew Schultz]

Attachment: less of a hack

The best part was realizing that I didn't need to turn it off all over the place

This is somewhat unoptimized in that finishAutoComplete is be forced to re-find the "default" match again even when the default match is fully in the URL textbox (since we can't  tell whether the front part has been chopped off or not).  But it already does that for forceComplete anyway.  The previous patch  actually broke forceComplete if a user tabbed away from the textbox.

Comment 11

[[e-mail]]

Comment on attachment 205375 [details] [diff] [review]
less of a hack

I've wasted my morning on this, and eventually come to the decision that this is the best we can do with the flags that we've got. The edge case I came up with which might not work was the case of (!this.forceComplete && !aForceComplete && this.mNeedToComplete && this.mDefaultMatchFilled && this.autoFillAfterMatch) which might need to complete but does not even after this patch.

>+            } else if (this.mTransientValue || !(this.forceComplete || 
>+                       (this.mDefaultMatchFilled && aForceComplete)) ||
>                        !(this.mNeedToComplete || aForceComplete)) {
I'd prefer the slightly longer but hopefully clearer
this.mTransientValue ||
!(this.forceComplete || this.mDefaultMatchFilled) ||
!(this.forceComplete || aForceComplete) ||
!(this.mNeedToComplete || aForceComplete)

Comment 12

[Andrew Schultz]

Attachment: patch for checkin (checked in on trunk)

Comment 13

[Andrew Schultz]

*** Bug 122862 has been marked as a duplicate of this bug. ***

Comment 14

[Andrew Schultz]

Comment on attachment 205557 [details] [diff] [review]
patch for checkin (checked in on trunk)

this should go into SM 1.1.  This has baked on the trunk for a month with no known regressions.  Code is shared with mailnews/tbird but shouldn't affect the code path there.