a11y AT-SPI: Qt sometimes uses same unique ID/object path for two different objects within a short time

When an a11y object is deleted right after it has been created (and before any other a11y object has been created), the next a11y is reassigned the same "unique ID", which results in the new object using the same object path in AT-SPI/D-Bus. This in turn can break assistive technology that makes use of caching, since it uses values from the old instead of the new object.

Steps to reproduce:

I'll submit a test case along with a suggested fix which can be used to reproduce the issue reliably.

The original scenario where I ran into this was with the Qt 6 based UI variant of LibreOffice, where this issue caused Orca to not announce a dialog that was started from a context menu. This does not always occur, but quite often. Steps:

0) in order to see helpful output, apply the attached patches

• qtbase.patch to qtbase (on top of dev branch as of commit 0131dbd2f95449c09758208d8b190c9238a5c46a)
• orca.patch (on top of orca master as of commit 75c433b3dd46b1b590e2758351f743d50e3d942a)

1) start the Orca screen reader

2) start LibreOffice Writer (current master as of commit 9d2c9a592ad697fd332b9bccb63e30c955f49422) with the Qt 6 based UI variant

3) type some text and move cursor around until Orca starts announcing things

4) in an empty line of text, press Shift+F10 to open a context menu

5) in that context menu, navigate to the "Page Style..." item using the "arrow down" key and press Enter to open the corresponding dialog

Actual result:

The dialog is (most of the time) not announced by Orca because Orca has incorrect information about the window/frame object of the dialog. The reason is that that object path is the same as that of the one the menu item has/had, more details below.

Expected result:

The dialog should be announced. Each a11y object should have a unique object path (until the whole range of IDs has been used up, at which point now unused IDs can be reused).

Further analysis:

The Orca output (orca_output.txt) shows that Orca is using incorrect data for the  dialog's frame object, e.g. a "menu item" role instead of "frame":

 onWindowActivated: [menu item | Page Style: Default Page Style (Type = 362)], role: <enum ATSPI_ROLE_MENU_ITEM of type Atspi.Role>

The LibreOffice output (libreoffice-log.txt) shows that the role for the frame is generally as expected (role: "frame") inside of LO/qtbase, e.g. this line:

qt.accessibility.atspi: AtSpiAdaptor::pathForInterface id: 2147483866 , interface: QAccessibleInterface(0x55f78b4de6c0 name="Page Style: Default Page Style (Type = 362)" role=Window childc=1 obj=QtWidget(0x55f7888569c0)rect=QRect(1074,168 732x508)) name: "Page Style: Default Page Style (Type = 362)" role:  "frame" 

However, searching for the object ID 2147483866 (s. above) in the log not only shows more lines for the expected object ("Page Style: Default Page Style (Type = 362)" role:  "frame" ) but also one for the menu item:

 qt.accessibility.atspi: AtSpiAdaptor::pathForInterface id: 2147483866 , interface: QAccessibleInterface(0x7faacc004b90 name="Page Style..." role=MenuItem obj=QAction(0x55f7888766a0)"focused"rect=QRect(1087,465 311x22)) name: "Page Style..." role:  "menu item"

This turns out to be the reason for Orca using the wrong role: It uses values from the cache, which relies on the objects having unique IDs/object paths, but that assumption is broken by the above, resulting in incorrect handling.