Closed Bug 781617 Opened 12 years ago Closed 12 years ago

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

Categories

(Firefox :: Address Bar, defect)

14 Branch
x86
All
defect
Not set
normal

Tracking

()

VERIFIED FIXED
Firefox 18
Tracking Status
firefox15 + wontfix
firefox16 + wontfix
firefox17 + verified

People

(Reporter: bensberg, Assigned: mak)

References

Details

(Keywords: regression, reproducible, sec-want)

Attachments

(1 file)

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:  http://de.wiktionary.org/wiki/Augenbraue
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: https://de.wiktionary.org/wiki/Augenbraue)


Expected results:

FF should honour the typed URL, consider http and https as fundamentally different, and refetch the requested page using https.
Regression window
Good:
http://hg.mozilla.org/mozilla-central/rev/0e4f8e1a141b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120603134204
Bad:
http://hg.mozilla.org/mozilla-central/rev/dd6ec482a85d
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:15.0) Gecko/15.0 Firefox/15.0a1 ID:20120603154604
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0e4f8e1a141b&tochange=dd6ec482a85d

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
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
OS: Linux → All
It's already reported here https://bugzilla.mozilla.org/show_bug.cgi?id=769994#c5 in scenario #2. And this comment from Marco Bonardo too: https://bugzilla.mozilla.org/show_bug.cgi?id=769994#c8
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
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".
Status: RESOLVED → REOPENED
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
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.
I tried the steps in comment 0, but I cannot reproduce, it goes to the https version for me. Can anyone else confirm steps?
(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?

See https://bugzilla.mozilla.org/show_bug.cgi?id=781617#c2
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.
When prefixing https in address bar or changing https to http, I still remain at the same protocol that I used before. 
Steps:
* Enter http://commons.wikimedia.org/wiki/Special:Contributions/Republicoat 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*

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

Expected behaviour:
* Allow me switching to HTTPS
(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.
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...
Attached patch patch v1.0Splinter Review
Blair, if you're too busy please let me know, since this is tracked and I'm late already :)
Attachment #663058 - Flags: review?
Attachment #663058 - Flags: review? → review?(bmcbride)
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.
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+
thank you, I had fixed the trailing spaces locally already.
https://hg.mozilla.org/integration/mozilla-inbound/rev/9efb8c43ee8a
Flags: in-testsuite+
Target Milestone: --- → Firefox 18
https://hg.mozilla.org/mozilla-central/rev/9efb8c43ee8a
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Keywords: sec-want
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+
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.
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.
Verified as fixed in FF 17.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.