Now that we cache ActionCount, we can check for the absence of actions
and return false, or send an async message and return true.
Differential Revision: https://phabricator.services.mozilla.com/D135909
Move ActionCount/ActionNameAt/ActionDescriptionAt to Accessible,
use cached values in RemoteAccessible, and tweak platforms.
Also introduce browser test.
Differential Revision: https://phabricator.services.mozilla.com/D135908
This fixes problems for Orca caused by object destruction when grabbing focus or setting the caret.
This patch also Fixes two bugs in the RemoteAccessible reuse code.
First, moved LocalAccessibles were previously being tracked even in the parent process if the cache was enabled.
While that was harmless, it was also unnecessary, since we only need to do that in order to send IPC notifications.
Second, when an OuterDocAccessible was moved, we were previously trying to shut down its child document, causing a crash.
Child documents must be left alone, since they are added ande removed differently to normal children.
Differential Revision: https://phabricator.services.mozilla.com/D135422
We need to handle OOP iframes specially when querying for IEnumVARIANT.
However, we can't rely on the role because it might be overridden by ARIA.
Instead, check for the absence of IAccessibleHyperText (which isn't supported for iframes) and a child count of 1.
This might trigger for a few things other than iframes, but it's not a problem to do what we're doing here whenever the child count is 1.
Differential Revision: https://phabricator.services.mozilla.com/D136257
In Gecko, ARIA documents and dialogs can fire load complete/reload/load stopped events, but they don't support AtkDocument.
Since the corresponding ATK signals are only supported on AtkDocument, just ignore these events for anything which isn't a DocAccessible.
This has no impact on clients, since the signal was invalid anyway, but it does prevent errors being logged.
Differential Revision: https://phabricator.services.mozilla.com/D135975
This fixes problems for Orca caused by object destruction when grabbing focus or setting the caret.
This also fixes an oversight where moved LocalAccessibles were being tracked even in the parent process if the cache was enabled.
While that was harmless, it was also unnecessary, since we only need to do that in order to send IPC notifications.
Differential Revision: https://phabricator.services.mozilla.com/D135422
I think there is a potential crasher if an AT holds a reference to a column object while its parent table expires, and then tries to retrieve AXChildren. We need to expire te column objects when the table expires or is destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D136288
In terms of the C++ code, this patch does basically one thing, which is
allowing creating option / optgroup accessibles without a frame for
comboboxes, and tracking mutations like layout does.
It seems this should be straight-forward, but handling mutations got a
bit complicated. We don't want to forcibly re-create accessibles, so we
want to re-use the PruneOrInsertSubtree logic that ContentInserted uses.
But determining whether we need to create the accessible requires
having flushed styles, so I added a ScheduleAccessibilitySubtreeUpdate
API to trigger that from WillRefresh once style and layout are
up-to-date.
The rest of the test updates should be sort of straight-forward. They
reflect two changes:
* <option> accessibles are leaves now (so they don't have text
children). Note that we still have the right native name and so on,
using the same logic we use to render the label.
* In 1proc tests, the focus no longer goes to the <option>, and uses
the same code-path that e10s does (moving focus to a <menulist> in
the parent process). Since that wasn't easy to test for (afaict) and
we have browser tests to cover that
(browser_treeupdate_select_dropdown.js, etc), I've decided to just
remove the tests that relied on the previous code-path, as they were
testing for a codepath that users weren't hitting anyways.
I've tested this with JAWS and Orca and behavior seems unchanged to my
knowledge.
Differential Revision: https://phabricator.services.mozilla.com/D133098
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
In terms of the C++ code, this patch does basically one thing, which is
allowing creating option / optgroup accessibles without a frame for
comboboxes, and tracking mutations like layout does.
It seems this should be straight-forward, but handling mutations got a
bit complicated. We don't want to forcibly re-create accessibles, so we
want to re-use the PruneOrInsertSubtree logic that ContentInserted uses.
But determining whether we need to create the accessible requires
having flushed styles, so I added a ScheduleAccessibilitySubtreeUpdate
API to trigger that from WillRefresh once style and layout are
up-to-date.
The rest of the test updates should be sort of straight-forward. They
reflect two changes:
* <option> accessibles are leaves now (so they don't have text
children). Note that we still have the right native name and so on,
using the same logic we use to render the label.
* In 1proc tests, the focus no longer goes to the <option>, and uses
the same code-path that e10s does (moving focus to a <menulist> in
the parent process). Since that wasn't easy to test for (afaict) and
we have browser tests to cover that
(browser_treeupdate_select_dropdown.js, etc), I've decided to just
remove the tests that relied on the previous code-path, as they were
testing for a codepath that users weren't hitting anyways.
I've tested this with JAWS and Orca and behavior seems unchanged to my
knowledge.
Differential Revision: https://phabricator.services.mozilla.com/D133098
With this patch on its own we get some a11y tests failures, but those
are fixed on a later patch.
Combobox select no longer creates frames for its <options>, nor an
nsListControlFrame. Instead, it computes its right intrinsic size using
the largest size of the options. This is better, because we render the
option text using the select style so if the select and option styles
are mismatched it'd cause changes in the size of the select when text
changes. See the following in a build without the patch, for example:
<select>
<option>ABC</option>
<option style="font-size: 1px">Something long</option>
</select>
This seems like a rather obscure case, but it's important to get it
right, see bug 1741888.
With this patch we use the same setup in content and parent processes
(this needs bug 1596852 and bug 1744152). This means we can remove a
bunch of the native view and popup code in nsListControlFrame. A couple
browser_* tests are affected by this change and have been tweaked
appropriately (the changes there are trivial).
Not creating an nsListControlFrame for dropdown select means that we
need to move a bunch of the event handling code from nsListControlFrame
to a common place that nsComboboxControlFrame can also use. That place
is HTMLSelectEventListener, and I think the setup is much nicer than
having the code intertwined with nsListControlFrame. It should be
relatively straight-forward to review, mostly moving code from one part
to another.
Another thing that we need to do in HTMLSelectEventListener that we
didn't use to do is listening for DOM mutations on the dropdown. Before,
we were relying on changes like text mutations triggering a reflow of
the listcontrolframe, which also triggered a reflow of the
comboboxcontrolframe, which in turn updated the text of the anonymous
content. Now we need to trigger that reflow manually.
There are some further simplifications that can be done after this
lands (cleanup naming of openInParentProcess and so on, among others),
but I'd rather land this first (after the merge of course) and work on
them separately.
Differential Revision: https://phabricator.services.mozilla.com/D132719
When adding a new accessibility event to NotificationController, we
check to see if the event should be suppressed. This is a time-memory
tradeoff; since we check every event before dispatching them, the
correctness should not be impacted regardless of whether we always
append events. This change takes the time required from O(mn^2) where m
is the average depth of an event's parent tree and n is the number of
events, to O(mn).
Differential Revision: https://phabricator.services.mozilla.com/D135159
Creating a non-remote browser is obscure, but it turns out that it is possible.
BrowserTestUtils.addTab/gBrowser.addTab takes a forceNotRemote: true option, but even though this doesn't set remote on the browser element, it still sets maychangeremoteness.
To work around this, we create a tab with a blank document and forceNotRemote: true, remove maychangeremoteness and finally set the src to load our document.
We must also set a pref to allow this.
With this patch, the sanitizer will no longer strip elements from our snippets.
Differential Revision: https://phabricator.services.mozilla.com/D135147
Changed how our attributes tests work a bit to be single "is" test
instead of comparing each attribute separately. This allows passing a
todo option without it failing on attributes that are identical.
Differential Revision: https://phabricator.services.mozilla.com/D134974
Now that GroupPosition and GetGroupInfo are in Accessible, we can make
AccGroupInfo use the Accessible base class.
With one exception: Tables are still local only. That should be
addressed in bug 1735970.
Differential Revision: https://phabricator.services.mozilla.com/D134212
Changed the methods a bit, instead of a HasDirty boolean method, I went
with a getter and a get-and-creator. This will lend better to remote
accessibles where we won't have a dirty flag.
Differential Revision: https://phabricator.services.mozilla.com/D134209
The nsAccUtils method was a "fast" one for calculating set sizes and
conceptual parents. Unified it with
LocalAccessible::GetLevelInternal in Accessible::GetLevel with an
argument.
I also fixed select->optgroup->option group attributes.
Differential Revision: https://phabricator.services.mozilla.com/D134208
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
While mingw builds don't require user32 and advapi32 explicitly, it doesn't
hurt for them to be there (and they're required for clang-cl build).
Likewise, while clang-builds don't require uuid and userenv explicitly
because they're pulled in via #pragmas in the source code, mingw doesn't
support those #pragmas and needs them explicitly, which doesn't hurt the
clang-cl builds.
Differential Revision: https://phabricator.services.mozilla.com/D134737
