GitLab

Don't read the full row if the last input event was a mouse button
event. We always generate the full line (i.e. each cell in the row)
when the caret moves due to a mouse click. If we think we should
read the full row for each cell in that row, we'll be extremely
chatty and also fail to present the column headers.

Increase consistency between load/remove profile dialogs.

Fixes #146

This addresses an edge case: We're in SayAll, a caret navigation command
is given which interrupts SayAll, and we happen to land in an empty text
element (e.g. a paragraph) as a consequence of that caret navigation
command. In this particular case, we should say "blank" but we weren't
doing so because we only do that "blank" fallback when we are not in
SayAll. (Interrupted SayAll is treated as in SayAll due to the fast-forward
and rewind commands.)

To address this edge case, add an optional argument to inSayAll() that
allows us to treat interrupted SayAll as not being in SayAll. Then
use that for the "blank" fallback for web content.

There shouldn't be useless empty elements at the top of a document. But
authors, along with Thunderbird.... Therefore when seeking the first
context in the document (e.g. when pressing Ctrl+Home), start with the
first child that isn't a useless empty element.

In <pre> and <code> blank lines are presumably there for a reason.
Thus skipping over them is a bug.

For most accessible objects, we attempt to generate lots of things
(e.g. role, relevant states, displayed text, selection, etc.) and
by default we separate these pieces of information by pauses. In
some cases (e.g. an empty paragraph) it is possible to generate
results consisting solely of pauses. We don't want to treat that as
actual results because it can cause other logic (e.g. saying "blank")
to not kick in and lead to our speaking nothing.

We were losing track that the last command was a caret-navigation
command when Ctrl was released after using Ctrl+Home. As a result,
when the browser emits caret-moved and focus-changed events we
triggered, we process them rather than ignoring them as caused by us.

Unfortunately, empty anchors can appear in the accessibility tree.
If caret navigation causes us to land on one, there's nothing to
present. Therefore look for and move to the first presentable thing
after the empty anchor.

* Try to get to the bottom of Orca not starting due to timeout
* Try to identify why braille contraction is not happening

On some pages, the content we're navigating in is contained in the
document itself (as opposed to a child element). In those cases, we
don't want to speak the document title when the caret first returns
to the body as a consequence of using caret navigation.

There were special occasions (such as headings) when caret moved events
caused the entire object to be presented when clicking with the physical
mouse. This was not intentional. Move mouse-button handling to the top
of the logic where we determine what to present when the locusOfFocus
changes.

In addition, explicitly set the prior object to the old focus for mouse-
button-triggered caret-moved events. This should ensure we present roles
when initially clicking into a new element.

Quirks in web sites and web browsers are tricky....

* If the children-changed event is our current object, dump cache and
  also the context because all bets are off regarding whether or not
  our current location is stale.
* If the children-changed event is an ancestor of our current object,
  dump cache but preserve the context because something around us
  has changed, but our present location should still be valid. Plus
  subsequent sanity checks should trigger us to update things if
  our present location isn't valid after all.
* Otherwise, something elsewhere has changed so don't dump the cache.

Also add more debugging to get to the bottom of remaining quirks.

Hopefully this will work around whatever bugs we're seeing in Firefox's
table and text support that cause us to not be able to correctly locate
our position.

We now dump all of our cache when children-changed events are emitted.
This ensures we are not working with a stale tree (which can cause us
to get stuck and/or skip over content). Unfortunately, clearing the
context has exposed bugs in browsers. It should be safe to preserve
the context by default so we do not have to search for the current
location after a children-changed event that hasn't destroyed the
current location's accessible object.

We now clear our cache whenever the document or its descendant emits
children-changed events. This prevents us from potentially getting
stuck in a stale accessibility subtree. Unfortunately, if clicking
with the mouse causes the browser to emit duplicate caret-moved events
with a children-changed event in between, we'll double-speak that
caret-moved event. Try to work around this by caching the last caret
context resulting from a mouse click -- and not clearing that cache
in response to children-changed.

When the caret moves, we compare the object emitting the event with
the current context, searching for that context if it doesn't yet
exist. When initially clicking inside a web page, the context might
not yet exist because we cleared the cache in response to a children-
changed event. Thus when we search for the context, the result is
where we just clicked, so we say nothing. Fix this by adding an
option to not search for the context when it doesn't exist.

When the user Tabs into the document, we sometimes see a caret-moved
event for the document. This causes us to look for the first presentable
thing at offset and update our location to that thing. If the first
presentable thing in the document happens to be a focusable widget,
this can cause us to present the focusable widget as if it were focused
and to ignore a subsequent focus event for when it really becomes focused.
On the other hand, if the first presentable thing is a text element such
as a paragraph, we should be getting the caret moved event for that
element rather than from the document.

Not using the cache for children was an old solution to work around not
getting updates from apps/toolkits/browsers when objects were added or
removed. But not using the AT-SPI2 cache comes with a performance hit
in large accessibility trees. Therefore, we'll start using the cache for
children and address specific offenders on a more targeted basis.

If the document content changes anywhere around the current element,
we can wind up with stale information that can break navigation in
browse mode. Therefore, always dump all cached objects in response
to children-changed events unless we're in a live region. Live
region updates are typically presented rather than navigated within.

The fallback in the web code was preventing other fallbacks from
doing their thing.