1254503 - After entering http:// or https:// in Location Bar , the Location Bar will no longer function.

Status: VERIFIED FIXED

(Firefox :: Address Bar, defect, P1)

Description

[biuro]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20160210153822

Steps to reproduce:

When you try to type an address of WEB and by mistake You will type 'http://' and press enter then card will hang and even if we type another address, this card wont be useful.



Actual results:

When you try to type an address of WEB and by mistake You will type 'http://' and press enter then card will hang and even if we type another address, this card wont be useful.



Expected results:

error or nothing

Comment 1

[Loic]

Which card?

Comment 2

[biuro]

Attachment: mozilla fail.png

Start mozilla, type an address "http://" and press enter. 

Now try to go to another url. It is impossible, firefox tab dont work.

It should be like in https:// case - it should print error.

Comment 3

[Loic]

I can't reproduce it. I opened a new tab, I typed http:// then I pressed "enter", Firefox did nothing and I could browse the other tabs. Same with https:///

Could you test with a fresh profile, please.
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Comment 4

[biuro]

Try to type "http://" , press enter. Now select our "http://" and type anty page for example "http://dell.com" and press enter. Mozilla doesnt go to dell.

Of corse in other tabs you can go to any page , but this one tab stops to the time that you will close it.

Comment 5

[Alice0775 White]

I can reproduce the problem on Wndows7 regardless of the setting of browser.urlbar.unifiedcomplete.


Regression window (default setting):
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=7bcc6573d204&tochange=daf6fc0b0195

Regressed by:	daf6fc0b0195	Marco Bonardo — Bug 1105456 - Temporarily disable Unified Complete due to recent regressions. r=post-facto a=ryanVM for pushing on a CLOSED TREE central


#1 Regression window (with force browser.urlbar.unifiedcomplete = false):

#1-1 The Location Bar autocomplete list will no longer pop up.
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=5e58c0e59964&tochange=a4d2e72afc42

#1-1 Regressed by:	5b4fe2faa70d	Gijs Kruitbosch — Bug 1094179 - use uriFixup for trimURL, r=dao

#1-2 The Location Bar will no longer function.
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=c294ed0b5502&tochange=1791d8198cc3

#1-2 Regressed by:	Bug 1067903


#2 Regression window (with force browser.urlbar.unifiedcomplete = true):
   The Location Bar will no longer function.
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=ec87657146eb&tochange=bd910b32e904

#2 Regressed by:	9b446ed418fe	Gijs Kruitbosch — Bug 1043584 - fix mouseover vs. enter issue in the urlbar, r=mak

Comment 6

[Marco Bonardo [:mak]]

nice way to kill the awesomebar in a single tab... Should be investigated, off-hand I can't tell which bug effectively caused this. If I should bet, considered it's limited to a tab, I'd say something related to the trimurl change... autocomplete component should not really stop working for a single tab...

Comment 7

[Loic]

In the past, entering http:// added a / to the end (http:///) and the tab displayed an error message.

Comment 8

[:Gijs (he/him)]

Attachment: MozReview Request: Bug 1254503 - ignore exceptions from trying to fix up obviously broken URIs, r?mak

Review commit: https://reviewboard.mozilla.org/r/38699/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/38699/

Comment 9

[:Gijs (he/him)]

The attached patch is sufficient to fix the issue. Stack from busted 45 rc (happens when you hit enter on 'http://', but on a timeout, and then eventually shows up as a promsie rejection, which I find interesting...) to help explain what I did here:

A promise chain failed to handle a rejection. Did you forget to '.catch', or did you forget to 'return'?
See https://developer.mozilla.org/Mozilla/JavaScript_code_modules/Promise.jsm/Promise

Date: Tue Mar 08 2016 16:55:11 GMT+0000 (GMT)
Full Message: Component returned failure code: 0x80070057 (NS_ERROR_ILLEGAL_VALUE) [nsIURIFixup.createFixupURI]
Full Stack: JS frame :: chrome://browser/content/utilityOverlay.js :: trimURL :: line 756
JS frame :: chrome://browser/content/urlbarBindings.xml :: trimValue :: line 212
JS frame :: chrome://global/content/bindings/autocomplete.xml :: set_value :: line 289
JS frame :: chrome://browser/content/urlbarBindings.xml :: continueOperation :: line 384
JS frame :: chrome://browser/content/urlbarBindings.xml :: handleCommand/< :: line 377
JS frame :: chrome://browser/content/urlbarBindings.xml :: _canonizeURL/< :: line 526
JS frame :: resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js :: Handler.prototype.process :: line 933
JS frame :: resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js :: this.PromiseWalker.walkerLoop :: line 812
JS frame :: resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js :: this.PromiseWalker.scheduleWalkerLoop/< :: line 746

Comment 10

[Marco Bonardo [:mak]]

Comment on attachment 8727939 [details]
MozReview Request: Bug 1254503 - ignore exceptions from trying to fix up obviously broken URIs, r?mak

https://reviewboard.mozilla.org/r/38699/#review35381

Sounds like I put a bet on the right regressing patch. We should uplift this as far as we can, it may explain some of the cases where people complained the awesomebar stopped working.

And Gijs wins the prize for the fastest patch :)

Comment 11

[Pulsebot]

https://hg.mozilla.org/integration/fx-team/rev/ef4f7bdd2b5b

Comment 12

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/ef4f7bdd2b5b

Comment 13

[:Gijs (he/him)]

Comment on attachment 8727939 [details]
MozReview Request: Bug 1254503 - ignore exceptions from trying to fix up obviously broken URIs, r?mak

Approval Request Comment
[Feature/regressing bug #]: bug 1094179
[User impact if declined]: it's possible to break the awesomebar by providing input that makes createFixupURI die, like "http://", and then hitting enter.
[Describe test coverage new/current, TreeHerder]: nope, or we would have caught this...
[Risks and why]: reasonably low. All I'm doing is putting an existing call into a try...catch.
[String/UUID change made/needed]: no.

Comment 14

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

biuro, could you please verify this issue is fixed as expected on 03-10 Nightly build? Thanks!

Comment 15

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8727939 [details]
MozReview Request: Bug 1254503 - ignore exceptions from trying to fix up obviously broken URIs, r?mak

Fix for a basic regression, taking it.

Comment 16

[biuro]

No , it still doesnt work.
I have an actual version of mozilla (45.0)

Comment 17

[:Gijs (he/him)]

(In reply to biuro from comment #16)
> No , it still doesnt work.
> I have an actual version of mozilla (45.0)

Ritu was asking about Nightly ( https://nightly.mozilla.org/ ), the development version of Firefox. You're running 45, which is the current release version - we don't make fixes directly to the release version.

Would you be able to test nightly?

Comment 18

[biuro]

In nightly is ok :-)

Comment 19

[:Gijs (he/him)]

(In reply to biuro from comment #18)
> In nightly is ok :-)

Thanks!

Comment 20

[:Gijs (he/him)]

Ritu, did you mean to approve this for the EOL esr31? I'm assuming not - but I don't know if you want it landing on 45-esr or whether that should just not be there at all. :-)

Comment 21

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Comment on attachment 8727939 [details]
MozReview Request: Bug 1254503 - ignore exceptions from trying to fix up obviously broken URIs, r?mak

Ooops, my bad. :)

Comment 22

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-aurora/rev/0744a3f1a325

Comment 23

[Wes Kocher (:KWierso) (Not reading bugmail; email directly if needed)]

https://hg.mozilla.org/releases/mozilla-beta/rev/107c1a440c77

Comment 24

[DJ-Leith]

(In reply to :Gijs Kruitbosch from comment #20)
> Ritu, did you mean to approve this for the EOL esr31? I'm assuming not - but
> I don't know if you want it landing on 45-esr or whether that should just not
> be there at all. :-)

(In reply to  Marco Bonardo [::mak] from comment #10)
> ... We should uplift this as far as we can, it may explain some of the cases where
> people complained the awesomebar stopped working.

Ritu,
Please consider uplift to ESR 45+.

In comment #0 biuro, the Reporter, on 2016-03-08 at 04:34:50 PST

> User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
> Build ID: 20160210153822
Saw this in Firefox 44.

status-firefox-esr45:   affected 

DJ-Leith

Comment 25

[:Gijs (he/him)]

Marco, I'm on the fence about this & esr45. Pretty safe fix, but obviously not a (sec-)critical issue. How do you feel about esr45, and if you think we should take it, could you note this and/or fill out an approval request? Thanks!

Comment 26

[Marco Bonardo [:mak]]

Comment on attachment 8727939 [details]
MozReview Request: Bug 1254503 - ignore exceptions from trying to fix up obviously broken URIs, r?mak

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: considered the fix is very simple and unlikely to create issues, and considered the awesomebar is the primary interaction point of the browser, this may be considered.
User impact if declined: Typing an invalid uri breaks the awesomebar forever for a given tab
Fix Landed on Version: 46-48
Risk to taking this patch (and alternatives if risky): very low, it's a try/catch
String or UUID changes made by this patch: none

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.

Comment 27

[Sylvestre Ledru [:Sylvestre]]

Comment on attachment 8727939 [details]
MozReview Request: Bug 1254503 - ignore exceptions from trying to fix up obviously broken URIs, r?mak

[Triage Comment]
OK, taking it for esr45 & 45.0.1

Comment 28

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

(In reply to DJ-Leith from comment #24)
> (In reply to :Gijs Kruitbosch from comment #20)
> > Ritu, did you mean to approve this for the EOL esr31? I'm assuming not - but
> > I don't know if you want it landing on 45-esr or whether that should just not
> > be there at all. :-)
> 
> (In reply to  Marco Bonardo [::mak] from comment #10)
> > ... We should uplift this as far as we can, it may explain some of the cases where
> > people complained the awesomebar stopped working.
> 
> Ritu,
> Please consider uplift to ESR 45+.
> 
> In comment #0 biuro, the Reporter, on 2016-03-08 at 04:34:50 PST
> 
> > User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:44.0) Gecko/20100101 Firefox/44.0
> > Build ID: 20160210153822
> Saw this in Firefox 44.
> 
> status-firefox-esr45:   affected 
> 
> DJ-Leith

DJ-Leith, thanks for flagging this one. We were trying to determine whether the fix is safe enough to be included in esr45. And it was deemed safe to be uplifted to ESR45 branch. Thanks!

Comment 29

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

https://hg.mozilla.org/releases/mozilla-release/rev/a149bbca9351

Comment 30

[Ryan VanderMeulen [:RyanVM][PTO June 24-28]]

https://hg.mozilla.org/releases/mozilla-esr45/rev/a149bbca9351

Comment 31

[Sylvestre Ledru [:Sylvestre]]

Added to the release notes "Fix a regression when using the location bar (1254503)"
Don't hesitate to propose a better wording

Comment 32

[Camelia Badau [:cbadau], Desktop QA]

I've reproduced the initial issue on Firefox 44.0.2 Build 3 (buildID: 20160210153822). 

Verified fixed on Windows 7 64bit and Mac OSX 10.9.5 using Firefox 46 Beta 6 (buildID: 20160328182534) and Aurora 47.0a2 (buildID: 20160323004040): a "/" is added to the end ("http:///") and the tab displays an error message: "The address isn't valid".