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
Offset in a node is declared as "unsigned long" by the standards and we don't
limit node can have less than `INT32_MAX`. So it should return `uint32_t`, but
it also needs to represent the case of "not found". For consistency with some
other APIs like `nsContentUtils::ComparePoints`, using `Maybe` must be a good
style rather than `Result<uint32_t, bool>`.
This patch fixes the callers in assertions for example.
Differential Revision: https://phabricator.services.mozilla.com/D131335
It's hard to fix some callers. Therefore, in this bug, we should fix only
simple cases. Therefore, we should rename existing API first.
Differential Revision: https://phabricator.services.mozilla.com/D131334
And fix existing users of course.
The frame loader one is the only one slightly scary (but if it causes
trouble we could make nsObjectLoadingContent::Unlink a no-op).
Differential Revision: https://phabricator.services.mozilla.com/D107269
As it won't after that if something flushes (because
FlushPendingNotifications will just ignore the flush if the sink is no
longer a document observer).
Otherwise we might not notify of some document insertions, and that
might reasonably confuse layout if it has started before.
The reason we don't have more similar crashes seems to be two different
things:
* That in the crashtest, the custom element triggers a partial parser
flush via the innerHTML setter while the parser is creating the
element. That causes the parser to flush the previous text node
(which tells layout to go look under the <body> for children) but
unless we FlushTags() once we're done we won't know about the
custom-element child.
* That there's no end tag for the <body> or <html> nodes, so we don't
reach this code when we end them:
https://searchfox.org/mozilla-central/rev/df23c6e58c6be1eb8399e475878f73d4867bef87/dom/xml/nsXMLContentSink.cpp#1041-1047
Differential Revision: https://phabricator.services.mozilla.com/D106421
This matches other browsers, and common sense to some extent.
The code is a bit awkward because I want this behind a pref for now, as
it's not precisely a zero-risk change.
Differential Revision: https://phabricator.services.mozilla.com/D95065
This matches other browsers, and common sense to some extent.
The code is a bit awkward because I want this behind a pref for now, as
it's not precisely a zero-risk change.
Differential Revision: https://phabricator.services.mozilla.com/D95065
This matches other browsers, and common sense to some extent.
The code is a bit awkward because I want this behind a pref for now, as
it's not precisely a zero-risk change.
Differential Revision: https://phabricator.services.mozilla.com/D95065
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Make some ad-hoc manual updates to `testing/marionette/client/setup.py`, `testing/marionette/harness/setup.py`, and `testing/firefox-ui/harness/setup.py`, which have hard-coded regexes that break after the reformat.
5. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
Allow-list all Python code in tree for use with the black linter, and re-format all code in-tree accordingly.
To produce this patch I did all of the following:
1. Make changes to tools/lint/black.yml to remove include: stanza and update list of source extensions.
2. Run ./mach lint --linter black --fix
3. Make some ad-hoc manual updates to python/mozbuild/mozbuild/test/configure/test_configure.py -- it has some hard-coded line numbers that the reformat breaks.
4. Add a set of exclusions to black.yml. These will be deleted in a follow-up bug (1672023).
# ignore-this-changeset
Differential Revision: https://phabricator.services.mozilla.com/D94045
This changes the way we deal with page use counters so that we can
handle out of process iframes.
Currently, when a parent document is being destroyed, we poke into all
of the sub-documents to merge their use counters into the parent's page
use counters, which we then report via Telemetry. With Fission enabled,
the sub-documents may be out of process. We can't simply turn these
into async IPC calls, since the parent document will be destroyed
shortly, as might the content processes holding the sub-documents.
So instead, each document during its initialization identifies which
ancestor document it will contribute its page use counters to, and
stores its WindowContext id to identify that ancestor. A message is
sent to the parent process to notify it that page use counter data will
be sent at some later point. That later point is when the document
loses its window. It doesn't matter if the ancestor document has
already been destroyed at this point, since all we need is its
WindowContext id to uniquely identify it. Once the parent process has
received all of the use counters it expects to accumulate to a given
WindowContext Id, it reports them via Telemetry.
Reporting of document use counters remains unchanged and is done by each
document in their content process.
While we're here, we also:
* Limit use counters to be reported for a pre-defined set of document
URL schemes, rather than be based on the document principal.
* Add proper MOZ_LOG logging for use counters instead of printfs.
Differential Revision: https://phabricator.services.mozilla.com/D87188
This ensures that styles from UA widgets apply. Turns out they look
pretty much right without them, but there's a bug in nsDateTimeBoxFrame
where we rely on the styles in order for the baseline to be sensible.
Differential Revision: https://phabricator.services.mozilla.com/D91616
This ensures that styles from UA widgets apply. Turns out they look
pretty much right without them, but there's a bug in nsDateTimeBoxFrame
where we rely on the styles in order for the baseline to be sensible.
Differential Revision: https://phabricator.services.mozilla.com/D91616
Unlike other engine vendors, we process meta elements
at parser, instead of when they are inserted. This
leads some web compact issues.
This patch aligns us with other vendors.
Differential Revision: https://phabricator.services.mozilla.com/D84545
This changes the UA widget setup (again). What is going on in this
test-case is that we have a marquee inside a video, two things that have
their own UA widget. Given how the code is currently written, the
runnable to attach and set up the marquee's widget is posted before than
the video one (which is potentially reasonable).
However that means that the marquee one runs before and flushes layout,
and catches the video in an inconsistent state (in the composed doc, but
without a shadow root). That in turn messes up reflow because
nsVideoFrame assumes stuff.
Rather than putting the attach / detach logic in script runners, just
run that bit synchronously, and post only the event async. I audited the
consumers of those events and it seems fine to me, they either already
deal with the possibility of the shadow root being already detached or
they don't care.
For teardown, none of the destructors of the UA widgets rely on the
shadow root being still attached to the element.
Differential Revision: https://phabricator.services.mozilla.com/D84487
This changes the UA widget setup (again). What is going on in this
test-case is that we have a marquee inside a video, two things that have
their own UA widget. Given how the code is currently written, the
runnable to attach and set up the marquee's widget is posted before than
the video one (which is potentially reasonable).
However that means that the marquee one runs before and flushes layout,
and catches the video in an inconsistent state (in the composed doc, but
without a shadow root). That in turn messes up reflow because
nsVideoFrame assumes stuff.
Rather than putting the attach / detach logic in script runners, just
run that bit synchronously, and post only the event async. I audited the
consumers of those events and it seems fine to me, they either already
deal with the possibility of the shadow root being already detached or
they don't care.
For teardown, none of the destructors of the UA widgets rely on the
shadow root being still attached to the element.
Differential Revision: https://phabricator.services.mozilla.com/D84487
Kris Maglione
Marian-Vasile Laza
Kagami Sascha Rosylight
Tom Ritter
Peter Van der Beken
Shane Hughes
Henri Sivonen
Masayuki Nakano
Andrew McCreight
Edgar Chen
Sean Feng
Valentin Gosu
Emilio Cobos Álvarez
Simon Giesecke
Andi-Bogdan Postelnicu
Narcis Beleuzu
Ricky Stewart
Bogdan Tara
Dorel Luca
Cameron McCormack
Frederik Braun