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
