[Webkit-unassigned] [Bug 30482] [GTK] Expose Page::tabKeyCyclesThroughElements in the API

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=30482


Gustavo Noronha (kov) <gns at gnome.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #41381|review?                     |review+, commit-queue+
               Flag|                            |




--- Comment #5 from Gustavo Noronha (kov) <gns at gnome.org>  2009-10-25 10:57:34 PDT ---
(From update of attachment 41381)
(In reply to comment #4)
> (From update of attachment 41381 [details])
> > +    * If @flag is %TRUE, pressing the tab key will focus the next element in
> > +    * the @web_view. If @flag is %FALSE, the @web_view will interpret tab
> > +    * key presses as normal key presses. If the selected element is editable, the
> 
> What's the difference between pressing the tab key and the tab key being
> interpreted as a normal key press?

As I understand it, TRUE will cause tab presses while on a textarea to move the
cursor on to the next element, while FALSE will add \t to the text.

> > +                 "tab-key-cycles-through-elements", &tabKeyCyclesThroughElements,
> 
> I think we prefix boolean settings with enable-.

I think in this case, the setting is more akin to the likes of
'auto-load-images', as in, this is no feature that may be enable/disabled, but
decision on behavior of an already enabled feature (interpreting tab key
presses). I'm in favor of keeping the name as is in the patch, then. I'm going
to go ahead and say r=me.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.