When an Accessible is shut down, there might still be external references to it, so we keep the instance alive.
We don't want to reuse the id until all references are released, so we only release the id in the destructor (which runs when all references are released).
Previously, we were clearing the id variable in Shutdown, which meant we couldn't release the id in the destructor!
This meant we always leaked ids, never reusing them.
Now, we don't clear the id in Shutdown.
Differential Revision: https://phabricator.services.mozilla.com/D84653
I split the switch statement into two: the first switch determines the
MOX target accessible. The second one does all the rest. This makes it more
readable and scalable when we add more events that need to be accompanied with
data.
Differential Revision: https://phabricator.services.mozilla.com/D84053
This patch adds several new parameters:
* AXLeftWordTextMarkerRangeForTextMarker
* AXRightWordTextMarkerRangeForTextMarker
* AXStartTextMarkerForTextMarkerRange
* AXEndTextMarkerForTextMarkerRange
* AXNextTextMarkerForTextMarker
* AXPreviousTextMarkerForTextMarker
Our word boundaries API is pretty buggy. Instead of trying to
resolve or triage each issue I found, I added todo tests
for them.
Differential Revision: https://phabricator.services.mozilla.com/D83680
For remote documents, the DocAccessibleChild isn't created until the tree is constructed.
This means we can't send events to the parent process and thus to the client.
We shouldn't fire these events in the first place, since this makes events inconsistent for local and remote documents.
Differential Revision: https://phabricator.services.mozilla.com/D83605
This causes the browser to steal focus from any element that was focused prior
to the completion of the remoteness flip. This is particularly a problem for
fission because every cross-origin navigation requires a process switch.
This code is still necessary for "normal" session restores (see bug 1410591),
but focus is handled elsewhere for remote navigations.
Differential Revision: https://phabricator.services.mozilla.com/D82783
An accessible can be hidden twice in a mutation event queue. With the first
time representing a move. Instead of queueing a second hide event,
simply drop it.
Differential Revision: https://phabricator.services.mozilla.com/D83373
Accessible::RootAccessible() returns null on the ApplicationAccessible.
We weren't null checking this previously, so QueryService for SID_IAccessibleContentDocument on the ApplicationAccessible in a content process would crash.
This is rare, but JAWS does sometimes trigger it.
Differential Revision: https://phabricator.services.mozilla.com/D83452
DynamicIA2Data can be built to be transmitted in two different ways:
1. As part of the payload included in the stream when an accessible is marshaled; or
2. As an out parameter returned by IGeckoBackChannel::Refresh().
DynamicIA2Data includes arrays for row/column header ids.
Normally, such arrays would be allocated by CoTaskMemAlloc and freed by CoTaskMemFree.
However, in the first case, the struct is actually marshaled by RPC encoding functions, not by COM itself.
This means we must use midl_user_allocate/free, lest we crash.
We previously used midl_user_allocate/free for the second case as well.
Unfortunately, it turns out that this too causes crashes.
To fix this, we now use different memory allocation functions depending on how the struct is transmitted.
This patch also cleans up the old DynamicIA2Data in the client before calling IGeckoBackChannel::Refresh.
Previously, we didn't do this, which would have resulted in a leak.
Differential Revision: https://phabricator.services.mozilla.com/D82823
These classes do a few things:
1. They implement and abstract common text operations, for example:
(a) comparing two markers to know which one precedes the other.
(b) text retrieval for ranges
(c) geometric bounds for ranges
(d) etc.
2. They can be converted to and from AXTextMarker(Range)s. Since the AXTextMarker
should not contain a raw pointer since there is a potential for use-after-free,
we need to lookup the referenced accessible in its document to know that it still exists.
Note: mozTextAccessible got pushed to another unified source file, so we need to
declare some stuff for it. Ideally we would be detecting these kinds of things sooner.
Differential Revision: https://phabricator.services.mozilla.com/D81760
The delegate is associated with accessible documents (either local or remote).
I made a separate protocol for all the text marker stuff as it really is a seperate API.
Differential Revision: https://phabricator.services.mozilla.com/D81759
AXTextMarker and AXTextMarkerRange are opaque types that are not queried or
manipulated by the AT. For tests, we need to be able to retrieve them,
and pass them back.
This patch generalizes the wrapper we already had in nsIAccessibleMacInterface
and allows other types to be wrapped.
Differential Revision: https://phabricator.services.mozilla.com/D81758
The DocProxyAccessibleWrap for an OOP iframe document is always created before we know its parent.
Previously, this resulted in the document getting an id of -1, which is only valid for the root document.
It also broke subsequent assumptions once the parent was set later.
Because we don't have the parent in this case, we can't add the document's id to its parent's hash table.
To deal with this, we no longer add any document to its parent's hash table.
Instead, when finding an accessible by id, we just check the id of each child document before checking that child document's hash table.
Differential Revision: https://phabricator.services.mozilla.com/D81959
The IPC docs of the first/last nodes are not guaranteed to exist. This
could happen early on when the child docs are still hanging and have not
yet been processed in the NotificationController.
Differential Revision: https://phabricator.services.mozilla.com/D81883
This is already handled in a different way on Windows.
For documents at the top level of their process (including OOP iframes), we can just set the flag rather than waiting for a message, since we can never get queries for such documents or descendants before parent process construction is complete.
Differential Revision: https://phabricator.services.mozilla.com/D81009
It seems the window location isn't the issue here at all.
Rather, we never get the expected a11y events.
So, let's try to find out what events we *do* get.
Differential Revision: https://phabricator.services.mozilla.com/D81478
Previously, this returned a value if the ARIA value rule was not eNoValue, which covered eHasValueMinMaxIfFocusable.
However, eHasValueMinMaxIfFocusable needs the focusable state to be checked.
Rather than checking the value rule directly, just use HasNumericValue(), which already knows how to handle this.
Differential Revision: https://phabricator.services.mozilla.com/D81483
This includes 3 changes:
1. Add a lazy ranges getter to AccTextSelChangeEvent.
2. Create an XPCOM interface for testing purposes.
3. Add IPDL bindings for passing ranges in e10s.
Differential Revision: https://phabricator.services.mozilla.com/D80556
This is the actual fix.
Previously, we opened a download prompt, but we didn't close it.
This download prompt could sometimes get focus and prevent subsequent tests from getting focus.
Explicitly closing it should prevent this from happening.
Differential Revision: https://phabricator.services.mozilla.com/D80590
It's just too difficult/confusing to mix a11y and non-a11y async stuff using eventQueue.
This patch should be functionally equivalent; it doesn't fix the bug.
Differential Revision: https://phabricator.services.mozilla.com/D80589
Labels are often used as primary click targets for related inputs. If
they are styled to certain bounds, but contain overflowing text for a11y
with a color of "transparent", the synthesized click will happen outside
the bounds of the label.
If we skip text leafs with "color: transparent", we will skip labels
altogether. Instead, lets land on labels when traversing, and ignore
its subtree.
Differential Revision: https://phabricator.services.mozilla.com/D77898
Labels are often used as primary click targets for related inputs. If
they are styled to certain bounds, but contain overflowing text for a11y
with a color of "transparent", the synthesized click will happen outside
the bounds of the label.
If we skip text leafs with "color: transparent", we will skip labels
altogether. Instead, lets land on labels when traversing, and ignore
its subtree.
Differential Revision: https://phabricator.services.mozilla.com/D77898
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
Using overlay scrollbars will avoid the need to account for the trimmed
space that is introduced after an overflowing zoom caused by scrollbars.
Differential Revision: https://phabricator.services.mozilla.com/D80102
This avoids arbitrary precision loss when computing REM units and so on,
which is particularly important if we ever change the base of our app
units (but useful regardless).
Differential Revision: https://phabricator.services.mozilla.com/D79928
We're converting to nscoord in some places unnecessarily, reducing the
precision of the computed value we return.
This makes some tests unnecessarily fail if we change the base of
nscoord.
Differential Revision: https://phabricator.services.mozilla.com/D79996
The cache should already be empty by this point unless there's a bug, but we should still clean up regardless.
Also, the hashtable itself was previously never cleaned up even if it was empty.
Differential Revision: https://phabricator.services.mozilla.com/D79781
We can receive IPC events after a DocAccessibleParent is shut down if the BrowserParent is in the process of being destroyed (probably the tab closed) but there are still events in the IPC queue.
Most Recv*Event methods in BrowserParent check mShutdown, but a few don't.
For the events that don't, if the event is for a document, we'll successfully fire the platform event, and then successfully get and cache an xpcAccessibleDocument.
However, that xpcAccessibleDocument will never be removed from the cache because it's already shut down, so NotifyOfRemoteDocShutdown (which would normally remove it from the XPC cache) won't get called.
This results in a leaked object.
Thus, it's important that all Recv*Event methods drop the event if mShutdown is true.
This patch adds that check to the methods which didn't have it already.
Differential Revision: https://phabricator.services.mozilla.com/D79780
We really want to know about this because the document will never be removed from the cache, since NotifyOfRemoteDocShutdown (which would normally remove it from the XPC cache) won't get called.
Differential Revision: https://phabricator.services.mozilla.com/D79779
We're converting to nscoord in some places unnecessarily, reducing the
precision of the computed value we return.
This makes some tests unnecessarily fail if we change the base of
nscoord.
Differential Revision: https://phabricator.services.mozilla.com/D79996
This patch exposes the dialog element as a HyperTextAccessible with role DIALOG and enables the test after flipping the pref temporarily. Once the pref is on by default, the if block should be removed and the test run always.
Differential Revision: https://phabricator.services.mozilla.com/D79798
Otherwise, if we're replacing a previous top level doc, we might refer to the old top level doc during initialization.
Differential Revision: https://phabricator.services.mozilla.com/D79398
When window emulation is enabled, the emulated window is set on the top level DocAccessibleChild.
However, it isn't set on child documents (in-process iframes).
Therefore, when querying the window handle, we need to check for an emulated window handle on the top level document and return that if present.
This fixes the window handle returned by IAccessible2::get_windowHandle.
Note that the window handle used when firing events was already correct, as that is determined in the parent process.
In the parent process, the emulated window was already being propagated down to child DocAccessibleParents by BrowserParent::RecvPDocAccessibleConstructor.
Differential Revision: https://phabricator.services.mozilla.com/D79035
This usage of nsIDocShellTreeItem is safe, but nsIDocShellTreeItem is going away and it's trivial to convert this to use BrowsingContext.
As a bonus, the code is also shorter and more readable.
Differential Revision: https://phabricator.services.mozilla.com/D79022
This also adds some assertions where these are used in the Windows code, as it would be bad if that code ran in an OOP iframe document.
Differential Revision: https://phabricator.services.mozilla.com/D79021
According to SVG Accessibility API Mappings, an SVG element which has title or desc element must be exposed.
https://w3c.github.io/svg-aam/#include_elements
Previously, we didn't expose <g> elements at all even if they had a title/desc, and we unconditionally exposed some other SVG elements even when they didn't.
This removes the Dev Tools A11y Panel code which explicitly allowed unlabelled descendants of role="img" <svg> elements, since we don't create descendants if they don't have a label now anyway.
The associated tests had to be tweaked as well, since now we don't create unlabelled descendants.
Original patch by Takeshi Kurosawa.
Differential Revision: https://phabricator.services.mozilla.com/D77763
According to SVG Accessibility API Mappings, an SVG element which has title or desc element must be exposed.
https://w3c.github.io/svg-aam/#include_elements
Previously, we didn't expose <g> elements at all even if they had a title/desc, and we unconditionally exposed some other SVG elements even when they didn't.
Original patch by Takeshi Kurosawa.
Differential Revision: https://phabricator.services.mozilla.com/D77763
Also update documentation to suggest using the `GeneratedFile` template rather than directly referencing `GENERATED_FILES` where possible.
Differential Revision: https://phabricator.services.mozilla.com/D77496
A casualty of this is the "switch" action description for pressing tabs. That code
goes way back to our first Mac a11y support. WebKit and Chromium don't have it.
I tried to figure out when other browsers or apps had that with no luck.
Anyway, removing that description gives us the same behavior in VO as
WebKit and Chromium where there are no custom action description strings.
Differential Revision: https://phabricator.services.mozilla.com/D77342
A casualty of this is the ability to change listed attribute names on the fly.
I think this is the right choice in general and doesn't seem to affect VO.
If we run into a case where it does we should reconsider.
Differential Revision: https://phabricator.services.mozilla.com/D77341
Keeping accessibilityAttributeNames because it calls additionalAccessibilityAttributeNames
which is used by subclasses.
Differential Revision: https://phabricator.services.mozilla.com/D77335
Add most attributes getters, setters and actions to prottocol,
autogenerate objective c dictionaries, and implement forwarding
logic from NSAccessibility methods.
Differential Revision: https://phabricator.services.mozilla.com/D76921
This sets up the possibility of moving most non-gecko things to a base class, and
start a protocol to add for all the subclasses to implement as needed.
Differential Revision: https://phabricator.services.mozilla.com/D76920
There's no use case for stateful comparators, so they can be just plain
function pointers.
This is used in some hot places like CSS selector matching.
Differential Revision: https://phabricator.services.mozilla.com/D77084
1. When we unmarshal a row/column header, cache it so we can get it by id later.
2. get_rowHeaderCells and get_columnHeaderCells use the header ids in the payload.
If the headers are in the cache (as per 1), return them to the client.
Otherwise, fall back to a cross-process call, which might happen if we haven't encountered the header yet.
Differential Revision: https://phabricator.services.mozilla.com/D76667
1. When we unmarshal a row/column header, cache it so we can get it by id later.
2. get_rowHeaderCells and get_columnHeaderCells use the header ids in the payload.
If the headers are in the cache (as per 1), return them to the client.
Otherwise, fall back to a cross-process call, which might happen if we haven't encountered the header yet.
Differential Revision: https://phabricator.services.mozilla.com/D76667
Previously, to get the column headers for a cell when there weren't explicit headers, we walked over all previous cells in the column looking for headers.
For large tables with thousands of rows, this was very expensive, particularly when Windows screen readers rendered virtual buffers, fetching headers for all cells.
To speed this up, we now lazily cache the previous column header for each cell.
We even cache whether there is no previous header, since that is quite common and we don't want to pointlessly walk in that case.
Subsequent cells utilise the cached values (if any) for prior cells.
We don't store the cache on individual TableCellAccessibles because that would require us to walk all cells to invalidate the cache, even if few or no cells had cached values.
Instead, we store the cache as a hash table on the TableAccessible.
This way, we can just clear the cache whenever a column header is added to the tree.
We invalidate the cache whenever a column header is bound to its parent.
We don't need to invalidate the cache for removals because we instead just ignore defunct Accessibles in the cache.
Differential Revision: https://phabricator.services.mozilla.com/D76106
In favor of the NativeAnonymous versions which they forward to.
Done automatically with:
rg -l 'IsInAnonymousSubtree' | xargs sed -i 's/IsInAnonymousSubtree/IsInNativeAnonymousSubtree/g'
And removing the function definitions afterwards.
Differential Revision: https://phabricator.services.mozilla.com/D76681
These tests insert a <browser> into the DOM via tabbrowser, and
immediately try to get a hold to the underlying document right after.
However the a11y tree is constructed after frame construction, and with
bug 1584935 there's no longer a guarantee that it gets done in time
without these explicit flushes.
Note that I couldn't reproduce these failures locally, so take the
diagnostic with a grain of salt, but I believe it's accurate and that
this is the right fix.
Differential Revision: https://phabricator.services.mozilla.com/D75715
For an OOP iframe, the logged parent will be null and the logged root won't be the real top level document.
This is just the way things are and this might still be useful info sometimes, so we still log it, but make it clear in the log message that it's about the in-process tree.
Differential Revision: https://phabricator.services.mozilla.com/D74587
DocAccessibleParent::AddChildDoc sends a COM proxy for the embedded document to the embedder process hosting the iframe.
This gets returned as the child of the embedder OuterDocAccessible.
Whenever we send a proxy to a content process, we must hold a PreservedStreamPtr in the parent process.
Previously, we set mDocProxyStream on the parent (embedder) document.
However, if a document had multiple OOP iframes, this meant we ended up losing the PreservedStreamPtr for all but the last added child OOP document.
We now set mDocProxyStream on the child document instead, since there can only be one embedder OuterDocAccessible per child document.
Differential Revision: https://phabricator.services.mozilla.com/D74584
To improve performance for cross-process COM, we disable COM garbage collection in content processes for calls from our parent process.
However, this means we don't receive Release calls from in-process a11y clients.
For an Accessible, we get around this by explicitly disconnecting remote clients when the Accessible shuts down.
This doesn't cover COM objects which aren't interfaces of an Accessible; i.e. where the object has a different IUnknown to the Accessible.
This patch adds AccessibleWrap::AssociateCOMObjectForDisconnection to allow these objects to be tracked.
Tracked objects are then disconnected when the Accessible shuts down.
Differential Revision: https://phabricator.services.mozilla.com/D74999
Platform accessibles from proxies were not getting pruned. Also, there is no need
to walk up ancestors to find a pruning container since all pruning containers have direct
leaf children.
Differential Revision: https://phabricator.services.mozilla.com/D72482
This is something that was implemented a long time ago, but it isn't covered in any spec, other browsers don't implement it and I don't know of any usage in the wild.
This doesn't work with OOP iframes, since what we're doing here requires the documents to be in the same process.
Given it isn't used or specified, the simplest solution is to just remove the behaviour altogether.
Differential Revision: https://phabricator.services.mozilla.com/D74628
This depends on richlistitem's nsIDOMXULSelectControlItemElement::label implementation, which does the wrong thing in several cases.
We could make this use a11y name computation, but I can't find any other list box implementation that exposes accessible value on the list box itself, so I don't see any reason to keep this.
Differential Revision: https://phabricator.services.mozilla.com/D74372
This is not strictly related to this bug, but I'm touching the surrounding code and I've been confused by this on several occasions.
The previous comments suggested that NameFromAssociatedXULLabel (which uses XULLabelIterator) looks at child labels.
This is incorrect: XULLabelIterator only looks at <label control="id">.
The inclusion of child labels in the name comes from GetNameFromSubtree, which is called elsewhere.
Differential Revision: https://phabricator.services.mozilla.com/D74371
This was only used for richlistitems, but the richlistitem implementation of this property did the wrong thing in several cases.
The a11y engine's label computation code generally does a better job.
Where the label does need to be overridden in specific cases, we should use ARIA instead.
Differential Revision: https://phabricator.services.mozilla.com/D74370
As of bug 1621451 this argument was ignored, but it just silently runs your code with `python3` if you pass it anyway. Ensure this doesn't happen any more, and protect against any other unexpected arguments as well.
Differential Revision: https://phabricator.services.mozilla.com/D73485
`ply`, [by design](https://github.com/dabeaz/ply/issues/79), does not produce reproducible table files; hence bug 1633156. (Note that this was *always* true, but only became a problem once we switched to Python 3, which has more unpredictable dict iteration order than Python 2.7, at least prior to [3.7](https://docs.python.org/3/whatsnew/3.7.html#summary-release-highlights).)
In any other circumstance I would consider submitting a patch to `ply` to fix this, but as of the [in-progress version 4.0 of the library](https://github.com/dabeaz/ply/blob/master/CHANGES), it doesn't even emit this cached data any more, and indeed the [latest version of the code](1fac9fed64/ply) doesn't even call `open()` at all except to do logging or to read the text data to be parsed from `stdin`. So if we were going to pin our future on `ply` and upgrade to later versions of the library in the future, we would have to live in a world where `ply` doesn't generate cached table files for us anyway.
Emitting the cached table files so later build steps can consume them is an "optimization", but it's not clear exactly how much actual value that optimization provides overall. Quoth the `CHANGES` file from that repository:
```
PLY no longer writes cached table files. Honestly, the use of
the cached files made more sense when I was developing PLY on
my 200Mhz PC in 2001. It's not as much as an issue now. For small
to medium sized grammars, PLY should be almost instantaneous.
```
In practice, I have found this to be true; namely, `./mach build pre-export export` takes just about as long on my machine after this patch as it did before, and in a try push I performed, there's no noticeable performance regression from applying this patch. In local testing I also found that generating the LALR tables in calls to `yacc()` takes about 0.01s on my machine generally, and we generate these tables a couple dozen times total over the course of the `export` tier now. This isn't *nothing*, but in my opinion it's also not nearly long enough where it would be a concern given how long `export` already takes.
That `CHANGES` file also stresses that if caching this data is important, we have the option of doing so via `pickle`. If and when we decide that re-enabling this optimization is valuable for us, we should take control of this process and perform the generation in such a way that we can guarantee reproducibility.
Differential Revision: https://phabricator.services.mozilla.com/D73484
In-process iframes get a DocAccessibleChild, even though they're not top level in their process.
However, the parent IAccessible on DocAccessibleChild (sent from the parent process) is only relevant for the top level.
Previously, we used the parent IAccessible on the DocAccessibleChild for *all* documents, resulting in accParent returning null for in-process iframe documents.
Instead, we need to use the base implementation in this case.
Differential Revision: https://phabricator.services.mozilla.com/D74180
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
The code in mozAccessible SubRole was actually never executed for inputs, so the SearchField sub role was never set. Moved the implementation to mozTextAccessible. Also reenabled the tests from bug 1634373, which now pass.
Depends on D73308
Differential Revision: https://phabricator.services.mozilla.com/D73735
When an Accessible is removed, the AccGroupInfo for its siblings is marked dirty.
However, when AccGroupInfo::Update is called, it previously didn't clear mParent, which is used for the NODE_CHILD_OF relation.
This meant that if the conceptual group parent was removed and there was subsequently no conceptual parent, NODE_CHILD_OF would return an incorrect (potentially dead) Accessible.
Differential Revision: https://phabricator.services.mozilla.com/D73776
Fixes tooltips/menus in responsive design mode. A few accesibility tests
had to be adjusted since tooltips are now automatically created
for them.
Differential Revision: https://phabricator.services.mozilla.com/D72400
I also simplified mozTextLeafAccessible by redirecting value to title. And removing some dead methods. It previously was calling Text() on the text accessible, but this is not necessary since Name() returns
the same value.
Differential Revision: https://phabricator.services.mozilla.com/D72584
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
1. CleanupStaticIA2Data just called ReleaseStaticIA2DataInterfaces and zeroed memory.
We don't need it to zero memory, since we're going to delete the data anyway.
So, just call ReleaseStaticIA2DataInterfaces directly and get rid of CleanupStaticIA2Data.
2. CleanupDynamicIA2Data had a aZeroMemory argument, but no caller ever set it to true.
Therefore, get rid of the argument.
Differential Revision: https://phabricator.services.mozilla.com/D70297
This avoids separate cross-thread calls when marshaling each object returned from an IGeckoBackChannel bulk fetch method.
Differential Revision: https://phabricator.services.mozilla.com/D69485
This is the recommended role in the HTML Accessibility API Mappings draft[1].
Although Chrome and Safari just expose unlinked a tags as AXStaticText.
They also don't update the accessble if it gets an href. So while we
are doing this a bit differently, I think it is probably better. And VO is happy.
1. https://www.w3.org/TR/html-aam-1.0/#html-element-role-mappings
Differential Revision: https://phabricator.services.mozilla.com/D71260
I want to generalize it for other link stuff. Need a separate commit or
it is not recognized as a move, and won't retain history. For some reason.
Differential Revision: https://phabricator.services.mozilla.com/D71259
addA11yLoadEvent gets the contentWindow and wait for the document from that window to fire the load event.
Enabling the DocumentChannel for parent process load (or here in non-e10s mode) we have one extra event loop before the load starts.
So the window passed to addAllyLoadEvent would have been of the about:blank page.
The current code was based on an observable behaviour which was that the load was occuring synchronously.
DocumentChannel broke that assumption.
Differential Revision: https://phabricator.services.mozilla.com/D70799
We need it to live in BrowsingContext instead of WindowContext, because
we need to preserve the zoom level across same-origin navigation.
It'd be nice if it only lived in the top BC, but that's not possible at
the moment because a lot of tests rely on zooming only iframes. Some of
them can be adjusted for scaling the top instead, but not sure it's
worth it's worth fixing them and moving the zoom to be top-only, as it'd
be a bunch of effort, and the complexity and overhead of propagating the
zoom is not so big.
The print-preview-specific code in nsContentViewer is from before we did
the document cloning setup, and it seems useless. I've tested print
preview scaling before and after my patch and both behave the same.
The rest is just various test changes to use the SpecialPowers APIs or
BrowsingContext as needed instead of directly poking at the content
viewer.
I named the pres context hook RecomputeBrowsingContextDependentData, as
more stuff should move there like overrideDPPX and other media emulation
shenanigans.
I also have some ideas to simplify or even remove ZoomChild and such,
but that's followup work.
Differential Revision: https://phabricator.services.mozilla.com/D71969
When the tree is mutated, we set eGroupInfoDirty regardless of whether there is GroupInfo.
Previously, we cleared eGroupInfoDirty when updating GroupInfo, but not when creating it.
This meant that the flag was often still set, causing the cache to not be used a lot of the time.
Differential Revision: https://phabricator.services.mozilla.com/D72139
addA11yLoadEvent gets the contentWindow and wait for the document from that window to fire the load event.
Enabling the DocumentChannel for parent process load (or here in non-e10s mode) we have one extra event loop before the load starts.
So the window passed to addAllyLoadEvent would have been of the about:blank page.
The current code was based on an observable behaviour which was that the load was occuring synchronously.
DocumentChannel broke that assumption.
Differential Revision: https://phabricator.services.mozilla.com/D70799
In order for a form control to be labelled by an ancestor HTML label, its Accessible must return true for isWidget().
Also, HTML AAM says the text-input-type attribute should be exposed.
Differential Revision: https://phabricator.services.mozilla.com/D72080
We already skipped descendants for eNameFromSubtreeIfReqRule when the element wasn't labelled by something else; i.e. when calling GetNameFromSubtree.
However, when such an element is labelled/described by an ancestor, we compute the text equiv for the label using AppendTextEquivFromContent.
Previously, when descending from the ancestor down into the element itself, we would descend into its subtree despite eNameFromSubtreeIfReqRule.
This meant that groupings labelled/described by ancestor would include the content of the grouping itself in its label/description.
This was causing problems for time inputs (once those can accept an ancestor label in the next patch).
Differential Revision: https://phabricator.services.mozilla.com/D72079
addA11yLoadEvent gets the contentWindow and wait for the document from that window to fire the load event.
Enabling the DocumentChannel for parent process load (or here in non-e10s mode) we have one extra event loop before the load starts.
So the window passed to addAllyLoadEvent would have been of the about:blank page.
The current code was based on an observable behaviour which was that the load was occuring synchronously.
DocumentChannel broke that assumption.
Differential Revision: https://phabricator.services.mozilla.com/D70799
I want to generalize it for other link stuff. Need a separate commit or
it is not recognized as a move, and won't retain history. For some reason.
Differential Revision: https://phabricator.services.mozilla.com/D71259
