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)

36 Branch
x86_64
Windows 7
defect

Tracking

()

VERIFIED FIXED
Firefox 48
Tracking Status
firefox45 --- fixed
firefox46 --- verified
firefox47 --- verified
firefox48 --- verified
firefox-esr38 --- affected
firefox-esr45 45+ fixed
relnote-firefox --- 45+

People

(Reporter: biuro, Assigned: Gijs)

References

Details

(Keywords: regression, Whiteboard: [fxsearch])

Attachments

(2 files)

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?
URL: http://
Flags: needinfo?(biuro)
Priority: P1 → --
Whiteboard: http
Attached 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)
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.
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]
In the past, entering http:// added a / to the end (http:///) and the tab displayed an error message.
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 :)
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 48
No longer blocks: 1043584, 1067903, 1105456
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+
No , it still doesnt work. I have an actual version of mozilla (45.0)
Flags: needinfo?(biuro)
(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)
In nightly is ok :-)
Flags: needinfo?(biuro)
(In reply to biuro from comment #18) > In nightly is ok :-) Thanks!
Status: RESOLVED → VERIFIED
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+
(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?
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.

Attachment

General

Creator:
Created:
Updated:
Size: