Bug 224967 – [GTK] REGRESSION(r276448): imported/w3c/web-platform-tests/css/selectors/focus-visible-002.html is failing

• Component: New Bugs
• Status: RESOLVED FIXED

[Diego Pino]

The test became a failure after r276448:

https://results.webkit.org/?platform=GTK&suite=layout-tests&test=imported%2Fw3c%2Fweb-platform-tests%2Fcss%2Fselectors%2Ffocus-visible-002.html

https://build.webkit.org/results/GTK-Linux-64-bit-Release-Tests/r276464%20%281341%29/imported/w3c/web-platform-tests/css/selectors/focus-visible-002-diff.txt

--- /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/imported/w3c/web-platform-tests/css/selectors/focus-visible-002-expected.txt
+++ /home/buildbot/worker/gtk-linux-64-release-tests/build/layout-test-results/imported/w3c/web-platform-tests/css/selectors/focus-visible-002-actual.txt
@@ -26,10 +26,10 @@
 PASS Focus element INPUT#input6 via mouse should match :focus-visible as it supports keyboard input
 PASS Focus element INPUT#input7 via mouse should match :focus-visible as it supports keyboard input
 PASS Focus element INPUT#input8 via mouse should match :focus-visible as it supports keyboard input
-PASS Focus element INPUT#input9 via mouse should match :focus-visible as it supports keyboard input
-PASS Focus element INPUT#input10 via mouse should match :focus-visible as it supports keyboard input
-PASS Focus element INPUT#input11 via mouse should match :focus-visible as it supports keyboard input
-PASS Focus element INPUT#input12 via mouse should match :focus-visible as it supports keyboard input
-PASS Focus element INPUT#input13 via mouse should match :focus-visible as it supports keyboard input
+FAIL Focus element INPUT#input9 via mouse should match :focus-visible as it supports keyboard input assert_equals: outlineColor for INPUT#input9 should be green expected "rgb(0, 128, 0)" but got "rgb(0, 0, 0)"
+FAIL Focus element INPUT#input10 via mouse should match :focus-visible as it supports keyboard input assert_equals: outlineColor for INPUT#input10 should be green expected "rgb(0, 128, 0)" but got "rgb(0, 0, 0)"
+FAIL Focus element INPUT#input11 via mouse should match :focus-visible as it supports keyboard input assert_equals: outlineColor for INPUT#input11 should be green expected "rgb(0, 128, 0)" but got "rgb(0, 0, 0)"
+FAIL Focus element INPUT#input12 via mouse should match :focus-visible as it supports keyboard input assert_equals: outlineColor for INPUT#input12 should be green expected "rgb(0, 128, 0)" but got "rgb(0, 0, 0)"
+FAIL Focus element INPUT#input13 via mouse should match :focus-visible as it supports keyboard input assert_equals: outlineColor for INPUT#input13 should be green expected "rgb(0, 128, 0)" but got "rgb(0, 0, 0)"
 PASS Focus element TEXTAREA#input14 via mouse should match :focus-visible as it supports keyboard input

The tests that are failing are related with input=date. r276448 turned on editable input=date for GTK. Perhaps it's enough with updating the test baseline to the new results.

[Manuel Rego Casasnovas]

I've been checking this, there's a kind of weird thing.

For example if we have 2 inputs:
  <input>
  <input type="date">

If we focus the first one we see a blue outline, but not in the 2nd one, and as we don't have a date picker so far, it looks like we should.

Now Element::isTextField() is false, and that's why we're not matching :focus-visible in Element::focus().

Anyway if we have plans to implement the date picker maybe current behavior is not a big deal and we can just update the -expected results. Otherwise we might want to do some other change. Dunno really.

[Diego Pino]

This test is now crashing since r277262.

r277261                       TEXT (Expected: FAIL)
[r277262-r277264]             CRASH (Expected: FAIL)
[r277265-r277267]             UNKNOWN

Craslog:

https://build.webkit.org/results/GTK-Linux-64-bit-Debug-Tests/r277315%20(1048)/imported/w3c/web-platform-tests/css/selectors/focus-visible-002-crash-log.txt

Program terminated with signal SIGSEGV, Segmentation fault.
#0  g_type_check_instance_is_fundamentally_a (type_instance=type_instance@entry=0x561af58003d0, fundamental_type=fundamental_type@entry=80) at ../gobject/gtype.c:4082
4082	  node = lookup_type_node_I (type_instance->g_class->g_type);
[Current thread is 1 (Thread 0x7f97210a2200 (LWP 14256))]

Thread 1 (Thread 0x7f97210a2200 (LWP 14256)):
#0  g_type_check_instance_is_fundamentally_a (type_instance=type_instance@entry=0x561af58003d0, fundamental_type=fundamental_type@entry=0x50 [GObject]) at ../gobject/gtype.c:4082
#1  0x00007f9722962e82 in g_object_ref (_object=_object@entry=0x561af58003d0) at ../gobject/gobject.c:3389
#2  0x00007f97243aaddd in gtk_window_real_set_focus (window=<optimized out>, focus=0x561af55ed080 [WebKitWebViewBase]) at ../gtk/gtkwindow.c:8711
#9  0x00007f97229779c3 in <emit signal ??? on instance 0x561af55ed080 [WebKitWebViewBase] or 0x561af5882a50 [GtkWindow]> (instance=instance@entry=0x561af55ed080, signal_id=<optimized out>, detail=detail@entry=0) at ../gobject/gsignal.c:3553
    #3  0x00007f972295df3f in g_closure_invoke (closure=closure@entry=0x561af506cef0, return_value=return_value@entry=0x0, n_param_values=2, param_values=param_values@entry=0x7ffe4d3fbd70, invocation_hint=invocation_hint@entry=0x7ffe4d3fbcf0) at ../gobject/gclosure.c:810
    #4  0x00007f9722970769 in signal_emit_unlocked_R (node=node@entry=0x561af505bb70, detail=detail@entry=0, instance=instance@entry=0x561af5882a50, emission_return=emission_return@entry=0x0, instance_and_params=instance_and_params@entry=0x7ffe4d3fbd70) at ../gobject/gsignal.c:3780
    #5  0x00007f9722977861 in g_signal_emit_valist (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>, var_args=var_args@entry=0x7ffe4d3fbf10) at ../gobject/gsignal.c:3497
    #6  0x00007f97229779c3 in g_signal_emit (instance=<optimized out>, signal_id=<optimized out>, detail=<optimized out>) at ../gobject/gsignal.c:3553
    #7  0x00007f972295e179 in _g_closure_invoke_va (closure=closure@entry=0x561af506dc60, return_value=return_value@entry=0x0, instance=instance@entry=0x561af55ed080, args=args@entry=0x7ffe4d3fc1e0, n_params=0, param_types=0x0) at ../gobject/gclosure.c:873
    #8  0x00007f97229777df in g_signal_emit_valist (instance=0x561af55ed080, signal_id=<optimized out>, detail=0, var_args=var_args@entry=0x7ffe4d3fc1e0) at ../gobject/gsignal.c:3406
#10 0x00007f972439762a in gtk_widget_grab_focus (widget=0x561af55ed080 [WebKitWebViewBase]) at ../gtk/gtkwidget.c:8097
#11 0x00007f972bb596b0 in webkitWebViewBaseSynthesizeMouseEvent(_WebKitWebViewBase*, MouseEventType, unsigned int, unsigned short, int, int, unsigned int, int, WTF::String const&) (webViewBase=0x561af55ed080 [WebKitWebViewBase], type=MouseEventType::Press, button=1, buttons=256, x=96, y=444, modifiers=0, clickCount=1, pointerType=...) at ../../Source/WebKit/UIProcess/API/gtk/WebKitWebViewBase.cpp:2726

[Diego Pino]

Created attachment 448204 [details]
[fast-cq] Patch

[Diego Pino]

Crash was fixed by https://bugs.webkit.org/show_bug.cgi?id=225659.

I'm emitting a new baseline for GTK. The test will start failing again once `<form type=date>` is implemented.

[EWS]

Committed r287528 (245663@main): <https://commits.webkit.org/245663@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 448204 [details].

[Radar WebKit Bug Importer]

<rdar://problem/87058536>