Some UI operations work with focused frames.
Created attachment 72406 [details] proposed patch Some notes of interest: 1. I don't know why exactly there are separate setFocusedNode() and setFocusedFrame() methods on FocusController. Just matching that in client, even though it seems that one could calculate focused frame from focused node. 2. FocusController's notion of "focused" is different from WebView's. For example, -[WebView _focusedFrame] would return null when keyboard focus is in page find banner in Safari, but FocusController simply remembers the last focused subframe, and also has an isActive() method. I don't know what makes more sense, so I just exposed FocusController's notion. This might be a mistake. 3. Ultimately, this WKPageGetFocusedFrame() is going to be used as a replacement for -[WebView selectedFrame]. As documented (and implemented), selectedFrame @discussion Returns the frame that contains the first responder, if any. Otherwise returns the frame that contains a non-zero-length selection, if any. Returns nil if no frame meets these criteria. WKPageGetFocusedFrame() is different in a single case: 1. Click in a frame. 2. Click on address bar, or press Cmd+F. WKPageGetFocusedFrame will return that last click frame, but selectedFrame will return null. There is no visual indication for focused frame, so it was strange that we recognized it in some situations, but not in others.
Comment on attachment 72406 [details] proposed patch View in context: https://bugs.webkit.org/attachment.cgi?id=72406&action=review > WebKit2/WebProcess/WebCoreSupport/WebChromeClient.cpp:117 > + WebFrame* webFrame = static_cast<WebFrameLoaderClient*>(frame->loader()->client())->webFrame(); Extra space after = sign on this line.
> Extra space after = sign on this line. This was copied from elsewhere in this file. Fixed all instances. Committed <http://trac.webkit.org/changeset/71541>.
*** Bug 46165 has been marked as a duplicate of this bug. ***