Only GeckoMVMContext really needs the flush, to measure scrolled height
afterwards. Do that explicitly.
This shouldn't change behavior, for the most part; there was a preload
test that relied on the flush when changing DPI to start a run really
clean, but other than that this looks green on try.
Should at best be neutral (just code clean-up), or be a performance
improvement.
In a follow-up, we can possibly remove the DelayedResize code from the
view manager, though I need to think how to possibly coalesce the MVM
reflows, so let's not do that yet.
Differential Revision: https://phabricator.services.mozilla.com/D155385
Only GeckoMVMContext really needs the flush, to measure scrolled height
afterwards. Do that explicitly.
This shouldn't change behavior, for the most part; there was a preload
test that relied on the flush when changing DPI to start a run really
clean, but other than that this looks green on try.
Should at best be neutral (just code clean-up), or be a performance
improvement.
In a follow-up, we can possibly remove the DelayedResize code from the
view manager, though I need to think how to possibly coalesce the MVM
reflows, so let's not do that yet.
Differential Revision: https://phabricator.services.mozilla.com/D155385
This removes HTMLMenuItemElement and all the code and tests preffed off
by dom.menuitem.enabled.
The HTML parser changes are the result of applying the previous patch.
Differential Revision: https://phabricator.services.mozilla.com/D149979
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
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
We were calling XML_GetCurrentColumnNumber after ParseBuffer caused Expat
to consume some data. XML_GetCurrentColumnNumber uses the buffer that was
last passed to Expat. Before Expat was put in an RLBox sandbox the caller
of ParseBuffer would keep the data in the scanner string until after the
call to XML_GetCurrentColumnNumber. Now that we copy the data into the
RLBox sandbox the data is freed when the TransferBuffer in ParseBuffer
goes out of scope, so in the caller of ParseBuffer the call to
XML_GetCurrentColumnNumber would cause us to read freed memory inside the
sandbox. Moving the call to XML_GetCurrentColumnNumber to inside
ParseBuffer, when TransferBuffer is still in scope, solves the issue.
Differential Revision: https://phabricator.services.mozilla.com/D141795
In particular, gather telemetry to evaluate the impact of unlabeled UTF-8
and how detector-triggered reloads would change if ASCII-only at initial
guess was treated as UTF-8.
Differential Revision: https://phabricator.services.mozilla.com/D140818
This removes the pref `security.csp.enable` and amends various callers
in dom/, which no longer have to take this pref into consideration.
Furthermore, we can remove the test in dom/base/test/browser_bug593387.js
The test used the pref to test that external content can be embedded into
about:plugins, which is historic baggage from a previous architecture of
said page that we no longer require. It's also an anti-pattern that we
do not want to support any longer. In fact, the test had to jump through
additional hoops to make that work at all.
Differential Revision: https://phabricator.services.mozilla.com/D138661
Emilio Cobos Álvarez
Cristian Tuns
Tom Schuster
Marian-Vasile Laza
Fabrice Desré
Andreea Pavel
Mark Banner
smolnar
Iulian Moraru
Joel Maher
Sebastian Hengst
Kris Maglione
Henri Sivonen
Peter Van der Beken
Randell Jesup
Noemi Erli
Butkovits Atila
Frederik Braun