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

[bugzilla-daemon at webkit.org]

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


Grzegorz Czajkowski <g.czajkowski at samsung.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |darin at apple.com,
                   |                            |g.czajkowski at samsung.com,
                   |                            |justin.garcia at apple.com,
                   |                            |rniwa at webkit.org




--- Comment #5 from Grzegorz Czajkowski <g.czajkowski at samsung.com>  2013-10-18 07:30:11 PST ---
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).

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