Opening about:blank and hitting the down arrow in the location bar searches for "about:blank"

NEW
Unassigned

Status

()

defect
P3
normal
5 years ago
Last year

People

(Reporter: andrei, Unassigned)

Tracking

({regression})

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox33 affected, firefox34 affected)

Details

(Whiteboard: [mozmill][fxsearch])

Reporter

Description

5 years ago
We got this via a Mozmill test. See bug 1038119 for more info.

Steps:

1. Open Firefox (preferably a populated profile, otherwise visit some pages)
2. In an existing or new tab type in "about:blank"
3. Hit the down arrow once

Expected result: the AutoComplete popup opens
Actual result: nothing happens

If you blur the Location Bar and refocus it, this works again as expected.

==

Both: "about:blank", "about:newtab" are affected.
Only OSX appears to be affected.

The regressor is bug 1034845
Do you get any errors in the browser console?

Comment 2

5 years ago
I can reproduce the about:blank case. AFAICT it has to do with focus in general: on about:home, the search box is automatically focused, so when I then focus the location bar again, it works fine. On Firefox 31, at least, the location bar loses focus if you load about:blank, so the whole thing is not reproducible.

I don't see how Dão's patch would have caused a change in focus behaviour... how sure are you about the regression range, and does backing out the patch against trunk fix things for you?

Comment 3

5 years ago
(In reply to Dão Gottwald [:dao] from comment #1)
> Do you get any errors in the browser console?

Not for the about:blank case, at least...
Reporter

Comment 4

5 years ago
(In reply to :Gijs Kruitbosch from comment #2) 
> I don't see how Dão's patch would have caused a change in focus behaviour...
> how sure are you about the regression range, and does backing out the patch
> against trunk fix things for you?

Well I've retested, and this is the pushlog:
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=1829aad143e2&tochange=4ce737d7339d

Using tinderbox builds, last good build:
https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/fx-team-macosx64/1405033490/
And first bad build:
https://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/fx-team-macosx64/1405033910/
Keywords: regression
OS: Mac OS X → All
Hardware: x86 → All
The interesting thing is that when I press the DEL key, the auto-complete opens afterward.
Whiteboard: [mozmill]
Reporter

Comment 6

5 years ago
Gijs, any updates here?
Flags: needinfo?(gijskruitbosch+bugs)

Comment 7

5 years ago
I'm not currently working on this, I was hoping Dão was looking at it... Have you tried backing out the patch on current trunk?
Flags: needinfo?(gijskruitbosch+bugs)
Reporter

Comment 8

5 years ago
I thought the tinderbox builds would be enough.
I'll make a build on trunk with the mentioned commit backed out to make sure then.

Comment 9

5 years ago
(In reply to Andrei Eftimie from comment #8)
> I thought the tinderbox builds would be enough.
> I'll make a build on trunk with the mentioned commit backed out to make sure
> then.

Usually, yes, but in this case I am really, really, really confused as to how this patch would cause focus/autocomplete differences... if it was up to me, the next step would likely be bisecting the patch itself... :-\
Reporter

Comment 10

5 years ago
I've build Firefox from m-c, backed out the responsible changeset and the issue is no longer reproducible.

It's exactly what is reported in comment 2.
The Location Bar _loses focus_. Once you focus it the Automcomplete Popup works as expected.

On a current Nightly the Location Bar does not lose focus, and the Autocomplete Popup doesn't load.

---

So the problem itself is probably older, but it was masked by the fact that you always focused the Location Bar after a page would load. It seems now we maintain focus when we load "about:blank".

Also this is the only page I've found that maintains focus. Any external page or other "about:*" do actually load a page, thus the focus on the Location Bar is lost.
Reporter

Comment 11

5 years ago
Gijs, have you had any time to look into this issue?
Flags: needinfo?(gijskruitbosch+bugs)
Summary: Opening "about:home" or "about:blank" stops the loading of the Autocomplete Popup → Opening "about:blank" stops the loading of the Autocomplete Popup

Comment 12

5 years ago
(In reply to Andrei Eftimie from comment #11)
> Gijs, have you had any time to look into this issue?

I've not been aware this was urgently necessary. I don't really know what to do here; seems to me like putting work into removing focus from the location bar for about:blank is kind of pointless, because there's nothing to move focus to. We can't blame bug 1034845 for the original regression which was masked by the focus issue. Sounds like we should just fix the focus vs. autocomplete issue, but that's not really related to bug 1034845, nor would I really know where to start in figuring out what's breaking that. Marco or Dão would be better bets.

While I understand this broke a test, I'm not really sure how many real users this would affect, if it only reproduces when literally typing "about:blank" or "about:newtab" in the location bar (AIUI it doesn't happen if you open a new tab that defaults to either of these pages (for which there's a pref IIRC?)). In other words, I'm also not sure if fixing this should be much of a priority.
Flags: needinfo?(gijskruitbosch+bugs)
Reporter

Comment 13

5 years ago
(In reply to :Gijs Kruitbosch from comment #12)
> (In reply to Andrei Eftimie from comment #11)
> > Gijs, have you had any time to look into this issue?
> 
> I've not been aware this was urgently necessary. I don't really know what to
> do here; seems to me like putting work into removing focus from the location
> bar for about:blank is kind of pointless, because there's nothing to move
> focus to.

This should be a UX discussion.
Only "about:blank" and "about:newtab" maintain focus on the Location Bar, opening any other page does not have this behaviour. 

Should this be maintained or not?
I'm not sure who can make this call.

If these pages should behave like all others, it would also fix the current issue.

> We can't blame bug 1034845 for the original regression which was
> masked by the focus issue. Sounds like we should just fix the focus vs.
> autocomplete issue, but that's not really related to bug 1034845, nor would
> I really know where to start in figuring out what's breaking that. Marco or
> Dão would be better bets.

That's correct, bug 1034845 only unmasked a deeper issue.

> While I understand this broke a test, I'm not really sure how many real
> users this would affect, if it only reproduces when literally typing
> "about:blank" or "about:newtab" in the location bar (AIUI it doesn't happen
> if you open a new tab that defaults to either of these pages (for which
> there's a pref IIRC?)). In other words, I'm also not sure if fixing this
> should be much of a priority.

That's also correct, but this still looks like a bug in either the LocationBar or Autocomplete List. I _can_ fix the test, but that would be only a workaround around undocumented functionality.
Reporter

Comment 14

5 years ago
Flagging both Marco and Dão.
Do any of you has an idea on how (or _if_) this should be handled?
Flags: needinfo?(mak77)
Flags: needinfo?(dao)
I think it makes sense that we are not removing focus from the urlbar for blank pages (about:blank and about:newTab are both considered blank pages). It's pages the user starts navigation from, the most common operation from there would be to use the awesomebar. Even if with the search field in newtab page things might change... I don't know what's the plan.

Fwiw, I cannot reproduce on my Mac with Nightly, I see the autocomplete popup... by "type in" do you mean just type or also confirm with Enter? (I see the popup with both actions)

key_down should be handled by handleKeyNavigation at http://mxr.mozilla.org/mozilla-central/source/toolkit/components/autocomplete/nsAutoCompleteController.cpp#428 but I don't see anything related to focus... though might be a starting point to debug.
Flags: needinfo?(mak77)

Comment 16

5 years ago
(In reply to Marco Bonardo [:mak] (Away 15-31 Aug) from comment #15)
> Fwiw, I cannot reproduce on my Mac with Nightly, I see the autocomplete
> popup... by "type in" do you mean just type or also confirm with Enter? (I
> see the popup with both actions)

No typing, just hitting the down arrow after the page has loaded and the location bar text has been cleared to only show the placeholder text (which happens only on about:blank and about:newtab, AFAICT). I can still repro on today's nightly, so I'm not sure why it's different for you...
Adjusting the summary to how I understand this bug. If I misunderstood then I guess I also can't reproduce this.
Flags: needinfo?(dao)
Summary: Opening "about:blank" stops the loading of the Autocomplete Popup → Opening about:blank and hitting the down arrow in the location bar searches for "about:blank"
Depends on: 1070778
Gijs or Dao, could this become a mentored bug?

Comment 19

4 years ago
(In reply to Henrik Skupin (:whimboo) from comment #18)
> Gijs or Dao, could this become a mentored bug?

I don't understand what's causing this bug yet (haven't really looked into it), and so I'd be hesitant to make it a mentored bug. I don't know if it's different for Dão, but he's away at the moment, so probably not right now. I'll set a needinfo so he can take a look when he's back.
Flags: needinfo?(dao)
Hm, interesting. I tried the steps as given in comment 0 and it works for me with Nightly on OS X. Having about:blank open, and pressing the down arrow once really opens the auto-complete for me.

Teodor, would it be possible for you to test this with a recent nightly and the workaround in testAccessLocationbar.js being commented out? It might be that something else fixed that in-between and we can get rid of the workaround in our tests. Thanks.
Flags: needinfo?(teodor.druta)

Comment 21

4 years ago
(In reply to Henrik Skupin (:whimboo) from comment #20)
> Hm, interesting. I tried the steps as given in comment 0 and it works for me
> with Nightly on OS X. Having about:blank open, and pressing the down arrow
> once really opens the auto-complete for me.
> 
> Teodor, would it be possible for you to test this with a recent nightly and
> the workaround in testAccessLocationbar.js being commented out? It might be
> that something else fixed that in-between and we can get rid of the
> workaround in our tests. Thanks.

Our test is still affected by this issue, and I can reproduce it manually with today's nightly.
Flags: needinfo?(teodor.druta)
(In reply to Teodor Druta from comment #21)
> Our test is still affected by this issue, and I can reproduce it manually
> with today's nightly.

Would you mind to give exact steps for that? I think it would be pretty helpful for Gijs and Dao. Thanks.

Comment 23

4 years ago
(In reply to Henrik Skupin (:whimboo) from comment #22)
> Would you mind to give exact steps for that? I think it would be pretty
> helpful for Gijs and Dao. Thanks.

I followed the steps from comment #0.

1. Open Nightly (Firefox)
2. Open a few web pages (eg. yahoo, google, bing)
3. In the current active tab type 'about:blank' or 'about:newtab'
4. Press Enter or 'Go to the address in the location bar' button
5. Press arrow down key (VK_DOWN)
6. Observe that nothing happens
7. Click anywhere else but the location (awesome) bar in the firefox window
8. Observe that the location bar has been blurred (lost its focus)
9. Click back on the location (awesome) bar
10. Observe that the location bar has been focused
11. Repeat (5)
12. Observe that the awesomebar autocomplete popup opens

This is reproducible only on OSX systems.
Ok, so I re-tried and personally I do not have this problem with latest nightly build on OS X 10.10.2. Which version of OS X are you running? Maybe it's related to 10.9 or earlier?

Comment 25

4 years ago
(In reply to Henrik Skupin (:whimboo) from comment #24)
> Ok, so I re-tried and personally I do not have this problem with latest
> nightly build on OS X 10.10.2. Which version of OS X are you running? Maybe
> it's related to 10.9 or earlier?

I am running on 10.8.5, but I just reproduced this on the 10.10 staging machine. 
So I don't think it's OSX version related.
I observe the same behavior that's described in Comment 23 in current Nightly on OS X 10.10.2 *and* 10.7.5.

The blur() workaround employed in testAccessLocationBar also appears to fail, and so the test itself fails (verified only on  10.10.2).
I think keeping the location bar focused when loading about:blank is the right thing to do. Unfortunately, I don't know why this confuses autocomplete.
Flags: needinfo?(dao)

Comment 28

4 years ago
So after a lot of sad times with autocomplete code, it seems that the issue is that we try to get autocomplete results for about:blank, which yields 2 things neither of which increase the autocomplete controller's mRowCount. In the working case, we try to get results for "".

Marco, any idea why this is and how to fix it (or why it is OSX-only) ?
Flags: needinfo?(mak77)
It's not OSX-only, I can reproduce on Linux.
(In reply to :Gijs Kruitbosch from comment #28)
> Marco, any idea why this is and how to fix it (or why it is OSX-only) ?

nope sorry. Blank pages have indeed a special handling compared to the others, but I can't tell off-hand where that handling fails. I can just exclude it's the search providers, cause they seem to do the right thing based on the string they get.
They should always be requested to search "" on blank pages.
http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/autocomplete.xml#383
Flags: needinfo?(mak77)
Priority: -- → P3
Whiteboard: [mozmill] → [mozmill][fxsearch]
You need to log in before you can comment on or make changes to this bug.