This is a short-term solution to our inability to apply CSP to
chrome-privileged documents.
Ideally, we should be preventing all inline script execution in
chrome-privileged documents, since the reprecussions of XSS in chrome
documents are much worse than in content documents. Unfortunately, that's not
possible in the near term because a) we don't support CSP in system principal
documents at all, and b) we rely heavily on inline JS in our static XUL.
This stop-gap solution at least prevents some of the most common vectors of
XSS attack, by automatically sanitizing any HTML fragment created for a
chrome-privileged document.
MozReview-Commit-ID: 5w17celRFr
--HG--
extra : rebase_source : 1c0a1448a06d5b65e548d9f5362d06cc6d865dbe
extra : amend_source : 7184593019f238b86fd1e261941d8e8286fa4006
Recognize the graphics-document, graphics-object, and graphics-symbol
ARIA roles, mapping them to the DOCUMENT, GROUPING, and GRAPHIC internal
roles respectively.
JAWS uses QueryService for these.
Using QI avoids a cross-process call, since we have these interfaces cached.
More importantly, if QS is used, the handler won't get used for that object, so our caching won't be used.
MozReview-Commit-ID: Ejc2Bjp7NSv
--HG--
extra : rebase_source : f0154a6691d4d6be97e9aa60b0613ff04f76b7ff
We just return failure for these, thus avoiding a pointless cross-process call.
I also updated the comment for an existing service, since I discovered its constant name.
MozReview-Commit-ID: E5hjhR6nYtv
--HG--
extra : rebase_source : 8f01da6b98a881809a106a03eb611aadc90a6d20
Most of the Shadow DOM related code are behind "dom.webcomponents.enabled" and
this pref is only used by Shadow DOM right now, so we should rename it to
"dom.webcomponents.shadowdom.enabled"
MozReview-Commit-ID: er1c7AsSSW
In theory other radixes can be passed in but we don't actually handle them.
This asserts that the radix is supported and just switches over to using 10 and
16 directly.
--HG--
extra : rebase_source : 71891302d499bfd108a5bb41626d921b3be193ce
When switching from a tab to another, accessibility layers needs to get
events about the tab switch before events about the newly-focused
element of the document.
This changeset does it so by first making IsUpdatePending() not only
watch for the document's pending updates, but also its parent's pending
updates, so that the document doesn't process focus events immediately,
but queue them.
Then, WillRefresh for the document should not process events until its
parent chrome has finished processing its content insertion events
(corresponding to the tab switch).
Eventually, ScheduleContentInsertion can not afford leaving an empty
array of notifications and not a schedule processing any more.
(was introduced by c2aeece5eb10 'Bug 1242989 - keep content insertions
in a hash')
We weren't checking for null previously, thus causing a crash when there was no caret.
MozReview-Commit-ID: 6NNRafcVPhb
--HG--
extra : rebase_source : 7d6bfc8c776c1be1429da8c2c94f4bda232c6314
Bug 1422201 changed GetIAccessibleFor so it only handles remote ids when called on the root accessible.
However, this breaks webextension popup documents.
These popups have their own HWND, so the root accessible of that HWND needs to handle accChild for ids in remote documents within that HWND.
Therefore, expand the restriction to cover the root accessible of any HWND, not just the main HWND.
MozReview-Commit-ID: 69v4XSeQLcS
--HG--
extra : rebase_source : bf5c5e0a475424b2276800d1a10ab1a46c136bd6