Closed
Bug 1254503
Opened 9 years ago
Closed 9 years ago
After entering http:// or https:// in Location Bar , the Location Bar will no longer function.
Categories
(Firefox :: Address Bar, defect, P1)
Tracking
()
People
(Reporter: biuro, Assigned: Gijs)
References
Details
(Keywords: regression, Whiteboard: [fxsearch])
Attachments
(2 files)
508.96 KB,
image/png
|
Details | |
58 bytes,
text/x-review-board-request
|
mak
:
review+
ritu
:
approval-mozilla-aurora+
ritu
:
approval-mozilla-beta+
Sylvestre
:
approval-mozilla-release+
Sylvestre
:
approval-mozilla-esr45+
|
Details |
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
URL: http://
OS: Unspecified → Windows 7
Priority: -- → P1
Hardware: Unspecified → x86_64
Whiteboard: http
Which card?
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)
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
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•9 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
status-firefox45:
--- → affected
status-firefox46:
--- → affected
status-firefox47:
--- → affected
status-firefox48:
--- → affected
status-firefox-esr38:
--- → affected
status-firefox-esr45:
--- → affected
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
Comment 6•9 years ago
|
||
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]
In the past, entering http:// added a / to the end (http:///) and the tab displayed an error message.
Assignee | ||
Comment 8•9 years ago
|
||
Review commit: https://reviewboard.mozilla.org/r/38699/diff/#index_header
See other reviews: https://reviewboard.mozilla.org/r/38699/
Attachment #8727939 -
Flags: review?(mak77)
Assignee | ||
Comment 9•9 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)
Updated•9 years ago
|
Attachment #8727939 -
Flags: review?(mak77) → review+
Comment 10•9 years ago
|
||
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•9 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
Updated•9 years ago
|
Assignee | ||
Comment 13•9 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•9 years ago
|
||
No , it still doesnt work.
I have an actual version of mozilla (45.0)
Flags: needinfo?(biuro)
Assignee | ||
Comment 17•9 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)
Assignee | ||
Comment 19•9 years ago
|
||
(In reply to biuro from comment #18)
> In nightly is ok :-)
Thanks!
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 20•9 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 22•9 years ago
|
||
bugherder uplift |
Comment 23•9 years ago
|
||
bugherder uplift |
Comment 24•9 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•9 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)
Updated•9 years ago
|
Flags: qe-verify+
Comment 26•9 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]
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 27•9 years ago
|
||
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!
tracking-firefox-esr45:
--- → 45+
Flags: needinfo?(rkothari)
Comment 29•9 years ago
|
||
bugherder uplift |
Comment 30•9 years ago
|
||
bugherder uplift |
Comment 31•9 years ago
|
||
Added to the release notes "Fix a regression when using the location bar (1254503)"
Don't hesitate to propose a better wording
relnote-firefox:
--- → 45+
Comment 32•9 years ago
|
||
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.
Description
•