This is 100% reproducible on mac at least when running browser_caching_name test for a "CSSContent" ruleset.

When running the test we expect a re-order event on the button parent when the style e lement is removed (both hide of the CSS content "do not " and the style element removal trigger re-order on the document). This works as expected when the content is in the top level doc or fission iframe (when fission is enabled). However, when the content is in a local iframe, the re-order only fires on the button itself, since the static text accessible for "do not " (from CSS content) is removed. REORDER does not seem to coalesce to the document even though the style element (sibling of the button) is removed.

The doc that is being tested in that test is:

data:text/html;charset=utf-8,%3Chtml%3E%0A%20%20%20%20%20%20%3Chead%3E%0A%20%20%20%20%20%20%20%20%3Cmeta%20charset%3D%22utf-8%22%2F%3E%0A%20%20%20%20%20%20%20%20%3Ctitle%3EAccessibility%20Test%3C%2Ftitle%3E%0A%20%20%20%20%20%20%3C%2Fhead%3E%0A%20%20%20%20%20%20%3Cbody%20id%3D%22body%22%3E%3Ciframe%20id%3D%22default-iframe-id%22%20src%3D%22data%3Atext%2Fhtml%3Bcharset%3Dutf-8%2C%253Cbody%2520id%253D%2522default-iframe-body-id%2522%253E%250A%2520%2520%2520%2520%253Cstyle%253E%250A%2520%2520%2520%2520%2520%2520button%253A%253Abefore%2520%257B%250A%2520%2520%2520%2520%2520%2520%2520%2520content%253A%2520%2522do%2520not%2520%2522%253B%250A%2520%2520%2520%2520%2520%2520%257D%250A%2520%2520%2520%2520%253C%252Fstyle%253E%250A%2520%2520%2520%2520%253Cbutton%2520id%253D%2522btn%2522%253Epress%2520me%253C%252Fbutton%253E%253C%252Fbody%253E%22%2F%3E%3C%2Fbody%3E%0A%20%20%20%20%3C%2Fhtml%3E

I'm actually puzzled by our "expected" result and surprised we don't always get the "unexpected" result. A style element doesn't have an Accessible, so it isn't part of the a11y tree. Therefore, it shouldn't be considered for mutation events; i.e. we shouldn't fire a reorder on the parent when the style element is removed. I guess the document must get re-flowed by layout for some reason when it's top level in its process (tab doc or Fissoin iframe), but I don't know why it's inconsistent for in-process iframes.

Note that before the work to eliminate tree re-creation due to layout reflow (bug 686400), the button Accessible would have been re-created, since removing CSS pseudo-content reflows the button. That would fire a reorder event on the parent. However, I'm surprised we haven't seen frequent failures here since bug 686400 landed.

The priority flag is not set for this bug.
:Jamie, could you have a look please?

For more information, please visit auto_nag documentation.

Yura, do I recall correctly that we found a workaround for this issue in the test? If so, we can close this in favour of bug 1597916.

Actually, scratch that. Comment 2 still applies; i.e. we don't know why the reorder event fires on the parent of the button. I'm still inclined to say we should be relying more on text events, though, since they don't coalesce and are thus more consistently reliable.

Thoughts on wontfix or p5?

The priority flag is not set for this bug.
:Jamie, could you have a look please?

For more information, please visit auto_nag documentation.