Until Bug 1654938 is fixed we delete layer manager for hidden popups,
otherwise it can easily hold 1GB+ memory for long time.
Differential Revision: https://phabricator.services.mozilla.com/D202910
The Pernosco session shows that the content child is about to destroy at that point, so there is not much we can do.
Removing the diagnostic assert seems to be the only way.
Differential Revision: https://phabricator.services.mozilla.com/D202875
Both use cases of the getter of the WritableFileStream pointer are already handling the case where the result is null. In the debug-only check of whether all streams are closed, null result is possible, as evidenced by the bug. When the streams are closed at shutdown, we assume that closing takes place only once and the result is not null but since the second closing can be handled as a no-op, it is not necessary enforce this expectation, following declarative API design.
Differential Revision: https://phabricator.services.mozilla.com/D202589
KeyboardShortcut is only implemented for LocalAccessible because KeyboardShortcut isn't currently relevant (or supported) for RemoteAccessible.
AriaProperties can't be supported for RemoteAccessible currently.
See the code comment for details.
Differential Revision: https://phabricator.services.mozilla.com/D202551
Previously, uiaRawElmProvider was a tear-off; i.e. an entirely separate object from MsaaAccessible.
That meant uiaRawElmProvider had to hold its own reference to the Accessible.
This would be problematic for RemoteAccessible because you can't hold a strong reference to a RemoteAccessible.
It's also messy from a lifecycle perspective to have yet another object tree.
Instead, have MsaaAccessible inherit uiaRawElmProvider, just as it does for ia2Accessible, etc.
This way, only MsaaAccessible needs to manage the reference to the underlying Accessible.
Differential Revision: https://phabricator.services.mozilla.com/D202550
In a subsequent patch, MsaaAccessible will inherit from uiaRawElmProvider, which is in a different directory.
This causes problems for things outside the a11y module which include (either directly or indirectly) AccessibleWrap.h.
While this could be fixed by exporting more headers, we also end up with type conflicts with Windows API headers.
It's better if we can minimise what gets included anyway.
1. In AccessibleWrap.h, stop including MsaaAccessible.h and forward declare MsaaAccessible.
2. Move the definition of the AccessibleWrap destructor into the cpp. Otherwise, we run into compile errors due to the RefPtr<MsaaAccessible> destructor.
3. AccessibleWrap still has a private UpdateSystemCaretFor function which takes an HWND, which requires windows.h. To avoid including that in AccessibleWrap.h, move it to a static function only inside the cpp file. Rename it to prevent compiler overload confusion.
4. Since code outside the a11y module no longer needs to indirectly include MsaaAccessible, don't export MsaaAccessible.h any more.
5. While we're at it, don't export MsaaIdGenerator.h either, which is never used outside the Windows a11y code.
There should be no functional change here.
Differential Revision: https://phabricator.services.mozilla.com/D202549
KeyboardShortcut is only implemented for LocalAccessible because KeyboardShortcut isn't currently relevant (or supported) for RemoteAccessible.
AriaProperties can't be supported for RemoteAccessible currently.
See the code comment for details.
Differential Revision: https://phabricator.services.mozilla.com/D202551
Previously, uiaRawElmProvider was a tear-off; i.e. an entirely separate object from MsaaAccessible.
That meant uiaRawElmProvider had to hold its own reference to the Accessible.
This would be problematic for RemoteAccessible because you can't hold a strong reference to a RemoteAccessible.
It's also messy from a lifecycle perspective to have yet another object tree.
Instead, have MsaaAccessible inherit uiaRawElmProvider, just as it does for ia2Accessible, etc.
This way, only MsaaAccessible needs to manage the reference to the underlying Accessible.
Differential Revision: https://phabricator.services.mozilla.com/D202550
In a subsequent patch, MsaaAccessible will inherit from uiaRawElmProvider, which is in a different directory.
This causes problems for things outside the a11y module which include (either directly or indirectly) AccessibleWrap.h.
While this could be fixed by exporting more headers, we also end up with type conflicts with Windows API headers.
It's better if we can minimise what gets included anyway.
1. In AccessibleWrap.h, stop including MsaaAccessible.h and forward declare MsaaAccessible.
2. Move the definition of the AccessibleWrap destructor into the cpp. Otherwise, we run into compile errors due to the RefPtr<MsaaAccessible> destructor.
3. AccessibleWrap still has a private UpdateSystemCaretFor function which takes an HWND, which requires windows.h. To avoid including that in AccessibleWrap.h, move it to a static function only inside the cpp file. Rename it to prevent compiler overload confusion.
4. Since code outside the a11y module no longer needs to indirectly include MsaaAccessible, don't export MsaaAccessible.h any more.
5. While we're at it, don't export MsaaIdGenerator.h either, which is never used outside the Windows a11y code.
There should be no functional change here.
Differential Revision: https://phabricator.services.mozilla.com/D202549
It's currently handling its job with the closest ancestor block which may be
non-editable and editing host which is either inline or block. However, the
closest block is required for check whether the range won't be extended outside
the closest block of the common ancestor of the range and the range is
guaranteed that they are in an editing host. Therefore, it's not required if
it's outside the editing host. So, comparisons which check whether a node is
either/neither editing host or/nor ancestor block can get same result with
comparing with the closest one of the editing host or the closest editable
block.
Differential Revision: https://phabricator.services.mozilla.com/D202697
