Bug 43498 – [Qt] add an API for QWebPage to get current focused element

• Component: WebKit Qt
• Status: RESOLVED WONTFIX

[Yi Shen]

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.

[Yi Shen]

Created attachment 63473 [details]
first try

[Ariya Hidayat]

API addition needs to be discussed, might be too late for 4.7?

In all cases, a new function will need \since tag.

[Yi Shen]

Created attachment 64115 [details]
add since tag

[Yi Shen]

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 :)

[Eric Seidel (no email)]

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?

[Eric Seidel (no email)]

https://developer.mozilla.org/en/DOM/selection

[Csaba Osztrogonác]

I cc-ed Simon and Kenneth, they are the competent persons for API changes.

[Simon Hausmann]

If at all then this method belongs into QWebFrame.

Doesn't the following code work alternatively?

QWebElement focusedElement = frame->findFirstElement("*:focus");

[Yi Shen]

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.

[Simon Hausmann]

(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?

[Ariya Hidayat]

> QWebFrame* frame = page->currentFrame();

Is this the same as 'focusedFrame'?

[Antonio Gomes]

(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.

[Ariya Hidayat]

> 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.

[Antonio Gomes]

 
> 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.

[Ariya Hidayat]

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 :)

[Yi Shen]

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 :)

[Ariya Hidayat]

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).

[Antonio Gomes]

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.

[Yi Shen]

Thanks a lot for all your comments. I really appreciate it!