Bugzilla

Discovered this while trying to get aria-owns working properly on the address bar (bug 

STR:

1. Open this test case:
    `data:text/html,<div role="combobox" aria-owns="listbox"></div><div id="container"><div id="listbox" role="listbox"></div></div><button onClick="container.hidden = true; listbox.innerHTML = `<div role='option'>1</div>`;">Break things</button><button onClick="container.hidden = false;">Break more things</button>`
2. Observe that in the accessibility tree, there is an editcombobox containing a combobox list. The combobox list does not have the invisible state.
3. Press the "Break things" button.
4. In the accessibility tree, examine the children of the editcombobox.
    - Expected: There should be no children.
    - Actual: The combobox list is still there. It has the invisible state.
5. Press the "Break more things" button.
6. In the accessibility tree, examine the children of the editcombobox.
    - Observe: As expected, the combobox list is there and it does not have the invisible state.
7. In the accessibility tree, examine the children of the combobox list.
    - Expected: There should be a combobox option child.
    - Actual: There is a text leaf child.

This is *not* fixed by the patch for bug 1571616 (I applied and tested locally).

In PruneOrInsertSubtree, when we remove something (e.g. because its accessible no longer has a frame), we call ContentRemoved(acc) and return early. That removes the accessible and its descendant accessibles. However, relocated accessibles aren't descendant accessibles, even though they're descendant DOM nodes. I think we need to remove Accessibles for descendant DOM nodes here.

Can we just call ContentRemoved on the node instead of the Accessible? That will iterate through descendant DOM nodes.

Discovered this while trying to get aria-owns working properly on the address bar (bug 1567377).

STR:

1. Open this test case:
    `data:text/html,<div role="combobox" aria-owns="listbox"></div><div id="container"><div id="listbox" role="listbox"></div></div><button onClick="container.hidden = true; listbox.innerHTML = `<div role='option'>1</div>`;">Break things</button><button onClick="container.hidden = false;">Break more things</button>`
2. Observe that in the accessibility tree, there is an editcombobox containing a combobox list. The combobox list does not have the invisible state.
3. Press the "Break things" button.
4. In the accessibility tree, examine the children of the editcombobox.
    - Expected: There should be no children.
    - Actual: The combobox list is still there. It has the invisible state.
5. Press the "Break more things" button.
6. In the accessibility tree, examine the children of the editcombobox.
    - Observe: As expected, the combobox list is there and it does not have the invisible state.
7. In the accessibility tree, examine the children of the combobox list.
    - Expected: There should be a combobox option child.
    - Actual: There is a text leaf child.

This is *not* fixed by the patch for bug 1571616 (I applied and tested locally).

In PruneOrInsertSubtree, when we remove something (e.g. because its accessible no longer has a frame), we call ContentRemoved(acc) and return early. That removes the accessible and its descendant accessibles. However, relocated accessibles aren't descendant accessibles, even though they're descendant DOM nodes. I think we need to remove Accessibles for descendant DOM nodes here.

Can we just call ContentRemoved on the node instead of the Accessible? That will iterate through descendant DOM nodes.

Discovered this while trying to get aria-owns working properly on the address bar (bug 1567377).

STR:

1. Open this test case:
    ```data:text/html,<div role="combobox" aria-owns="listbox"></div><div id="container"><div id="listbox" role="listbox"></div></div><button onClick="container.hidden = true; listbox.innerHTML = `<div role='option'>1</div>`;">Break things</button><button onClick="container.hidden = false;">Break more things</button>```
2. Observe that in the accessibility tree, there is an editcombobox containing a combobox list. The combobox list does not have the invisible state.
3. Press the "Break things" button.
4. In the accessibility tree, examine the children of the editcombobox.
    - Expected: There should be no children.
    - Actual: The combobox list is still there. It has the invisible state.
5. Press the "Break more things" button.
6. In the accessibility tree, examine the children of the editcombobox.
    - Observe: As expected, the combobox list is there and it does not have the invisible state.
7. In the accessibility tree, examine the children of the combobox list.
    - Expected: There should be a combobox option child.
    - Actual: There is a text leaf child.

This is *not* fixed by the patch for bug 1571616 (I applied and tested locally).

In PruneOrInsertSubtree, when we remove something (e.g. because its accessible no longer has a frame), we call ContentRemoved(acc) and return early. That removes the accessible and its descendant accessibles. However, relocated accessibles aren't descendant accessibles, even though they're descendant DOM nodes. I think we need to remove Accessibles for descendant DOM nodes here.

Can we just call ContentRemoved on the node instead of the Accessible? That will iterate through descendant DOM nodes.