Closed
Bug 303928
Opened 20 years ago
Closed 20 years ago
Tabbing or arrowing off autocomplete closes selection and location shows last selected entry
Categories
(Firefox :: Address Bar, defect)
Firefox
Address Bar
Tracking
()
RESOLVED
FIXED
Firefox1.5
People
(Reporter: Mardak, Assigned: zeniko)
References
Details
(Keywords: fixed1.8, regression)
Attachments
(1 file)
2.89 KB,
patch
|
mconnor
:
review+
mtschrep
:
approval1.8b5+
|
Details | Diff | Splinter Review |
Steps to reproduce:
1. Activate autocomplete by typing a character
2. Press tab until the last selection
3. Press tab again
Actual: The last entry goes into the location bar and autocomplete closes.
Expected: Original value in location for before autocomplete should be shown
while keeping autocomplete open.
Last working version is from 20050805. Probably caused by fix for bug 302677.
This also happens when shift-tabbing backwards and then the first selection goes
into the location bar. However, pressing down to show a list of history items
then tabbing off does not cause the problem.
Updated•20 years ago
|
Assignee: nobody → aaronleventhal
Summary: Tabbing off autocomplete closes selection and location shows last selected entry → Tabbing or arrowing off autocomplete closes selection and location shows last selected entry
Comment 1•20 years ago
|
||
*** Bug 305279 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 2•20 years ago
|
||
The problem is an unexpected blur event when setting the focus to the
autocomplete widget (on blurring, the search controller is reset and the popup
closed). This hack prevents this through the introduction of one new focus
method which prevents the unwanted consequences of the blur event.
This bug should probably be resolved at the level of the focus infrastructure,
but until then this low risk patch resolves the regression.
Attachment #194019 -
Flags: review?(mconnor)
Updated•20 years ago
|
Flags: blocking1.8b4?
Comment 3•20 years ago
|
||
Was the orginal patch checked in on the brnach? I see this regression on the
branch too.
Assignee | ||
Comment 4•20 years ago
|
||
The original patch was checked in before branching. This bug applies to the
trunk and the 1.5 branch, now.
Comment 5•20 years ago
|
||
another regression from accessibility changes. beltzner, mconnor: could you
please review from a product standpoint and chime in on what the right behaviour
needs to be here?
Flags: blocking1.8b4? → blocking1.8b4-
Comment 6•20 years ago
|
||
IMO, as reporter indicated seems right. So,
- User enters partial string, auto-complete appears
- TAB, down arrow: move down one entry in list
- Shift+TAB, up arrow: move up one entry in list
- the partial string should be the first/last item in the list
- ESC exits autocomplete mode
If autocomplete mode is exited with ESC, then the URL bar should be set to the
string as entered by the user, not the drop-down selection at the time of the
ESC keystroke. A second ESC should (of course) escape all typing in the URL bar
and return it to its previous state.
Comment 7•20 years ago
|
||
*** Bug 307659 has been marked as a duplicate of this bug. ***
Comment 8•20 years ago
|
||
Comment on attachment 194019 [details] [diff] [review]
prevents detaching the controller
I'm not altogether happy with the overall behaviour/inconsistency here, but
this isn't the time to fight that battle.
Attachment #194019 -
Flags: review?(mconnor) → review+
Assignee | ||
Updated•20 years ago
|
Attachment #194019 -
Flags: superreview?(aaronleventhal)
An additional set of steps to reproduce for what I'm pretty sure qualifies as
the same bug (and is being called that in bug 302677):
* type http://archive.mozilla.org/ in URL bar, press enter
* type http://archive.mozilla.org/pub/mozilla/ in URL bar, press enter
* type "archi" in URL bar, press down arrow to go over all the entries
Actual results: after last entry, http://archive.mozilla.org/pub/mozilla/ is in
the URL bar.
Expected results: after last entry, "archi" is in the URL bar.
These steps regressed between 2005-08-05-05-trunk and 2005-08-06-05-trunk.
Flags: blocking1.8b5?
Comment 10•20 years ago
|
||
Comment on attachment 194019 [details] [diff] [review]
prevents detaching the controller
Toolkit patches don't need superreview and I'm not a superreviewer anyway.
You're ready to check into the trunk, but you'll need approval for branch.
Attachment #194019 -
Flags: superreview?(aaronleventhal)
Assignee | ||
Updated•20 years ago
|
Attachment #194019 -
Flags: approval1.8b5?
Updated•20 years ago
|
Whiteboard: [checkin needed]
Comment 11•20 years ago
|
||
Please land this on the trunk and get the bug resolved so we can verify there
before taking onto the branch. thanks.
Flags: blocking1.8b5? → blocking1.8b5+
Updated•20 years ago
|
Assignee: aaronleventhal → zeniko
Whiteboard: [checkin needed]
Target Milestone: --- → Firefox1.5
Version: Trunk → unspecified
Comment 12•20 years ago
|
||
Trunk:
mozilla/toolkit/content/widgets/autocomplete.xml; new revision: 1.46;
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Updated•20 years ago
|
Attachment #194019 -
Flags: approval1.8b5? → approval1.8b5+
Comment 13•20 years ago
|
||
1.8 Branch:
Checking in autocomplete.xml;
/cvsroot/mozilla/toolkit/content/widgets/autocomplete.xml,v <-- autocomplete.xml
new revision: 1.44.2.2; previous revision: 1.44.2.1
done
Keywords: fixed1.8
You need to log in
before you can comment on or make changes to this bug.
Description
•