http is given from History even when https is explicitly typed in address bar

VERIFIED FIXED in Firefox 17



Location Bar
5 years ago
5 years ago


(Reporter: Benno Schulenberg, Assigned: mak)


({regression, reproducible, sec-want})

14 Branch
Firefox 18
regression, reproducible, sec-want
Dependency tree / graph
Bug Flags:
in-testsuite +

Firefox Tracking Flags

(firefox15+ wontfix, firefox16+ wontfix, firefox17+ verified)



(1 attachment)



5 years ago
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:14.0) Gecko/20100101 Firefox/14.0.1
Build ID: 20120713225625

Steps to reproduce:

I typed an explicit https URL in the address bar.

Actual results:

FF showed the page using http instead.  (The page was visited many days before using http, and apparently FF recognizes the typed URL as equivalent to the one in the history, ignoring the all-important https component.)

For example, visit:
Then type  https://  at the start of the address bar en hit Enter.
No go.  The https part is discarded.

(Clicking a link works fine, of course:

Expected results:

FF should honour the typed URL, consider http and https as fundamentally different, and refetch the requested page using https.

Comment 1

5 years ago
Regression window
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120603134204
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120603154604

Regressed by
dd6ec482a85d	Marco Bonardo — Bug 720081 - Part 1: backportable solution for autocomplete controller to provide a different final defaultComplete value for typeAheadResults r=gavin
Blocks: 720081
tracking-firefox14: --- → ?
tracking-firefox15: --- → ?
tracking-firefox16: --- → ?
tracking-firefox17: --- → ?
Ever confirmed: true
Keywords: regression
OS: Linux → All

Comment 2

5 years ago
It's already reported here in scenario #2. And this comment from Marco Bonardo too:
Last Resolved: 5 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 769994
tracking-firefox14: ? → ---
tracking-firefox15: ? → ---
tracking-firefox16: ? → ---
tracking-firefox17: ? → ---
Not a dupe - this bug is the opposite of bug 769994, per the summary. IIRC, preferring https is intentional, and we should never override that with "http".
tracking-firefox15: --- → ?
Resolution: DUPLICATE → ---
Component: Untriaged → Location Bar
Marco can you look into backing out bug 720081 in that case so we don't ship 15 with this regression?
Assignee: nobody → mak77
status-firefox15: --- → affected
status-firefox16: --- → affected
status-firefox17: --- → affected
tracking-firefox15: ? → +
tracking-firefox16: --- → +
tracking-firefox17: --- → +
Keywords: reproducible
We can't back out the patch, it's critical to the functionality of inline autocomplete. The "regression" shipped in 14, and doesn't seem to be affecting all cases, so if it comes down to it we can ship with this again, but we should definitely make an effort to investigate and correct it.

Comment 7

5 years ago
I tried the steps in comment 0, but I cannot reproduce, it goes to the https version for me. Can anyone else confirm steps?

Comment 8

5 years ago
(In reply to Marco Bonardo [:mak] from comment #7)
> I tried the steps in comment 0, but I cannot reproduce, it goes to the https
> version for me. Can anyone else confirm steps?

I think it's the same scenario as this bug.
At this point in FF15 cycle we must wontfix for 15 but please keep this as a priority for 16.
status-firefox15: affected → wontfix


5 years ago
Duplicate of this bug: 784248

Comment 11

5 years ago
When prefixing https in address bar or changing https to http, I still remain at the same protocol that I used before. 
* Enter with C&Past in address bar
* Press enter key. "http://" disappears.
* Wait until page is loaded
* Clicking before the first char in the address bar in order to prepend "https://". Enter "https://" using the keyboard.
* Clicking enter
* Firefox, again loads the page, but *not using HTTPS*, but instead *HTTP*

* Add or modify a query-parameter so the URL is a different one

Expected behaviour:
* Allow me switching to HTTPS

Comment 12

5 years ago
(In reply to Rainer Rillke from comment #11)
> * Clicking before the first char in the address bar in order to prepend
> "https://". Enter "https://" using the keyboard.
> * Clicking enter

hm this is strange cause inline ac is active only when the mouse cursor is at the end :(
Btw, looking into this.

Comment 13

5 years ago
so, looks like there is a missing condition for typeAhead results in the controller, the suggested string should always contain the input value.
The problem comes from the fact you search for
"https://something", the code strips the prefix and searches for "something", it finds "http://something" and suggests it, at this point we lack the check.
So this could either be fixed:
- in the controller, this would be sort of a firewall for broken searches
- in the search, makes sense that a search can do whatever on the input string but should not suggest nonsense results

Or just in both places, I'd probably do the latter but put an aborting assert in the controller...

Comment 14

5 years ago
Created attachment 663058 [details] [diff] [review]
patch v1.0

Blair, if you're too busy please let me know, since this is tracked and I'm late already :)
Attachment #663058 - Flags: review?


5 years ago
Attachment #663058 - Flags: review? → review?(bmcbride)


5 years ago
Blocks: 769348
FF15 was affected, so given where we are in the cycle, we're going to leave this unfixed. Please nominate for FF17 Aurora approval when ready.
status-firefox16: affected → wontfix


5 years ago
Duplicate of this bug: 792969
Comment on attachment 663058 [details] [diff] [review]
patch v1.0

Review of attachment 663058 [details] [diff] [review]:

Seems reasonable :)

::: toolkit/components/places/nsPlacesAutoComplete.js
@@ +1521,5 @@
>      // Add the result.
> +    // If the untrimmed value doesn't preserve the user's input just
> +    // ignore it and complete to the found url.
> +    let untrimmedURL = prefix + url;    

Nit: trailing whitespace.
Attachment #663058 - Flags: review?(bmcbride) → review+

Comment 18

5 years ago
thank you, I had fixed the trailing spaces locally already.
Flags: in-testsuite+
Target Milestone: --- → Firefox 18
Last Resolved: 5 years ago5 years ago
Resolution: --- → FIXED


5 years ago
Keywords: sec-want

Comment 20

5 years ago
Comment on attachment 663058 [details] [diff] [review]
patch v1.0

[Approval Request Comment]
Bug caused by (feature/regressing bug #): bug 720081
User impact if declined: we are not respecting what the user types, so he may end up to the unwanted page
Testing completed (on m-c, etc.): m-c, automated test
Risk to taking this patch (and alternatives if risky): regressions in autoFill, but it's quite well covered by tests, and the change is quite contained
String or UUID changes made by this patch: none
Attachment #663058 - Flags: approval-mozilla-aurora?
Attachment #663058 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+

Comment 21

5 years ago
status-firefox17: affected → fixed

Comment 22

5 years ago
ARGH! This just cost me half a day try to figure out whether I had done something wrong in my new ASP.NET MVC application. Broken in v15 indeed, very very inconvenient! Sorry, I just had to complain.
Duplicate of this bug: 801247
Duplicate of this bug: 806143


5 years ago
Duplicate of this bug: 806323


5 years ago
Duplicate of this bug: 807292

Comment 27

5 years ago
Verified as fixed on Firefox 17 beta 6 - 20121113065533.

I wasn't redirected to http for any pages in the above comments, nor other web pages.
status-firefox17: fixed → verified

Comment 28

5 years ago
Verified as fixed in FF 17.
You need to log in before you can comment on or make changes to this bug.