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
Which is the spec term. nsIStyleSheetLinkingElement is even more
confusing since it may not be an element at all (see: processing
instructions).
Differential Revision: https://phabricator.services.mozilla.com/D76071
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
The cast in InitWithNode is wrong. AsElement() asserts instead of
checking the flag, so we always pass an element (and if we didn't we'd
have type confusion problems). I audited the callers and we're fine.
Anyhow, always require an element, and add two convenience constructors
for C++ code.
Differential Revision: https://phabricator.services.mozilla.com/D73636
Emilio Cobos Álvarez
Narcis Beleuzu
Ricky Stewart
Bogdan Tara
Dorel Luca
Cameron McCormack
Simon Giesecke
Sean Feng
Frederik Braun
Butkovits Atila
Andrea Marchesini
Csoregi Natalia
Noemi Erli
Razvan Maries
Honza Bambas
Cosmin Sabou
Zibi Braniecki