[webkit-reviews] review granted: [Bug 30482] [GTK] Expose Page::tabKeyCyclesThroughElements in the API : [Attachment 41381] Page for this issue (WebKitWebSettings version)

[bugzilla-daemon at webkit.org]

Gustavo Noronha (kov) <gns at gnome.org> has granted Martin Robinson
<martin.james.robinson at gmail.com>'s request for review:
Bug 30482: [GTK] Expose Page::tabKeyCyclesThroughElements in the API
https://bugs.webkit.org/show_bug.cgi?id=30482

Attachment 41381: Page for this issue (WebKitWebSettings version)
https://bugs.webkit.org/attachment.cgi?id=41381&action=review

------- Additional Comments from Gustavo Noronha (kov) <gns at gnome.org>
(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.