Bug 43498 - [Qt] add an API for QWebPage to get current focused element
Summary: [Qt] add an API for QWebPage to get current focused element
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Qt (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Enhancement
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-08-04 11:43 PDT by Yi Shen
Modified: 2010-08-26 06:21 PDT (History)
7 users (show)

See Also:


Attachments
first try (3.94 KB, patch)
2010-08-04 11:44 PDT, Yi Shen
no flags Details | Formatted Diff | Diff
add since tag (4.05 KB, patch)
2010-08-11 08:01 PDT, Yi Shen
eric: review-
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Yi Shen 2010-08-04 11:43:20 PDT
The QWebPage has no API to retrieve current focused element, although you can use QWebFrame::findAllElement(":focus") to search for the focused element, which is not convenient enough and efficient to use (you have to find the focused frame first). So I am thinking about to add this API, which might be very useful in implementing tab navigation.
Comment 1 Yi Shen 2010-08-04 11:44:29 PDT
Created attachment 63473 [details]
first try
Comment 2 Ariya Hidayat 2010-08-10 23:32:04 PDT
API addition needs to be discussed, might be too late for 4.7?

In all cases, a new function will need \since tag.
Comment 3 Yi Shen 2010-08-11 08:01:07 PDT
Created attachment 64115 [details]
add since tag
Comment 4 Yi Shen 2010-08-11 08:11:39 PDT
Thanks for your comments. I have added a \since tag for it. which can be changed if too late for 4.7.

I would like to have this new Api for qwebpage because I think I am not the only people who has the problem to get the focused element. I have talked to several people to find out a way to get focused element, but had no luck. 

In stead of using CSS selector, why not just provides a straightforward and efficient way to help its developers like me :)
Comment 5 Eric Seidel (no email) 2010-08-12 07:16:14 PDT
Comment on attachment 64115 [details]
add since tag

There is already DOM API for this.  Why would you want to expose new separate Qt API?
Comment 6 Eric Seidel (no email) 2010-08-12 07:17:41 PDT
https://developer.mozilla.org/en/DOM/selection
Comment 7 Csaba Osztrogonác 2010-08-12 07:21:56 PDT
I cc-ed Simon and Kenneth, they are the competent persons for API changes.
Comment 8 Simon Hausmann 2010-08-12 08:59:29 PDT
If at all then this method belongs into QWebFrame.

Doesn't the following code work alternatively?

QWebElement focusedElement = frame->findFirstElement("*:focus");
Comment 9 Yi Shen 2010-08-12 10:47:31 PDT
Yes, I am sure that frame->findFirstElement("*:focus") can work. But to use this, we have to find the focused frame first, then call the findFisrtElement function to search the DOM tree, right? (Please correct me if I am wrong)

So, the only reason I propose this API is to introduce a straightforward and efficient (no need to search DOM tree) way for qtwebkit developer to get the focused element.
Comment 10 Simon Hausmann 2010-08-12 14:05:26 PDT
(In reply to comment #9)
> Yes, I am sure that frame->findFirstElement("*:focus") can work. But to use this, we have to find the focused frame first, then call the findFisrtElement function to search the DOM tree, right? (Please correct me if I am wrong)
> 
> So, the only reason I propose this API is to introduce a straightforward and efficient (no need to search DOM tree) way for qtwebkit developer to get the focused element.

Is it that inconvenient? :)

QWebFrame* frame = page->currentFrame();
QWebElement focusedElement = frame->...


I agree about the efficiency though, that may be a good point for adding a method to QWebFrame.

What are you doing with the focused element once you have retrieved it?
Comment 11 Ariya Hidayat 2010-08-12 14:36:24 PDT
> QWebFrame* frame = page->currentFrame();

Is this the same as 'focusedFrame'?
Comment 12 Antonio Gomes 2010-08-12 17:26:16 PDT
(In reply to comment #11)
> > QWebFrame* frame = page->currentFrame();
> 
> Is this the same as 'focusedFrame'?

QWebFrame *QWebPage::currentFrame() const
{
    d->createMainFrame();
    return static_cast<WebCore::FrameLoaderClientQt *>(d->page->focusController()->focusedOrMainFrame()->loader()->client())->webFrame();
}

looks like it'd work, yes.
Comment 13 Ariya Hidayat 2010-08-12 20:14:49 PDT
> QWebFrame *QWebPage::currentFrame() const
> {
>     d->createMainFrame();
>     return static_cast<WebCore::FrameLoaderClientQt *>(d->page->focusController()->focusedOrMainFrame()->loader()->client())->webFrame();
> }
> 
> looks like it'd work, yes.

Then this patch can't really be justified.
Comment 14 Antonio Gomes 2010-08-12 21:06:20 PDT
 
> Then this patch can't really be justified.

I tend to agree here too. I'd suggest:

1) If we decide to *not* go for it:
1.1) it could be a patch to the documentation in the sense of providing a snippet code for this possibly common task.
1.2) Maybe making it a helper method of your class, for convenience, would be enough.

2) To prove itself as needed:
2.1) Help us to understand your test case, in a broader context. For example, you might be needing to call this method so often that the performance of making it through a CSS selector really matter.
Comment 15 Ariya Hidayat 2010-08-13 05:33:04 PDT
If this is about performance, a use case where focused element needs to be fetched or detected so many times is probably a corner case. It's hard to imagine a type of application which does that :)
Comment 16 Yi Shen 2010-08-13 08:43:09 PDT
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).

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.

Thanks for all the comments and your time :)
Comment 17 Ariya Hidayat 2010-08-13 08:48:45 PDT
Android WebKit does this by caching navigation-able elements in a special tree, so as to avoid looking it up on the fly.

In all cases, such a use case should be implemented using Antonio’s spatial navigation support, which has been there for a while (https://bugs.webkit.org/show_bug.cgi?id=18662).
Comment 18 Antonio Gomes 2010-08-25 21:21:55 PDT
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.
Comment 19 Yi Shen 2010-08-26 06:21:36 PDT
Thanks a lot for all your comments. I really appreciate it!