User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 I normally use keyboard navigation, especially on sites that ask me for username, password. Sometimes, the input carat is not in the field so I use type-to-find to search for the nearest word before the field and then press TAB to get to the field. This behavior does not work under 1.5b1. TAB will now go to "Match case" in the search bar. If I press TAB again, it goes next to the Address Bar, then Search Bar, then the current page, then the field I want. Needless to say, this is a break in functionality and an annoyance. At least have some configurable option so I can use the old behavior. Reproducible: Always Steps to Reproduce: 1. Enable "Begin finding when you begin typing" in Options, Advanced, General 2. Go to mail.yahoo.com 3. Yahoo actually places your carat on the Yahoo! ID: field. Simulate other websites that don't do this by clicking on any text portion of the web page 4. Now type "sign " w/out the double-quotes 5. Press TAB Actual Results: Step 4. Firefox highlights "Sign " just before the Yahoo! ID: field. Yahoo has several versions of this page so it's important to type correctly instead of blindly typing. Step 5. Under FF1.0.6, the carat is now in the field. Under FF1.5b1, input focus now is on Match case within the find bar. Press TAB again will then place focus to the Address bar, then Search bar, the page, then the Yahoo! ID field. Expected Results: Step 5. Should behave like FF1.0.6.
Assignee: nobody → masayuki
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Summary: Change in behavior with type-to-find and pressing TAB → Change in behavior with type-to-find for non-link text and pressing TAB
Created attachment 197002 [details] [diff] [review] Patch rv1.0
Attachment #197002 - Flags: review?(mconnor)
Whiteboard: [needs review mconnor]
No longer depends on: 307874
Comment on attachment 197002 [details] [diff] [review] Patch rv1.0 Sorry. This patch based old code. I'll create new patch.
Attachment #197002 - Flags: review?(mconnor) → review-
Created attachment 197058 [details] [diff] [review] Patch rv1.1
Attachment #197058 - Flags: review?(mconnor) → review-
Created attachment 197144 [details] [diff] [review] Patch rv1.2 This patch is better than previous. We should use try and chatch for |focus()|. Becuase if the element or window is destroied already(e.g., META refresh), the code is broken. If so, suppressFocusScroll makes serious problem.
Attachment #197144 - Flags: review?(mconnor) → review+
Comment on attachment 197144 [details] [diff] [review] Patch rv1.2 This patch's risk is low. This is a regression.
Attachment #197144 - Flags: approval1.8b5?
checked-in to trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Whiteboard: [needs review mconnor] → [needs approval]
Comment on attachment 197144 [details] [diff] [review] Patch rv1.2 Approved per 9/26 bug triage meeting. Please land tomororw after you confirm that nightly trunk builds are fine.
Attachment #197144 - Flags: approval1.8b5? → approval1.8b5+
checked-in to 1.8 branch.
Whiteboard: [needs approval]
You need to log in before you can comment on or make changes to this bug.