Bugzilla

Steps to reproduce:
1. Launch the attached at-spi2 accessible-event listener in a terminal
2. Load and reload https://docs.microsoft.com/en-us/dotnet/standard/async-in-depth, important: focus must be in the document and NOT in the location bar

Expected results: Either no objects would reported as defunct by the listener (preferred), or all objects would be.

Actual results: Some objects report being defunct; others don't. It changes from reload to reload. See sample output at the end of this comment.

Question/Aside: If focus is in the location bar, nothing gets destroyed. It's only when focus is in the document. So is destruction absolutely necessary?

Use case/scenario: Orca's structural navigation commands are by side effect triggering objects on (at least) the site in question to be destroyed and recreated. More specifically, as the user moves by heading, Orca sets the caret in that heading. For focusable objects like links, navigation causes Orca to do a focus grab. If the object gets destroyed before Orca can present it to the user, presentation is broken. 

(Related aside: Orca moves the caret and/or grabs focus because it doesn't have a virtual buffer and relies upon the browser's native functionality for things like text selection, link activation, etc. In other words, Firefox needs to know where the caret and focus are prior to the user doing Shift+Arrows or Return.)

I have just committed a workaround in Orca master to deal with this: I save the path within the accessibility tree, update the location (set caret, grab focus, etc.), check for object destruction and then use the path to get the replacement object from AT-SPI2 if need be. That brings me to the following:

In order for this workaround to work, AT-SPI2 must have already received the children-changed event from Gecko. That event causes AT-SPI2 to update its accessibility tree and give Orca the right object. I am seeing instances where the event has not yet been fired/received at the moment Orca seeks the replacement object. When that happens, the user experience is still broken. So.... If these objects really do need to be destroyed, could that destruction and recreation be prioritized? *smiles*

Sample output:
==============
7 matching headings found
Heading is now defunct. Old name: ' What does this mean for a server scenario?' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 27]
Link is now defunct. Old name: ' What does this mean for a server scenario?' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, -1, -1]
2 objects out of 14 are now defunct.
==============
7 matching headings found
Heading is now defunct. Old name: ' What does this mean for a server scenario?' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 27]
Link is now defunct. Old name: ' What does this mean for a server scenario?' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 27, 0]
2 objects out of 14 are now defunct.
==============
7 matching headings found
Heading is now defunct. Old name: ' Deeper Dive into Tasks for an I/O-Bound Operation' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 13]
Link is now defunct. Old name: ' Deeper Dive into Tasks for an I/O-Bound Operation' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 12, 0]
Heading is now defunct. Old name: ' What does this mean for client scenario?' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 33]
Link is now defunct. Old name: ' What does this mean for client scenario?' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 33, 0]
Heading is now defunct. Old name: ' Deeper Dive into Task and Task<T> for a CPU-Bound Operation' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 37]
Link is now defunct. Old name: ' Deeper Dive into Task and Task<T> for a CPU-Bound Operation' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 36, 0]
6 objects out of 14 are now defunct.
==============
7 matching headings found
Link is now defunct. Old name: ' Deeper Dive into Tasks for an I/O-Bound Operation' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 13, 0]
Heading is now defunct. Old name: ' Deeper Dive into Task and Task<T> for a CPU-Bound Operation' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 37]
Link is now defunct. Old name: ' Deeper Dive into Task and Task<T> for a CPU-Bound Operation' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 37, 0]
3 objects out of 14 are now defunct.

Steps to reproduce:
1. Launch the attached at-spi2 accessible-event listener in a terminal
2. Load and reload https://docs.microsoft.com/en-us/dotnet/standard/async-in-depth, important: focus must be in the document and NOT in the location bar

Expected results: Either no objects would reported as defunct by the listener (preferred), or all objects would be.

Actual results: Some objects report being defunct; others don't. It changes from reload to reload. See sample output at the end of this comment.

Question/Aside: If focus is in the location bar, nothing gets destroyed. It's only when focus is in the document. So is destruction absolutely necessary?

Use case/scenario: Orca's structural navigation commands are by side effect triggering objects on (at least) the site in question to be destroyed and recreated. More specifically, as the user moves by heading, Orca sets the caret in that heading. For focusable objects like links, navigation causes Orca to do a focus grab. If the object gets destroyed before Orca can present it to the user, presentation is broken. 

(Related aside: Orca moves the caret and/or grabs focus because it doesn't have a virtual buffer and relies upon the browser's native functionality for things like text selection, link activation, etc. In other words, Firefox needs to know where the caret and focus are prior to the user doing Shift+Arrows or Return.)

I have just committed a workaround in Orca master to deal with this: I save the path within the accessibility tree, update the location (set caret, grab focus, etc.), check for object destruction and then use the path to get the replacement object from AT-SPI2 if need be. That brings me to the following:

In order for this workaround to work, AT-SPI2 must have already received the children-changed event from Gecko. That event causes AT-SPI2 to update its accessibility tree and give Orca the right object. I am seeing instances where the event has not yet been fired/received at the moment Orca seeks the replacement object. When that happens, the user experience is still broken. So.... If these objects really do need to be destroyed, could that destruction and recreation be prioritized? *smiles*

Sample output:
`==============`
7 matching headings found
Heading is now defunct. Old name: ' What does this mean for a server scenario?' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 27]
Link is now defunct. Old name: ' What does this mean for a server scenario?' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, -1, -1]
2 objects out of 14 are now defunct.
`==============`
7 matching headings found
Heading is now defunct. Old name: ' What does this mean for a server scenario?' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 27]
Link is now defunct. Old name: ' What does this mean for a server scenario?' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 27, 0]
2 objects out of 14 are now defunct.
`==============`
7 matching headings found
Heading is now defunct. Old name: ' Deeper Dive into Tasks for an I/O-Bound Operation' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 13]
Link is now defunct. Old name: ' Deeper Dive into Tasks for an I/O-Bound Operation' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 12, 0]
Heading is now defunct. Old name: ' What does this mean for client scenario?' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 33]
Link is now defunct. Old name: ' What does this mean for client scenario?' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 33, 0]
Heading is now defunct. Old name: ' Deeper Dive into Task and Task<T> for a CPU-Bound Operation' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 37]
Link is now defunct. Old name: ' Deeper Dive into Task and Task<T> for a CPU-Bound Operation' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 36, 0]
6 objects out of 14 are now defunct.
`==============`
7 matching headings found
Link is now defunct. Old name: ' Deeper Dive into Tasks for an I/O-Bound Operation' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 13, 0]
Heading is now defunct. Old name: ' Deeper Dive into Task and Task<T> for a CPU-Bound Operation' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 37]
Link is now defunct. Old name: ' Deeper Dive into Task and Task<T> for a CPU-Bound Operation' New name: '' Path: [-1, 0, 16, 0, 0, 0, 7, 0, 0, 37, 0]
3 objects out of 14 are now defunct.