[webkit-reviews] review requested: [Bug 48685] Notify UI process about focused frame : [Attachment 72406] proposed patch

[bugzilla-daemon at webkit.org]

Alexey Proskuryakov <ap at webkit.org> has asked  for review:
Bug 48685: Notify UI process about focused frame
https://bugs.webkit.org/show_bug.cgi?id=48685

Attachment 72406: proposed patch
https://bugs.webkit.org/attachment.cgi?id=72406&action=review

------- Additional Comments from Alexey Proskuryakov <ap at webkit.org>
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.