[GTK] Test cases for typehead in form menu lists should start from known state

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Adrian Perez]

See bug #171492 for details, in particular this comment:

  https://bugs.webkit.org/show_bug.cgi?id=171492#c2

The TL;DR is:

  * The “testTypeAheadFunction()“ function doesn't set an initial
    state: the result each call is dependent on the state in which
    previous calls left the element.

  * The fix for bug #170680 introduced pre-selection of the active
    element when the popup menu appears, to mimic the behavior of
    GtkComboBox.
 
    Before, when popping up the menu, the type-ahead search (which
    is implemented in GTK+) would always start from the beginning of
    the list. Now that we tell GTK+ to preactivate an item, it does
    not and the layout test breaks.

[Adrian Perez]

Created attachment 309321 [details]
Patch

[Adrian Perez]

Created attachment 309322 [details]
Patch

[Adrian Perez]

(In reply to Adrian Perez from comment #0)
> See bug #171492 for details, in particular this comment:
> 
>   https://bugs.webkit.org/show_bug.cgi?id=171492#c2
>
> [...]
>  
>     Before, when popping up the menu, the type-ahead search (which
>     is implemented in GTK+) [...]

Well, forget about this comment: I have just noticed that the type-ahead
search is implemented in “WebPopupMenuProxyGtk::typeAheadFind()”. The
fact that the test should start from a known state still applies :-P

[Michael Catanzaro]

What is the blur for?

[Adrian Perez]

(In reply to Michael Catanzaro from comment #4)
> What is the blur for?

It causes the HTML element to lose keyboard focus:

 https://developer.mozilla.org/en-US/docs/Web/API/HTMLElement/blur

When the HTML for the layout test is loaded, the <select> element is
not focused, so calling “.blur()” on it ensures that it is not focused
before “testTypeAheadFunction()” starts sending mouse and keyboard
events, regardless of the state it was left on previous uses of the
function.

(NB: It does not really make a difference here, but for consistency
it seems like a good idea to remove the focus from the element as well
to guarantee the same state as after page load.)

[Adrian Perez]

Created attachment 309327 [details]
Patch

[Adrian Perez]

I did some double checking, and right after page load the first element
is the selected one, so the patch is not updated to set “.selectedIndex=0”.

[Carlos Garcia Campos]

Comment on attachment 309327 [details]
Patch

Wait, r171792 has nothing to do with this, it's a very old revision

[Carlos Garcia Campos]

(In reply to Carlos Garcia Campos from comment #8)
> Comment on attachment 309327 [details]
> Patch
> 
> Wait, r171792 has nothing to do with this, it's a very old revision

It seems you used the bug number, instead of the revision number.

[Adrian Perez]

(In reply to Carlos Garcia Campos from comment #9)
> (In reply to Carlos Garcia Campos from comment #8)
> > Comment on attachment 309327 [details]
> > Patch
> > 
> > Wait, r171792 has nothing to do with this, it's a very old revision
> 
> It seems you used the bug number, instead of the revision number.

You are right, the correct revision is r215188:

  http://trac.webkit.org/changeset/215188

I'll update the ChangeLog accordingly before landing this.

[Adrian Perez]

Committed r217554: <http://trac.webkit.org/changeset/217554>