Bug 99356 - Using tab after find-as-you-type should be firefox-like
Summary: Using tab after find-as-you-type should be firefox-like
Status: RESOLVED UNMAINTAINED
Alias: None
Product: konqueror
Classification: Applications
Component: khtml (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR wishlist
Target Milestone: ---
Assignee: Konqueror Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-02-14 14:52 UTC by Urs Dönni
Modified: 2024-05-06 18:39 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Urs Dönni 2005-02-14 14:52:58 UTC
Version:           3.3.92 (using KDE 3.3.92 (beta2), compiled sources)
Compiler:          gcc version 3.3.4
OS:                Linux (i686) release 2.4.29

I'll explain my wish with an example:
When I want to enter my username on http://forums.gentoo.org/ (text field on bottom of page) this is pretty easy in firefox. You search for the word "username", press "tab" - and your in the textfield! This is extremely convenient when you don't want to work with the mouse all the time.
In konqueror, I can't do the same without having to "tab" several times until I get where I want.
I suggest the following: when something is selected (for example after you find a string with find-as-you-type) and then "tab" is pressed, the first link after the selection should be marked.
Comment 1 Krishna Sethuraman 2005-02-19 18:03:41 UTC
I tried this by find-as-you-type ing the 'Add CC:' text in front of the field in the bugs.kde.org page for this bug, and it seemed to tab properly into the text field next to it.  However, when I tried it with the 'Additional Comments' text, it jumped into the 'Add CC' field.

The feature works quite well otherwise,  Thanks for adding it.
Krishna Sethuraman

P.S. I suspect this could be difficult, selecting the 'next' element based on it lying physically proximate on the rendered page, rather than nearby in the source markup or the DOM tree.  But not being versed in HTML rendering, I'm really not qualified to comment.  See also bug 51259 , comments 38 and 39.

Ref also https://bugzilla.mozilla.org/show_bug.cgi?id=239175#c1
Comment 2 Urs Dönni 2005-02-20 12:07:50 UTC
Ah, I see how it works:
When you press "tab" it selects the first link on the page that is visible in the konqueror window (that is why "add cc: " worked and "additional comments" didn't work).
I still think tab should work differently, because:
If you have multiple columns on a page (like on slashdot.org), and you would like to select a link or a textfield in the column in the middle or on the right side, then there's no easy way: pressing tab will always select the first link in the left column (try to select the textfild for "Nickname" on slashdot.org - that's pretty hard without using the mouse).
The way firefox does this is IMHO much more convenient.
Comment 3 Sebastian Sauer 2005-03-21 05:02:58 UTC
Hi Urs,

please take a look at the wishes #53166 or #97068 or #97068 ... they are very similar to what your wish is about. Maybe it would be an idear, to just choose on of them, vote for it and close this wishreport?
I guess that would make it on the one hand easier for people with a similar wish and on the other hand would increase the number of votes for this feature :)
Thanks for the feedback.
Comment 4 Krishna Sethuraman 2006-12-12 05:44:23 UTC
One partial workaround for this is konqueror's excellent access-keys implementation.  Tap Control, and the access keystrokes for up to 36 (?) (a-z0-9) elements (including links and text areas) are displayed.  The keys are automatically assigned if otherwise unspecified by the HTML -- much smarter than opera, which just says 'No access keys have been defined for this page'.
Comment 5 Christoph Cullmann 2024-05-06 18:39:17 UTC
Dear user,

KHTML (and KJS) was a long time more or less unmaintained and got removed in KF6.

Please migrate to use a QWebEngine based HTML component.

We will do no further fixes or improvements to the KF5 branches of these components beside important security fixes.

For security issues, please see:

https://kde.org/info/security/

Sorry that we did not fix this issue during the life-time of KHTML.

Greetings
Christoph Cullmann