Bug 16910

Summary: [GTK] REGRESSION: keyboard cursor doesn't blink
Product: WebKit Reporter: Luca Bruno <lethalman88>
Component: WebKitGTKAssignee: Nobody <webkit-unassigned>
Status: RESOLVED FIXED    
Severity: Normal CC: alp, aroben, tonikitoo
Priority: P1 Keywords: Gtk
Version: 528+ (Nightly build)   
Hardware: PC   
OS: Linux   
Attachments:
Description Flags
patch for focusing
none
toplevel focus alp: review+

Description Luca Bruno 2008-01-17 13:41:29 PST
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.
Comment 1 Alp Toker 2008-01-18 00:55:55 PST
Regression appears to have been introduced in r29581. Upgrading to P1.
Comment 2 Timothy Hatcher 2008-01-18 11:52:19 PST
This should be fixed in r29629.
Comment 3 Adam Roben (:aroben) 2008-01-18 12:00:15 PST
Lethalman in #webkit-gtk says this is not fixed.
Comment 4 Adam Roben (:aroben) 2008-01-18 12:07:36 PST
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.
Comment 5 Adam Roben (:aroben) 2008-01-18 12:13:35 PST
(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.
Comment 6 Alp Toker 2008-01-18 12:20:11 PST
(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.

Comment 7 Luca Bruno 2008-01-18 13:38:51 PST
Created attachment 18532 [details]
patch for focusing

Fixes also http://bugs.webkit.org/show_bug.cgi?id=16863
Comment 8 Adam Roben (:aroben) 2008-01-18 13:40:38 PST
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?
Comment 9 Luca Bruno 2008-01-18 14:18:55 PST
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 :)
Comment 10 Alp Toker 2008-01-18 23:45:34 PST
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.
Comment 11 Alp Toker 2008-01-18 23:51:37 PST
Landed in r29665.