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
Also move MOZ_MUST_USE before function declarations' specifiers and return type. While clang and gcc's __attribute__((warn_unused_result)) can appear before, between, or after function specifiers and return types, the [[nodiscard]] attribute must precede the function specifiers.
Differential Revision: https://phabricator.services.mozilla.com/D71713
This change adds support for canceling CSS transitions when a property
is no longer transitionable or when an element becomes styled with
display:none. Support for canceling and replacing CSS transitions when
the end value changes is still pending. This change also takes advantage
of updating the constellation message to fix a bug where transition
events could be sent for closed pipelines.
Cherry-picked from https://github.com/servo/servo/pull/26244
(though this is not part of the Gecko build).
This intermediate data structure doesn't really buy us anything and is a
bit confusing.
Cherry-picked from https://github.com/servo/servo/pull/26214
(though this is not part of the Gecko build).
RuleTree::gc is now a safe method that any thread can call
at any time, and StrongRuleNode values can all be dropped
whenever their owner want to, on any thread.
Cherry-picked from https://github.com/servo/servo/pull/26227
These styles will produce no change in the layout, and only apply in
high contrast mode.
Also removed an extra comma that broke parsing in aurora.
Differential Revision: https://phabricator.services.mozilla.com/D72070
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
When starting a load via the ParentProcessDocumentChannel, the event http-on-modify-request will be fired before the DocumentLoadListener has a chance to set the notificationCallback attribute.
When using a DocumentChannel, this test will not trigger the expected codepath as the DOMWindowCreated event will be fired once the channel is fully up and running; which in effect is also a fix of the original bug 1339722
Instead we use the document-on-modify-request event when the DocumentChannel is enabled.
Differential Revision: https://phabricator.services.mozilla.com/D70011
Some tests rely on this event to start action. The DocumentChannel had no equivalent. We make the ParentProcessDocumentChannel listen to this event and if it matches the nsIChannel currently in use in the DocumentLoadListener than we emit a similar document-on-modify-request event on the DocumentChannel.
Differential Revision: https://phabricator.services.mozilla.com/D70010
Add ParentProcessDocumentChannel object. This object is a DocumentChannel that will start a channel load from the parent process via a DocumentChannel.
The aim of this task is two-fold.
1- Be consistent on how we handle redirects before continuing the load on the final channel.
2- Prepare to initiate a process switch when needed without having to go via an intermediary content process, saving a process switch. This task will be done in a follow-up task.
The behaviour of the ParentProcessDocumentChannel is similar in logic to the DocumentChannelChild/DocumentChannelParent pair.
The ParentProcessDocumentChannel sets up a DocumentLoadListener, have it handle the redirects and upon completion continue the load on the final channel.
Differential Revision: https://phabricator.services.mozilla.com/D70009
We must wait for the iframe created by extension1 to be fully loaded before we can attempt to send a message to it.
So we send a message when it is ready, and suspend the execution until this message is received.
Differential Revision: https://phabricator.services.mozilla.com/D70008
The code assumed that nsJARChannel::RetargetDeliveryTo would have been called synchronously from nsJARChannel::OnStartRequest, which would be true if we weren't using a DocumentChannel.
The DocumentLoadListener queue the calls to OnStartRequest until the final redirect.
nsJARChannel::RetargetDelivery mRequest member is be set to forward the call.
So we need to only reset it once OnStopRequest has been received.
Differential Revision: https://phabricator.services.mozilla.com/D70007
The DocumentLoadListener is setting up a ParentChannelListener to go in between the normal listener->channel chain.
ParentChannelListener not implementing nsIThreadRetargetableStreamListener would prevent a nsHtml5StreamParser settings things up so that OnDataAvailable could be sent to a html parser thread off the main thread; improving performance.
Differential Revision: https://phabricator.services.mozilla.com/D70006
Following the changes to DocumentChannel the test was failing.
With DC, a load may take a few event loops to start. This current test was only waiting for the load to start to the URL about:preferences#privacy-logins and would immediately tear down the window.
However, this URL redirects to about:preferences#privacy ; destroying the window midway could cause XML parsing error.
So now we wait for the page to fully load, and make sure we've been through both addresses.
Differential Revision: https://phabricator.services.mozilla.com/D70003
This also removes the need to call SerializeRedirectData to set mRedirectChannelId to the proper value and register the channel.
Differential Revision: https://phabricator.services.mozilla.com/D69998
This will correctly handle the case of "display:grid" or "display:flex" being
added or removed from the Element frame right before the call to
getGridFragments or getAsFlexContainer on the Element.
Differential Revision: https://phabricator.services.mozilla.com/D71806
