Hi Slava,

Le dimanche 23 mars 2008, Slava Tokarev a écrit :
> Hi, Germain
>
> I'm looking at http://bugs.kde.org/show_bug.cgi?id=159364 KHTML bug.
> Especially at
> http://samples.msdn.microsoft.com/csstestpages/Chapter_5/focus-selector-001
>.htmtest.

at least that specific testcase seem to work fine for me? (I.e. the text goes 
green when focused - though admittedly this is not very visible because my 
french spellchecker almost instantly turns everything back to red :)

> I've debugged konq for a while and found that the possible problem can be
> with handling of FocusOut event. I believe that the possible place to
> update style of TextArea would be render_replaced.cpp::eventFilter(); It's
> called but it doesn't accept event because isRedirectedWidget() is true for
> TextAreaWidget, i.e. it gathers all events by itself.
>
> Can you point me with some direction? Why isRedirectedWidget() is true in
> this case and if it is correct, then how should we (and where) handle style
> changing?

Ah yes, Widgets are a bit complicated ;(
We have two kind of them: external (Qt-native) widgets, and redirected widgets 
(KHTMLWidgets). 

Redirected widgets, though implemented with off-screen Qt widgets, are 
entirely under control of KHTML for both painting and event handling. 

This allows control of precise stacking order when painting (so we may e.g. 
paint other Render objects on top), but also control of the event flow by the 
DOM.

External widgets are controlled by Qt and/or the windowing system, and we have 
not much  bearing upon them.

This is why redirected widgets are standard, and only in very specific cases 
do we fall back to external (e.g. for hosting a netscape plugin, or a java 
applet, or a subframe that itself hosts a netscape plugin).

So this eventFilter() is only part of the fallback mechanism, where we can't 
make the events go through the DOM.

Normal event handling goes through the DOM (for instance, a mouse event would 
be dispatched from KHTMLView to the DOM with the widget as a target, and if 
no event listener intercepts it, it will eventually reach  
HTMLGenericFormElementImpl::defaultEventHandler(EventImpl *evt), that will 
dispatch it to the widget using the RenderWidget::handleEvent(const 
DOM::EventImpl& ev) DOM-event-to-Qt-event translation mechanism.

So in your case, it's in handleEvent() that DOM focus in/out events will reach 
the widget.

But I'm not sure I remember where the change in style is really handled on 
focus out. I think it's probably  when the new DOM focus node is set 
(DocumentImpl::setFocusNode) that the style gets recalculated (and thus 
RenderWidget::setStyle is called).. but I'm not sure where the widget's node 
is marked as changed in this process *shrug*

Greetings,
Germain