css doesn't work correctly on FocusOut event
Germain Garand
germain at ebooksfrance.org
Tue Mar 25 14:50:13 GMT 2008
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
More information about the kfm-devel
mailing list