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
Hiroyuki Ikezoe
Emilio Cobos Álvarez
James Teh
Taylor
Sylvestre Ledru
Masayuki Nakano
Coroiu Cristina
Yura Zenevich
Marco Zehe
Tim Nguyen
Dorel Luca
Csoregi Natalia
Alexander Surkov
Brendan Dahl
Andrew Creskey
Cosmin Sabou
Mihai Alexandru Michis
Ciure Andrei
Edgar Chen
Ehsan Akhgari