Closed Bug 597009 Opened 14 years ago Closed 6 years ago

Select the first item of the location/awersome bar to allow hiting Enter on keyboard directly if autocomplete is disable or escaped

Categories

(Firefox :: Address Bar, enhancement)

3.6 Branch
enhancement
Not set
normal

Tracking

()

RESOLVED INACTIVE
Tracking Status
blocking2.0 --- -

People

(Reporter: NicolasWeb, Unassigned)

References

Details

(Keywords: parity-chrome, parity-safari)

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; fr; rv:1.9.2.9) Gecko/20100824 Firefox/3.6.9 Build Identifier: Select the first item of the location/awersome bar to allow hiting Enter on keyboard directly. This should be the behavior at least until bug 566489 land. As it seams to me lagging, I beleve that implementing this could be easier (and done in time for Fx4) Reproducible: Always Actual Results: 1.type in location bar to go to a web site 2.hit the down arrow of the keyboard 3.hit Enter on the keyboard Expected Results: 1.type in location bar to go to a web site 2.hit Enter on the keyboard
Whiteboard: [parity-chrome]
If not blockink the release of Fx4, could it be tag as wanted 4.0, or final, ... ?
blocking2.0: --- → ?
I am not sure if a bug was filed on this, but Mardak implemented this functionality in "Enter Selects" extension. https://addons.mozilla.org/addon/7423/
This isn't really what we want to do, we prefer supporting autocomplete instead, so the people that "speak URL" get a good solution too. See bug 566489 for tracking this.
(In reply to comment #3) > This isn't really what we want to do, we prefer supporting autocomplete > instead, so the people that "speak URL" get a good solution too. Ok, but if the new smart autocomplete (bug 566489) is disable (by pref) or escaped (by key "Esc"), then the fist item of the location bar should be selected (aka : this bug should be the normal behavior) ;-) In this way it's good an fast for URL and non-URL speakers ;-) Safari is doing this : - Showing results with the first item selected - User press Esc - Showing autocomplete of URL
Summary: Select the first item of the location/awersome bar to allow hiting Enter on keyboard directly → Select the first item of the location/awersome bar to allow hiting Enter on keyboard directly if autocomplete is disable or escaped
Whiteboard: [parity-chrome] → [parity-chrome], [parity-safari]
As per Limi, I think this is WONTFIX. I agree with that conclusion.
Status: UNCONFIRMED → RESOLVED
blocking2.0: ? → -
Closed: 14 years ago
Resolution: --- → WONTFIX
(In reply to comment #5) > As per Limi, I think this is WONTFIX. I agree with that conclusion. Sorry to be insistant... Ok, but his conclusion is not exclusive : > (In reply to comment #3) > Ok, but if the new smart autocomplete (bug 566489) is disable (by pref) or > escaped (by key "Esc"), then the fist item of the location bar should be > selected For non-url speakers (aka when autocomplete is disable by pref for those that don't want it) it could be nice and easy to implement to select the first item of the loacation bar. > Safari is doing this : > - Showing results with the first item selected > - User press Esc > - Showing autocomplete of URL We can do the same steps but in the opposite way, so the new default behavior (autocomplet) is respected (the first one) : 1- Showing autocomplete of URL 2- User press Esc 3- Showing results with the first item selected 4- User press Esc : cancel the modifications that have already been made in location bar (actual behaviour I mean) So The only thing we have to implement are steps 2 and 3 ;-) >
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
blocking2.0: - → ?
Not blocking.
blocking2.0: ? → ---
blocking2.0: --- → -
Version: unspecified → 3.6 Branch
(In reply to Mike Beltzner [:beltzner] from comment #5) > As per Limi, I think this is WONTFIX. I agree with that conclusion. So, this bug going to marked WONTFIX or Not??? To BE or NOT TO Be is the Question....
enh request, no reason to stay unconfirmed.
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
No longer blocks: 566489
Depends on: 566489
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Whiteboard: [parity-chrome], [parity-safari]
Status: NEW → RESOLVED
Closed: 14 years ago6 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.