New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 900846 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Dec 20
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug

Blocking:
issue 859152



Sign in to add a comment

RemoteMacViews: Make accessibility work

Project Member Reported by ccameron@chromium.org, Nov 1

Issue description

Accessibility doesn't work when using RemoteMacViews.

The following patch adds use of the NSAccessibilityRemoteUIElement API. It also tears out WebContents NSViews, to simplify the problem. I also tore out everything that was affecting results in my limited test (to keep things as similar as possible between the remote and local versions).

It does succeed at getting some things across the wire. When I open a window, the title of the window is hilighted and focused. When I open a new window that doesn't have a title, the first element (usually a text field) is focused). But when I change the focus, VoiceOver doesn't follow.

I have three theories about why this isn't working
1. There is a "focus has changed" signal that we aren't sending to the app shim process
2. Finding the focused element in the browser process is failing in one way or another.
 
Accessibility Inspector has a panel you can open to observe notifications. You could see if the focus notifications are making it through or not; compare it to regular Chrome.

What I've observed is that when VoiceOver gets a focus notification, it doesn't "trust" it, rather it starts at the top-level window and calls accessibilityFocusedUIElement.


I'm not sure how focus is supposed to work in that case. Maybe when focus is inside the remote view, we need accessibilityFocusedUIElement to return the NSAccessibilityRemoteUIElement view?

I would check to see if [RenderWidgetHostViewCocoa accessibilityFocusedUIElement] is getting called when focus changes.

Indeed, I get a -[NSWindow accessibilityFocusedUIElement] call in the app shim process at appropriate times.

From -[NSWindow accessibilityFocusedUIElement]
- just the remote object
- calling accessibilityFocusedUIElement on the remote object
and regardless of what I do, the behavior is always the same. 

** This behavior is identical to what happens in regular chrome when I force the normal -[NSWindow accessibilityFocusedUIElement] to always return the -[NSWindow contentView]. **

WRT tracing calls, this got a bit strange. Returning -[NSAccessibilityRemoteUIElement accessibilityFocusedUIElement] results is a call to -[NSWindow accessibilityFocusedUIElement] in the browser process ... but that NSWindow is "whatever browser window happens to be open", and if there are no windows open in the browser process, the call doesn't seem to cause the browser process to do anything at all.

Of note is that it looks as though the full tree does come across (see the attached exciting screenshot).

insp.png
608 KB View Download
Cc: tapted@chromium.org
Oh...
    // rdar://9118639 accessibilityFocusedUIElement in NSApplication defaults to use the keyWindow. Since there's
    // no window in WK2, NSApplication needs to use the focused page's focused element.
    Method methodToPatch = class_getInstanceMethod([NSApplication class], @selector(accessibilityFocusedUIElement));
    method_setImplementation(methodToPatch, (IMP)NSApplicationAccessibilityFocusedUIElement);
On to the next issue -- the focus is correctly set now, but we don't update when focus changes (I can select various elements by turning voiceover on and off, but once something is selected, it stays selected permanently.
is something sending NSAccessibilityFocusedUIElementChangedNotification ?  (e.g. via NotifyMacEvent(AXPlatformNodeCocoa*, ax::mojom::Event::kFocus); )
Labels: proj-MacPwa
Components: UI>Browser>WebAppInstalls
Labels: -proj-MacPwa OS-Mac
Cc: mgiuca@chromium.org
 Issue 898612  has been merged into this issue.
Re #7 ... no, nothing is doing that yet -- I need to forward that!

I have a prototype that mostly-works -- I need to whittle it down to "only the needed parts".
Indeed we are hitting NotifyMacEvent with kFocus in the browser process. We're not calling it in the app process, though.
Project Member

Comment 13 by bugdroid1@chromium.org, Nov 16

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/38dabcbbf77558e103ee3941d829aa0906f02248

commit 38dabcbbf77558e103ee3941d829aa0906f02248
Author: Christopher Cameron <ccameron@chromium.org>
Date: Fri Nov 16 07:29:22 2018

RemoteMacViews: Hook up remote accessibility interface

Add the NSAccessibilityRemoteUIElement interface along with helper
functions to use the interface with stl structures.

Make the previously-dummy GetNativeViewAccessible implementation of
perform a sync call to BridgedNativeWidgetHost to set up the required
accessibility tree structures.
- Send to the browser process the accessibility tokens for the
  NSWindow and its content NSView.
- Retrieve the accessibility token for the root AXPlatformNodeCocoa,
  along with the browser process id.

This is not sufficient for accessibility to work. The remaining parts
are to
- Update the AXPlatformNodeCocoa class to return the object created
  from the accessibility tokens.
  - Add TODOs where this needs to be hooked up, but defer the actual
    change to a separate patch.
- Splice together the accessibility trees for content and views.

Create a ScopedAccessibilityFocus class to override the value returned
by -[NSApplication accessibilityFocusedUIElement]. This is required for
cross-process accessibility methods to find the appropriate focused
element.

Bug:  900846 
Change-Id: I09df0bfddd82b7904131b195ece55dc803c56aa9
Reviewed-on: https://chromium-review.googlesource.com/c/1337377
Commit-Queue: ccameron <ccameron@chromium.org>
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608690}
[modify] https://crrev.com/38dabcbbf77558e103ee3941d829aa0906f02248/ui/accessibility/platform/ax_platform_node_mac.mm
[modify] https://crrev.com/38dabcbbf77558e103ee3941d829aa0906f02248/ui/base/BUILD.gn
[add] https://crrev.com/38dabcbbf77558e103ee3941d829aa0906f02248/ui/base/cocoa/remote_accessibility_api.h
[add] https://crrev.com/38dabcbbf77558e103ee3941d829aa0906f02248/ui/base/cocoa/remote_accessibility_api.mm
[modify] https://crrev.com/38dabcbbf77558e103ee3941d829aa0906f02248/ui/views/BUILD.gn
[modify] https://crrev.com/38dabcbbf77558e103ee3941d829aa0906f02248/ui/views/accessibility/view_ax_platform_node_delegate_mac.mm
[modify] https://crrev.com/38dabcbbf77558e103ee3941d829aa0906f02248/ui/views/cocoa/bridged_native_widget_host_impl.h
[modify] https://crrev.com/38dabcbbf77558e103ee3941d829aa0906f02248/ui/views/cocoa/bridged_native_widget_host_impl.mm
[add] https://crrev.com/38dabcbbf77558e103ee3941d829aa0906f02248/ui/views/cocoa/scoped_accessibility_focus.h
[add] https://crrev.com/38dabcbbf77558e103ee3941d829aa0906f02248/ui/views/cocoa/scoped_accessibility_focus.mm
[modify] https://crrev.com/38dabcbbf77558e103ee3941d829aa0906f02248/ui/views_bridge_mac/bridge_factory_impl.mm
[modify] https://crrev.com/38dabcbbf77558e103ee3941d829aa0906f02248/ui/views_bridge_mac/bridged_native_widget_host_helper.h
[modify] https://crrev.com/38dabcbbf77558e103ee3941d829aa0906f02248/ui/views_bridge_mac/mojo/bridged_native_widget_host.mojom

Project Member

Comment 14 by bugdroid1@chromium.org, Nov 16

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e31793abe65058ac976a1badfb472070f68a9f5f

commit e31793abe65058ac976a1badfb472070f68a9f5f
Author: Christopher Cameron <ccameron@chromium.org>
Date: Fri Nov 16 22:02:25 2018

RemoteMacViews: Fix web contents accessibility focus

ScopedAccessibilityFocus should have changed the focus to return
-[NSWindow accessibilityFocusedUIElement].

TBR=ellyjones

Bug:  900846 
Change-Id: I7813e4eb7099c69d1106630050b9581b4927d79b
Reviewed-on: https://chromium-review.googlesource.com/c/1340911
Commit-Queue: ccameron <ccameron@chromium.org>
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#608971}
[modify] https://crrev.com/e31793abe65058ac976a1badfb472070f68a9f5f/ui/views/cocoa/scoped_accessibility_focus.h
[modify] https://crrev.com/e31793abe65058ac976a1badfb472070f68a9f5f/ui/views/cocoa/scoped_accessibility_focus.mm

Project Member

Comment 15 by bugdroid1@chromium.org, Nov 21

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ca224255035c559a8f454278d358975c5eba4698

commit ca224255035c559a8f454278d358975c5eba4698
Author: Christopher Cameron <ccameron@chromium.org>
Date: Wed Nov 21 09:08:41 2018

RemoteMacViews: Return NSAccessibilityRemoteUIElement where appropriate

When using RemoteMacViews, for a given widget, the widget's NSWindow
and content NSView exist in the app shim process, while the tree of
AXPlatformNodeCocoas exists in the browser process.

In the browser process, the widget's NSWindow and content NSView are
represented by NSAccessibilityRemoteUIElements in
views::BridgedNativeWidgetHostImpl.

Update AXPlatformNodeDelegateMac::GetParent and GetNSWindow to retrieve
these values from views::BridgedNativeWidgetHostImpl.

In AXPlatformNodeDelegate, replace the method GetTopLevelWidget with
the method GetNSWindow and call this method in -[AXPlatformNodeCocoa
AXWindow]. Replace all subclass implementations except for
AXPlatformNodeDelegateMac with NOTREACHED.

Bug:  900846 
Change-Id: Ia0d26c4d118391ce66cc1e080ca3b62fb228aa8c
Reviewed-on: https://chromium-review.googlesource.com/c/1338722
Commit-Queue: ccameron <ccameron@chromium.org>
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#609959}
[modify] https://crrev.com/ca224255035c559a8f454278d358975c5eba4698/content/browser/accessibility/browser_accessibility.cc
[modify] https://crrev.com/ca224255035c559a8f454278d358975c5eba4698/content/browser/accessibility/browser_accessibility.h
[modify] https://crrev.com/ca224255035c559a8f454278d358975c5eba4698/ui/accessibility/platform/ax_platform_node_delegate.h
[modify] https://crrev.com/ca224255035c559a8f454278d358975c5eba4698/ui/accessibility/platform/ax_platform_node_delegate_base.cc
[modify] https://crrev.com/ca224255035c559a8f454278d358975c5eba4698/ui/accessibility/platform/ax_platform_node_delegate_base.h
[modify] https://crrev.com/ca224255035c559a8f454278d358975c5eba4698/ui/accessibility/platform/ax_platform_node_mac.mm
[modify] https://crrev.com/ca224255035c559a8f454278d358975c5eba4698/ui/views/accessibility/ax_virtual_view.cc
[modify] https://crrev.com/ca224255035c559a8f454278d358975c5eba4698/ui/views/accessibility/ax_virtual_view.h
[modify] https://crrev.com/ca224255035c559a8f454278d358975c5eba4698/ui/views/accessibility/view_ax_platform_node_delegate.cc
[modify] https://crrev.com/ca224255035c559a8f454278d358975c5eba4698/ui/views/accessibility/view_ax_platform_node_delegate.h
[modify] https://crrev.com/ca224255035c559a8f454278d358975c5eba4698/ui/views/accessibility/view_ax_platform_node_delegate_mac.h
[modify] https://crrev.com/ca224255035c559a8f454278d358975c5eba4698/ui/views/accessibility/view_ax_platform_node_delegate_mac.mm
[modify] https://crrev.com/ca224255035c559a8f454278d358975c5eba4698/ui/views/cocoa/bridged_native_widget_host_impl.h
[modify] https://crrev.com/ca224255035c559a8f454278d358975c5eba4698/ui/views/cocoa/bridged_native_widget_host_impl.mm

Project Member

Comment 16 by bugdroid1@chromium.org, Nov 21

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6931f4c0d081f179dae827911989bc74aeb12761

commit 6931f4c0d081f179dae827911989bc74aeb12761
Author: Christopher Cameron <ccameron@chromium.org>
Date: Wed Nov 21 20:59:50 2018

RemoteMacViews: Generalize remote accessibility focus override

Move ScopedAccessibilityFocus from ui/views/cocoa to ui/base/cocoa,
because it is going to be used by content/ (which, for the moment,
does not depends on ui/views, though I would like to add an explicit
dependency at some point).

Rename ScopedAccessibilityFocus to AccessibilityFocusOverrider, and
- make it track
  - whether or not the view it represents if the first responder for
    its window
  - whether or not its window is key
- override -[NSApplication accessibilityFocusedUIElement] only when
  both of those conditions are true

Apply this scheme to the two main NSViews
- BridgedContentView uses an AccessibilityFocusOverrider in
  BridgedNativeWidgetHostImpl
- RenderWidgetHostViewCocoa uses an AccessibilityFocusOverrider in
  RenderWidgetHostViewMac

Change slightly the way that NSWindow key status is tracked between
RenderWidgetHostViewCocoa/Mac.
- These changes were only send to the browser when the view was also
  first responder
- Change this to always send changes in key status, and early-out
  when the view is not first responder on the browser side.

Bug:  900846 
Change-Id: I15bb144ae4570eeffa51c4609f58aa8b58b892d9
Reviewed-on: https://chromium-review.googlesource.com/c/1345121
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#610209}
[modify] https://crrev.com/6931f4c0d081f179dae827911989bc74aeb12761/content/browser/renderer_host/render_widget_host_ns_view_client_helper.h
[modify] https://crrev.com/6931f4c0d081f179dae827911989bc74aeb12761/content/browser/renderer_host/render_widget_host_ns_view_client_helper.mm
[modify] https://crrev.com/6931f4c0d081f179dae827911989bc74aeb12761/content/browser/renderer_host/render_widget_host_view_cocoa.mm
[modify] https://crrev.com/6931f4c0d081f179dae827911989bc74aeb12761/content/browser/renderer_host/render_widget_host_view_mac.h
[modify] https://crrev.com/6931f4c0d081f179dae827911989bc74aeb12761/content/browser/renderer_host/render_widget_host_view_mac.mm
[modify] https://crrev.com/6931f4c0d081f179dae827911989bc74aeb12761/ui/base/BUILD.gn
[add] https://crrev.com/6931f4c0d081f179dae827911989bc74aeb12761/ui/base/cocoa/accessibility_focus_overrider.h
[add] https://crrev.com/6931f4c0d081f179dae827911989bc74aeb12761/ui/base/cocoa/accessibility_focus_overrider.mm
[modify] https://crrev.com/6931f4c0d081f179dae827911989bc74aeb12761/ui/views/BUILD.gn
[modify] https://crrev.com/6931f4c0d081f179dae827911989bc74aeb12761/ui/views/cocoa/bridged_native_widget_host_impl.h
[modify] https://crrev.com/6931f4c0d081f179dae827911989bc74aeb12761/ui/views/cocoa/bridged_native_widget_host_impl.mm
[delete] https://crrev.com/0ec959f96db10622eee34b30579073a8b3b194a3/ui/views/cocoa/scoped_accessibility_focus.h
[delete] https://crrev.com/0ec959f96db10622eee34b30579073a8b3b194a3/ui/views/cocoa/scoped_accessibility_focus.mm
[modify] https://crrev.com/6931f4c0d081f179dae827911989bc74aeb12761/ui/views_bridge_mac/bridged_content_view.mm

Project Member

Comment 17 by bugdroid1@chromium.org, Nov 27

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/94853e6e121dd37d23e5258b392e65007e990f73

commit 94853e6e121dd37d23e5258b392e65007e990f73
Author: Christopher Cameron <ccameron@chromium.org>
Date: Tue Nov 27 20:23:27 2018

RemoteMacViews: Add mojo plumbing for content accessibility elements

Add a mojo method to send the NSAccessibilityRemoteUIElement tokens for
the NSView and NSWindow in the viewer (app shim) process to the browser
process, and to return the NSAccessibilityRemoteUIElement for the web
contents (in the browser) the viewer (app shim) process.

Update -[BrowserAccessibilityCocoa window] to call either
-[NSView window] or -[NSAccessibilityRemoteUIElement windowUIElement],
depending on which object is returned by GetParentView.

Change -[RenderWidgetHostViewCocoa accessibilityFocusedUIElement] to
call a GetFocusedBrowserAccessibilityElement, which will return the
the NSAccessibilityRemoteUIElement when called in an app shim
process.

Bug:  900846 
Change-Id: I0d3d65e9924613b0dc137a08d0030d31981ecfdd
Reviewed-on: https://chromium-review.googlesource.com/c/1351415
Commit-Queue: ccameron <ccameron@chromium.org>
Reviewed-by: Dominick Ng <dominickn@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#611284}
[modify] https://crrev.com/94853e6e121dd37d23e5258b392e65007e990f73/content/browser/accessibility/browser_accessibility_cocoa.mm
[modify] https://crrev.com/94853e6e121dd37d23e5258b392e65007e990f73/content/browser/ns_view_bridge_factory_impl.mm
[modify] https://crrev.com/94853e6e121dd37d23e5258b392e65007e990f73/content/browser/renderer_host/render_widget_host_ns_view_client_helper.h
[modify] https://crrev.com/94853e6e121dd37d23e5258b392e65007e990f73/content/browser/renderer_host/render_widget_host_view_cocoa.mm
[modify] https://crrev.com/94853e6e121dd37d23e5258b392e65007e990f73/content/browser/renderer_host/render_widget_host_view_mac.h
[modify] https://crrev.com/94853e6e121dd37d23e5258b392e65007e990f73/content/browser/renderer_host/render_widget_host_view_mac.mm
[modify] https://crrev.com/94853e6e121dd37d23e5258b392e65007e990f73/content/common/render_widget_host_ns_view.mojom

This is mostly-there, but I'm still having issues with web content. Still poking at it.
Project Member

Comment 19 by bugdroid1@chromium.org, Nov 28

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/59a9684528005dda6651a5e5de900288bddeb0be

commit 59a9684528005dda6651a5e5de900288bddeb0be
Author: Christopher Cameron <ccameron@chromium.org>
Date: Wed Nov 28 10:06:02 2018

content: Remove AccessibilityOriginInScreen

Remove this method from both BrowserAccessibilityDelegate and from
RenderWidgetHostViewBase.

This method has only one caller, -[BrowserAccessibilityCocoa
pointInScreen], which can implement the functionality using the existing
AccessibilityGetViewBounds method. While in the neighborhood, convert
pointInScreen to rectInScreen, because
- that's what all of the callers but one want
- there already exist helper functions for that method
- it maintains the rule that "gfx::* structures are in gfx coordinates
  while NS* structures are in NS coordinates"

Bug:  900846 
Change-Id: Idd62dc256e5d05e946f9a47fa61b8479fbc8be56
Reviewed-on: https://chromium-review.googlesource.com/c/1351580
Commit-Queue: ccameron <ccameron@chromium.org>
Reviewed-by: Avi Drissman <avi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#611624}
[modify] https://crrev.com/59a9684528005dda6651a5e5de900288bddeb0be/content/browser/accessibility/browser_accessibility_cocoa.h
[modify] https://crrev.com/59a9684528005dda6651a5e5de900288bddeb0be/content/browser/accessibility/browser_accessibility_cocoa.mm
[modify] https://crrev.com/59a9684528005dda6651a5e5de900288bddeb0be/content/browser/accessibility/browser_accessibility_manager.h
[modify] https://crrev.com/59a9684528005dda6651a5e5de900288bddeb0be/content/browser/accessibility/browser_accessibility_manager_unittest.cc
[modify] https://crrev.com/59a9684528005dda6651a5e5de900288bddeb0be/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/59a9684528005dda6651a5e5de900288bddeb0be/content/browser/frame_host/render_frame_host_impl.h
[modify] https://crrev.com/59a9684528005dda6651a5e5de900288bddeb0be/content/browser/renderer_host/render_widget_host_view_base.cc
[modify] https://crrev.com/59a9684528005dda6651a5e5de900288bddeb0be/content/browser/renderer_host/render_widget_host_view_base.h
[modify] https://crrev.com/59a9684528005dda6651a5e5de900288bddeb0be/content/browser/renderer_host/render_widget_host_view_mac.h
[modify] https://crrev.com/59a9684528005dda6651a5e5de900288bddeb0be/content/browser/renderer_host/render_widget_host_view_mac.mm

Labels: -Pri-3 M-73 Pri-1
Okay, this is now completely working with
https://chromium-review.googlesource.com/c/chromium/src/+/1369134

(wipes brow)
\o/
Project Member

Comment 23 by bugdroid1@chromium.org, Dec 10

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/78521d8cd6ed96cbce883bbdce1e4c44a94ba5f8

commit 78521d8cd6ed96cbce883bbdce1e4c44a94ba5f8
Author: Christopher Cameron <ccameron@chromium.org>
Date: Mon Dec 10 19:25:32 2018

RemoteMacViews: Simplify content accessibility

The previous scheme that was being used for accessibility was to have
a tree that looked like
- NativeWidgetMacNSWindow in app shim process
- BridgedContentView in app shim process
- views::Views AX tree in the browser process
- WebContentsViewCocoa in the app shim process
  - this was sort of hand-wavy and hadn't been completely implemented
- RenderWidgetHostViewCocoa in the app shim process
- content AX tree in the browser process
This sandwiching of the app shim's WebContentsViewCocoa and
RenderWidgetHostViewCocoa was unnecessarily complicated -- we should
just use the NSViews that we have in the browser process.

This patch simplifies things to just stay in the browser process once
we get there.

The one time that we need to jump back to the app shim process is
when the content AX tree is asked about its window property. To
accommodate this
- Add a AccessibilityGetNativeViewAccessibleForWindow method that
  plumbs over to the RenderWidgetHostViewMac, and returns the
  NSAccessibilityRemoteUIElement in remote mode (and the NSWindow
  otherwise).
- Add a mojo method to set the NSAccessibilityRemoteUIElement whenever
  the window is changed (we may need it before its previous "lazy"
  initialization in SyncConnectAccessibilityElements).
- Remove setting the NSAccessibilityRemoteUIElement tokens from the
  SyncConnectAccessibilityElements method, and rename it to
  SyncGetRootAccessibilityElement (because it now connects nothing).

Bug:  900846 
Change-Id: I8a88ffc75a797eaad9445f66fbc4aa47539ec769
Reviewed-on: https://chromium-review.googlesource.com/c/1369134
Reviewed-by: Avi Drissman <avi@chromium.org>
Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org>
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#615199}
[modify] https://crrev.com/78521d8cd6ed96cbce883bbdce1e4c44a94ba5f8/content/browser/accessibility/browser_accessibility_cocoa.mm
[modify] https://crrev.com/78521d8cd6ed96cbce883bbdce1e4c44a94ba5f8/content/browser/accessibility/browser_accessibility_manager.h
[modify] https://crrev.com/78521d8cd6ed96cbce883bbdce1e4c44a94ba5f8/content/browser/accessibility/browser_accessibility_manager_mac.h
[modify] https://crrev.com/78521d8cd6ed96cbce883bbdce1e4c44a94ba5f8/content/browser/accessibility/browser_accessibility_manager_mac.mm
[modify] https://crrev.com/78521d8cd6ed96cbce883bbdce1e4c44a94ba5f8/content/browser/accessibility/browser_accessibility_manager_unittest.cc
[modify] https://crrev.com/78521d8cd6ed96cbce883bbdce1e4c44a94ba5f8/content/browser/frame_host/render_frame_host_impl.cc
[modify] https://crrev.com/78521d8cd6ed96cbce883bbdce1e4c44a94ba5f8/content/browser/frame_host/render_frame_host_impl.h
[modify] https://crrev.com/78521d8cd6ed96cbce883bbdce1e4c44a94ba5f8/content/browser/ns_view_bridge_factory_impl.mm
[modify] https://crrev.com/78521d8cd6ed96cbce883bbdce1e4c44a94ba5f8/content/browser/renderer_host/render_widget_host_ns_view_client_helper.h
[modify] https://crrev.com/78521d8cd6ed96cbce883bbdce1e4c44a94ba5f8/content/browser/renderer_host/render_widget_host_view_base.cc
[modify] https://crrev.com/78521d8cd6ed96cbce883bbdce1e4c44a94ba5f8/content/browser/renderer_host/render_widget_host_view_base.h
[modify] https://crrev.com/78521d8cd6ed96cbce883bbdce1e4c44a94ba5f8/content/browser/renderer_host/render_widget_host_view_cocoa.mm
[modify] https://crrev.com/78521d8cd6ed96cbce883bbdce1e4c44a94ba5f8/content/browser/renderer_host/render_widget_host_view_mac.h
[modify] https://crrev.com/78521d8cd6ed96cbce883bbdce1e4c44a94ba5f8/content/browser/renderer_host/render_widget_host_view_mac.mm
[modify] https://crrev.com/78521d8cd6ed96cbce883bbdce1e4c44a94ba5f8/content/common/render_widget_host_ns_view.mojom

And ... it was completely working because I'd disabled RemoteMacViews and not noticed it :(

It's mostly-working now, but text selection isn't read. Is there something special about how selected text inside the web contents area is done?
Project Member

Comment 26 by bugdroid1@chromium.org, Dec 17

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/6b760d54c04148828c796d0aa3711f2bb0a00f9a

commit 6b760d54c04148828c796d0aa3711f2bb0a00f9a
Author: Christopher Cameron <ccameron@chromium.org>
Date: Mon Dec 17 20:10:08 2018

RemoteMacViews: Accessibility clean-up

Separate the operations of:
1. Getting the accessibility token from root views::View (from the
   Browser process) in the AppShim process.
2. Sending the accessibility tokens for the NSView and NSWindow from the
   AppShim to the Browser process.

Prior to this change these operations would be done only when the
AppShim process requested accessibility info -- this could potentially
be long after the Browser process needed accessibility info.

Now do [2] immediately upon creating the NSView in the AppShim process
(as early as possible), and continue to do [1] on demand.

Bug:  900846 
Change-Id: If4818b0818056e71525f2ce654f4df72a12836c9
Reviewed-on: https://chromium-review.googlesource.com/c/1379694
Reviewed-by: Robert Sesek <rsesek@chromium.org>
Reviewed-by: Sidney San Martín <sdy@chromium.org>
Commit-Queue: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/heads/master@{#617203}
[modify] https://crrev.com/6b760d54c04148828c796d0aa3711f2bb0a00f9a/ui/views/cocoa/bridged_native_widget_host_impl.h
[modify] https://crrev.com/6b760d54c04148828c796d0aa3711f2bb0a00f9a/ui/views/cocoa/bridged_native_widget_host_impl.mm
[modify] https://crrev.com/6b760d54c04148828c796d0aa3711f2bb0a00f9a/ui/views_bridge_mac/bridge_factory_impl.mm
[modify] https://crrev.com/6b760d54c04148828c796d0aa3711f2bb0a00f9a/ui/views_bridge_mac/bridged_native_widget_impl.mm
[modify] https://crrev.com/6b760d54c04148828c796d0aa3711f2bb0a00f9a/ui/views_bridge_mac/mojo/bridged_native_widget_host.mojom

Status: Fixed (was: Assigned)
Closing this out and replacing it with issue 916923, which is the one feature that (I know of that) is not working with PWAs.

Sign in to add a comment