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
I spent some time looking into this, and the Linux runs when opening up the
popup and the private browser are not working consistently. The popupshown
and popuphidden events are not firing consistently. It's probably good enough
to just disable this test on Linux, as it's mainly a UI test, and it works
on the other platforms.
Differential Revision: https://phabricator.services.mozilla.com/D81602
Some intermittents were caused by the failure to ensure the popup was closed.
This patch creates a new API that explicitly ensures that the popup is actually
closed in the patch.
It also adds a listener to the popupshown and popuphidden events dispatched by
the XUL elements to ensure that we're not just relying on a single requestAnimationFrame
tick.
Differential Revision: https://phabricator.services.mozilla.com/D79332
This adds 3 new profiler markers for each IPC message:
* One just before the first byte is sent over the IPC channel
* One just after the last byte is sent over the IPC channel
* One just after the last byte is received from the IPC channel
With the already-existing IPC markers (for when SendXXX and RecvXXX are
called), this allows us to calculate the following statistics:
* Send thread latency
* IPC send duration
* IPC recv latency
* Recv thread latency
For more information on how this is presented in the UI, see:
<https://github.com/firefox-devtools/profiler/pull/2535>.
Differential Revision: https://phabricator.services.mozilla.com/D70790
bc's original patch, but restricted to py3 (py2 already works - no need to change it!). I also updated
the six imports to suit my preference.
Differential Revision: https://phabricator.services.mozilla.com/D81561
Makes `sourceId` available in the `resource.message` object for log points from 'resourceWatcher' to better address sources than only by `fileName`.
Differential Revision: https://phabricator.services.mozilla.com/D80642
Sentry is initialized globally, but it's not clear to consumers when this actually happens.
For example, an unwary developer may call report_exception() within check_and_get_mach(),
not knowing that Sentry hasn't been initialized yet.
Using a class should make the dependency on register_sentry() more verbose.
Depends on D80913
Differential Revision: https://phabricator.services.mozilla.com/D80918
Hiroyuki Ikezoe
Marco Bonardo
Ting-Yu Lin
Logan Smyth
Gabriel Luong
caroline
Tiger Oakes
Cosmin Sabou
Aaron Klotz
Kris Maglione
Mitchell Hentges
Honza Bambas
Magnus Melin
alwu
Jared Wein
Greg Tatum
Junior Hsu
Zeke Medley
Nihanth Subramanya
Jim Porter
David Walsh
Geoff Brown
Stepan Stava
longsonr
Michael Cooper
Hubert Boma Manilla