Bug 1333990 added the ability to have multiple parser blockers at the same
time, so we no longer need to guard against recursively blocking. What's more,
if we do, and skip calling `BlockParser` while it's blocked for another reason,
we still call `UnblockParser` when we receive script data, at which point we
crash.
This patch moves the XHTML parser's behavior closer in line with the HTML
parser's.
The only way I've seen this manifest as a bug is when we have an XHTML
document with a top-level <script> element, and an extension with content
scripts that cause us to block parsing when we see that top-level element and
need to wait for them to compile.
Differential Revision: https://phabricator.services.mozilla.com/D145513
Since we don't encode the output, the resulting value is a `bytes`
and therefore using `"="` to split results in a `TypeError`.
Add a specified encoding to force a `str` and fix the exception.
Differential Revision: https://phabricator.services.mozilla.com/D145881
It seems that where there is an expression of the form vecN_scalar OP float, and
friend operators OP(vecN_scalar, vecN_scalar) or OP(vecN, Float) are defined, the
compiler can't appropriately decide which implicit conversions to use to dispatch
to one operator or the other and considers them ambiguous. Add a few more friend
operators that catch these vecN_scalar OP float cases where they were missing
definitions.
Differential Revision: https://phabricator.services.mozilla.com/D145824
Our scrollbar drawing code had various RTL checks for the writing mode.
These checks were busted since bug 1554571 (where the writing-mode of
the scrollbar frames and so on is reset). However, they also wouldn't be
correct (we allow to customize scrollbar position via pref).
Instead, look at the scrollable frame to really know if the scrollbar is
on the right or not. Compute that once in Theme.cpp and pass it around
light we were doing for the "is horizontal" bit.
Differential Revision: https://phabricator.services.mozilla.com/D145865
My previous patch for bug 1755570 contained an oversight that caused
problems when deleting history downloads' target files. This patch just
adds a minimal data removal method to the history download prototype,
so the DownloadElementShell methods can execute without exceptions.
Differential Revision: https://phabricator.services.mozilla.com/D145279
This used to be used to get access to the server from the host, but
hasn't been needed since we set up port forwarding using adb.
Differential Revision: https://phabricator.services.mozilla.com/D145135
Looks fairly ugly in HiDPI, and release doesn't have shadows either, so it's
probably fine.
This allows me to clean-up -moz-window-shadow, as with bug 1768278 this is the
last use in the tree.
Differential Revision: https://phabricator.services.mozilla.com/D145819
Probably, the editor's bug has already been fixed in bug 1724650 which makes
`HTMLEditor` and `WhiteSpaceVisibilityKeeper` handle white-spaces of
`white-space: pre-*` correctly. Therefore, once Thunderbird or some other
MUAs which uses Gecko as its mail composer specify `white-space: pre-wrap`,
at least the editor will work as users expected.
This patch just adds automated tests for avoiding the regressions in Gecko-side.
Differential Revision: https://phabricator.services.mozilla.com/D145817
The initialization itself can take some time and this audibility event is used
to prioritize the process, that will soon become audible, on at least Windows,
so it's better to get prioritized slightly ahead of time.
We should eventually untie audibility from priorities, but this hasn't happened
yet. Instead, we should make it so silent audio for an extended period of time
causes a shutdown of the cubeb stream, it's a lot more efficient.
Differential Revision: https://phabricator.services.mozilla.com/D145328
On Windows (in particular, but also not quick on other OS, depending on the
hardware being used), opening a system-level audio stream (using cubeb)
can be very long. It's a blocking call from the MDSM thread. The MDSM can't
query the clock and update video frames while the stream is being opened,
resulting in the video freezing.
On the other hand, we don't want the clock starting to increase while first
starting the media, it's better to block the MDSM in this case.
This patch changes `AudioSinkWrapper::StartAudioSink` to have two modes:
- A synchronous mode for the first opening (and therefore for seeking, etc.)
- An asynchronous mode to use when the stream is unmuted: the AudioSinkWrapper
will continue to use a clock based on the system clock, until the system-level
audio stream is effectively opened, at which point it will switch to using it
for the clock.
This new mode does the initialization on a background thread, but starts the
system-level audio stream from the MDSM thread (it's fast enough and simplifies
the code a lot).
The promises are created synchronously, because this is what the MDSM expects,
but they are rejected in case of failure.
Finally, an edge case is handled: if the stream is stopped while it's being
opened asynchronously. This is detected, and instead of starting the
system-level audio stream, the stream is shut down.
Differential Revision: https://phabricator.services.mozilla.com/D145000
No change in functionality, this is to prepare for the next patch that will do
the initialization asynchronously because it's expensing and blocking.
Differential Revision: https://phabricator.services.mozilla.com/D144999
Kagami Sascha Rosylight
Luca Greco
Morgan Reschenberg
Kris Maglione
Molly Howell
Connor Sheehan
Marian-Vasile Laza
Katherine Patenio
mcheang
stransky
Dimi
Boris Chiou
Lee Salzman
Emilio Cobos Álvarez
Shane Hughes
Harveer Singh
Norisz Fay
Mike Kaply
Cosmin Sabou
James Graham
Amy Churchwell
Bas Schouten
Dmitrij Feller
Byron Campen
William Durand
Masayuki Nakano
Ben Hearsum
ffxbld
Mathieu Leplatre
Paul Adenot