[Webkit-unassigned] [Bug 43498] [Qt] add an API for QWebPage to get current focused element

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=43498


Antonio Gomes <tonikitoo at webkit.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX




--- Comment #18 from Antonio Gomes <tonikitoo at webkit.org>  2010-08-25 21:21:55 PST ---
WONTFIX'ing this one. Please re-open if there is still stuff to be discussed here.

(In reply to comment #16)
> OK, one user case I can find is the Next button on VKB. Like android's browser does, when user clicks the next button, it scrolls user to the next input field (e.g. form field). In this case, we need to know the focused element to get its info. It would be better to get the focused element as fast as possible, then the app can start scrolling quickly (the user don't want to wait after click the next button).

The snippet code Simon provide should run *really* fast, even on mobo devices, since it relies on a simple and well known/supported pseudo-selector (:focus). If it is not working as fast as you need, please file a bug about that. Providing profile data is even more helpful.

As far as I know, there is no API for such scrolling-an-element-into-view action, but it'd be another bug. 

An important detail is that depending on how the window system handles the pop up and hiding of the virtual keyboard, scrolling an element into view might be simple or less-simple. Cases:

1) If when the vkb pops up, the windowing system resizes the application window, it is all fine.

2) Otherwise, the vkb needs to provide a way to get its bounding area, and it has to be considered when scrolling an element into view.


> Also, I noticed that Mac's WebHTMLView.mm has a function to get accessibilityFocusedUIElement. Don't really know what it is but I think it would be friendly to developer to have this kind of Api, or just like Antonio Gomes says, added a snippet code example to the dev documentation.

I vote for the later.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.