avada Reporter
	Description • 9 years ago

Normally (e10s off) the text enter is retained an one can correct it.
It's particularly annoying with a mistyped keyword search, when you need to re-type everything.

You also need to have keyword.enabled;false. Otherwise you get redirected to a search.

	Tracy Walker [:tracy]
	Comment 1 • 9 years ago

Hi avada, thanks for the report.  But can you provide a succinct set of steps to reproduce this bug.  Also if you're running any addons, please try to reproduce with all of them disabled (that or test in a new profile).   Thank you.

	avada Reporter
	Comment 2 • 9 years ago

(In reply to [:tracy] Tracy Walker - QA Mentor from comment #1)
> Hi avada, thanks for the report.  But can you provide a succinct set of
> steps to reproduce this bug.

I practically did already. Set have keyword.enabled;false and e10s enabled. Screw up a keyword search or type random characters with spaces. You'll get to the error page and the urlbar will be empty.

>Also if you're running any addons, please try
> to reproduce with all of them disabled (that or test in a new profile).  
> Thank you.

It still happens.

	Tracy Walker [:tracy]
	Comment 3 • 9 years ago

Ah yes, I am able to reproduce only in an e10s window.

	Tracy Walker [:tracy]
	Comment 4 • 9 years ago

It still happens if browser.urlbar.unifiedcomplete is false.

	:Felipe Gomes (needinfo for replies!)
	Comment 5 • 9 years ago

I should say that I've been investigating this bug and the problem is caused by the urlbar being cleared here after an OnLocationChange notification:
http://mxr.mozilla.org/mozilla-central/source/browser/base/content/tabbrowser.xml?rev=005290f8c1d5#805

This OnLocationChange doesn't happen in non-e10s because, after the keyword url fails, it open the error page through nsDocShell::DisplayLoadError, which doesn't trigger a location change.

In the e10s path, there's an extra location change event for about:blank when this happens. It's not a recent regression, it has always been this way for e10s code.

I'm looking into the differences of path between the two and trying to figure out the best way to avoid this extra load on e10s.

	Karla Merza [Away. Please needinfo? Brindusa Tot[:brindusat] ]
	Comment 6 • 8 years ago

User Agent 	Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID 	20160207004019

User Agent  Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID  20160208004010

User Agent  Mozilla/5.0 (X11; Linux x86_64; rv:46.0) Gecko/20100101 Firefox/46.0
Build ID  20160207004019


Tested on Windows 7, Mac OS 10.10 and Ubuntu 15.04 on Aurora 46.0a2 build. This issue is reproducible with e10s enabled.

	Brad Lassey [:blassey] (use needinfo?)
	Comment 7 • 8 years ago

This works for me. Can you retest?

	avada Reporter
	Comment 8 • 8 years ago

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #7)
> This works for me. Can you retest?

I retested in a clean profile on central, e10s=on. It works weirdly.
I disabled keyword.enabled.
I type two words. I see the first result in the results (which is a google search) highlighted for some reason. I press enter I get redirected to about:newtab, plus the tab remains in loading state indefinitely.

So I still don't get the text retained, nor the expected error page.

	Jim Mathies [:jimm]
	Comment 9 • 8 years ago

Very similar to bug 1239886.

	Ting-Yu Chou [:ting] (away)
	Comment 10 • 8 years ago

(In reply to avada from comment #2)
> I practically did already. Set have keyword.enabled;false and e10s enabled.
> Screw up a keyword search or type random characters with spaces. You'll get
> to the error page and the urlbar will be empty.

I can't reproduce this on Nightly, the urlbar is not cleared.

	Ting-Yu Chou [:ting] (away)
	Comment 11 • 8 years ago

(In reply to avada from comment #8)
> search) highlighted for some reason. I press enter I get redirected to
> about:newtab, plus the tab remains in loading state indefinitely.

I can't reproduce this on Nightly. Also e10s behaves the same as non-e10s with this highlighted google search:

1. Enter random text in urlbar, a highlighted item with "Search with Google" shows up
2a. Press Enter, an error page "The address isn't valid" will be shown and the text is retained
2b. Click mouse on the highlighted item, the google search page will be shown, and urlbar is changed to google search

According to this and comment 10, could you confirm the issue is no longer existed? Thanks.

	avada Reporter
	Comment 12 • 8 years ago

(In reply to Ting-Yu Chou [:ting] from comment #10)
> I can't reproduce this on Nightly, the urlbar is not cleared.

It stopped experiencing this a while ago with my main profile on aurora.

Did a bit of testing with a fresh profile on central. I got an infinite throbber with about:newtab in the urlbar, with the error page loaded in the content a bunch of times. (But not always)

	Mike Conley (:mconley) (:⚙️)
	Comment 13 • 8 years ago

I know that Gijs has been working a lot on making the AwesomeBar more reliably and less race-y for various things... I wonder if he's fixed this one as a by-product.

Is that plausible, Gijs?

	:Gijs (he/him)
	Comment 14 • 8 years ago

Some of it probably got fixed in bug 1209591.

Then some of the rest I literally *just* fixed in bug 1267289.

But the infinite spinner on the tab (bug 1239886) still happens for invalid URIs as well. In the testcase for the broken URL case I added in bug 1267289, if you were to add assertions for ok(!tab.hasAttribute("busy"), "Tab stops spinning"); next to the existing ones about the URL bar, those assertions will fail. In fact, I looked into fixing that for a bit and then I gave it up as too much of a (mostly unrelated) rats nest next to the URL bar case. :-\

	Ting-Yu Chou [:ting] (away)
	Comment 15 • 8 years ago

(In reply to avada from comment #12)
> Did a bit of testing with a fresh profile on central. I got an infinite
> throbber with about:newtab in the urlbar, with the error page loaded in the
> content a bunch of times. (But not always)

I can't reproduce this. :(

1. ./mach run -P and start with a new profile
2. set keyword.enable false in about:config
3. enter random text in urlbar and press enter

I tried step 3 for 20 times but didn't see an infinite throbber with about:newtab in the urlbar, also the urlbar was never cleared. Did I reproduce it correctly?

Note because the urlbar is not cleared anymore, I am going to close this and we can track infinite throbber in bug 1239886. Is that OK?

	:Gijs (he/him)
	Comment 16 • 8 years ago

(In reply to Ting-Yu Chou [:ting] from comment #15)
> (In reply to avada from comment #12)
> > Did a bit of testing with a fresh profile on central. I got an infinite
> > throbber with about:newtab in the urlbar, with the error page loaded in the
> > content a bunch of times. (But not always)
> 
> I can't reproduce this. :(
> 
> 1. ./mach run -P and start with a new profile
> 2. set keyword.enable false in about:config

The pref is called "keyword.enabled", not "keyword.enable".

> 3. enter random text in urlbar and press enter
> 
> I tried step 3 for 20 times but didn't see an infinite throbber with
> about:newtab in the urlbar, also the urlbar was never cleared. Did I
> reproduce it correctly?

STR:

1. open Firefox with a clean profile
2. turn off keyword.enabled in about:config
3. open a new tab (has to be a new, clean tab with about:newtab, not about:home or whatever your homepage is already loaded)
4. enter "foo bar" in the url bar, press enter.


Anyway, we can dupe, if that helps anyone. Feels like comment #14 indicating how to get an automated test for this might be useful to have there.