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

VERIFIED FIXED in Firefox 45

Status

()

defect
P1
normal
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: biuro, Assigned: Gijs)

Tracking

({regression})

36 Branch
Firefox 48
x86_64
Windows 7
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(firefox45 fixed, firefox46 verified, firefox47 verified, firefox48 verified, firefox-esr38 affected, firefox-esr4545+ fixed, relnote-firefox 45+)

Details

(Whiteboard: [fxsearch])

Attachments

(2 attachments)

Reporter

Description

3 years ago
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
Reporter

Updated

3 years ago
URL: http://
OS: Unspecified → Windows 7
Priority: -- → P1
Hardware: Unspecified → x86_64
Whiteboard: http

Comment 1

3 years ago
Which card?
URL: http://
Flags: needinfo?(biuro)
Priority: P1 → --
Whiteboard: http
Reporter

Comment 2

3 years ago
Posted image 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.
Flags: needinfo?(biuro)

Comment 3

3 years ago
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
Reporter

Comment 4

3 years ago
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

3 years ago
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
Status: UNCONFIRMED → NEW
Component: Untriaged → Location Bar
Ever confirmed: true
Flags: needinfo?(mak77)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(bmcbride)
Keywords: regression
Summary: http hangs card → After entering http:// or https:// in Location Bar , the Location Bar will no longer function.
Version: 44 Branch → 36 Branch
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...
Flags: needinfo?(mak77)
Priority: -- → P1
Whiteboard: [fxsearch]

Comment 7

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

Comment 9

3 years ago
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
Assignee: nobody → gijskruitbosch+bugs
Status: NEW → ASSIGNED
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(bmcbride)
Attachment #8727939 - Flags: review?(mak77) → review+
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 12

3 years ago
bugherder
https://hg.mozilla.org/mozilla-central/rev/ef4f7bdd2b5b
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
No longer blocks: 1043584, 1067903, 1105456
Assignee

Comment 13

3 years ago
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.
Attachment #8727939 - Flags: approval-mozilla-beta?
Attachment #8727939 - Flags: approval-mozilla-aurora?
biuro, could you please verify this issue is fixed as expected on 03-10 Nightly build? Thanks!
Flags: needinfo?(biuro)
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.
Attachment #8727939 - Flags: approval-mozilla-esr31+
Attachment #8727939 - Flags: approval-mozilla-beta?
Attachment #8727939 - Flags: approval-mozilla-beta+
Attachment #8727939 - Flags: approval-mozilla-aurora?
Attachment #8727939 - Flags: approval-mozilla-aurora+
Reporter

Comment 16

3 years ago
No , it still doesnt work.
I have an actual version of mozilla (45.0)
Flags: needinfo?(biuro)
Assignee

Comment 17

3 years ago
(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?
Flags: needinfo?(biuro)
Reporter

Comment 18

3 years ago
In nightly is ok :-)
Flags: needinfo?(biuro)
Assignee

Comment 19

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

Thanks!
Status: RESOLVED → VERIFIED
Assignee

Comment 20

3 years ago
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. :-)
Flags: needinfo?(rkothari)
Comment on attachment 8727939 [details]
MozReview Request: Bug 1254503 - ignore exceptions from trying to fix up obviously broken URIs, r?mak

Ooops, my bad. :)
Flags: needinfo?(rkothari)
Attachment #8727939 - Flags: approval-mozilla-esr31+

Comment 24

3 years ago
(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
Flags: needinfo?(rkothari)
Flags: needinfo?
Assignee

Comment 25

3 years ago
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!
Flags: needinfo? → needinfo?(mak77)
Flags: qe-verify+
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.
Flags: needinfo?(mak77)
Attachment #8727939 - Flags: approval-mozilla-esr45?
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
Attachment #8727939 - Flags: approval-mozilla-release+
Attachment #8727939 - Flags: approval-mozilla-esr45?
Attachment #8727939 - Flags: approval-mozilla-esr45+
(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!
Flags: needinfo?(rkothari)
Added to the release notes "Fix a regression when using the location bar (1254503)"
Don't hesitate to propose a better wording
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".
You need to log in before you can comment on or make changes to this bug.