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
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
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
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
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
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
This is an extension protocol that can be used for platform specific
API (ie. AccessibleWrap methods).
I'm not thrilled with the seperate constructor for the sub-protocol.
This means that the parent won't have the actor upon DocAccessibleParent
construction, and some timing bugs can arise because of the extra round
trip. It would be cool if both actors could be co-created, but that
would require ManagedEndpoint, and for PBrowser to manage them both. I
don't want to expose this to PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D37955
--HG--
extra : moz-landing-system : lando
And also this patch moves `TextEditRules::HandleNewLines()` and
`TextEditRules::DontEchoPassword()` to `TextEditor`.
Differential Revision: https://phabricator.services.mozilla.com/D45298
--HG--
extra : moz-landing-system : lando
This is an extension protocol that can be used for platform specific
API (ie. AccessibleWrap methods).
I'm not thrilled with the seperate constructor for the sub-protocol.
This means that the parent won't have the actor upon DocAccessibleParent
construction, and some timing bugs can arise because of the extra round
trip. It would be cool if both actors could be co-created, but that
would require ManagedEndpoint, and for PBrowser to manage them both. I
don't want to expose this to PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D37955
--HG--
extra : moz-landing-system : lando
This is an extension protocol that can be used for platform specific
API (ie. AccessibleWrap methods).
I'm not thrilled with the seperate constructor for the sub-protocol.
This means that the parent won't have the actor upon DocAccessibleParent
construction, and some timing bugs can arise because of the extra round
trip. It would be cool if both actors could be co-created, but that
would require ManagedEndpoint, and for PBrowser to manage them both. I
don't want to expose this to PBrowser.
Differential Revision: https://phabricator.services.mozilla.com/D37955
--HG--
extra : moz-landing-system : lando
This assures that a node that has already been inserted in a shadow root
subtree does not get erroneously reinserted into the top container.
Differential Revision: https://phabricator.services.mozilla.com/D44880
--HG--
extra : moz-landing-system : lando
Pruning these meant that `<span><br></span>` wasn't represented in the tree or rendered text at all.
This meant that lines were merged together in NVDA browse mode; e.g. in CI build logs on Gitlab.
The reason we started pruning these is that they were causing invalid line offsets to be returned for affected lines (bug 899433).
This patch also fixes this problem in HyperTextAccessible::FindOffset.
Differential Revision: https://phabricator.services.mozilla.com/D44815
--HG--
extra : moz-landing-system : lando
All calls to `profiler_add_marker()` (outside of the profilers code) are
now replaced by either:
- `PROFILER_ADD_MARKER(name, categoryPair)`
- `PROFILER_ADD_MARKER_WITH_PAYLOAD(name, categoryPair, TypeOfMarkerPayload,
(payload, ..., arguments))`
This makes all calls consistent, and they won't need to prefix the category pair
with `JS::ProfilingCategoryPair::`.
Also it will make it easier to add (and later remove) internal-profiling
instrumentation (bug 1576550), and to replace heap-allocated payloads with
stack-allocated ones (bug 1576555).
Differential Revision: https://phabricator.services.mozilla.com/D43588
--HG--
extra : moz-landing-system : lando
This patch does several things:
1. If there is a change to a host or a slot, check the slottable
elements to see if they are rendered in the tree. Remove them if not.
2. Check slot elements' fallback content if it is rendered and remove if
not.
3. Allow accessibles to be reinserted into a different parent or index.
Differential Revision: https://phabricator.services.mozilla.com/D43489
--HG--
extra : moz-landing-system : lando
Converts ui.key.generalAccessKey, ui.key.chromeAccess, and ui.key.contentAccess to static prefs. Updates usages.
Differential Revision: https://phabricator.services.mozilla.com/D42392
--HG--
extra : moz-landing-system : lando
The DOM mutation observer method is called during frame destruction
which is not a good state to be in when constructing and dispatching events.
Differential Revision: https://phabricator.services.mozilla.com/D41825
--HG--
extra : moz-landing-system : lando
