180656 - Ability to chancel link focus with ESCAPE key

Status: RESOLVED EXPIRED

(Core :: DOM: UI Events & Focus Handling, enhancement)

Description

[Navin]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021029 Phoenix/0.4
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2b) Gecko/20021029 Phoenix/0.4

Hi, I was hoping to suggest an enhancement on the typeahead functionality.
Currently if you visit a link, the focus remains on that link. The next
typeahead find continues down from that link and not from the top of the 'view'.
Can you please support a timeout on 'blurring' the focus on the link. Or, you
could also support ESC to loose focus on that link. Currently the first ESC
unhighlights the find, the second ESC could help in loosing focus on the focused
link. Thus if the user types in a character for a typeahead find then the find
will occur from the top of the current view of the page.

Please visit http://bugzilla.mozilla.org/show_bug.cgi?id=30088 - Comment 268 for
more details.

-Thanks. Navin

Reproducible: Always

Steps to Reproduce:
1. Visit slashdot.org and press page-down thrice to go to the fourth page.
2. Press Control+Enter (or mouse middle click) to open a link in the background
in a new tab.
3. Notice that the focus remains on the link you just clicked on. Now press
page-up twice to come to the second page. 
4. Press a character for a link visible on the view. Notice that the typeahead
will take the search down from the focused link and then wrap around to the top.

Actual Results:  
The typeahead searches down from a focused link and then wraps around to the top.

Expected Results:  
The typeahead find should, ideally, always search from the top of the viewable
area. Or, atleast the user can consciously press ESC after the first find to
unfocus the currently focussed link.

Comment 1

[Daniel Wang]

see bug 168634 comment 1

dupe of bug 146045?

Comment 2

[Aaron Leventhal]

I don't like the summary change. I think the bug should be titled "Always start
new typeaheadfind from top of visible area"

Comment 3

[Owen Marshall (Not reading bugmail)]

No duplicate. That bug deals with form elements, and was filed before anyone 
started work on typeahead.

Why does this not block 30088? I had it set like that...

blocks --> 30088
(wow, this will spam the universe...again...)

Comment 4

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 5

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.