Bug 111999 – [EFL] accessibility/disabled-controls-not-focusable.html is failing

• Component: WebKit EFL
• Status: RESOLVED WONTFIX

[Krzysztof Czech]

accessibility/disabled-controls-not-focusable.html is failing on all EFL platforms.

[Krzysztof Czech]

Created attachment 213775 [details]
Patch

[Krzysztof Czech]

Created attachment 213776 [details]
Patch

[Mario Sanchez Prada]

It's very weird that we need this specific expectation here (same for GTK), since it seems the only difference compared to the cross-platform expected results is that a blank space is missing in the first line (before "This test makes sure...").

I've observed that if I comment out the debug(element.id) line in the test, then the number of blank spaces there is always the same, which suggests that something is wrong with our version of DRT/WKTR (also happens there), potentially causing more trouble in other tests.

You can check yourself this weird situation by checking the diff

  $ diff -u \
    ./platform/gtk/accessibility/disabled-controls-not-focusable-expected.txt \
    ./accessibility/disabled-controls-not-focusable-expected.txt

You will see how there are only 16 spaces in the first line of the output for the GTK specific version (identical to the one for EFL you are adding here now) and 17 spaces for the other version.

How do you feel about investigating this issue instead of rebaselining this test?

[Krzysztof Czech]

> How do you feel about investigating this issue instead of rebaselining this test?
You are right, the difference is only in one space. Seems very weird.
I will take a look at this.

[Grzegorz Czajkowski]

As Mario said, the difference between cross-platform expectation and GTK/EFL is one space that seems to be missing.

The problem is with dumping (via dumpAsText) the first <div>...</div> element which contains various HTML elements to be tested:

<div>
  <button id="button"></button>
  <input id="text" type="text">
  <input id="checkbox" type="checkbox">
  <input id="radio" type="radio">
  <input id="submit" type="submit">
  <input id="slider" type="range">
  <select id="listbox" multiple><option>1<option>2</select>
  <select id="combobox"><option>1<option>2</select>
  <textarea id="textarea"></textarea>
</div>

It seems that while dumping tree to text, we erroneously replace the last space with '\n' character indicating the end of div element.

I've observed that if I exclude some elements from div, then the number of spaces seems fine. It looks that the problematic elements are:

<input id="text" type="text">
<input id="submit" type="submit">
<input id="slider" type="range">
<select id="combobox"><option>1<option>2</select>
<textarea id="textarea"></textarea>

To check this, try to comment out one of above elements and then the number of spaces (decreased by removed element) is OK.

What I found surprising that those elements cause problems only with this div element and its children. As a result, we cannot simplify the test case by defining own div, for example
<div>
  <button id="button"></button>
  <input id="text" type="text"> <!-- cause problems in our accessibility test -->
</div>
because its output is correct here.

As you've already mention, this bug is not related to accessibility at all and I could help in solving it. Do you guys prefer to continue work in this bug or creating a new one due to its core background? Then we could land EFL test expectation.

CC'ing authors of editing/TextIterator where I see difference of behaviour between Mac and EFL/GTK (probably the cause of bug is somewhere deeper).

[Darin Adler]

We should keep reducing this to the smallest possible test case.

[Gyuyoung Kim]

Krzystof, any update ?

[Krzysztof Czech]

(In reply to comment #7)
> Krzystof, any update ?
Basically this issue is not related to Accessibility. I will create a bug to handle this problem.

[Krzysztof Czech]

> I will create a bug to handle this problem.
https://bugs.webkit.org/show_bug.cgi?id=128522

[WebKit Commit Bot]

Comment on attachment 213776 [details]
Patch

Rejecting attachment 213776 [details] from commit-queue.

Failed to run "['/Volumes/Data/EWS/WebKit/Tools/Scripts/webkit-patch', '--status-host=webkit-queues.webkit.org', '--bot-id=webkit-cq-01', 'apply-attachment', '--no-update', '--non-interactive', 213776, '--port=mac']" exit_code: 2 cwd: /Volumes/Data/EWS/WebKit

Last 500 characters of output:
g file LayoutTests/ChangeLog
Hunk #1 succeeded at 1 with fuzz 3.
patching file LayoutTests/platform/efl-wk2/TestExpectations
Hunk #1 FAILED at 160.
1 out of 1 hunk FAILED -- saving rejects to file LayoutTests/platform/efl-wk2/TestExpectations.rej
patching file LayoutTests/platform/efl/accessibility/disabled-controls-not-focusable-expected.txt

Failed to run "[u'/Volumes/Data/EWS/WebKit/Tools/Scripts/svn-apply', '--force', '--reviewer', u'Darin Adler']" exit_code: 1 cwd: /Volumes/Data/EWS/WebKit

Full output: http://webkit-queues.webkit.org/results/948700

[Michael Catanzaro]

Closing this bug because the EFL port has been removed from trunk.

If you feel this bug applies to a different upstream WebKit port and was closed in error, please either update the title and reopen the bug, or leave a comment to request this.