Summary: Really sorry for the size of the patch. It's mostly automatic
s/nsIDocument/Document/ but I had to fix up in a bunch of places manually to
add the right namespacing and such.
Overall it's not a very interesting patch I think.
nsDocument.cpp turns into Document.cpp, nsIDocument.h into Document.h and
nsIDocumentInlines.h into DocumentInlines.h.
I also changed a bunch of nsCOMPtr usage to RefPtr, but not all of it.
While fixing up some of the bits I also removed some unneeded OwnerDoc() null
checks and such, but I didn't do anything riskier than that.
The clamping is intended to be a safeguard against extreme values in the
meta viewport tag. If the layout viewport is sized to the display size,
avoid the clamping, since the display size could legitimately be small
(e.g. in Android 8's picture-in-picture mode).
Differential Revision: https://phabricator.services.mozilla.com/D15605
--HG--
extra : moz-landing-system : lando
There's no guarantee a backend exists when a MediaManager does, and
crash-stats shows that shutdown can occur between posting a task and running
it, making it illegal to create a backend anew.
We're safer off avoiding creating a new backend. The cleanup step we're trying
to do is only effective if a backend already exists anyway.
Differential Revision: https://phabricator.services.mozilla.com/D15631
--HG--
extra : moz-landing-system : lando
These tests have always been skipped silently. Now that https tests are
enabled to actually run, we find that some (all?) actually fail on Android:
now explicitly skipped to allow for green runs of tier 1 suites.
The guts of MemoryReportRequestClient's supporting runnables contain
switches on the particular type of process we're running. If you're
bringing up a new process type, having to add extra cases for your
process type here is a bit onerous. These runnables really shouldn't
know anything about the process types that they're running on, either.
The easiest thing to do is modify MemoryReportRequestClient::Start to
take callbacks for what to do when a report is created and when
reporting is finished. Then all process-specific knowledge can be
pushed out to the clients themselves, leaving MemoryReportRequestClient
and friends process-type agnostic. We could even, at some later date,
move this code into xpcom/base/ to sit near nsMemoryReporterManager,
where it belongs.
Make the WindowProxyHolder hold a strong reference to a BrowsingContext, as in the future
we might not have a nsPIDOMWindowOuter (if the document is loaded in a different process).
Differential Revision: https://phabricator.services.mozilla.com/D12651
--HG--
extra : moz-landing-system : lando
Add a WindowProxyHolder type and generate binding code that takes or returns it whenever
the WebIDL refers to the WindowProxy type. This patch just makes the WindowProxyHolder
hold a strong reference to a nsPIDOMWindowOuter.
Differential Revision: https://phabricator.services.mozilla.com/D12650
--HG--
extra : moz-landing-system : lando
Verify that the script URI is not null before using it.
If it's the case, we can't really continue because that url
identifies the worker in the metrics.
Differential Revision: https://phabricator.services.mozilla.com/D15187
--HG--
extra : moz-landing-system : lando
Andrea Marchesini
Emilio Cobos Álvarez
Daniel Varga
Jon Coppeard
Olli Pettay
Tom Schuster
Jan de Mooij
Botond Ballo
Andreas Pehrson
Bogdan Tara
Jorg K
Geoff Brown
Nathan Froyd
longsonr
Daniel Holbert
James Willcox
Peter Van der Beken
Andrew McCreight
Tarek Ziadé
Narcis Beleuzu
Boris Zbarsky