CC'ing Eitan, as soon as your accessible recreation patch lands, this should be updated and augmented with a test so it can complete our details/summary implementation. I've confirmed that with your try build, the accessibles no longer get recreated. However I am not sure, with this 3 year old patch, if this is still the way we cause layout to fire events in accessibility, or if there's a new mechanism by now.

We should hopefully not be recreating accessibles here anymore.

Not related: I don't like the nsAccessibilityService interface added in this patch. We can simply watch for an attribute change of open to know when the details is opened or closed.

Handle this in DocAccessible::AttributeChangedImpl, probably just before this block:
https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/accessible/generic/DocAccessible.cpp#786

If we're handling the open attribute, fire a state change event for state expanded. Example of how to do that here:
https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/accessible/generic/DocAccessible.cpp#919

Add a test! This is tricky because current state change event tests were written well before JS promises existed, so we have this complicated framework called eventQueue. The test should probably go in accessible/tests/mochitest/events/test_aria_statechange.html. You'll want to do an expanded state change test similar to the aria-expanded test (but toggling open attribute on a details element instead of aria-expanded):
https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/accessible/tests/mochitest/events/test_aria_statechange.html#31
https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/accessible/tests/mochitest/events/test_aria_statechange.html#138

One thing to note is that the open attribute is set on the details element, but the state change event should fire on the summary Accessible, not the details Accessible.

If you're really struggling with eventQueue, you could create a new promise-based test file (we're moving towards promise-based tests anyway). Examples of those are accessible/tests/mochitest/events/test_announcement.html and accessible/tests/mochitest/events/test_focus_removal.html. Also, in accessible/tests/mochitest/events/test_focus_aria_activedescendant.html, I combine both eventQueue and promise-based tests (because I didn't want to split into a new file but didn't want to deal with eventQueue for newer tests), but that's fairly obscure.

https://hg.mozilla.org/mozilla-central/rev/6368f6953a8f