Bug 16910 – [GTK] REGRESSION: keyboard cursor doesn't blink

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Luca Bruno]

In latest clean build r29592 i discovered the cursor doesn't blink when in entry texts or in other text widgets.
I'm using GTK+ 2.12.1-r2.

[Alp Toker]

Regression appears to have been introduced in r29581. Upgrading to P1.

[Timothy Hatcher]

This should be fixed in r29629.

[Adam Roben (:aroben)]

Lethalman in #webkit-gtk says this is not fixed.

[Adam Roben (:aroben)]

Looks like the GTK code never calls FocusController::setActive. This used to happen as a side-effect of FocusController::setFocusedFrarme, but no longer does.

GTK's WebView needs to call FocusController::setActive whenever the window containing the WebView becomes the topmost window.

[Adam Roben (:aroben)]

(In reply to comment #4)
> GTK's WebView needs to call FocusController::setActive whenever the window
> containing the WebView becomes the topmost window.

This may not be strictly true. On Mac/Windows, we have to call setActive at this time because we want the color of the form controls in the WebView to change regardless of whether the WebView is focused or not. If in GTK there's nothing that changes based on whether the window is the topmost or not, then you could call setActive when, for example, the WebView gets focused.

[Alp Toker]

(In reply to comment #5)
> (In reply to comment #4)
> > GTK's WebView needs to call FocusController::setActive whenever the window
> > containing the WebView becomes the topmost window.
> 
> This may not be strictly true. On Mac/Windows, we have to call setActive at
> this time because we want the color of the form controls in the WebView to
> change regardless of whether the WebView is focused or not. If in GTK there's
> nothing that changes based on whether the window is the topmost or not, then
> you could call setActive when, for example, the WebView gets focused.
> 

GTK+ also has this concept of top-level window focus, so we probably need to do the same thing.

[Luca Bruno]

Created attachment 18532 [details]
patch for focusing

Fixes also http://bugs.webkit.org/show_bug.cgi?id=16863

[Adam Roben (:aroben)]

Comment on attachment 18532 [details]
patch for focusing

Is there a way to hook this call up to the "top-most window" concept, which Alp says GTK does have?

[Luca Bruno]

Created attachment 18533 [details]
toplevel focus

From devhelp: gtk_window_has_toplevel_focus Returns whether the input focus is within this GtkWindow.

Does this match the Mac meaning of topmost window? I'm poor with English in this case :)

[Alp Toker]

Comment on attachment 18533 [details]
toplevel focus

r=me

This fixes the regressions.

We will still need to look at fixing focus handling properly some time.

There are a few * position style issues here I'll have to fix up before landing.

[Alp Toker]

Landed in r29665.