After the fix for bug 646216, we no longer create divs with no text and only a br element for a line break. This breaks blank lines in contentEditables such as Gmail.
To fix, always create accessibles for divs if such a div contains a br element either as its first or last child.
Differential Revision: https://phabricator.services.mozilla.com/D18074
--HG--
extra : moz-landing-system : lando
Relevant divs are:
* Those that have an ID attribute. This is important so anchors still work.
* Those whose first or last child is a text-only node.
* Those whose first or last child has an inline frame.
We now discard divs that are not display:block; or display:inline-block;. We also discard divs that are part of an anonymous subtree.
We stop creating divs from the eHyperTextType frame type alltogether.
Note that because of shadow DOM properties in the video controls, two additional divs with IDs require role="none" in the media controls widget code.
Differential Revision: https://phabricator.services.mozilla.com/D17348
--HG--
extra : moz-landing-system : lando
Relevant divs are:
* Those that have an ID attribute. This is important so anchors still work.
* Those whose first or last child is a text-only node.
* Those whose first or last child has an inline frame.
We now discard divs that are not display:block; or display:inline-block;. We also discard divs that are part of an anonymous subtree.
We stop creating divs from the eHyperTextType frame type alltogether.
Note that because of shadow DOM properties in the video controls, two additional divs with IDs require role="none" in the media controls widget code.
Differential Revision: https://phabricator.services.mozilla.com/D17348
--HG--
extra : moz-landing-system : lando
***
Bug 1514594: Part 3a - Change ChromeUtils.import to return an exports object; not pollute global. r=mccr8
This changes the behavior of ChromeUtils.import() to return an exports object,
rather than a module global, in all cases except when `null` is passed as a
second argument, and changes the default behavior not to pollute the global
scope with the module's exports. Thus, the following code written for the old
model:
ChromeUtils.import("resource://gre/modules/Services.jsm");
is approximately the same as the following, in the new model:
var {Services} = ChromeUtils.import("resource://gre/modules/Services.jsm");
Since the two behaviors are mutually incompatible, this patch will land with a
scripted rewrite to update all existing callers to use the new model rather
than the old.
***
Bug 1514594: Part 3b - Mass rewrite all JS code to use the new ChromeUtils.import API. rs=Gijs
This was done using the followng script:
https://bitbucket.org/kmaglione/m-c-rewrites/src/tip/processors/cu-import-exports.jsm
***
Bug 1514594: Part 3c - Update ESLint plugin for ChromeUtils.import API changes. r=Standard8
Differential Revision: https://phabricator.services.mozilla.com/D16747
***
Bug 1514594: Part 3d - Remove/fix hundreds of duplicate imports from sync tests. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16748
***
Bug 1514594: Part 3e - Remove no-op ChromeUtils.import() calls. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16749
***
Bug 1514594: Part 3f.1 - Cleanup various test corner cases after mass rewrite. r=Gijs
***
Bug 1514594: Part 3f.2 - Cleanup various non-test corner cases after mass rewrite. r=Gijs
Differential Revision: https://phabricator.services.mozilla.com/D16750
--HG--
extra : rebase_source : 359574ee3064c90f33bf36c2ebe3159a24cc8895
extra : histedit_source : b93c8f42808b1599f9122d7842d2c0b3e656a594%2C64a3a4e3359dc889e2ab2b49461bab9e27fc10a7
Elements such as html:span are normally only made accessible with ARIA attributes. Also expose them if they have a title attribute set. It can be assumed that information should be conveyed to the user in such cases.
Differential Revision: https://phabricator.services.mozilla.com/D17227
--HG--
extra : moz-landing-system : lando
Previously, we were always returning VT_UNKNOWN and an IEnumVARIANT.
According to the IAccessible documentation, this should only be done for multiple selection.
Change this to correctly return VT_EMPTY for no selection and VT_DISPATCH (with an accessible) for single selection.
Differential Revision: https://phabricator.services.mozilla.com/D17091
--HG--
extra : moz-landing-system : lando
This commit adds categories to all markers. This way the profiler's
marker categories and frame label categories agree. There are a few
duplicate category properties on some of the marker payloads, but
this could be cleaned up in a follow-up if needed.
Differential Revision: https://phabricator.services.mozilla.com/D16864
--HG--
extra : moz-landing-system : lando
Our accSelection implementation always returns an IUnknown which clients QI to IEnumVARIANT.
Marshaling as IUnknown works fine in this case, but it's more efficient and correct to marshal the correct interface.
Also, without this, we'd hit an assertion.
Depends on D16662
Differential Revision: https://phabricator.services.mozilla.com/D16663
--HG--
extra : moz-landing-system : lando
We only use the handler for specific interfaces such as IAccessible* and IAccessibleHyperlink.
For interfaces which don't use the handler, we currently write an empty payload, but this still adds bytes to the stream.
This seems to break marshaling such an interface in a VT_UNKNOWN in a VARIANT.
To fix this, just don't write any payload at all when we aren't using the handler for the target interface.
Differential Revision: https://phabricator.services.mozilla.com/D16662
--HG--
extra : moz-landing-system : lando
1. This requires exposing radiogroup's focusedItem property to C++.
Unfortunately, there's no existing equivalent in nsIDOMXULSelectControlItemElement.
radiogroup is the only element that needs this, so a new interface has been created for it.
2. Accessibility uses focusedItem instead of selectedItem when setting focus.
3. When an item is focused, accessibility needs to be notified.
This is done using a DOMMenuItemActive event.
Differential Revision: https://phabricator.services.mozilla.com/D15295
--HG--
extra : moz-landing-system : lando
Previously, if we had children a, b, c, and d, then removed b, the group position for c and d would potentially be marked as dirty, but a would not. This caused the check for the availability of previous group info to return outdated information.
This patch now always forces the update of all children's group position when a children move has occurred, since it potentially affects all the children, not just the ones after it. In addition, accGroupInfo::Update() now checks if the previous and next siblings that are being used as shortcuts have dirty group info, and are being used only if they do not.
Differential Revision: https://phabricator.services.mozilla.com/D16059
--HG--
extra : moz-landing-system : lando
This converts the tabmodalprompt binding to a class, to be constructed along side with the element
by TabModalPromptBox.
TabModalPromptBox will keep the instances in a map and pass it to the callers, instead of the element.
The tests and callers can access the class instance by passing the element reference to the map.
Differential Revision: https://phabricator.services.mozilla.com/D15505
--HG--
rename : toolkit/components/prompts/content/tabprompts.xml => toolkit/components/prompts/content/tabprompts.jsm
extra : moz-landing-system : lando
Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
In order to support IA2 live regions with e10s (bug 1322532), text change events sent from the child process to the parent process use sync IPC.
That comes at a slight performance cost: the content process is blocked until the parent returns from sending and handling the event.
However, there is no reason to do this if the event is not for an accessible inside a live region; current clients don't need the sync behaviour outside of live regions.
Differential Revision: https://phabricator.services.mozilla.com/D15183
--HG--
extra : source : 415f827cb9ce211c48b0c6625e917582bc81fd3a