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
Per matrix discussion, this is safer to uplift (instead of relying on
the RedirectSink being released on the main thread).
Differential Revision: https://phabricator.services.mozilla.com/D91270
PreloaderBase -> RedirectSink -> PreloaderBase is a strong,
non-cycle-collected reference cycle, which in cases where we don't drop
the channel because we never get an NotifyStop notification, it can
cause leaks.
I'm investigating the root cause of the lack of NotifyStop, but this
should fix the leak and is correct anyhow.
Move the class to the cpp file to ease debugging and changes.
Differential Revision: https://phabricator.services.mozilla.com/D91259
Not just the one that takes a channel. This fixes the issue.
Also, as an optimization, avoid creating a timer if we're used already
or we have already one.
Differential Revision: https://phabricator.services.mozilla.com/D87267
Having two classes in the inheritance chain inherit from SupportsWeakPtr
now won't compile, but you can use WeakPtr<Derived> when any base class
inherits from SupportsWeakPtr.
Differential Revision: https://phabricator.services.mozilla.com/D83674
When we hit the stylesheet cache for an existing stylesheet in a
different document:
* There's no existing preload in the PreloadService (because the sheet
was loaded in another document).
* We don't create a PreloaderBase (because we don't trigger a load at
all).
* And thus we believe the load has just errored, which is wrong...
Fix it by properly passing through the "already complete" status from
PreloadStyle.
Note that there's still another issue, which is that we'd still hit this
broken path if two stylesheets with the same URI are loading in
different documents and the CSS loader coalesces them.
For that, I think we'd have to make SheetLoadData the thing that
actually implements PreloaderBase. This is kind of an obscure case, and
SheetLoadData has a pretty complex lifetime already (keeps alive a whole
lot of stuff), so I'd prefer to do this in a separate bug.
Differential Revision: https://phabricator.services.mozilla.com/D80289
We probably should remove the referrer policy check altogether in
bug 1642591, but the preload code still uses the whole referrer as the
key for css, which the css loader stopped doing in bug 1599160.
So this should be an uncontroversial simplification.
Differential Revision: https://phabricator.services.mozilla.com/D79810
I'm about to introduce the concept of "Loader principal" (as in "the
principal of the CSS loader"), and SheetLoadData already has an
mLoaderPrincipal.
However SheetLoadData's principal is just the triggering principal (the
principal that initiated the load). So name it that with consistency
with SheetInfo::mTriggeringPrincipal etc.
Differential Revision: https://phabricator.services.mozilla.com/D77613
Simon Giesecke
Ricky Stewart
Bogdan Tara
Dorel Luca
Emilio Cobos Álvarez
Barret Rennie
Razvan Maries
Kershaw Chang
Frederik Braun
Noemi Erli
Cameron McCormack
Honza Bambas
Geoff Lankow
Edgar Chen