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.
The default implementation of get_accKeyboardShortcut falls back to using the keyboard accelerator if an access key is not available. For XUL menu items, this is not appropriate since the accelerator gets exposed as part of the accessible name already.
The result was a double announcement of the keyboard accelerator on menu items that did not have an access key (underlined letter).
Differential Revision: https://phabricator.services.mozilla.com/D14533
--HG--
extra : moz-landing-system : lando
This is a best effort attempt at ensuring that the adverse impact of
reformatting the entire tree over the comments would be minimal. I've used a
combination of strategies including disabling of formatting, some manual
formatting and some changes to formatting to work around some clang-format
limitations.
Differential Revision: https://phabricator.services.mozilla.com/D13046
--HG--
extra : moz-landing-system : lando
The first patch inherits from the right classes, but because tables have additional interfaces, QueryInterface is overridden.
It had to be updated to also include HyperTextAccessibleWrap.
Rows worked correctly because they don't have any specific interfaces and thus don't override QI.
They just inherit their QI implementation from their base class.
Differential Revision: https://phabricator.services.mozilla.com/D10022
--HG--
extra : moz-landing-system : lando
In AccessibleWrap.cpp, VARIANT instances are initialized with {VT_I4}.
However, clang claims they should be initialized with {{{VT_I4}}}.
In CompatibilityUIA, the capturing variable is reference to static variable.
So, this patch makes it refer the static variable directly.
Differential Revision: https://phabricator.services.mozilla.com/D8511
--HG--
extra : moz-landing-system : lando
IMPL_IUNKNOWN_QUERY_HEAD defines HRESULT as hr. However, if its user uses
IMPL_IUNKNOWN_QUERY_TAIL_AGGREGATED, it's never used. Therefore, it causes
unused variable warning. hr is defined with ATTRIBUTE_UNUSED. However,
this is empty when built with clang.
IUnknownImpl.h already defines ATTRIBUTE_UNUSED as __attribute__((unused)) when
built with gcc. So, same warnings should be prevented when built with clang
too.
Differential Revision: https://phabricator.services.mozilla.com/D8510
--HG--
extra : moz-landing-system : lando
Some classes of a11y are defined from both IUnknown and nsISupports. Both of
them have QueryInterface(). So, one of them is overridden by a sub class
hides the other and this is warned by clang. However, AccessibleWrap.h
prevents this warning since it's by design when the compiler is GCC.
So, it should do same thing when the compiler is clang.
Differential Revision: https://phabricator.services.mozilla.com/D4310
--HG--
extra : moz-landing-system : lando
This introduces the machinery needed to generate crash annotations from a YAML
file. The relevant C++ functions are updated to take a typed enum. JavaScript
calls are unaffected but they will throw if the string argument does not
correspond to one of the known entries in the C++ enum. The existing whitelists
and blacklists of annotations are also generated from the YAML file and all
duplicate code related to them has been consolidated. Once written out to the
.extra file the annotations are converted in string form and are no different
than the existing ones.
All existing annotations have been included in the list (and some obsolete ones
have been removed) and all call sites have been updated including tests where
appropriate.
--HG--
extra : source : 4f6c43f2830701ec5552e08e3f1b06fe6d045860
This again exposes the accelerator (e.g. Ctrl+T for New Tab) for menu items via IAccessible::accName on windows.
Bug 1438193 made Accessible::Name const.
On Windows, XULMenuitemAccessibleWrap::Name is overridden to append the accelerator to the name.
Unfortunately, this override was missed when converting Name to const (and wasn't a compile error because it didn't use the override keyword).
As such, this override stopped being called; we always called the const version, since that's the one inherited into AccessibleWrap.
Making this const causes this override to be called.
MozReview-Commit-ID: 7Gb199mzhHa
--HG--
extra : rebase_source : 41d15042a09e4743d127fb12378c775099aa09a0
We don't fire a state change for the focused state, since that would be redundant given that we fire a focus event.
However, that also means the handler cache previously didn't get invalidated when there was a focus change without any other update.
That resulted in stale focused states, which could mean an object was exposed as focused when it wasn't.
Invalidating the cache for focus events ensures the focused state is always up to date.
MozReview-Commit-ID: DZTJMbiTwgt
--HG--
extra : rebase_source : 9977699999218432b07c4af2149cba6e0de466af
For example, this can happen when choosing File menu -> new Tab.
Focus briefly returns to the document in the original tab, so we ask that document to restore focus.
The remote document then sends a focus event to the parent.
However, before the parent can process that event, focus has already moved to the address bar for the new tab.
With this check, we discover that focus is now in the chrome and thus avoid firing the event for the remote accessible.
MozReview-Commit-ID: 7k58dzREqZD
--HG--
extra : rebase_source : 51303f54293957f562e8540c8bf98f821694be54
For example, this can happen when choosing File menu -> new Tab.
Focus briefly returns to the document in the original tab, so we ask that document to restore focus.
The remote document then sends a focus event to the parent.
However, before the parent can process that event, focus has already moved to the address bar for the new tab.
With this check, we discover that focus is now in the chrome and thus avoid firing the event for the remote accessible.
MozReview-Commit-ID: 7k58dzREqZD
--HG--
extra : rebase_source : 070d3a6b5032bd6d4cd36fb054be04509bb0faae
There is one actual behavior change here, in the webidl version of
TreeBoxObject::GetCellAt. I believe this change fixes a leak of the
nsTreeColumn, but could use careful review.
I tried to avoid changes not needed to get this compiling. There will be a lot
more cleanup in the next few changesets.
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
Bug 1421144 fixed IAccessible::accFocus to work when focus is within a remote document.
Unfortunately, this causes mysterious intermittent crashes when called from a UIA client in Windows 7.
Ideally, we'd deal with the actual cause of the crashes, but they seem to be deep in Windows RPC code and all attempts at tracking this down have failed.
Clients don't seem to need this too often anyway (and it's a minor annoyance if it doesn't work when they do).
MozReview-Commit-ID: IxvbBGJ2wxA
--HG--
extra : rebase_source : 504909703718b75fffcabf1fbe56c0bbff089b58
Bug 1421018 intended to block the Ask.Com Toolbar (tbnotifier.exe).
This is basically malware and is responsible for a huge number of unnecessary accessibility instantiations.
However, there seems to have been some confusion and we ended up blocking tbnnotifier.exe instead.
This changes that block to tbnotifier.exe.
MozReview-Commit-ID: 2gZF8sYeGtb
--HG--
extra : rebase_source : 3d14a24c12748edfc31ddf7dac51bca491abd744
These events were a hack implemented in bug 703198.
At that time, JAWS required focus events for selection changes in a collapsed combo box.
However, these events also fire for expanded combo boxes.
This is problematic with e10s because now, for an expanded combo box, the real focus events come from the XUL dropdown implemented in the parent process, which is not associated with the document a11y tree in any way.
JAWS seems to cope just fine with value changes for Firefox combo boxes now and VFO have agreed that this is the correct path forward.
MozReview-Commit-ID: Iefop25bFe0
--HG--
extra : rebase_source : a86e5d73d560853bb50e1d8e3bbd11431aba8eb0
I moved the IgnoreErrors decl so it would come after the OOMReporter decl and I
could add the new conversion operator.
MozReview-Commit-ID: B1S6DXmZfvE