UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3500.0 Safari/537.36

Steps to reproduce the problem:
1. Launch Chrome/Chromium
  * export ACCESSIBILITY_ENABLED=1, and
  * launch with --force-renderer-accessibility

2. Launch Accerciser (an accessibility inspector for GNU/Linux)

3. Expand "Accessible" in Accerciser's Interface Viewer and examine the state set of Chrome/Chromium's window

What is the expected behavior?
Chrome/Chromium windows would have a full state set, including the following states:

* active (when the window is active)
* enabled
* iconified (when the window is minimized)
* sensitive
* showing
* visible

What went wrong?
The only state in the state set is enabled.

Did this work before? No 

Chrome version: 70.0.3500.0  Channel: n/a
OS Version: 
Flash Version: 

Compare to: Firefox (with accessibility enabled), Epiphany, any Gtk+ app

Documentation: https://developer.gnome.org/atk/stable/atk-AtkState.html#AtkStateType

Impact: Orca has no way of knowing the Chrome/Chromium window is active. Chrome/Chromium windows also claim to not be showing or visible. As a result, Orca will more often than not treat Chrome/Chromium windows as something the user is not in (and thus something which is not relevant to the user).

Notes:

There is a recentish Firefox+Gtk3 bug which can cause state active to not reliably appear in the state set when viewed by Accerciser. Other apps can be used to demonstrate the expected state set for windows.

Some apps add focusable and focused to windows. Ditto for resizable. A case could be made for also including these states when appropriate, but Orca does not look for these states in the case of a window/frame.