Can't arrow back into location bar once the autocomplete popup has been shown by arrowing down

VERIFIED FIXED in Firefox 36

Status

()

Firefox
Location Bar
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: Rodze, Assigned: Unfocused)

Tracking

({regression})

36 Branch
Firefox 37
x86
Windows 7
regression
Points:
3
Dependency tree / graph
Bug Flags:
firefox-backlog +
in-testsuite +
qe-verify +

Firefox Tracking Flags

(firefox35 unaffected, firefox36+ verified, firefox37+ verified)

Details

Attachments

(1 attachment)

(Reporter)

Description

3 years ago
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:36.0) Gecko/20100101 Firefox/36.0
Build ID: 20141127030208

Steps to reproduce:

1. type "moz" in the awesome bar
2. keyboard arrow down (you must have at least one search result)
3. keyboard arrow up



Actual results:

selected focus jump to last search result


Expected results:

focus should jump to the awesome bar text input with only "moz"

Comment 1

3 years ago
[Tracking Requested - why for this release]:
Status: UNCONFIRMED → NEW
status-firefox35: --- → unaffected
status-firefox36: --- → affected
tracking-firefox36: --- → ?
Component: Untriaged → Location Bar
Ever confirmed: true

Comment 2

3 years ago
https://hg.mozilla.org/integration/fx-team/pushloghtml?fromchange=c294ed0b5502&tochange=1791d8198cc3
Blocks: 1067903
Keywords: regression

Updated

3 years ago
Flags: needinfo?(bmcbride)

Comment 3

3 years ago
I'm pretty sure this got backed out already.
Flags: needinfo?(mak77)

Updated

3 years ago
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Flags: needinfo?(mak77)
Flags: needinfo?(bmcbride)
Resolution: --- → DUPLICATE
Duplicate of bug: 1104985

Comment 5

3 years ago
Ugh. Summary and comment #0 are completely different...
Status: RESOLVED → REOPENED
Flags: needinfo?(mak77)
Flags: needinfo?(bmcbride)
Resolution: DUPLICATE → ---
Summary: awesome bar losing typed text → Can't arrow back into location bar once the autocomplete popup has been shown by arrowing down
there is nothing to track here, we disabled unified complete for now.

Actually I'm not sure IF we want to fix this, the new behavior basically traps the selection in the popup once you enter it, changing that could be problematic, but we'll see.
Blocks: 995091
status-firefox36: affected → unaffected
tracking-firefox36: ? → ---
Flags: needinfo?(mak77)
Flags: needinfo?(bmcbride)

Comment 7

3 years ago
[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

[Tracking Requested - why for this release]:

(In reply to Marco Bonardo [::mak] (needinfo? me) from comment #6)
> there is nothing to track here, we disabled unified complete for now.
> 
> Actually I'm not sure IF we want to fix this, the new behavior basically
> traps the selection in the popup once you enter it, changing that could be
> problematic, but we'll see.

This problem is reproduced on latest Aurora36.0a2 and Nightly37.0a1 which is disabled unified complete.

https://hg.mozilla.org/releases/mozilla-aurora/rev/94333fbcde0b
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:36.0) Gecko/20100101 Firefox/36.0 ID:20141128115136

https://hg.mozilla.org/mozilla-central/rev/17de0f463944
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:37.0) Gecko/20100101 Firefox/37.0 ID:20141128114334


So, I think this is a valid bug and should be tracking.
status-firefox36: unaffected → affected
status-firefox37: --- → affected
tracking-firefox36: --- → ?
tracking-firefox37: --- → ?
Flags: needinfo?(mak77)
oops, yes in such a case we need to fix this asap.

I think the problem here is that we override the index handling, but we should do that only if unified is enabled.
Flags: needinfo?(mak77) → needinfo?(bmcbride)
Eep. Indeed.
Assignee: nobody → bmcbride
Status: REOPENED → ASSIGNED
Points: --- → 3
Flags: needinfo?(bmcbride) → firefox-backlog+
tracking-firefox37: ? → +

Updated

3 years ago
Iteration: --- → 37.1
Flags: qe-verify?
Created attachment 8530762 [details] [diff] [review]
Patch v1
Attachment #8530762 - Flags: review?(mak77)
Comment on attachment 8530762 [details] [diff] [review]
Patch v1

Review of attachment 8530762 [details] [diff] [review]:
-----------------------------------------------------------------

::: browser/base/content/urlbarBindings.xml
@@ +1239,5 @@
>              return -1;
>  
>            let newIndex = index + (reverse ? -1 : 1) * amount;
>  
> +          // We only want to wrap if navigation is in any direction by one item;

s/;/,/

@@ +1246,5 @@
>            // at one end of the list.
> +
> +          if (Services.prefs.getBoolPref("browser.urlbar.unifiedcomplete")) {
> +
> +            if (newIndex < 0) {

nit: I'm not a lover of adding newlines to if/else bodies, while they seem to improve readability (but that's the scope of indentation) they greatly reduce visible context.
Attachment #8530762 - Flags: review?(mak77) → review+
https://hg.mozilla.org/integration/fx-team/rev/0e6026de7539
https://hg.mozilla.org/mozilla-central/rev/0e6026de7539
Status: ASSIGNED → RESOLVED
Last Resolved: 3 years ago3 years ago
status-firefox37: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 37
this should be uplifted to Aurora. Care to ask for approval please?
Verified fixed on Nightly 37.0a1 (2014-12-07) using Windows 7 64-bit, Ubuntu 14.04 LTS 32-bit and Mac OS X 10.9.5.

I'll keep an eye on this for when it lands on m-a.
Status: RESOLVED → VERIFIED
status-firefox37: fixed → verified
Flags: qe-verify? → qe-verify+
Blair, could you fill the uplift request? Thanks
Flags: needinfo?(bmcbride)
Flags: in-testsuite+
tracking-firefox36: ? → +
Comment on attachment 8530762 [details] [diff] [review]
Patch v1

Approval Request Comment
[Feature/regressing bug #]: bug 1067903
[User impact if declined]: Unable to have no URLBar autocomplete item selected, after selecting first item
[Describe test coverage new/current, TBPL]: Unit test, few days on the tree
[Risks and why]: Low risk - restoring previous functionality & code.
[String/UUID change made/needed]: None
Flags: needinfo?(bmcbride)
Attachment #8530762 - Flags: approval-mozilla-aurora?
Attachment #8530762 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
https://hg.mozilla.org/releases/mozilla-aurora/rev/2d389b81fc82
status-firefox36: affected → fixed
I was able to reproduce this bug on Firefox 36.0a1 (2014-11-27) using Windows 7 x64.

Verified fixed on Latest Firefox 36.0a2 (2014-12-11) using Windows 7 x64, Ubuntu 14.04 x86 and Mac OSX 10.9.5.
status-firefox36: fixed → verified
You need to log in before you can comment on or make changes to this bug.