User may paste a lot with pressing Accel+V for a while (i.e., with auto repeat).
So, calling nsIEditor::Paste() may be in a hot path and we can now make
non-virtual public method with AsHTMLEditor().
Differential Revision: https://phabricator.services.mozilla.com/D2993
--HG--
extra : moz-landing-system : lando
The accessibility tests currently rely, in many places, on lexical variables
defined in global frame scripts being available to other non-global frame
scripts. While that is currently the case, it will stop being so soon.
And, while the simplest solution would be to define them as properties on the
frame message manager by using `var` rather than `let`, storing references to
the current content window in a frame script scope is unsafe at best, and
should be avoided at all costs.
MozReview-Commit-ID: 4FCGtLgcFzl
--HG--
extra : rebase_source : d21206c9f119ca0ce61f9956f84a2e2d11484bca
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
The XULSelectControlAccessible selection methods don't handle ARIA selection.
Therefore, if aria-multiselectable is set, use the base implementation of the selection retrieval methods.
We don't bother overriding the selection setting methods because implementations (e.g. browser tabs) don't support setting of aria-selected by the a11y engine and we still want to be able to set the primary selected item according to XUL.
Being able to retrieve multiple selection programmatically is far more important than being able to set it.
MozReview-Commit-ID: CmVp9KyieMY
--HG--
extra : rebase_source : e3fa93aad4726b322956babb5422dceebfa0fbb2
We need to be able to call these methods from const methods, so they must take a const Accessible*.
MozReview-Commit-ID: CDsWZG1ik31
--HG--
extra : rebase_source : 4721669afcd9101cb017361bd8f87fb8a860664a
Summary:
This patch allows parsing generic types, such as Sequence<T>, in XPIDL. It does
this by introducing a new type, TypeId, which contains both the name string and
an optional list of generic parameters.
Various places which use the xpidl.py library had to be updated to construct one
of these TypeId objects, as TypeId and `str` are not compatible types.
Depends On D2106
Reviewers: mccr8!
Tags: #secure-revision
Bug #: 1474369
Differential Revision: https://phabricator.services.mozilla.com/D2109
This again exposes the accelerator (e.g. Ctrl+T for New Tab) for menu items via IAccessible::accName on windows.
Bug 1438193 made Accessible::Name const.
On Windows, XULMenuitemAccessibleWrap::Name is overridden to append the accelerator to the name.
Unfortunately, this override was missed when converting Name to const (and wasn't a compile error because it didn't use the override keyword).
As such, this override stopped being called; we always called the const version, since that's the one inherited into AccessibleWrap.
Making this const causes this override to be called.
MozReview-Commit-ID: 7Gb199mzhHa
--HG--
extra : rebase_source : 41d15042a09e4743d127fb12378c775099aa09a0
IA2 now has IA2_ROLE_CONTENT_INSERTION/DELETION.
Mac has AXInsert/DeleteStyleGroup subroles.
We now create accessibles for these elements and expose the appropriate role.
For ATK, there is no specific role for these, so we just use the generic ATK_ROLE_SECTION.
MozReview-Commit-ID: 2khzRa7BQ6z
--HG--
extra : rebase_source : e1c84bdef9a23b225e9870660050790df94c4beb
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : source : fcfb99baa0f0fb60a7c420a712c6ae7c72576871
extra : histedit_source : 5be9b7b29a52a4b8376ee0bdfc5c08b12e3c775a
DocShells are associated with outer DOM Windows, rather than Documents, so
having the getter on the document is a bit odd to begin with. But it's also
considerably less convenient, since most of the times when we want a docShell
from JS, we're dealing most directly with a window, and have to detour through
the document to get it.
MozReview-Commit-ID: LUj1H9nG3QL
--HG--
extra : rebase_source : a13c59d1a5ed000187c7fd8e7339408ad6e2dee6
This patch does several things:
1. When "domwindowopened" is dispatched it often doesn't have a
document yet, so we need to wait for it to load before determining if we
should attach it.
2. Instead of managing individual message managers use a broadcaster
and load delayed scripts. This makes new window additions more robust.
3. A content script now doesn't need a ready/start message but
initializes in-line. This added more complexity which we don't need. All
the info that we passed to it in AccessFu:Start can be gotten in other
ways (also, Services.appinfo.ID now works in child processes, so no need
for that).
4. Tweaked the tests to support inline frame script initilization.
5. Removed the scroll callback from content-script.js that was not used
anymore.
It's currently only accessible on XULDocument and XULElement, but that makes porting existing
JS to run in an HTML document inconvenient. We could alternatively change calling JS, but
this can be easily moved and exposed in chrome contexts.
MozReview-Commit-ID: JitYET20NSE
--HG--
extra : rebase_source : 75d823c688cba8d84dc19705e83284be383962f2
Before this change, we accessed the browser URL in the following ways:
- "chrome://browser/content/browser.xul"
- "chrome://browser/content/" (which redirects to chrome://browser/content/browser.xul)
- Services.prefs.getCharPref("browser.chromeURL") which returns "chrome://browser/content/"
- getBrowserURL() from utilityOverlay.js
MozReview-Commit-ID: I5vtRke1x9t
--HG--
extra : rebase_source : c525350a1954740873e85b045cbb14a8b43aa89d