When window emulation is enabled, each tab document gets its own HWND.
OOP iframes get the same HWND as their tab document and fire events with that HWND.
However, the root accessible for the HWND (the tab document) can't return accessibles for OOP iframes.
Therefore, we must get the root accessible from the main HWND and call accChild on that instead.
We must do this in the parent process, but the tab document accessible is in the content process.
Although OOP a11y clients talk directly to the content process, the clients that need window emulation are in-process.
All in-process client calls get intercepted by AccessibleHandler, so we can deal with this forwarding in AccessibleHandler.
Differential Revision: https://phabricator.services.mozilla.com/D65054
--HG--
extra : moz-landing-system : lando
This is similar to the fix in bug 1614079 where we need to account
for a descendant that might match past a process boundary.
Differential Revision: https://phabricator.services.mozilla.com/D63974
--HG--
extra : moz-landing-system : lando
This adds both the role as well as calculation of the posinset, setsize, and level calculation if not provided by the author.
Differential Revision: https://phabricator.services.mozilla.com/D64590
--HG--
extra : moz-landing-system : lando
Windows programs run via Wine don't like Unix absolute paths (they look
like command line arguments), so we need to use relative paths.
Mingw already run fxc2 via wine, but for some reason it doesn't care
about the Unix absolute paths. genshaders does need some adjustements to
run properly with the real fxc.
Now, on actual Windows, because the temporary directory where
tempfile.NamedTemporaryFile creates files by default is not necessarily
on the same drive as where the command runs from, a relative path can't
be constructed. So we also force the temporary file to be created in the
current (obj) directory.
There is no similar concern for other files because we only go from
objdir to srcdir, and the build system already doesn't support both
being on a separate drive.
While here, flush stdout when the genshared script writes to it, so that
the messages are printed out immediately rather than randomly, later,
after output from subprocesses.
Differential Revision: https://phabricator.services.mozilla.com/D64294
--HG--
extra : moz-landing-system : lando
nsFocusManager::SetFocus (and thus Accessible::TakeFocus) was fixed for Fission in bug 1556627.
Most of these tests now pass without modification.
browser_caching_value.js needed to be tweaked slightly to synthesize a key in the OOP iframe instead of the top level document.
Differential Revision: https://phabricator.services.mozilla.com/D64254
--HG--
extra : moz-landing-system : lando
This covers most cycle collected objects which support weak references, but
not the ones which inherit from a cycle collected class and don't do any cycle
collection on their own.
Differential Revision: https://phabricator.services.mozilla.com/D63962
--HG--
extra : moz-landing-system : lando
In a somewhat easy way. There are better ways to do this (moving
text-decoration-style to be a proper cbindgen enum class or such), but this
does the job for now.
Depends on D63794
Differential Revision: https://phabricator.services.mozilla.com/D63795
--HG--
extra : moz-landing-system : lando
::marker content gets handled like text from any other CSS pseudo-class.
Therefore, using HTMLListBulletAccessible ends up duplicating the content already exposed in the a11y tree.
Now, we only use HTMLListBulletAccessible for nsBulletFrames instead of all marker frames.
As part of this, remove nsContainerFrame::GetSpokenMarkerContent, since we no longer need it to retrieve ::marker content.
The bulk of its other work was done by nsBulletFrame::GetSpokenContent, which we now call directly.
It also handled producing a default bullet character for list-style-image, but it makes sense for this to live in the a11y code.
Differential Revision: https://phabricator.services.mozilla.com/D63443
--HG--
extra : moz-landing-system : lando
If a keyboard-focused accessible is removed, the caret jumps to its
nearest ancestor. To avoid arbitrary accessibility focus moves, ignore
caret events that have no selection and are not focusable items.
Differential Revision: https://phabricator.services.mozilla.com/D63541
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This removes the need for explicit #ifdef NS_BUILD_REFCNT_LOGGING without
introducing user-defined destructors when it is not defined.
Also, some uses of virtual for declaring destructors are replaced by the
appropriate override declaration through these changes.
Differential Revision: https://phabricator.services.mozilla.com/D62604
--HG--
extra : moz-landing-system : lando
This allows `performAction` to immediately return false if a boundary is
reached and allow TalkBack to navigate past the web view.
Change viewport cache listener to reorder since it should catch all tree
mutations in the document.
Differential Revision: https://phabricator.services.mozilla.com/D63117
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
Normally, XUL menupopups contain XUL menuitems, and XUL menuitems fire DOMMenuitemActive events from layout to manage a11y focus.
However, the new parent process select dropdown implementation uses a menulist containing div elements instead of XUL menuitems.
DOMMenuItemActive doesn't work for div elements because we check Accessible::ContainerWidget(), and that doesn't know to return the menupopup for div elements.
Since aria-activedescendant is the more web standard way to handle this, the new select dropdown implementation uses aria-activedescendant.
Differential Revision: https://phabricator.services.mozilla.com/D62677
--HG--
extra : moz-landing-system : lando
Currently, only documents dispatch scroll events when in reality any
element can have scrollable overflows.
Differential Revision: https://phabricator.services.mozilla.com/D62665
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
GENERATED_FILES now defaults to python3 unless py2=True is specified as
an argument. All existing GENERATED_FILES scripts and GeneratedFile
templates have the py2=True attribute added, so this patch should
effectively be a no-op.
Going forward, individual scripts can be converted to python3 and their
corresponding py2=True attribute can be deleted. In effect, this patch
will be backed out in pieces until all scripts run in python3, at which
point the py2 attribute itself can be removed.
Differential Revision: https://phabricator.services.mozilla.com/D60919
--HG--
extra : moz-landing-system : lando
Chrome prunes the subtrees of links and headings (with single text leaf
children) and we mimic this in Gecko. The problem is that sometimes a
heading can be a child of a link, and it would be impossible to reach
when navigating by headings.
The main reason we mimiced chrome is because we would getthe name of the
node and its subtree uttered, so you would hear the name of the node
twice. By using contentDescription we can suppress the subtree from
TalkBack's utterance and preserve the node's children for heading
navigation.
Differential Revision: https://phabricator.services.mozilla.com/D61766
--HG--
extra : moz-landing-system : lando
We replace the a11y telemetry thread with a call to the new
`NS_DispatchBackgroundTask` infrastructure. We use `NS_DISPATCH_EVENT_MAY_BLOCK`
because the task performs some I/O to load the instantiator's version info.
I also took the opportunity to eliminate some redundant copying.
Differential Revision: https://phabricator.services.mozilla.com/D61769
--HG--
extra : moz-landing-system : lando
Added long press as well as the old tooltip language back
and updated 2 tests.
Differential Revision: https://phabricator.services.mozilla.com/D61717
--HG--
extra : moz-landing-system : lando
`nsRange` instances are allocated a lot in the heap especially by editor and
spellchecker. The allocation cost is too bad for benchmarks. Therefore,
we should reuse released instances as far as possible. For managing it in
static factory methods of `nsRange`, we need to hide `nsRange` constructor.
Differential Revision: https://phabricator.services.mozilla.com/D61237
--HG--
extra : moz-landing-system : lando
Added right click on new tab button to open containers menu.
Removed long press and added option to enable left click in preferences menu.
Renamed privacy.userContext.longPressBehavior to privacy.userContext.newTabContainer.enabled
Differential Revision: https://phabricator.services.mozilla.com/D58410
--HG--
extra : moz-landing-system : lando
This is just not a thing you can do if you have min() / max() / etc, as the min
/ max value may depend on the percentage basis.
Differential Revision: https://phabricator.services.mozilla.com/D60168
--HG--
extra : moz-landing-system : lando
This means that for any other ARIA role, we will expose the DOCUMENT role on the DocAccessible.
Differential Revision: https://phabricator.services.mozilla.com/D60632
--HG--
extra : moz-landing-system : lando
This is just not a thing you can do if you have min() / max() / etc, as the min
/ max value may depend on the percentage basis.
Differential Revision: https://phabricator.services.mozilla.com/D60168
--HG--
extra : moz-landing-system : lando
This was done by:
This was done by applying:
```
diff --git a/python/mozbuild/mozbuild/code-analysis/mach_commands.py b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
index 789affde7bbf..fe33c4c7d4d1 100644
--- a/python/mozbuild/mozbuild/code-analysis/mach_commands.py
+++ b/python/mozbuild/mozbuild/code-analysis/mach_commands.py
@@ -2007,7 +2007,7 @@ class StaticAnalysis(MachCommandBase):
from subprocess import Popen, PIPE, check_output, CalledProcessError
diff_process = Popen(self._get_clang_format_diff_command(commit), stdout=PIPE)
- args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format]
+ args = [sys.executable, clang_format_diff, "-p1", "-binary=%s" % clang_format, '-sort-includes']
if not output_file:
args.append("-i")
```
Then running `./mach clang-format -c <commit-hash>`
Then undoing that patch.
Then running check_spidermonkey_style.py --fixup
Then running `./mach clang-format`
I had to fix four things:
* I needed to move <utility> back down in GuardObjects.h because I was hitting
obscure problems with our system include wrappers like this:
0:03.94 /usr/include/stdlib.h:550:14: error: exception specification in declaration does not match previous declaration
0:03.94 extern void *realloc (void *__ptr, size_t __size)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/malloc_decls.h:53:1: note: previous declaration is here
0:03.94 MALLOC_DECL(realloc, void*, void*, size_t)
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozilla/mozalloc.h:22:32: note: expanded from macro 'MALLOC_DECL'
0:03.94 MOZ_MEMORY_API return_type name##_impl(__VA_ARGS__);
0:03.94 ^
0:03.94 <scratch space>:178:1: note: expanded from here
0:03.94 realloc_impl
0:03.94 ^
0:03.94 /home/emilio/src/moz/gecko-2/obj-debug/dist/include/mozmemory_wrap.h:142:41: note: expanded from macro 'realloc_impl'
0:03.94 #define realloc_impl mozmem_malloc_impl(realloc)
Which I really didn't feel like digging into.
* I had to restore the order of TrustOverrideUtils.h and related files in nss
because the .inc files depend on TrustOverrideUtils.h being included earlier.
* I had to add a missing include to RollingNumber.h
* Also had to partially restore include order in JsepSessionImpl.cpp to avoid
some -WError issues due to some static inline functions being defined in a
header but not used in the rest of the compilation unit.
Differential Revision: https://phabricator.services.mozilla.com/D60327
--HG--
extra : moz-landing-system : lando
rg -l 'mozilla/Move.h' | xargs sed -i 's/#include "mozilla\/Move.h"/#include <utility>/g'
Further manual fixups and cleanups to the include order incoming.
Differential Revision: https://phabricator.services.mozilla.com/D60323
--HG--
extra : moz-landing-system : lando
On Windows, if the top level document hasn't received its parent COM proxy yet, sending constructors for child documents will be deferred.
If an OuterDocAccessible for an OOP iframe is created inside a child document before its constructor is sent, we must also defer the call to BrowserBridgeChild::SendSetEmbedderAccessible.
previously, we tried to send the embedder before the document constructor was sent, causing a crash.
Differential Revision: https://phabricator.services.mozilla.com/D59832
--HG--
extra : moz-landing-system : lando
After bug 981248, <input type="number"> no longer has an anonymous text input.
Instead, the <input type="number"> itself manages the text.
Previously, the a11y code which fired value change events for text changes only did this for combo boxes and role ENTRY.
This meant a value change event was no longer fired for <input type="number">.
This condition has now been extended to include role SPINBUTTON.
This fixes reporting of <input type="number"> changes for JAWS.
Differential Revision: https://phabricator.services.mozilla.com/D60101
--HG--
extra : moz-landing-system : lando
1. Implement ProxyAccessible::TakeFocus on Windows.
2. Use this implementation in xpcAccessible::TakeFocus like we do on other platforms.
3. Enable accessible/tests/browser/fission/browser_take_focus.js on Windows, since it now works.
Differential Revision: https://phabricator.services.mozilla.com/D59977
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
Instead, subclass nsTextControlFrame. This simplifies the code and avoids
correctness issues.
I kept the localization functionality though it is not spec compliant. But I
filed a bug to remove it in a followup.
Differential Revision: https://phabricator.services.mozilla.com/D57193
--HG--
extra : moz-landing-system : lando
Previously, when opening the dialog, we only waited for a reorder event.
This could mean we programmatically closed the dialog before it was ever focused.
That in turn would mean that focus would never be fired on the previous window when the dialog was closed, causing the close dialog test to time out.
Differential Revision: https://phabricator.services.mozilla.com/D59826
--HG--
extra : moz-landing-system : lando
This reverts the change I made in bug 1572811, and instead fixes a much
more narrow case when the inner table frame is mid-construction.
Differential Revision: https://phabricator.services.mozilla.com/D58570
--HG--
extra : moz-landing-system : lando
This is an alternative to carrying a revert of the offending changeset, since the bug doesn't show hope of a fix anytime soon, or maybe ever. This way we don't have to keep rebasing the patch as we pick up new clangs, and developers don't have to remember to apply the patch when building a local compiler.
Differential Revision: https://phabricator.services.mozilla.com/D59200
--HG--
extra : moz-landing-system : lando
It is unexpected (see bug) that a -moz-box is affected by baseline alignment.
Make -moz-box be block-outside, and -moz-inline-box be inline-outside, instead
of the bespoke thing we have now.
This is more similar to everything else, and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D58726
--HG--
extra : moz-landing-system : lando
It is unexpected (see bug) that a -moz-box is affected by baseline alignment.
Make -moz-box be block-outside, and -moz-inline-box be inline-outside, instead
of the bespoke thing we have now.
This is more similar to everything else, and fixes the bug.
Differential Revision: https://phabricator.services.mozilla.com/D58726
--HG--
extra : moz-landing-system : lando
Talkback users expect that when you navigate past the end of the text in a node, Talkback will move into the next node and navigate there.
However, even though text navigation is async (client performs an action on the focused accessible and then waits for a text traversal event), firing a traversal event with a different accessible from the focused accessible is not supported by Talkback.
Firing a11y focus on the new node (as we did previously) doesn't fix this, but instead causes the entire node to be reported, among other weird behaviour.
1. Don't fire a11y focus for text traversal.
Aside from Talkback reporting the entire node, this was also confusing Talkback, causing it to try to navigate several times into the new node.
2. When navigating text, cache whether we're at either edge.
We do this because we need to be able to synchronously query whether we're at the edge, but we do navigation async.
Special handling is needed for words at the end because words don't include trailing space.
3. When performing a text navigation action, check if we're already at the edge using the cache described above.
If we are, synchronously return false, as Talkback expects.
Talkback will then move to the next/previous node itself and navigate the text there.
Differential Revision: https://phabricator.services.mozilla.com/D57926
--HG--
extra : moz-landing-system : lando
In a follow-up commit a new `ComparePoints` method with cleaner
arguments and return value will be added.
Differential Revision: https://phabricator.services.mozilla.com/D55295
--HG--
extra : moz-landing-system : lando
For paragraphs, divs, spans, etc., a11y focus on Android goes to text leaf Accessibles, rather than to the HyperTextAccessible container.
This does make sense, as these containers frequently embed other content, so the text needs to be reachable as a separate item.
However, previously, performing text navigation on these text leaf Accessibles returned the HyperTextAccessible parent.
This isn't supported by Talkback, and even if it were, it causes other problems; e.g. a11y focus being lost if the user was focused on a child other than the first child of such a container.
Therefore, if text navigation was performed on a text leaf Accessible, we now return a result within the text leaf Accessible if possible, rather than the HyperTextAccessible.
1. Make AccessibleWrap::GetTextContents support text leaf Accessibles (for both local and remote proxied Accessibles).
This is used when providing text for text traversal events.
2. When navigating text on Android, we use Pivot::Next/PrevText.
However, this will always return a HyperTextAccessible, even when starting on a text leaf.
Therefore, if the result from Pivot::Next/prevText resides entirely within the same text leaf, translate the offsets from the HyperTextAccessible so they're relative to the text leaf and return the text leaf.
3. Pivot::Next/PrevText already supported starting from a text leaf Accessible.
However, they ignored the offsets, which meant that navigating from a text leaf would always navigate to the start/end of the text leaf.
Now, if a text leaf is passed to Pivot::Next/PrevText, the offsets (if specified) are translated to the HyperTextAccessible parent first.
4. Adjust the existing character/word/line tests so they ensure that navigation returns the node that has a11y focus; i.e. the text leaf.
Differential Revision: https://phabricator.services.mozilla.com/D57269
--HG--
extra : moz-landing-system : lando
The inclusions were removed with the following very crude script and the
resulting breakage was fixed up by hand. The manual fixups did either
revert the changes done by the script, replace a generic header with a more
specific one or replace a header with a forward declaration.
find . -name "*.idl" | grep -v web-platform | grep -v third_party | while read path; do
interfaces=$(grep "^\(class\|interface\).*:.*" "$path" | cut -d' ' -f2)
if [ -n "$interfaces" ]; then
if [[ "$interfaces" == *$'\n'* ]]; then
regexp="\("
for i in $interfaces; do regexp="$regexp$i\|"; done
regexp="${regexp%%\\\|}\)"
else
regexp="$interfaces"
fi
interface=$(basename "$path")
rg -l "#include.*${interface%%.idl}.h" . | while read path2; do
hits=$(grep -v "#include.*${interface%%.idl}.h" "$path2" | grep -c "$regexp" )
if [ $hits -eq 0 ]; then
echo "Removing ${interface} from ${path2}"
grep -v "#include.*${interface%%.idl}.h" "$path2" > "$path2".tmp
mv -f "$path2".tmp "$path2"
fi
done
fi
done
Differential Revision: https://phabricator.services.mozilla.com/D55443
--HG--
extra : moz-landing-system : lando
The change to moz.build unveiled a couple unified build issues that I also had
to fix.
Depends on D55365
Differential Revision: https://phabricator.services.mozilla.com/D55366
--HG--
extra : moz-landing-system : lando
Sometimes, when running tests, fetching IDispatch for a remote IAccessible succeeds, but QueryInterface to IAccessible fails.
This is probably because the remote Accessible died between these two calls.
While we want to know about this in case of real problems in future, it usually doesn't indicate a problem, so make it a warning.
Differential Revision: https://phabricator.services.mozilla.com/D55404
--HG--
extra : moz-landing-system : lando
Initially this was going to be a simple cleanup: Remove some useless namespaces
here and there and so on, remove `using` statements from the header and so on.
But unfortunately, DOMIntersectionObserver.h (which is included in Element.h,
unnecessarily) ended up exposing `Element` unnamespaced to a lot of code, so I
had to fix that.
Differential Revision: https://phabricator.services.mozilla.com/D55316
--HG--
extra : moz-landing-system : lando
ARIA role="combobox" gets a Gecko role of EDITCOMBOBOX.
However, there are two kinds of ARIA comboboxes:
1. ARIA 1.0 comboboxes are contentEditable. Text is entered into the combobox itself.
2. ARIA 1.1 comboboxes are not contentEditable. Instead, they have a textbox child into which text is entered.
On Android, traversal skipped EDITCOMBOBOX Accessibles altogether.
This meant that while 1.1 comboboxes were accessible (because we'd walk inside and land on the textbox), 1.0 comboboxes were not.
We still don't want to land on 1.1 comboboxes because the container isn't useful to the user.
Therefore, only stop on EDITCOMBOBOX Accessibles which are editable.
Differential Revision: https://phabricator.services.mozilla.com/D55224
--HG--
extra : moz-landing-system : lando
Gecko's link role is used even for <a> elements without href or onclick.
Actionable links are indicated using the linked state.
However, Android doesn't have a concept equivalent to the linked state.
Thus, on Android, we must not expose an element as a link at all if it does not have the linked state.
Differential Revision: https://phabricator.services.mozilla.com/D55207
--HG--
extra : moz-landing-system : lando
Previously, due to bug 33654, we incorrectly added the width of the scrollbars to the textarea.
This was causing lines to be limited to 6 characters on ubuntu 18.04, even though we set cols="5" and thus expect 5 characters.
Setting scrollbar-width: none on the textarea works around this.
Differential Revision: https://phabricator.services.mozilla.com/D55205
--HG--
extra : moz-landing-system : lando
A XUL <label control="id"> can refer to an HTML element.
Keyboard and mouse support for this already works, but previously, this wasn't being exposed via accessibility APIs.
1. Split the code to get the name from an associated XUL label out of Accessible::XULElmName into a new function Accessible::NameFromAssociatedXULLabel.
2. Use NameFromAssociatedXULLabel for HTMl elements.
3. Update AccessKey and RelationByType to support HTML elements with associated XUL labels.
4. Rename accessible/tests/mochitest/actions/test_keys_menu.xhtml to test_keys.xhtml so it can cover accessKey outside of menus.
5. Add tests.
Differential Revision: https://phabricator.services.mozilla.com/D55057
--HG--
rename : accessible/tests/mochitest/actions/test_keys_menu.xhtml => accessible/tests/mochitest/actions/test_keys.xhtml
extra : moz-landing-system : lando
Sub classes of `nsITextControlElement` are only `HTMLInputElement` and
`HTMLTextAreaElement`. And both base class is
`nsGenericHTMLFormElementWithState`. Therefore, we can make
`nsITextControlElement` inherit `nsGenericHTMLFormElementWithState` and
make `HTMLInputElement` and `HTMLTextAreaElement` inherit
`nsITextControlElement`. Then, we can get rid of a lot of QI between
`nsINode`/`nsIContent`/`Element` and `nsITextControlElement` (and note that
some of them in a hot path).
Additionally, this patch renames `nsITextControlElement` to
`mozilla::TextControlElement`.
Differential Revision: https://phabricator.services.mozilla.com/D54330
--HG--
rename : dom/html/nsITextControlElement.h => dom/html/TextControlElement.h
extra : moz-landing-system : lando
Sub classes of `nsITextControlElement` are only `HTMLInputElement` and
`HTMLTextAreaElement`. And both base class is
`nsGenericHTMLFormElementWithState`. Therefore, we can make
`nsITextControlElement` inherit `nsGenericHTMLFormElementWithState` and
make `HTMLInputElement` and `HTMLTextAreaElement` inherit
`nsITextControlElement`. Then, we can get rid of a lot of QI between
`nsINode`/`nsIContent`/`Element` and `nsITextControlElement` (and note that
some of them in a hot path).
Additionally, this patch renames `nsITextControlElement` to
`mozilla::TextControlElement`.
Differential Revision: https://phabricator.services.mozilla.com/D54330
--HG--
rename : dom/html/nsITextControlElement.h => dom/html/TextControlElement.h
extra : moz-landing-system : lando
Previously, HTMLTextFieldAccessible::DoAction just called TakeFocus().
When the field already has focus, TakeFocus() will do nothing.
However, the user might be activating this element because they dismissed a touch keyboard and want to bring it back.
Therefore, we must simulate a click so Gecko will bring up the keyboard.
Differential Revision: https://phabricator.services.mozilla.com/D54106
--HG--
extra : moz-landing-system : lando
This really shouldn't be possible.
All XUL trees should have nsIDOMXULMultiSelectControlElement, and the tree is focused at this point, so it shouldn't be dying.
Nevertheless, this sometimes happens in the wild and was causing crashes.
Differential Revision: https://phabricator.services.mozilla.com/D53373
--HG--
extra : moz-landing-system : lando
Mark the html:mark element to the new ROLE_MARK, which currently maps the same as role_text, and the xml-role of "mark", make sure we expose the roleDescription on Mac, and adjust the test so it tests that the attributes don't pick up any unexpected color for this particular element. So, the background attribute is empty when there is no unexpected, non-default background color.
Differential Revision: https://phabricator.services.mozilla.com/D52989
--HG--
extra : moz-landing-system : lando
This code doesn't want to deal with Shadow DOM but with <input type=number> and
such native-anonymous inputs. So do that explicitly.
Differential Revision: https://phabricator.services.mozilla.com/D53204
--HG--
extra : moz-landing-system : lando
Previously, we only restored focus within the top level remote browser.
This is fine for remote documents without iframes or only in-process iframes, as was the case with e10s.
For Fission, if an OOP iframe has focus, we need to get the appropriate nested remote browser.
Fortunately, BrowserParent::GetFocused was introduced to do exactly this.
Differential Revision: https://phabricator.services.mozilla.com/D52803
--HG--
extra : moz-landing-system : lando
If an embed or object doesn't specify a URL (or specifies a URL which isn't web content), it won't be created as an OuterDocAccessible.
For example, an embed with no src will be created as a generic HyperTextAccessible.
If the URL later changes to refer to web content, we must recreate as an OuterDocAccessible.
Previously, we didn't recreate, which was causing an assertion and may have caused other strange issues as well.
Differential Revision: https://phabricator.services.mozilla.com/D52292
--HG--
extra : moz-landing-system : lando
An OuterDoc shouldn't get accessibility focus itself.
Focus should always go to something inside it.
However, OOP iframes will get DOM focus because their content isn't in this process.
We now suppress the OuterDoc focus in this case.
The OOP browser will fire focus for the correct Accessible inside the embedded document.
Without suppression of the OuterDoc focus, the two focus events will race and the OuterDoc focus may override the correct embedded focus for accessibility clients.
Even if they fired in the correct order, clients may report extraneous focus information to the user before reporting the correct focus.
Differential Revision: https://phabricator.services.mozilla.com/D52126
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
3. Mac's implementation of ProxyCreated requires that AddChildDoc be called *before* ProxyCreated so it can invalidate the native children of the parent.
Because it's possible for an OOP iframe document to be added to its embedder after the document is created, we can't satisfy this requirement for OOP iframe documents.
Therefore, we now allow a null parent in Mac's ProxyCreated and use the reorder event fired later to invalidate the native children.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
We noticed a handful of linker errors when building with other build optimization flags -Os, -O2, and -O3 instead the default, -Oz.
(see Bug 1591725).
This change is intended to be 0-impact on functionality -- simply resolving the linker errors.
Differential Revision: https://phabricator.services.mozilla.com/D51312
--HG--
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
1. When creating a DocAccessibleParent for an embedded document in an OOP iframe, it's possible that the embedder accessible hasn't been set yet.
This can occur if the iframe is initially hidden.
Previously, we incorrectly set the document up as a top level document (e.g. tab document) in this case.
Now, we set up the document as top level in its content process, set up the proxy, etc.
The document will be added to its child document later when the embedder is set.
2. When setting the embedder accessible for an OOP iframe, check if the embedded DocAccessibleParent already exists.
This can happen if an iframe is hidden and then shown or an iframe is reflowed by layout.
If it already exists, add the embedded (child) document to its embedder.
Differential Revision: https://phabricator.services.mozilla.com/D51357
--HG--
extra : moz-landing-system : lando
nsXULWindow is no longer XUL specific and is somewhat confusing name.
Differential Revision: https://phabricator.services.mozilla.com/D51486
--HG--
rename : xpfe/appshell/nsXULWindow.cpp => xpfe/appshell/AppWindow.cpp
rename : xpfe/appshell/nsXULWindow.h => xpfe/appshell/AppWindow.h
rename : xpfe/appshell/nsIXULWindow.idl => xpfe/appshell/nsIAppWindow.idl
extra : moz-landing-system : lando
I don't have a test case for this crash, but the stack suggests the frame is null.
This can certainly happen for display: contents.
Differential Revision: https://phabricator.services.mozilla.com/D51560
--HG--
extra : moz-landing-system : lando
Sometimes, depending on how children were changed, children might be in the insertion list out of order; e.g. [child2, child1].
It's also possible that an earlier child (child1 in the above example) is being moved out of another container.
When processing the earlier insertion (child2), we'll determine we need to move it within its parent and will fetch its new previous sibling so we can move it into the right place.
However, in this case, the new previous sibling (child1) will be in the wrong container.
We can't move in that case; the new previous sibling's index in parent will obviously be wrong, since it's relative to the wrong container.
Therefore, we just skip the move.
Since the previous sibling (child1) is later in the insertion list, the ordering will be corrected when we process that insertion.
Differential Revision: https://phabricator.services.mozilla.com/D51037
--HG--
extra : moz-landing-system : lando
OuterDocAccessible has some special behaviour.
We really shouldn't try to use some other class for iframes.
Anyway, making an iframe part of an ARIA table won't work for other reasons, plus I'm not sure it makes much sense.
Differential Revision: https://phabricator.services.mozilla.com/D50769
--HG--
extra : moz-landing-system : lando
Please note that it is the first reformat with clang-format 9
I only saw a fix in the .mm file
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D49056
--HG--
extra : moz-landing-system : lando
I don't think these need invalidation of any sort since they only depend on
ancestors, and we recreate accessibles when the element's ancestor chain changes.
Differential Revision: https://phabricator.services.mozilla.com/D49408
--HG--
extra : moz-landing-system : lando
For remote content documents, select dropdowns (for <select size="1">) are rendered in the parent process using a XUL menupopup.
This means that the accessibility code for HTML selects doesn't apply.
In the menupopup, the optgroup is a sibling of its contained options.
For accessibility, we want to preserve the hierarchy such that the options are inside the optgroup.
We do this using aria-owns on the optgroup item.
This required some tweaks to XULMenuitemAccessible, as it couldn't previously handle grouping Accessibles between the menupopup and its items.
Differential Revision: https://phabricator.services.mozilla.com/D43901
--HG--
extra : moz-landing-system : lando
The previous code relied on the header label having a value property.
However, after the conversion to Fluent in bug 1563026, this is no longer the case.
Instead, use aria-labelledby, which avoids label duplication and will work irrespective of the label's implementation.
Differential Revision: https://phabricator.services.mozilla.com/D49125
--HG--
extra : moz-landing-system : lando
When XBL is disabled, no code in dom/xbl will be built. Also, adds ifdefs
to remove any of the XBL related code elsewhere. There's definitely more
that can be done here, but I think it's better to wait to do the rest of
the cleanup when we actually remove the code.
Depends on D45612
Differential Revision: https://phabricator.services.mozilla.com/D45613
--HG--
extra : moz-landing-system : lando
Lazily creating children might cause us to make layout calls at unsafe times.
Differential Revision: https://phabricator.services.mozilla.com/D47361
--HG--
extra : moz-landing-system : lando
For remote content documents, select dropdowns (for <select size="1">) are rendered in the parent process using a XUL menupopup.
This means that the accessibility code for HTML selects doesn't apply.
In the menupopup, the optgroup is a sibling of its contained options.
For accessibility, we want to preserve the hierarchy such that the options are inside the optgroup.
We do this using aria-owns on the optgroup item.
This required some tweaks to XULMenuitemAccessible, as it couldn't previously handle grouping Accessibles between the menupopup and its items.
Differential Revision: https://phabricator.services.mozilla.com/D43901
--HG--
extra : moz-landing-system : lando
