Bug 194764 - Some refinements for Node and Document
Summary: Some refinements for Node and Document
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: DOM (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Darin Adler
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2019-02-17 12:20 PST by Darin Adler
Modified: 2019-02-22 17:04 PST (History)
6 users (show)

See Also:


Attachments
Patch (62.42 KB, patch)
2019-02-17 12:57 PST, Darin Adler
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from ews103 for mac-highsierra (2.73 MB, application/zip)
2019-02-17 14:09 PST, Build Bot
no flags Details
Archive of layout-test-results from ews105 for mac-highsierra-wk2 (2.78 MB, application/zip)
2019-02-17 14:22 PST, Build Bot
no flags Details
Archive of layout-test-results from ews116 for mac-highsierra (2.34 MB, application/zip)
2019-02-17 14:52 PST, Build Bot
no flags Details
Archive of layout-test-results from ews125 for ios-simulator-wk2 (17.38 MB, application/zip)
2019-02-17 15:12 PST, Build Bot
no flags Details
Archive of layout-test-results from ews205 for win-future (12.90 MB, application/zip)
2019-02-17 16:16 PST, Build Bot
no flags Details
Patch (62.47 KB, patch)
2019-02-18 04:44 PST, Darin Adler
no flags Details | Formatted Diff | Diff
Archive of layout-test-results from ews125 for ios-simulator-wk2 (9.71 MB, application/zip)
2019-02-18 06:55 PST, Build Bot
no flags Details
Patch (62.47 KB, patch)
2019-02-18 07:00 PST, Darin Adler
rniwa: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Darin Adler 2019-02-17 12:20:10 PST
Some refinements for Node and Document
Comment 1 Darin Adler 2019-02-17 12:57:50 PST Comment hidden (obsolete)
Comment 2 Build Bot 2019-02-17 14:09:19 PST Comment hidden (obsolete)
Comment 3 Build Bot 2019-02-17 14:09:20 PST Comment hidden (obsolete)
Comment 4 Build Bot 2019-02-17 14:22:32 PST Comment hidden (obsolete)
Comment 5 Build Bot 2019-02-17 14:22:34 PST Comment hidden (obsolete)
Comment 6 Build Bot 2019-02-17 14:51:58 PST Comment hidden (obsolete)
Comment 7 Build Bot 2019-02-17 14:52:00 PST Comment hidden (obsolete)
Comment 8 Build Bot 2019-02-17 15:12:20 PST Comment hidden (obsolete)
Comment 9 Build Bot 2019-02-17 15:12:22 PST Comment hidden (obsolete)
Comment 10 Build Bot 2019-02-17 16:15:55 PST Comment hidden (obsolete)
Comment 11 Build Bot 2019-02-17 16:16:06 PST Comment hidden (obsolete)
Comment 12 Darin Adler 2019-02-18 04:44:32 PST Comment hidden (obsolete)
Comment 13 Build Bot 2019-02-18 06:55:56 PST Comment hidden (obsolete)
Comment 14 Build Bot 2019-02-18 06:55:58 PST Comment hidden (obsolete)
Comment 15 Darin Adler 2019-02-18 07:00:16 PST
Created attachment 362295 [details]
Patch
Comment 16 Darin Adler 2019-02-20 21:26:24 PST
Patch compiles and passes all tests; now looking for a reviewer. I think Chris or Ryosuke might be best since this affects DOM and specifically has a small amount of refactoring/changes for shadow DOM support.
Comment 17 Ryosuke Niwa 2019-02-21 18:50:40 PST
Comment on attachment 362295 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=362295&action=review

> Source/WebCore/dom/ContainerNode.cpp:748
> +    switch (change.type) {

Maybe we can add a helper like affectsElements() to ChildChange?

> Source/WebCore/dom/Document.cpp:749
> +        for (auto& node : composedTreeDescendants(*this)) {
> +            if (!is<Element>(node))

This will make access key work in shadow trees.
We probably want to add a test for that.

e.g. add an element with accesskey inside a shadow tree, then emulate it via eventSender.
The element should be focused and such.

> Source/WebCore/dom/Element.cpp:1560
> +        else if (name == classAttr)

Weird that this one doesn't have HTMLNames qualification...

> Source/WebCore/dom/Node.cpp:1013
> +    // FIXME: Why is this implementation so different from containsIncludingShadowDOM
> +    // function, given that the two functions' purposes are nearly identical?
> +    return other && (isDescendantOf(*other) || other->contains(shadowHost()));

This function is clearly broken.
This element's shadow tree's host could be inside another shadow tree.
And this function doesn't take care of that.

> Source/WebCore/editing/ReplaceSelectionCommand.cpp:172
> -        && !(shadowAncestorNode && shadowAncestorNode->renderer() && shadowAncestorNode->renderer()->isTextControl())
> +        && !(shadowHost && shadowHost->renderer() && shadowHost->renderer()->isTextControl())

We should probably just use enclosingTextFormControl(firstPositionInNode(shadowHost)).

> Source/WebCore/html/HTMLAreaElement.cpp:72
> -    } else if (name == altAttr || name == accesskeyAttr) {
> +    } else if (name == altAttr) {

Hm.. I wonder if we can write a test for this? Is there any behavior difference here??

> Source/WebCore/html/HTMLSelectElement.cpp:-310
> -    else if (name == accesskeyAttr) {

Ditto. I feel like this might be artifact of WebKit not making these elements focusable somehow...
If we had accesskey, we need to make the element focusable.

> Source/WebCore/html/HTMLTextAreaElement.cpp:-197
> -    } else if (name == accesskeyAttr) {
> -        // ignore for the moment

Ditto. We should probably add a test for these three elements.

> Source/WebCore/loader/DocumentWriter.cpp:193
> -TextResourceDecoder* DocumentWriter::createDecoderIfNeeded()
> +TextResourceDecoder& DocumentWriter::decoder()

ensureEncoder per our naming convention?

> Source/WebCore/page/DragController.cpp:353
> +static bool hasEnabledColorInputAsShadowHost(Node& node)

I'd call this isInShadowTreeOfEnabledColorInput instead.
Comment 18 Darin Adler 2019-02-21 19:07:16 PST
Comment on attachment 362295 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=362295&action=review

>> Source/WebCore/dom/Document.cpp:749
>> +            if (!is<Element>(node))
> 
> This will make access key work in shadow trees.
> We probably want to add a test for that.
> 
> e.g. add an element with accesskey inside a shadow tree, then emulate it via eventSender.
> The element should be focused and such.

This is not intended to be a change in behavior. Note that the old version of this function already recursed into the shadow root.

Yes, I could add a test, just to make sure I’m not breaking it. Or I can find the existing test.

>> Source/WebCore/dom/Element.cpp:1560
>> +        else if (name == classAttr)
> 
> Weird that this one doesn't have HTMLNames qualification...

Good point. Maybe none of them need it.

>> Source/WebCore/dom/Node.cpp:1013
>> +    return other && (isDescendantOf(*other) || other->contains(shadowHost()));
> 
> This function is clearly broken.
> This element's shadow tree's host could be inside another shadow tree.
> And this function doesn't take care of that.

OK. Would you like me to do something about it? I was preserving behavior, but I’d also be happy to go further and fix the function or get rid of it; need your advice on the direction to take.

>> Source/WebCore/editing/ReplaceSelectionCommand.cpp:172
>> +        && !(shadowHost && shadowHost->renderer() && shadowHost->renderer()->isTextControl())
> 
> We should probably just use enclosingTextFormControl(firstPositionInNode(shadowHost)).

I’ll look into making that change in a follow-up patch.

>> Source/WebCore/html/HTMLAreaElement.cpp:72
>> +    } else if (name == altAttr) {
> 
> Hm.. I wonder if we can write a test for this? Is there any behavior difference here??

No, there’s no behavior difference. This code has no effect on whether the acesskey attribute is "respected" for these elements.

It’s normally harmless to not call through to the base class. In fact, I’d prefer that the pattern be that we always call through; we get a small performance boost from not calling through that I would be getting rid of if I made that change broadly.

I’m pretty sure that it’s not important for altAttr to not call through so I could have deleted that case case well. Since I added code for accesskeyAttr in the base class, I needed to remove all places like this that choose not to call through to it, and that’s why I did this.

If we don’t want accesskey to have an effect on area elements, we need a code change elsewhere. This code tha not calling through to parseAttribute had no effect on whether the attribute was respected.

>> Source/WebCore/html/HTMLSelectElement.cpp:-310
>> -    else if (name == accesskeyAttr) {
> 
> Ditto. I feel like this might be artifact of WebKit not making these elements focusable somehow...
> If we had accesskey, we need to make the element focusable.

No, that’s not right. This code had no effect before and did not prevent accesskey attributes from having an effect on select elements.

It’s true, perhaps, that we don’t want accesskey to work on these, but to accomplish that we need to make a change to another function; parseAttribute has no effect on that.

>> Source/WebCore/html/HTMLTextAreaElement.cpp:-197
>> -        // ignore for the moment
> 
> Ditto. We should probably add a test for these three elements.

There’s no behavior change for the same reason as above. Adding a test is fine, but has little to do with this patch.

>> Source/WebCore/loader/DocumentWriter.cpp:193
>> +TextResourceDecoder& DocumentWriter::decoder()
> 
> ensureEncoder per our naming convention?

Do we really need to add the word "ensure"? I’ll do it if you insist, but I’d prefer to just leave it named decoder().

I can’t remember what we decided on for our convention. I personally prefix the thing()/existingThing() pairing, but maybe I was outvoted?

>> Source/WebCore/page/DragController.cpp:353
>> +static bool hasEnabledColorInputAsShadowHost(Node& node)
> 
> I'd call this isInShadowTreeOfEnabledColorInput instead.

OK. I will rename it.
Comment 19 Ryosuke Niwa 2019-02-21 19:42:37 PST
Comment on attachment 362295 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=362295&action=review

>>> Source/WebCore/dom/Document.cpp:749
>>> +            if (!is<Element>(node))
>> 
>> This will make access key work in shadow trees.
>> We probably want to add a test for that.
>> 
>> e.g. add an element with accesskey inside a shadow tree, then emulate it via eventSender.
>> The element should be focused and such.
> 
> This is not intended to be a change in behavior. Note that the old version of this function already recursed into the shadow root.
> 
> Yes, I could add a test, just to make sure I’m not breaking it. Or I can find the existing test.

Oh, I see. Sorry, I missed the part where it recursed into buildAccessKeyCache.

> Source/WebCore/dom/Document.cpp:755
> +            map.add(key, &element);

Hm... because this would override the existing entry in the map, there is a subtle behavior change.
Namely, if an element with the same accesskey appears inside the shadow tree
as well as its slotted content, this would change which element will be associated with that accesskey.

In the following example, Option+Control currently focuses the slotted content.
I expect after this code change, the shadow content will be focused.
(You may need to swap the location of slot & button in the shadow tree to reproduce the difference).

<!DOCTYPE html>
<html>
<body>
<button href="javascript:void" accesskey="w">before</button>
<div id="host"><button href="javascript:void" accesskey="w">slotted</button></div>
<script>
const shadowRoot = host.attachShadow({mode: 'closed'});
shadowRoot.innerHTML = `<slot></slot><div><button href="javascript:void" accesskey="w">shadow</button>`;
</script>
</body>
</html>

None of this seems to be defined anywhere so I filed https://github.com/whatwg/html/issues/4385

>>> Source/WebCore/html/HTMLAreaElement.cpp:72
>>> +    } else if (name == altAttr) {
>> 
>> Hm.. I wonder if we can write a test for this? Is there any behavior difference here??
> 
> No, there’s no behavior difference. This code has no effect on whether the acesskey attribute is "respected" for these elements.
> 
> It’s normally harmless to not call through to the base class. In fact, I’d prefer that the pattern be that we always call through; we get a small performance boost from not calling through that I would be getting rid of if I made that change broadly.
> 
> I’m pretty sure that it’s not important for altAttr to not call through so I could have deleted that case case well. Since I added code for accesskeyAttr in the base class, I needed to remove all places like this that choose not to call through to it, and that’s why I did this.
> 
> If we don’t want accesskey to have an effect on area elements, we need a code change elsewhere. This code tha not calling through to parseAttribute had no effect on whether the attribute was respected.

Okay.

>>> Source/WebCore/html/HTMLSelectElement.cpp:-310
>>> -    else if (name == accesskeyAttr) {
>> 
>> Ditto. I feel like this might be artifact of WebKit not making these elements focusable somehow...
>> If we had accesskey, we need to make the element focusable.
> 
> No, that’s not right. This code had no effect before and did not prevent accesskey attributes from having an effect on select elements.
> 
> It’s true, perhaps, that we don’t want accesskey to work on these, but to accomplish that we need to make a change to another function; parseAttribute has no effect on that.

The spec explicitly talks about these elements having accesskey.
So perhaps it would be a good idea to test some tests.
Maybe this used to be disabled purposefully but presumably that's no longer the case now,
which coincidentally matches that the HTML5 spec says:
https://html.spec.whatwg.org/multipage/interaction.html#assigned-access-key

>>> Source/WebCore/loader/DocumentWriter.cpp:193
>>> +TextResourceDecoder& DocumentWriter::decoder()
>> 
>> ensureEncoder per our naming convention?
> 
> Do we really need to add the word "ensure"? I’ll do it if you insist, but I’d prefer to just leave it named decoder().
> 
> I can’t remember what we decided on for our convention. I personally prefix the thing()/existingThing() pairing, but maybe I was outvoted?

Oh, I guess we landed on
StyleResolver* styleResolverIfExists()
StyleResolver& styleResolver()
https://lists.webkit.org/pipermail/webkit-dev/2013-June/025074.html

Maybe we should update the style guidelines...
Comment 20 Darin Adler 2019-02-21 19:48:13 PST
Comment on attachment 362295 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=362295&action=review

>> Source/WebCore/dom/Document.cpp:755
>> +            map.add(key, &element);
> 
> Hm... because this would override the existing entry in the map, there is a subtle behavior change.
> Namely, if an element with the same accesskey appears inside the shadow tree
> as well as its slotted content, this would change which element will be associated with that accesskey.
> 
> In the following example, Option+Control currently focuses the slotted content.
> I expect after this code change, the shadow content will be focused.
> (You may need to swap the location of slot & button in the shadow tree to reproduce the difference).
> 
> <!DOCTYPE html>
> <html>
> <body>
> <button href="javascript:void" accesskey="w">before</button>
> <div id="host"><button href="javascript:void" accesskey="w">slotted</button></div>
> <script>
> const shadowRoot = host.attachShadow({mode: 'closed'});
> shadowRoot.innerHTML = `<slot></slot><div><button href="javascript:void" accesskey="w">shadow</button>`;
> </script>
> </body>
> </html>
> 
> None of this seems to be defined anywhere so I filed https://github.com/whatwg/html/issues/4385

What you say is not quite right:

1) HashMap::add does *not* override existing entries in a map.
2) I believe the new code still processes an element before it processes its descendants. That’s the same as the old code.

I must admit that, yes, I did change behavior. If two elements have the same accesskey, the old code would make the later one in document order win (because it uses HashMap::set) and my new code would make the earlier one in document order win (because it uses HashMap::add). I could change the add back into a set to get rid of the behavior change. Or write tests for this edge case. I am tempted to do neither, but you can keep me honest.

>>>> Source/WebCore/html/HTMLSelectElement.cpp:-310
>>>> -    else if (name == accesskeyAttr) {
>>> 
>>> Ditto. I feel like this might be artifact of WebKit not making these elements focusable somehow...
>>> If we had accesskey, we need to make the element focusable.
>> 
>> No, that’s not right. This code had no effect before and did not prevent accesskey attributes from having an effect on select elements.
>> 
>> It’s true, perhaps, that we don’t want accesskey to work on these, but to accomplish that we need to make a change to another function; parseAttribute has no effect on that.
> 
> The spec explicitly talks about these elements having accesskey.
> So perhaps it would be a good idea to test some tests.
> Maybe this used to be disabled purposefully but presumably that's no longer the case now,
> which coincidentally matches that the HTML5 spec says:
> https://html.spec.whatwg.org/multipage/interaction.html#assigned-access-key

If it was disabled, that was a very long time ago. Our accesskey implementation hasn’t depended on this for a long time, if ever. I think someone might have *thought* this disabled something but not sure it ever did.

>>>> Source/WebCore/loader/DocumentWriter.cpp:193
>>>> +TextResourceDecoder& DocumentWriter::decoder()
>>> 
>>> ensureEncoder per our naming convention?
>> 
>> Do we really need to add the word "ensure"? I’ll do it if you insist, but I’d prefer to just leave it named decoder().
>> 
>> I can’t remember what we decided on for our convention. I personally prefix the thing()/existingThing() pairing, but maybe I was outvoted?
> 
> Oh, I guess we landed on
> StyleResolver* styleResolverIfExists()
> StyleResolver& styleResolver()
> https://lists.webkit.org/pipermail/webkit-dev/2013-June/025074.html
> 
> Maybe we should update the style guidelines...

Hooray, I can name it decoder!
Comment 21 Ryosuke Niwa 2019-02-21 19:56:53 PST
For posterity, I've posted a patch to update the style guideline in https://bugs.webkit.org/show_bug.cgi?id=194930.
Comment 22 Darin Adler 2019-02-21 21:16:28 PST
OK, I created a test and it shows that, before the patch:

1) accesskey does follow a "last node in document order wins" rule
2) accesskey does work in shadow trees
3) when both the slotted button and the shadow button have the same accesskey, somehow the slotted button always seems to win, regardless of where the slot is

That behavior (3) is a bit mystifying.

I will add the test to my patch. I do intend to change rule (1) so that "first node in document order wins". As an aside, HTML specification says that "first node to claim the key wins", which is a rule about timing, not document order. We can return to fix that at some point.

I’d like to understand this (3) thing better.
Comment 23 Ryosuke Niwa 2019-02-21 21:25:37 PST
(In reply to Darin Adler from comment #22)
> OK, I created a test and it shows that, before the patch:
> 
> 1) accesskey does follow a "last node in document order wins" rule
> 2) accesskey does work in shadow trees
> 3) when both the slotted button and the shadow button have the same
> accesskey, somehow the slotted button always seems to win, regardless of
> where the slot is
> 
> That behavior (3) is a bit mystifying.

I don't think that's surprising. In the original code, we were always traversing the shadow tree, which DOES NOT have any slotted content before traversing the descendants of the shadow host. Because a slotted element is always a descendent, in fact, it's always a direct child of the shadow host, so it would always appear later in our traversal than any element of the shadow tree.
Comment 24 Darin Adler 2019-02-21 22:44:47 PST
Comment on attachment 362295 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=362295&action=review

>> Source/WebCore/dom/ContainerNode.cpp:748
>> +    switch (change.type) {
> 
> Maybe we can add a helper like affectsElements() to ChildChange?

I added it, but for now just as a separate function in this file, not as a member function in ChildChange.

>>>> Source/WebCore/dom/Document.cpp:749
>>>> +            if (!is<Element>(node))
>>> 
>>> This will make access key work in shadow trees.
>>> We probably want to add a test for that.
>>> 
>>> e.g. add an element with accesskey inside a shadow tree, then emulate it via eventSender.
>>> The element should be focused and such.
>> 
>> This is not intended to be a change in behavior. Note that the old version of this function already recursed into the shadow root.
>> 
>> Yes, I could add a test, just to make sure I’m not breaking it. Or I can find the existing test.
> 
> Oh, I see. Sorry, I missed the part where it recursed into buildAccessKeyCache.

Added a test.

>>> Source/WebCore/dom/Document.cpp:755
>>> +            map.add(key, &element);
>> 
>> Hm... because this would override the existing entry in the map, there is a subtle behavior change.
>> Namely, if an element with the same accesskey appears inside the shadow tree
>> as well as its slotted content, this would change which element will be associated with that accesskey.
>> 
>> In the following example, Option+Control currently focuses the slotted content.
>> I expect after this code change, the shadow content will be focused.
>> (You may need to swap the location of slot & button in the shadow tree to reproduce the difference).
>> 
>> <!DOCTYPE html>
>> <html>
>> <body>
>> <button href="javascript:void" accesskey="w">before</button>
>> <div id="host"><button href="javascript:void" accesskey="w">slotted</button></div>
>> <script>
>> const shadowRoot = host.attachShadow({mode: 'closed'});
>> shadowRoot.innerHTML = `<slot></slot><div><button href="javascript:void" accesskey="w">shadow</button>`;
>> </script>
>> </body>
>> </html>
>> 
>> None of this seems to be defined anywhere so I filed https://github.com/whatwg/html/issues/4385
> 
> What you say is not quite right:
> 
> 1) HashMap::add does *not* override existing entries in a map.
> 2) I believe the new code still processes an element before it processes its descendants. That’s the same as the old code.
> 
> I must admit that, yes, I did change behavior. If two elements have the same accesskey, the old code would make the later one in document order win (because it uses HashMap::set) and my new code would make the earlier one in document order win (because it uses HashMap::add). I could change the add back into a set to get rid of the behavior change. Or write tests for this edge case. I am tempted to do neither, but you can keep me honest.

Added a test that shows the change in the behavior.

>>> Source/WebCore/dom/Element.cpp:1560
>>> +        else if (name == classAttr)
>> 
>> Weird that this one doesn't have HTMLNames qualification...
> 
> Good point. Maybe none of them need it.

Added a HTMLNames qualifier here, but didn’t remove the "using namespace HTMLNames" at the top of this file. Could do that later.

>>> Source/WebCore/dom/Node.cpp:1013
>>> +    return other && (isDescendantOf(*other) || other->contains(shadowHost()));
>> 
>> This function is clearly broken.
>> This element's shadow tree's host could be inside another shadow tree.
>> And this function doesn't take care of that.
> 
> OK. Would you like me to do something about it? I was preserving behavior, but I’d also be happy to go further and fix the function or get rid of it; need your advice on the direction to take.

I left this alone for now.

>>> Source/WebCore/editing/ReplaceSelectionCommand.cpp:172
>>> +        && !(shadowHost && shadowHost->renderer() && shadowHost->renderer()->isTextControl())
>> 
>> We should probably just use enclosingTextFormControl(firstPositionInNode(shadowHost)).
> 
> I’ll look into making that change in a follow-up patch.

I left this alone for now.

>>>>> Source/WebCore/html/HTMLSelectElement.cpp:-310
>>>>> -    else if (name == accesskeyAttr) {
>>>> 
>>>> Ditto. I feel like this might be artifact of WebKit not making these elements focusable somehow...
>>>> If we had accesskey, we need to make the element focusable.
>>> 
>>> No, that’s not right. This code had no effect before and did not prevent accesskey attributes from having an effect on select elements.
>>> 
>>> It’s true, perhaps, that we don’t want accesskey to work on these, but to accomplish that we need to make a change to another function; parseAttribute has no effect on that.
>> 
>> The spec explicitly talks about these elements having accesskey.
>> So perhaps it would be a good idea to test some tests.
>> Maybe this used to be disabled purposefully but presumably that's no longer the case now,
>> which coincidentally matches that the HTML5 spec says:
>> https://html.spec.whatwg.org/multipage/interaction.html#assigned-access-key
> 
> If it was disabled, that was a very long time ago. Our accesskey implementation hasn’t depended on this for a long time, if ever. I think someone might have *thought* this disabled something but not sure it ever did.

We have a test that makes sure that accesskey works on all types of elements already, and it passes both with and without the patch. Could add more later, but for now there's no real problem here.

>>> Source/WebCore/page/DragController.cpp:353
>>> +static bool hasEnabledColorInputAsShadowHost(Node& node)
>> 
>> I'd call this isInShadowTreeOfEnabledColorInput instead.
> 
> OK. I will rename it.

Did that.
Comment 25 Darin Adler 2019-02-21 22:46:43 PST
Committed r241932: <https://trac.webkit.org/changeset/241932>
Comment 26 Radar WebKit Bug Importer 2019-02-21 22:47:40 PST
<rdar://problem/48303160>
Comment 27 Truitt Savell 2019-02-22 16:40:19 PST
The new test fast/forms/access-key-shadow-and-ordering.html

added in https://trac.webkit.org/changeset/241932/webkit

is failing on iOS Simulator. History:
http://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.html#showAllRuns=true&tests=fast%2Fforms%2Faccess-key-shadow-and-ordering.html

Diff:
--- /Volumes/Data/slave/ios-simulator-12-debug-tests-wk2/build/layout-test-results/fast/forms/access-key-shadow-and-ordering-expected.txt
+++ /Volumes/Data/slave/ios-simulator-12-debug-tests-wk2/build/layout-test-results/fast/forms/access-key-shadow-and-ordering-actual.txt
@@ -1,15 +1,4 @@
 This test checks to see what happens when the same accesskey is set on multiple elements including cases where the elements are in the a shadow tree.
 
 1c 1w   3c   4w  5w  6c
-1: correct button focused, earlier in document
-1: correct button clicked, earlier in document
-2: correct button focused, in shadow
-2: correct button clicked, in shadow
-3: correct button focused, earlier in document
-3: correct button clicked, earlier in document
-4: correct button focused, earlier in document and in shadow
-4: correct button clicked, earlier in document and in shadow
-5: correct button focused, earlier in document and in shadow
-5: correct button clicked, earlier in document and in shadow
-6: correct button focused, earlier in document in slot
-6: correct button clicked, earlier in document in slot
+
Comment 28 Ryosuke Niwa 2019-02-22 16:59:59 PST
(In reply to Truitt Savell from comment #27)
> The new test fast/forms/access-key-shadow-and-ordering.html
> 
> added in https://trac.webkit.org/changeset/241932/webkit
> 
> is failing on iOS Simulator. History:
> http://webkit-test-results.webkit.org/dashboards/flakiness_dashboard.
> html#showAllRuns=true&tests=fast%2Fforms%2Faccess-key-shadow-and-ordering.
> html

We probably need to skip it on iOS for now.
Comment 29 Ryosuke Niwa 2019-02-22 17:04:33 PST
Skipped the test on iOS for now:
https://trac.webkit.org/changeset/241973