And also this patch moves some related methods which use the inline methods
and member variables used only by them.
Differential Revision: https://phabricator.services.mozilla.com/D29201
--HG--
rename : layout/base/nsIPresShellInlines.h => layout/base/PresShellInlines.h
extra : moz-landing-system : lando
Just one set of stylesheets is enough. While at it, unify SheetType and Origin.
Differential Revision: https://phabricator.services.mozilla.com/D27564
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
This makes `Document::GetShell()` return `PresShell*` instead of `nsIPresShell`.
Additonally, "shell" is unclear ("docshell" vs. "presshell"). Therefore, this
also renames `Document::GetShell()` to `Document::GetPresShell()`.
Similarly, some other method names of `Document` are also renamed from
`*Shell*` to `*PresShell*`.
Differential Revision: https://phabricator.services.mozilla.com/D25338
--HG--
extra : moz-landing-system : lando
We can get back the fancy flag syntax as soon as we get C++17 inline variables,
which I sent an email to dev-platform@ about, with no reply.
Differential Revision: https://phabricator.services.mozilla.com/D22382
--HG--
extra : moz-landing-system : lando
clang's -Wmissing-prototypes option identifies global functions that can be made static (because they're only called from one compilation unit) or removed (if they're never called).
layout/painting/FrameLayerBuilder.cpp:2593:6 [-Wmissing-prototypes] no previous prototype for function 'ReleaseLayerUserData'
layout/painting/RetainedDisplayListBuilder.cpp:1084:6 [-Wmissing-prototypes] no previous prototype for function 'FindContainingBlocks'
layout/style/FontFaceSet.cpp:423:6 [-Wmissing-prototypes] no previous prototype for function 'IsPdfJs'
layout/svg/SVGObserverUtils.cpp:969:6 [-Wmissing-prototypes] no previous prototype for function 'DestroyFilterProperty'
Differential Revision: https://phabricator.services.mozilla.com/D21851
--HG--
extra : rebase_source : 7b876a976087eef710ff70ca0ae42abb3c505e49
extra : histedit_source : 4254fd49e36bef38bbb6197861a4a22e040d17e0
Replacing js and text occurences of asyncOpen2
Replacing open2 with open
Differential Revision: https://phabricator.services.mozilla.com/D16885
--HG--
rename : layout/style/test/test_asyncopen2.html => layout/style/test/test_asyncopen.html
extra : moz-landing-system : lando
Copy fonts loaded during a mozPrintCallback into the cloned document,
so they are available during printing.
Differential Revision: https://phabricator.services.mozilla.com/D18613
--HG--
extra : moz-landing-system : lando
When the FontFaceSet gets unlinked, we remove the strong pointer it holds to to
the UserFontSet.
This is not strictly necessary, since that object will no longer have any
reference to any other cycle collected object.
In any case, the loaders keep alive the user font entries, which _don't_ keep
alive the user font set (they have a weak reference instead). So if the user
font set is gone, all is bad.
Ensure we cancel all loads when unlinking rather than just when the object is
destroyed, and that the font face loader doesn't keep a reference to the user
font entry anymore after being canceled (this shouldn't be necessary either, but
it's better IMO).
Differential Revision: https://phabricator.services.mozilla.com/D18256
--HG--
extra : moz-landing-system : lando
And start tracking the loader ASAP to be on the safe side.
Both sides already take care of cleaning up pointers on destruction.
Differential Revision: https://phabricator.services.mozilla.com/D16514
--HG--
extra : moz-landing-system : lando
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.
Copy over non-rule font faces to the static clone document that is used
during printing.
MozReview-Commit-ID: 8ggNrCcVpEK
--HG--
extra : rebase_source : 27e270edd28c3ecf19a99f4df5398a89e6c53e6a
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
This rearranges how synthetic-bold use is determined in the font selection
& rendering code. Previously, we would decide during the font-selection
algorithm whether we need to apply synthetic-bold to the chosen face, and
then pass that decision through the fontgroup (storing it in the FamilyFace
entries of the mFonts array there) down to the actual rendering code that
instantiates fonts from the faces (font entries) we've selected.
That became a problem for variation fonts because in the case of a user
font, we may not have downloaded the resource yet, so we just have a "user
font container" entry, which carries the descriptors from the @font-face
rule and will fetch the actual resource when needed. But in the case of a
@font-face rule without a weight descriptor, we don't actually know at
font-selection time whether the face will support "true" bold (via a
variation axis) or not, so we can't reliably make the right decision about
applying synthetic bold.
So we now defer that decision until we actually instantiate a platform font
object to shape/measure/draw text. At that point, we have the requested
style and we also have the real font resource, so we can easily determine
whether fake-bold is required.
(This patch should not result in any visible behavior change; that will
come in a second patch now that the architecture supports it.)
