This is a brand new (and first) DAMP talos test for accessibility panel. "accessibility.cold-open" is similar to other cold open tests such as inspector one. It opens accessibility panel, waits for its UI to render and then closes the toolbox.
Differential Revision: https://phabricator.services.mozilla.com/D80512
On a new machine the instructions didn't fully work for me. I suspect that `libpulse-dev:i686` -> `i386` might have been a typo, and I also needed `libx11-xcb-dev:i386`.
Differential Revision: https://phabricator.services.mozilla.com/D81560
Because jar_maker is not in the libs tier, we also rename the libs-%
targets for l10n repacks to l10n-%, which make it clearer what they are
for.
And because multilocale.txt is both a GeneratedFile and a file that is
generated (and installed) via manual build rules, keeping it in the misc
target actually breaks building in toolkit/locales during l10n repacks,
so move it to libs for now.
Differential Revision: https://phabricator.services.mozilla.com/D81766
Use universal_newlines as a convenient way of treating the process I/O as text,
so string read/writes continue to succeed under python 3.
Differential Revision: https://phabricator.services.mozilla.com/D81774
Note that on Chrome table-row-pagination-001-print.html doesn't generate the
second page at least in the print preview. The second page is actually just a
blank page, but the height of a table element in the test is `160%` so that
there should be overflowed area from the first page.
It may be possible that it's an optimization in Chrome to reduce paper
consumption, but the second page in the reference, it's also a blank page, is
generated in the print preview, so I suppose it's either a bug or an
inconsistent optimization in Chrome.
Differential Revision: https://phabricator.services.mozilla.com/D81635
When focusing the urlbar after a non-whitelisted host is visited, we add the
trimmed protocol in front of it, because otherwise modifying the url and then
resubmitting may end up searching. Due to that, it's possible the value is not
trimmed when we build the clipboard string.
Differential Revision: https://phabricator.services.mozilla.com/D81537
It's incorrect to use childFrame's next sibling to check whether we have
more children since we iterate the children with respect to the CSS
'order' property.
Rather than creating a new flex line immediately, we keep a boolean when
a flex item requested "break-after", and create a new flex in the next
iteration.
Differential Revision: https://phabricator.services.mozilla.com/D81283
I added this slot as a quick fix because I was not confident of when exactly
the script stepper count would be incremented or decremented. Now that the
lifecycle of DebuggerFrame is centralized and standardized in a sensible way,
we no longer need it because we can infer the state of the increment from the
state of the frame itself.
Differential Revision: https://phabricator.services.mozilla.com/D80742
The lifecycle of a DebuggerFrame has been really hard to follow, so this
patch aims to centralize all of that handling by making it clear exactly
how a DebuggerFrame is terminated.
Secondly, this patch adds OOM guards to a bunch of places that previously
would have caused DebuggerFrame instances to persist in the "frames"
and/or "generatorFrames" list, or even worse, leave the Generator observer
count and script stepper count incremented unexpectedly.
Differential Revision: https://phabricator.services.mozilla.com/D80741
This patch waits to remove the frame from the "from" map until after it has
been added to the "to" map, so that we can rely on the existing scope guard
to clean up any frames if we get an OOM.
Differential Revision: https://phabricator.services.mozilla.com/D80740
There's no reason to create this FrameIter over and over again inside the loop.
Similarly, ensureExecutionObservabilityOfFrame is a no-op if
"frame.isDebuggee()", and slowPathOnResumeFrame asserts that to be true, so
there is no reason to ensure observability here because it already is
guaranteed.
Differential Revision: https://phabricator.services.mozilla.com/D80739
It is difficult to follow the overall lifecycle of entries in the
generatorFrames list when it is mutated in many places across many files.
This patch's primary aim is to begin centralizing the handling of this
map a little bit by keeping it all inside Debugger.cpp so that the
DebuggerFrame instance itself does not actually care whether it is found
in that map.
Differential Revision: https://phabricator.services.mozilla.com/D80738
It is guaranteed that this will already be populated because in 1539654 we
started properly preserving the debuggee-ness of frames across suspend and
resume. With slowPathOnResumeFrame guaranteed to run, we no longer need to
try to hande handle the case where the generator has been resumed, but
the Debugger.Frame's inner data was not populated.
Differential Revision: https://phabricator.services.mozilla.com/D80735
Exposing frameIterData() and setFrameIterData() isn't great since it makes it
harder to follow what state transitions for frame data we expect the frame
to have. By hiding this, it helps clarify that frame data can be cleared
or replaced, but public usage of the FrameIter::Data object itself isn't
expected outside of the class itself.
Differential Revision: https://phabricator.services.mozilla.com/D80734
The core issue is that we run removeFromFrameMapsAndClearBreakpointsIn(cx, from)
even for non-OOM paths in this function, which is undesirable because that will
remove the breakpoints for evaled scripts. In the non-OOM case there are no
Debugger.Frame objects left in the frames map for the "frame" list, so there
is no reason to actually call it in that case.
This patch merges the two OOM handlers together for simplicity, though it
is not technically necessary, it seems like the very minor increase in code
run if there is an OOM is worth it to keep things centralized.
Differential Revision: https://phabricator.services.mozilla.com/D80762
The only fallout from part 1 is a single test where we run `evaluateJS` on a session, serialize it to a `Parcel`,
deserialize it to new, distinct `GeckoSession` object, and then perform additional `evaluateJS` on the latter.
Since the deserialization of the `Parcel` transferred the session's contents from the original session to the new
session, we also need to transfer the `WebExtension.Port` used by `evaluateJS` to the new session.
Note that this fix is kind of hacky, but because we are going to deprecate the parcelability of `GeckoSession`, I
do not believe that it is worth the effort to implement a "perfect" fix; that would likely involve adding new APIs
to support another API that we are going to deprecate anyway.
Depends on D81746
Differential Revision: https://phabricator.services.mozilla.com/D81748
Because `GeckoSession`'s overrides of `hashCode` and `equals` look solely at session ID, this may cause
strange behaviors if a `GeckoSession` is reloaded with session state from a previous instance, and the
previous instance still exists. For example, suppose the previous instance is closed and the new instance is
open. As far as the Android runtime is concerned, both objects are equivalent. Trying to insert both objects
into the same container will not work as expected.
In this patch, we revert those overrides. To ensure that we still have a short-circuit path in
`GeckoView.restoreSession`, we add and utilize a new, `package`-scoped, `equalsId` method.
Differential Revision: https://phabricator.services.mozilla.com/D81746
We only allow drops from descendant frames into ancestors if they're same
origin anyway, which implies same-process, but outside of Fission, we allow
cross-origin interstitial frames, whereas with Fission we currently don't due
to our walking the ancestor tree using GetInProcessParentDocument.
Differential Revision: https://phabricator.services.mozilla.com/D80081
The only fallout from part 1 is a single test where we run `evaluateJS` on a session, serialize it to a `Parcel`,
deserialize it to new, distinct `GeckoSession` object, and then perform additional `evaluateJS` on the latter.
Since the deserialization of the `Parcel` transferred the session's contents from the original session to the new
session, we also need to transfer the `WebExtension.Port` used by `evaluateJS` to the new session.
Note that this fix is kind of hacky, but because we are going to deprecate the parcelability of `GeckoSession`, I
do not believe that it is worth the effort to implement a "perfect" fix; that would likely involve adding new APIs
to support another API that we are going to deprecate anyway.
Depends on D81746
Differential Revision: https://phabricator.services.mozilla.com/D81748
Because `GeckoSession`'s overrides of `hashCode` and `equals` look solely at session ID, this may cause
strange behaviors if a `GeckoSession` is reloaded with session state from a previous instance, and the
previous instance still exists. For example, suppose the previous instance is closed and the new instance is
open. As far as the Android runtime is concerned, both objects are equivalent. Trying to insert both objects
into the same container will not work as expected.
In this patch, we revert those overrides. To ensure that we still have a short-circuit path in
`GeckoView.restoreSession`, we add and utilize a new, `package`-scoped, `equalsId` method.
Differential Revision: https://phabricator.services.mozilla.com/D81746
Depending on how MozillaBuild is invoked, python may think that the drive letter is a different case.
Since some paths are saved between builds in "config.status", this inconsistency can cause issues.
Though this patch doesn't solve the underlying inconsistency, it resolves the crash that was occurring.
Differential Revision: https://phabricator.services.mozilla.com/D81738
When aborting the current load, media element is undoubtedly inaudible. Therefore, we should reset its audible state in order to keep the audible state correct. That can help us show the sound indicator on the tab bar correctly.
Differential Revision: https://phabricator.services.mozilla.com/D81631
