[Webkit-unassigned] [Bug 61532] A focusedNode should be kept in each TreeScope, not in each Document.

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Sun May 29 23:44:10 PDT 2011


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





--- Comment #3 from Hayato Ito <hayato at chromium.org>  2011-05-29 23:44:10 PST ---
Thank you for the comment. I appreciate it.

(In reply to comment #2)
> That sounds good to me. Putting activeElement on TreeScope and having it point to the shadow host when an element in the shadow has focus sounds good.
> 
> I don’t understand why focusedNode belongs on TreeScope. Is focusedNode() the same for all TreeScopes in a document? Why does having focusedNode on TreeScope make things easier?
> 
> focusedNode is completely internal to WebKit, right? Who uses it? Why would making it non-0 when a frame is focused make things easier? Seems like it might be good to know when you’re crossing an iframe boundary.

That's good point. Actually we don't need maintain each focusedNode in each scope. We can calculate an upper scope's direct focused child on the fly once we know a deepest focused Node.
e.g. If we know E is focused, we can easily calculate that A's direct focused child is B.

  - shadow-host - A
     - shadow-host - B
        - iframe - C
           - shadow-host - D
                <input> E ---> focused

Maybe the similar discussion can apply to the Document::m_focusedNode. A focusedNode is the same for all Documents (and iframes) within one 'page', isn't it? We can calculate each iframe's activeElement on the fly only if we know a deepest focused Node. Document::activeElement() is actually doing that. It looks that Document::m_focusedNode is only used internally to make implementations simpler.
I'd would like to treat iframe and shadow-root uniformly.
  - Both maintain a focusedNode.
  - Or neither maintain focusedNode. Only focusedController maintains focusedNode within one page.

I've not started to try implementation of this idea, so having focusedNode in each TreeScope might not be a good idea.  Anyway, it should be just a implementation detail, so I might change my mind if things won't go well as I expected.


> 
> Another question: What happens when you have this?
> 
> Document
>   - <shadow-host> <--- A
>     … shadow-root
>       - <content>
>     - <input> <--- B
> 
> Say node B has focus. Is the activeElement of the document A or B?

Interesting. In this case, document.activeElement should be 'A' for me at the first glance.
But we should discuss which is better and natural.

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


More information about the webkit-unassigned mailing list