Summary: | [GTK] REGRESSION: keyboard cursor doesn't blink | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Luca Bruno <lethalman88> | ||||||
Component: | WebKitGTK | Assignee: | 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
Luca Bruno
2008-01-17 13:41:29 PST
Regression appears to have been introduced in r29581. Upgrading to P1. Lethalman in #webkit-gtk says this is not fixed. 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. (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. (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. Created attachment 18532 [details] patch for focusing Fixes also http://bugs.webkit.org/show_bug.cgi?id=16863 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?
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 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.
Landed in r29665. |