searching for reviewer(eeejay)
b1afc99c9bfb722ef9b12ba1eb2a92268e694e16: Bug 1577381: Correct accessibility exposure for optgroups in content select dropdowns. r=eeejay,NeilDeakin
James Teh <jteh@mozilla.com> - Wed, 16 Oct 2019 06:10:32 +0000 - rev 497767
Push 114154 by btara@mozilla.com at Thu, 17 Oct 2019 09:58:40 +0000
Bug 1577381: Correct accessibility exposure for optgroups in content select dropdowns. r=eeejay,NeilDeakin 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
ea2c6977957107879904ebedf2e6668c2d5d5c47: Bug 1577381: Correct accessibility exposure for optgroups in content select dropdowns. r=eeejay,NeilDeakin
James Teh <jteh@mozilla.com> - Fri, 27 Sep 2019 02:50:59 +0000 - rev 495297
Push 114134 by ccoroiu@mozilla.com at Mon, 30 Sep 2019 09:57:15 +0000
Bug 1577381: Correct accessibility exposure for optgroups in content select dropdowns. r=eeejay,NeilDeakin 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
0cabfa57360c86cfa855ae918faccc2a3d51dca0: Bug 1503084 - add additional event logging to e10s name tests. r=eeejay
Yura Zenevich <yura.zenevich@gmail.com> - Wed, 25 Sep 2019 18:24:59 +0000 - rev 494958
Push 114131 by dluca@mozilla.com at Thu, 26 Sep 2019 09:47:34 +0000
Bug 1503084 - add additional event logging to e10s name tests. r=eeejay Differential Revision: https://phabricator.services.mozilla.com/D46972
50b62338cf188abc7bd0092df755304e512bef16: Bug 1561412 - Remove unused SynthStreamListener class. r=eeejay
Chun-Min Chang <chun.m.chang@gmail.com> - Thu, 05 Sep 2019 20:38:23 +0000 - rev 493103
Push 114082 by dvarga@mozilla.com at Fri, 13 Sep 2019 21:51:00 +0000
Bug 1561412 - Remove unused SynthStreamListener class. r=eeejay Differential Revision: https://phabricator.services.mozilla.com/D35872
703f93f28ac817aa42116b0645cbf4b177b4dd68: Bug 1503084 - added a wait for NAME_CHANGE event after aria-label removal. r=eeejay
Yura Zenevich <yura.zenevich@gmail.com> - Thu, 12 Sep 2019 19:29:26 +0000 - rev 492918
Push 114079 by nerli@mozilla.com at Fri, 13 Sep 2019 04:45:18 +0000
Bug 1503084 - added a wait for NAME_CHANGE event after aria-label removal. r=eeejay Differential Revision: https://phabricator.services.mozilla.com/D45361
6368f6953a8f1d617588ad00e9e7eaa909dd9b2e: Bug 1277201: Fire a STATE_CHANGE event when a details element is opened or closed. r=eeejay
Morgan Reschenberg <mreschenberg@mozilla.com> - Tue, 10 Sep 2019 16:16:53 +0000 - rev 492539
Push 114064 by opoprus@mozilla.com at Tue, 10 Sep 2019 21:46:41 +0000
Bug 1277201: Fire a STATE_CHANGE event when a details element is opened or closed. r=eeejay Differential Revision: https://phabricator.services.mozilla.com/D44872
3bfc0e27d0389a069380540e49b0c4c5b6ecdc3e: Bug 1578604: accessible/tests/mochitest/actions/test_general.xul: Don't require the focus event on menulist to be unique. r=eeejay
James Teh <jteh@mozilla.com> - Thu, 05 Sep 2019 20:38:32 +0000 - rev 491936
Push 114036 by nerli@mozilla.com at Fri, 06 Sep 2019 09:46:47 +0000
Bug 1578604: accessible/tests/mochitest/actions/test_general.xul: Don't require the focus event on menulist to be unique. r=eeejay focusChecker expects a unique focus event. However, there might still be pending focus events not caught by previous tests. Therefore, we specify our own checker so we can disable the uniqueness requirement. This is a little ugly, but it's rather difficult to work around this within this declarative framework without potentially breaking other tests. Differential Revision: https://phabricator.services.mozilla.com/D44615
641f1c8c0fd2e597b63da5f838916310aeab30eb: Bug 1578311: Don't prune a trailing HTML br child from the accessibility tree. r=eeejay
James Teh <jteh@mozilla.com> - Thu, 05 Sep 2019 23:41:36 +0000 - rev 491935
Push 114036 by nerli@mozilla.com at Fri, 06 Sep 2019 09:46:47 +0000
Bug 1578311: Don't prune a trailing HTML br child from the accessibility tree. r=eeejay 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
68678ee894cbc881e1227474c9582c6950ddae5f: Bug 1578140: Use nsXULElement::Click for DoAction on XULLabelAccessible so it works for labels inside buttons. r=eeejay
James Teh <jteh@mozilla.com> - Tue, 03 Sep 2019 19:11:35 +0000 - rev 491600
Push 114026 by aiakab@mozilla.com at Wed, 04 Sep 2019 04:24:07 +0000
Bug 1578140: Use nsXULElement::Click for DoAction on XULLabelAccessible so it works for labels inside buttons. r=eeejay For labels inside buttons, The base implementation of DispatchClickEvent doesn't fire a command event on the button. To fix this, override DispatchClickEvent to use nsXULElement::Click, which does fire a command event on the button. Differential Revision: https://phabricator.services.mozilla.com/D44410
952b14eb6ea33af77240fb8eab0b2e6f5f6181bd: Bug 1574286: When adding a remote child document, if the parent proxy doesn't exist yet, defer adding until it does. r=eeejay
James Teh <jteh@mozilla.com> - Fri, 30 Aug 2019 03:32:55 +0000 - rev 490784
Push 114002 by shindli@mozilla.com at Fri, 30 Aug 2019 09:43:28 +0000
Bug 1574286: When adding a remote child document, if the parent proxy doesn't exist yet, defer adding until it does. r=eeejay For OOP iframes, sometimes, AddChildDoc gets called before the embedder sends us the OuterDocAccessible. Previously, we crashed when this occurred. Now, we add the child when the OuterDocAccessible proxy gets created later. Differential Revision: https://phabricator.services.mozilla.com/D42798
49ff97acd5ce9f094430bf4538e7f32792201182: Bug 1577258 - Explicitly flush layout in an a11y test. r=eeejay
Emilio Cobos Álvarez <emilio@crisal.io> - Thu, 29 Aug 2019 21:25:12 +0000 - rev 490740
Push 114001 by csabou@mozilla.com at Fri, 30 Aug 2019 04:44:11 +0000
Bug 1577258 - Explicitly flush layout in an a11y test. r=eeejay We have an optimization to avoid an expensive reflow from SetFullZoom, see mSuppressResizeReflow[1]. That was done because we used to do a full synchronous reflow right after. We no longer do that, but due to that member we also don't invalidate! My second patch in this bug changes the behavior of that flag so that we don't synchronously reflow, but we do invalidate. So in turn this test before the change wasn't really testing the zoomed code-path since it was using the clean layout from before the zoom operation. a11y getBounds and co. don't flush layout (they probably should), but since with my patch we dirty the frame tree, and dirty frames return bogus offsets, the test starts failing. Flush layout explicitly to ensure we're testing the zoomed code path. [1]: https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/layout/base/nsPresContext.cpp#952 Differential Revision: https://phabricator.services.mozilla.com/D43952
c5c1ac80fd436e1c002b2ad25fb0a9529ebcdadd: Bug 1523920 - P4: Move the state from SpeechSynthesisUtterance to nsSpeechTask. r=eeejay
Chun-Min Chang <chun.m.chang@gmail.com> - Wed, 21 Aug 2019 20:37:02 +0000 - rev 490128
Push 113979 by csabou@mozilla.com at Tue, 27 Aug 2019 09:55:53 +0000
Bug 1523920 - P4: Move the state from SpeechSynthesisUtterance to nsSpeechTask. r=eeejay It would be easier to reuse the utterance if it's stateless. The state could still be tracked by moving from SpeechSynthesisUtterance to nsSpeechTask, which is the place to change the state in original implementation. By removing state in utterance, we don't need to check the state of utterance when it's pushed into the speech queue. Differential Revision: https://phabricator.services.mozilla.com/D35464
1d4911d7a26ca3a88065dc8d45e7a019825b2324: Bug 1523920 - P3: Enable the web-platform test to check the utterance is reusable. r=eeejay
Chun-Min Chang <chun.m.chang@gmail.com> - Wed, 21 Aug 2019 20:11:38 +0000 - rev 490127
Push 113979 by csabou@mozilla.com at Tue, 27 Aug 2019 09:55:53 +0000
Bug 1523920 - P3: Enable the web-platform test to check the utterance is reusable. r=eeejay Differential Revision: https://phabricator.services.mozilla.com/D35463
18d8187317cdc1d33de3abcf2158be990dad83f4: Bug 1523920 - P2: Destroy AudioChannelAgent when error occurs. r=eeejay
Chun-Min Chang <chun.m.chang@gmail.com> - Wed, 21 Aug 2019 20:11:27 +0000 - rev 490126
Push 113979 by csabou@mozilla.com at Tue, 27 Aug 2019 09:55:53 +0000
Bug 1523920 - P2: Destroy AudioChannelAgent when error occurs. r=eeejay When error occurs, there is no need to use audio. Differential Revision: https://phabricator.services.mozilla.com/D35462
2e49430660ae20e1acecff858966effc4d851e24: Bug 1523920 - P1: Align the LOG policy in the nsSpeechTask. r=eeejay
Chun-Min Chang <chun.m.chang@gmail.com> - Wed, 21 Aug 2019 20:11:17 +0000 - rev 490125
Push 113979 by csabou@mozilla.com at Tue, 27 Aug 2019 09:55:53 +0000
Bug 1523920 - P1: Align the LOG policy in the nsSpeechTask. r=eeejay All the LOG are placed in Dispatch*Impl except DispatchErrorImpl. Move the LOG from DispatchError to DispatchErrorImpl to align the LOG policy in the nsSpeechTask. Differential Revision: https://phabricator.services.mozilla.com/D35461
73148ae7d1e5e1a92f127f209911240142d59578: Bug 1547176, try to make browser_test_zoom_text.js more resilient to scheduling changes, r=eeejay
Olli Pettay <Olli.Pettay@helsinki.fi> - Wed, 21 Aug 2019 15:51:24 +0000 - rev 489237
Push 113941 by aciure@mozilla.com at Wed, 21 Aug 2019 21:59:00 +0000
Bug 1547176, try to make browser_test_zoom_text.js more resilient to scheduling changes, r=eeejay Differential Revision: https://phabricator.services.mozilla.com/D42486
09dfba0277d13158da0a53413a68df1b3745939a: Bug 1572317: When removing an Accessible because it lost its frame, remove Accessibles for DOM descendants as well. r=eeejay
James Teh <jteh@mozilla.com> - Fri, 09 Aug 2019 01:21:54 +0000 - rev 487127
Push 113860 by nbeleuzu@mozilla.com at Fri, 09 Aug 2019 10:00:25 +0000
Bug 1572317: When removing an Accessible because it lost its frame, remove Accessibles for DOM descendants as well. r=eeejay Removing an Accessible removes descendants in the a11y tree. However, there may be DOM descendants which have been relocated elsewhere in the a11y tree. Their DOM nodes are now hidden as well, so we need to remove those Accessibles too. In addition to Accessibles remaining in the tree when they shouldn't, failing to remove relocated Accessibles caused problems later on when a relocated Accessible was shown with new descendants. Differential Revision: https://phabricator.services.mozilla.com/D41178
d3b29691bdc63344fb7359b0f258c884ad5a5ff9: Bug 1571327: Process generic notifications after relocations to fix aria-activedescendant with simultaneous insertion and relocation. r=eeejay
James Teh <jteh@mozilla.com> - Tue, 06 Aug 2019 03:07:51 +0000 - rev 486467
Push 113840 by dluca@mozilla.com at Tue, 06 Aug 2019 09:43:33 +0000
Bug 1571327: Process generic notifications after relocations to fix aria-activedescendant with simultaneous insertion and relocation. r=eeejay Previously, if a hidden, aria-owned subtree was shown and aria-activedescendant was simultaneously targeted inside it, aria-activedescendant would fail. This occurred because when we processed insertions, the presence of aria-owns meant we didn't create the subtree. This meant that when we processed aria-activedescendant (which occurred before relocations), the active descendant didn't exist yet. To fix this, we now process generic notifications (including aria-activedescendant) *after* relocations. Differential Revision: https://phabricator.services.mozilla.com/D40579
f869dc3ce4a9853a84077daf9a3db6d0af771c6d: Bug 1509234: Return early if accessible dies while processing a focus event to prevent crashes. r=eeejay
James Teh <jteh@mozilla.com> - Thu, 01 Aug 2019 03:00:16 +0000 - rev 485721
Push 113820 by rmaries@mozilla.com at Fri, 02 Aug 2019 04:17:07 +0000
Bug 1509234: Return early if accessible dies while processing a focus event to prevent crashes. r=eeejay In FocusManager::ProcessFocusEvent, after firing the event, we get the anchor jump from the target Accessible's document. However, it seems the Accessible can be shut down during the call to nsEventShell::FireEvent, resulting in a crash when we try to get the anchor jump. Protect against this by checking whether the target is defunct after firing the event. Differential Revision: https://phabricator.services.mozilla.com/D39450
9c49cf0958b9b3040cee06f59ef9d63242aaa8a9: Bug 1566324 part 2: Respect shadow DOM for aria-activedescendant. r=eeejay
James Teh <jteh@mozilla.com> - Thu, 25 Jul 2019 20:44:18 +0000 - rev 484759
Push 113781 by csabou@mozilla.com at Fri, 26 Jul 2019 03:47:00 +0000
Bug 1566324 part 2: Respect shadow DOM for aria-activedescendant. r=eeejay Previously, the target element for aria-activedescendant was retrieved by calling GetElementById on the owner document. This meant that aria-activedescendant inside shadow DOM looked for ids in the owner document instead of the shadow DOM. To fix this, use IDRefsIterator::GetElem instead. Differential Revision: https://phabricator.services.mozilla.com/D38833
381183f36e382b844798418f670b4c4cb7731201: Bug 1566324 part 1: Make a static version of IDRefsIterator::GetElem which can be called to get an id reference for any element. r=eeejay
James Teh <jteh@mozilla.com> - Thu, 25 Jul 2019 20:44:18 +0000 - rev 484758
Push 113781 by csabou@mozilla.com at Fri, 26 Jul 2019 03:47:00 +0000
Bug 1566324 part 1: Make a static version of IDRefsIterator::GetElem which can be called to get an id reference for any element. r=eeejay IDRefsIterator::GetElem was previously an instance method which could only be used if you instantiated IDRefsIterator. This is overkill for attributes which can only take a single id reference (rather than an id reference list). Now, there is a static version of IDRefsIterator::GetElem which can be called with an arbitrary source element. Any accessibility code should henceforth be using this instead of calling GetElementById directly, as this deals with shadow DOM, etc. Differential Revision: https://phabricator.services.mozilla.com/D38832
96372a2ff71d3db3724bde3891d3764a08a4577e: Bug 1566543. Stop using [array] for get/setColorMatrix. r=eeejay
Boris Zbarsky <bzbarsky@mit.edu> - Tue, 16 Jul 2019 18:30:10 +0000 - rev 483003
Push 113703 by archaeopteryx@coole-files.de at Wed, 17 Jul 2019 16:57:18 +0000
Bug 1566543. Stop using [array] for get/setColorMatrix. r=eeejay Differential Revision: https://phabricator.services.mozilla.com/D38222
36d571eb919891dda1c2a2c9f6ba11ce570b36f7: Bug 1554831: For out-of-process iframe documents on Windows, send the a11y emulated window (if any) to the content process. r=eeejay
James Teh <jteh@mozilla.com> - Wed, 29 May 2019 04:37:28 +0000 - rev 476736
Push 113311 by btara@mozilla.com at Tue, 04 Jun 2019 16:10:59 +0000
Bug 1554831: For out-of-process iframe documents on Windows, send the a11y emulated window (if any) to the content process. r=eeejay If window emulation is enabled, an out-of-process iframe document should use the same emulated window as its embedder. Previously, we were setting this on DocAccessibleParent, but we weren't sending it to content to make it available on DocAccessibleChild. This meant that accessibles in out-of-process iframe documents were reporting the wrong window handle. Differential Revision: https://phabricator.services.mozilla.com/D32788
38c2478a4825044a8c33bb72539b42fbdda833fc: Bug 1553706: Fix IAccessible::accChild in the parent process for out-of-process iframes. r=eeejay
James Teh <jteh@mozilla.com> - Mon, 03 Jun 2019 06:03:10 +0000 - rev 476702
Push 113305 by cbrindusan@mozilla.com at Tue, 04 Jun 2019 03:54:43 +0000
Bug 1553706: Fix IAccessible::accChild in the parent process for out-of-process iframes. r=eeejay It must be possible to retrieve any accessible by calling IAccessible::accChild on the RootAccessible (in the parent process) with the unique id of the desired accessible. Among other things, this is the way accessibility events are targeted on Windows. Previously, this code only searched remote documents at the top level of the tree. In order to support out-of-process iframes, it must now also search embedded documents at the top level of their content process. As part of this, the MSAA id must be set for out-of-process iframe documents, just as it is for top level documents. This was already being sent from the content process, but previously, we didn't store this in the parent process. Differential Revision: https://phabricator.services.mozilla.com/D32417
379dc9cb2ae9fa7ceea647a35fcedb86fafb3bba: Bug 1543313 part 3: For out-of-process iframes on Windows, send the embedder accessible COM proxy to be used as the parent of the embedded document. r=eeejay,yzen
James Teh <jteh@mozilla.com> - Mon, 03 Jun 2019 14:29:37 +0000 - rev 476701
Push 113305 by cbrindusan@mozilla.com at Tue, 04 Jun 2019 03:54:43 +0000
Bug 1543313 part 3: For out-of-process iframes on Windows, send the embedder accessible COM proxy to be used as the parent of the embedded document. r=eeejay,yzen Aside from the parent being needed by the client, this is also important because events from the embedded document are deferred until the parent COM proxy is received. As part of this, we no longer try to send the parent COM proxy during construction of an OuterDocAccessible in the parent process. This was previously a no-op anyway, as DocAccessibleParent::SendParentCOMProxy called DocAccessible::GetAccessible for the frame element, which would have returned null because the accessible isn't bound to the document until *after* it is constructed. Changing this to directly pass the OuterDocAccessible was causing assertions in content processes, since it sometimes meant the parent COM proxy was sent twice, which is precisely what the assertion is protecting against. Instead, the parent proxy is sent in Browserparent::RecvPDocAccessibleConstructor as it always was. Differential Revision: https://phabricator.services.mozilla.com/D32284
ef50240bdb1f11199b00f6cc30bd65ddea364a78: Bug 1543313 part 2: Support getting an IAccessible for a ProxyAccessible in an out-of-process iframe. r=eeejay
James Teh <jteh@mozilla.com> - Fri, 31 May 2019 03:27:18 +0000 - rev 476700
Push 113305 by cbrindusan@mozilla.com at Tue, 04 Jun 2019 03:54:43 +0000
Bug 1543313 part 2: Support getting an IAccessible for a ProxyAccessible in an out-of-process iframe. r=eeejay Previously, a COM proxy was only sent from content for top level documents. Now, a COM proxy is also sent (and needed) for out-of-process iframe documents. This change adjusts GetProxiedAccessibleInSubtree accordingly. Differential Revision: https://phabricator.services.mozilla.com/D32283
3c619a698b9627c7cc6f072c2ec6c547df33f928: Bug 1543313 part 1: Allow identification and retrieval of DocAccessibleParents at the top level of their content process. r=eeejay
James Teh <jteh@mozilla.com> - Fri, 31 May 2019 03:27:26 +0000 - rev 476699
Push 113305 by cbrindusan@mozilla.com at Tue, 04 Jun 2019 03:54:43 +0000
Bug 1543313 part 1: Allow identification and retrieval of DocAccessibleParents at the top level of their content process. r=eeejay DocAccessibleParent already has IsTopLevel(), which identifies a document at the top level of the hierarchy; i.e. it has no parents. Now that we have out-of-process iframes, we need to be able to identify and retrieve documents at the top level of their content process, even if they are embedded by another remote document. DocAccessibleParent::IsTopLevelInContentProcess() has been introduced to achieve this. BrowserParent::GetTopLevelDocAccessible() now uses this instead of IsTopLevel(), since we want to be able to get the top DocAccessibleParent even for a BrowserParent for an out-of-process iframe. Differential Revision: https://phabricator.services.mozilla.com/D32282
1a8bea02205d138e7881bcf63aff985ae1f2d64d: Bug 1553706: Fix IAccessible::accChild in the parent process for out-of-process iframes. r=eeejay
James Teh <jteh@mozilla.com> - Wed, 29 May 2019 00:59:53 +0000 - rev 476333
Push 113271 by archaeopteryx@coole-files.de at Fri, 31 May 2019 17:09:51 +0000
Bug 1553706: Fix IAccessible::accChild in the parent process for out-of-process iframes. r=eeejay It must be possible to retrieve any accessible by calling IAccessible::accChild on the RootAccessible (in the parent process) with the unique id of the desired accessible. Among other things, this is the way accessibility events are targeted on Windows. Previously, this code only searched remote documents at the top level of the tree. In order to support out-of-process iframes, it must now also search embedded documents at the top level of their content process. As part of this, the MSAA id must be set for out-of-process iframe documents, just as it is for top level documents. This was already being sent from the content process, but previously, we didn't store this in the parent process. Differential Revision: https://phabricator.services.mozilla.com/D32417
15f3e6bb3ba913aa9d67687edd59899873b671ae: Bug 1543313 part 3: For out-of-process iframes on Windows, send the embedder accessible COM proxy to be used as the parent of the embedded document. r=eeejay
James Teh <jteh@mozilla.com> - Fri, 24 May 2019 06:14:24 +0000 - rev 476332
Push 113271 by archaeopteryx@coole-files.de at Fri, 31 May 2019 17:09:51 +0000
Bug 1543313 part 3: For out-of-process iframes on Windows, send the embedder accessible COM proxy to be used as the parent of the embedded document. r=eeejay Aside from the parent being needed by the client, this is also important because events from the embedded document are deferred until the parent COM proxy is received. Differential Revision: https://phabricator.services.mozilla.com/D32284
30b106088985198cfdc755e09173bd663ca657c7: Bug 1543313 part 2: Support getting an IAccessible for a ProxyAccessible in an out-of-process iframe. r=eeejay
James Teh <jteh@mozilla.com> - Thu, 23 May 2019 20:13:00 +0000 - rev 476331
Push 113271 by archaeopteryx@coole-files.de at Fri, 31 May 2019 17:09:51 +0000
Bug 1543313 part 2: Support getting an IAccessible for a ProxyAccessible in an out-of-process iframe. r=eeejay Previously, a COM proxy was only sent from content for top level documents. Now, a COM proxy is also sent (and needed) for out-of-process iframe documents. This change adjusts GetProxiedAccessibleInSubtree accordingly. Differential Revision: https://phabricator.services.mozilla.com/D32283
85d11dab6b63d60a229f3dc42734bc7d0ab27fbd: Bug 1543313 part 1: Allow identification and retrieval of DocAccessibleParents at the top level of their content process. r=eeejay
James Teh <jteh@mozilla.com> - Thu, 23 May 2019 20:00:31 +0000 - rev 476330
Push 113271 by archaeopteryx@coole-files.de at Fri, 31 May 2019 17:09:51 +0000
Bug 1543313 part 1: Allow identification and retrieval of DocAccessibleParents at the top level of their content process. r=eeejay DocAccessibleParent already has IsTopLevel(), which identifies a document at the top level of the hierarchy; i.e. it has no parents. Now that we have out-of-process iframes, we need to be able to identify and retrieve documents at the top level of their content process, even if they are embedded by another remote document. DocAccessibleParent::IsTopLevelInContentProcess() has been introduced to achieve this. BrowserParent::GetTopLevelDocAccessible() now uses this instead of IsTopLevel(), since we want to be able to get the top DocAccessibleParent even for a BrowserParent for an out-of-process iframe. Differential Revision: https://phabricator.services.mozilla.com/D32282
bb49389d34ba661c503f8e5c3c88807c18fe2320: Bug 1543307: For out-of-process iframes on Windows, return the embedded document as a child of the OuterDocAccessible. r=eeejay
James Teh <jteh@mozilla.com> - Thu, 23 May 2019 19:54:37 +0000 - rev 476175
Push 113253 by malexandru@mozilla.com at Thu, 30 May 2019 10:02:35 +0000
Bug 1543307: For out-of-process iframes on Windows, return the embedded document as a child of the OuterDocAccessible. r=eeejay Windows accessibility clients talk directly to the content process via COM. In order to expose an OOP iframe document accessible as a child of the embedder iframe accessible via COM, the embedder process needs a COM proxy for the iframe document accessible. This is exposed on the embedder's BrowserBridgeChild, so we can use this when a client asks for the child of the OuterDocAccessible. Differential Revision: https://phabricator.services.mozilla.com/D32281
aa4c140e21929e3efcdfd69ad8aba2aacc508a62: Bug 1543298 part 3: For out-of-process iframes, send the embedded document accessible's COM proxy to the embedder. r=eeejay
James Teh <jteh@mozilla.com> - Fri, 24 May 2019 00:19:51 +0000 - rev 476174
Push 113253 by malexandru@mozilla.com at Thu, 30 May 2019 10:02:35 +0000
Bug 1543298 part 3: For out-of-process iframes, send the embedded document accessible's COM proxy to the embedder. r=eeejay This will be later exposed as a child of the embedder OuterDocAccessible. Differential Revision: https://phabricator.services.mozilla.com/D32280
02b71771b27b0e2955b1a4692ffa14834333135a: Bug 1543298 part 2: Add PBrowserBridge::SetEmbeddedDocAccessibleCOMProxy so the parent can send the child the COM proxy for the embedded document accessible. r=eeejay,nika
James Teh <jteh@mozilla.com> - Fri, 24 May 2019 18:49:31 +0000 - rev 476173
Push 113253 by malexandru@mozilla.com at Thu, 30 May 2019 10:02:35 +0000
Bug 1543298 part 2: Add PBrowserBridge::SetEmbeddedDocAccessibleCOMProxy so the parent can send the child the COM proxy for the embedded document accessible. r=eeejay,nika Differential Revision: https://phabricator.services.mozilla.com/D32279
eed17a01f44fd2477e6acf2f9ff7d17c1a6a2c6b: Bug 1543298 part 1: Add a stub AccessibleWrap used in a Windows content process for an embedded document residing in another content process. r=eeejay
James Teh <jteh@mozilla.com> - Thu, 23 May 2019 18:14:39 +0000 - rev 476172
Push 113253 by malexandru@mozilla.com at Thu, 30 May 2019 10:02:35 +0000
Bug 1543298 part 1: Add a stub AccessibleWrap used in a Windows content process for an embedded document residing in another content process. r=eeejay For an out-of-process iframe, we need to be able to return a remote embedder accessible as a child of an OuterDocAccessible. For parent process OuterDocAccessibles, we use the ProxyAccessible for the embedded document. In the case of out-of-process iframes, there is no ProxyAccessible for the embedded document, since the iframe is in a content process and ProxyAccessibles only exist in the parent process. Like ProxyAccessibleWrap, the only real method that gets called is GetNativeInterface, which returns a COM proxy for the document. Differential Revision: https://phabricator.services.mozilla.com/D32278
dd9b4c826f73c2d416e1342eac54fafcca5d9f4c: Bug 1543287: Add embedded out-of-process iframe DocAccessibleParent as a child of its embedder DocAccessibleParent. r=eeejay,nika
James Teh <jteh@mozilla.com> - Wed, 29 May 2019 04:36:18 +0000 - rev 476005
Push 113240 by nerli@mozilla.com at Wed, 29 May 2019 09:56:33 +0000
Bug 1543287: Add embedded out-of-process iframe DocAccessibleParent as a child of its embedder DocAccessibleParent. r=eeejay,nika For iframes in a different process to their embedder, when the embedded iframe content process tells the parent process about the iframe document, it does not have the actor for the parent document accessible, nor does it know the accessible id of the embedding iframe. However, the embedder will have previously sendt the actor and id for the embedder accessible to the parent via PBrowserBridge, so we can use that to identify the parent accessible. Differential Revision: https://phabricator.services.mozilla.com/D31395
60ecb1a2cb86d14a289a1aa71475cb1f45ff8ac5: Bug 1543282 part 3: For iframes rendered in other processes, tell the parent the embedder iframe accessible. r=eeejay
James Teh <jteh@mozilla.com> - Wed, 29 May 2019 04:42:55 +0000 - rev 476004
Push 113240 by nerli@mozilla.com at Wed, 29 May 2019 09:56:33 +0000
Bug 1543282 part 3: For iframes rendered in other processes, tell the parent the embedder iframe accessible. r=eeejay We do this when the OuterDocAccessible is constructed. This will be used later in the parent process to link the trees together when the iframe's embedded document accessible is added. Differential Revision: https://phabricator.services.mozilla.com/D31394
ac2d3dd7d7043dde4c0609e4a7947e21c7d4bd1e: Bug 1543282 part 2: Add PBrowserBridge::SetEmbedderAccessible so the child can tell the parent the embedder iframe accessible. r=nika,eeejay
James Teh <jteh@mozilla.com> - Fri, 24 May 2019 19:23:18 +0000 - rev 476003
Push 113240 by nerli@mozilla.com at Wed, 29 May 2019 09:56:33 +0000
Bug 1543282 part 2: Add PBrowserBridge::SetEmbedderAccessible so the child can tell the parent the embedder iframe accessible. r=nika,eeejay Differential Revision: https://phabricator.services.mozilla.com/D31393
094829c443f30c614689eac605e243afb7720a45: Bug 1543282 part 1: Reference counting for DocAccessibleParent. r=eeejay,nika
James Teh <jteh@mozilla.com> - Tue, 28 May 2019 17:42:59 +0000 - rev 476002
Push 113240 by nerli@mozilla.com at Wed, 29 May 2019 09:56:33 +0000
Bug 1543282 part 1: Reference counting for DocAccessibleParent. r=eeejay,nika Supporting out-of-process iframes requires us to hold onto a DocAccessibleParent in BrowserBridgeParent. However, we can't guarantee the order of cleanup between the two content processes. Therefore, we need reference counting to kee the object alive. Differential Revision: https://phabricator.services.mozilla.com/D32277
139abe6b4223b612cde09672f384f5f7fad7e53b: Bug 1549855 - remove references to e10s force-enable pref that is no longer used, r=ato,eeejay
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Fri, 17 May 2019 09:25:14 +0000 - rev 474310
Push 113144 by shindli@mozilla.com at Fri, 17 May 2019 16:44:55 +0000
Bug 1549855 - remove references to e10s force-enable pref that is no longer used, r=ato,eeejay Differential Revision: https://phabricator.services.mozilla.com/D31417
928038c23227504c1cd7dff5f5e214501bb4b688: Bug 1549855 - remove references to e10s force-enable pref that is no longer used, r=ato,snorp,eeejay
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Thu, 16 May 2019 16:21:56 +0000 - rev 474201
Push 113144 by shindli@mozilla.com at Fri, 17 May 2019 16:44:55 +0000
Bug 1549855 - remove references to e10s force-enable pref that is no longer used, r=ato,snorp,eeejay Differential Revision: https://phabricator.services.mozilla.com/D31417
97c7af33ac1db2daa8b55c9f4f7e14e342010ab7: Bug 1544584 - Make it possible to remove android.speech dependencies using Proguard r=snorp,rbarker,eeejay
Imanol Fernandez <imanol@mozilla.com> - Thu, 16 May 2019 01:05:01 +0000 - rev 474039
Push 113120 by dvarga@mozilla.com at Thu, 16 May 2019 04:21:05 +0000
Bug 1544584 - Make it possible to remove android.speech dependencies using Proguard r=snorp,rbarker,eeejay Some minor refactor to make it possible to remove android.speech dependencies using Proguard Differential Revision: https://phabricator.services.mozilla.com/D27612
b60e7b3407b3aa6a2110f7e09a41e1ea10a04213: Bug 1544584 - Make it possible to remove android.speech dependencies using Proguard r=snorp,rbarker,eeejay
Imanol Fernandez <mortimergoro@gmail.com> - Wed, 15 May 2019 19:56:43 +0000 - rev 474008
Push 113120 by dvarga@mozilla.com at Thu, 16 May 2019 04:21:05 +0000
Bug 1544584 - Make it possible to remove android.speech dependencies using Proguard r=snorp,rbarker,eeejay Some minor refactor to make it possible to remove android.speech dependencies using Proguard Differential Revision: https://phabricator.services.mozilla.com/D27612
28b9af9efee6a0317e21fa3a1971f039f53a25ed: Bug 1190882: If the focused accessible is removed from the tree, fire a11y focus on the document. r=eeejay
James Teh <jteh@mozilla.com> - Wed, 15 May 2019 00:31:16 +0000 - rev 473882
Push 113113 by rgurzau@mozilla.com at Wed, 15 May 2019 09:32:06 +0000
Bug 1190882: If the focused accessible is removed from the tree, fire a11y focus on the document. r=eeejay If the DOM focus is removed before something else is focused, the document gets DOM focus, but no blur event is fired (bug 559561). This means that no a11y focus event is fired, so clients aren't notified. This is particularly problematic for screen readers when dismissing some ARIA dialogs, as the screen reader doesn't know that focus has returned to the top level document. Differential Revision: https://phabricator.services.mozilla.com/D31024
f348b1ddb6c6aff4b1cb72dd519768c213de8b9a: Bug 1546744 - Ensure we are testing for the correct things when validating screenshots r=eeejay
Emily Toop <etoop@mozilla.com> - Fri, 26 Apr 2019 20:49:00 +0000 - rev 471779
Push 112948 by shindli@mozilla.com at Mon, 29 Apr 2019 21:58:23 +0000
Bug 1546744 - Ensure we are testing for the correct things when validating screenshots r=eeejay Differential Revision: https://phabricator.services.mozilla.com/D28983
50c1ff58c6824782afdc10e65ee28cccdb60f7b2: Bug 1543561: Expose the focusable state on a node focused by aria-activedescendant, even if that node isn't a descendant. r=eeejay
James Teh <jteh@mozilla.com> - Wed, 17 Apr 2019 23:13:10 +0000 - rev 469999
Push 112839 by apavel@mozilla.com at Thu, 18 Apr 2019 21:50:57 +0000
Bug 1543561: Expose the focusable state on a node focused by aria-activedescendant, even if that node isn't a descendant. r=eeejay Sometimes, we use aria-activedescendant targeting something which isn't actually a descendant. This is technically a spec violation, but it's a useful hack which makes certain things much easier. For example, we use this for "fake focus" for multi select browser tabs and Quantumbar autocomplete suggestions. This already worked previously; the accessible received a focus event and the focused state. However, it did *not* receive the focusable state. This is because the code which applies the focusable state for potential active descendants only works for descendants. It really doesn't make sense for something to be focused when it isn't focusable. In fact, this is an a11y test failure when it occurs. So, if the active item has the focused state, ensure we expose the focusable state too. Differential Revision: https://phabricator.services.mozilla.com/D27021
8ea3101cfbad67458ee23e560ce4c873e129d307: Bug 1544065 - fix clicking on <span> tags inside voice selector in reader mode, r=eeejay
Gijs Kruitbosch <gijskruitbosch@gmail.com> - Mon, 15 Apr 2019 16:34:28 +0000 - rev 469539
Push 112801 by ccoroiu@mozilla.com at Mon, 15 Apr 2019 21:40:09 +0000
Bug 1544065 - fix clicking on <span> tags inside voice selector in reader mode, r=eeejay Differential Revision: https://phabricator.services.mozilla.com/D27510
b5298ae1354231d13c9e59a46dc2984493169541: Bug 1540180 - The role of a broken input[type="image"] doesn't depend on its display value. r=surkov,eeejay
Emilio Cobos Álvarez <emilio@crisal.io> - Mon, 01 Apr 2019 18:51:14 +0000 - rev 467424
Push 112626 by cbrindusan@mozilla.com at Tue, 02 Apr 2019 08:40:51 +0000
Bug 1540180 - The role of a broken input[type="image"] doesn't depend on its display value. r=surkov,eeejay Differential Revision: https://phabricator.services.mozilla.com/D25517
5697e0aa6e26882f0bca8216687c642f458c7e91: Bug 1473234: make a11y listen to DOM events from iframes and shadow DOM. r=eeejay
James Teh <jteh@mozilla.com> - Mon, 25 Mar 2019 05:04:36 +0000 - rev 466040
Push 112550 by rgurzau@mozilla.com at Tue, 26 Mar 2019 09:57:15 +0000
Bug 1473234: make a11y listen to DOM events from iframes and shadow DOM. r=eeejay 1. Register with the root document window's parent target, since this receives events for iframes and shadow DOM. (The root document itself doesn't.) 2. Hold onto the target node when scheduling processing of the DOM event, as GetOriginalTarget returns null when we process shadow DOM events async. Depends on D21349 Differential Revision: https://phabricator.services.mozilla.com/D21350
1b6bf93953727decb8481cb58937ec3eefa5821a: Bug 1530931: Correctly handle retrieving a container accessible for a shadow root. r=eeejay
James Teh <jteh@mozilla.com> - Mon, 25 Mar 2019 05:04:29 +0000 - rev 465902
Push 112540 by aiakab@mozilla.com at Mon, 25 Mar 2019 15:58:26 +0000
Bug 1530931: Correctly handle retrieving a container accessible for a shadow root. r=eeejay This can happen, for example, when GetAccessibleOrContainer is called within SelectionManager::ProcessSelectionChanged due to focusing a direct child of a shadow root. In this case, the common ancestor is the shadow root itself. Previously, we returned null in this case because GetFlattenedTreeParent doesn't work on the shadow root itself. Now, we check if the given node is the shadow root, and if so, we use the shadow host instead. This prevents the "We must reach document accessible implementing text interface!" assertion in SelectionManager::ProcessSelectionChanged when a direct child of a shadow root gets focus. Differential Revision: https://phabricator.services.mozilla.com/D21349