This is not an error in the same way as a download failure, and should not be reported as one.
An Info message is sufficient.
Also suppress "unknown" location in messages about @font-face rules, as it is not useful,
pending a proper fix (bug 1450903).
Differential Revision: https://phabricator.services.mozilla.com/D50346
--HG--
extra : moz-landing-system : lando
We can end up in here from a style worker thread. But that's safe since
we only read data from the FontFaceSet, and the main thread is blocked
so writes can't happen underneath us.
Differential Revision: https://phabricator.services.mozilla.com/D44589
--HG--
extra : moz-landing-system : lando
ReferrerPolicy gets tossed back and forth as a uint32_t and
ReferrerPolicy enum in header file. Expose ReferrerPolicyValues from
webidl file and use consistently in native code.
Differential Revision: https://phabricator.services.mozilla.com/D41954
--HG--
extra : moz-landing-system : lando
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
--HG--
extra : moz-landing-system : lando
This doesn't clean up as much as a whole, but it's a step in the right
direction. In particular, it allows us to start using simple bindings for:
* Filters
* Shapes and images, almost. Need to:
* Get rid of the complex -moz- gradient parsing (let
layout.css.simple-moz-gradient.enabled get to release).
* Counters, almost. Need to:
* Share the Attr representation with Gecko, by not using Option<>.
* Just another variant should be enough (ContentItem::{Attr,Prefixedattr},
maybe).
Which in turn allows us to remove a whole lot of bindings in followups to this.
The setup changes a bit. This also removes the double pointer I complained about
while reviewing the shared UA sheet patches. The old setup is:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* UrlValueSource
* Arc<CssUrlData>
* load id
* resolved uri
* CORS mode.
* ...
```
The new one removes the double reference to the url data via URLValue, and looks
like:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* CorsMode
* LoadData
* load id
* resolved URI
```
The LoadData is the only mutable bit that C++ can change, and is not used from
Rust. Ideally, in the future, we could just use rust-url to resolve the URL
after parsing or something, and make it all immutable. Maybe.
I've verified that this approach still works with the UA sheet patches (via the
LoadDataSource::Lazy).
The reordering of mWillChange is to avoid nsStyleDisplay from going over the
size limit. We want to split it up anyway in bug 1552587, but mBinding gains a
tag member, which means that we were having a bit of extra padding.
One thing I want to explore is to see if we can abuse rustc's non-zero
optimizations to predict the layout from C++, but that's something to explore at
some other point in time and with a lot of care and help from Michael (who sits
next to me and works on rustc ;)).
Differential Revision: https://phabricator.services.mozilla.com/D31742
This doesn't clean up as much as a whole, but it's a step in the right
direction. In particular, it allows us to start using simple bindings for:
* Filters
* Shapes and images, almost. Need to:
* Get rid of the complex -moz- gradient parsing (let
layout.css.simple-moz-gradient.enabled get to release).
* Counters, almost. Need to:
* Share the Attr representation with Gecko, by not using Option<>.
* Just another variant should be enough (ContentItem::{Attr,Prefixedattr},
maybe).
Which in turn allows us to remove a whole lot of bindings in followups to this.
The setup changes a bit. This also removes the double pointer I complained about
while reviewing the shared UA sheet patches. The old setup is:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* UrlValueSource
* Arc<CssUrlData>
* load id
* resolved uri
* CORS mode.
* ...
```
The new one removes the double reference to the url data via URLValue, and looks
like:
```
SpecifiedUrl
* CssUrl
* Arc<CssUrlData>
* String
* UrlExtraData
* CorsMode
* LoadData
* load id
* resolved URI
```
The LoadData is the only mutable bit that C++ can change, and is not used from
Rust. Ideally, in the future, we could just use rust-url to resolve the URL
after parsing or something, and make it all immutable. Maybe.
I've verified that this approach still works with the UA sheet patches (via the
LoadDataSource::Lazy).
The reordering of mWillChange is to avoid nsStyleDisplay from going over the
size limit. We want to split it up anyway in bug 1552587, but mBinding gains a
tag member, which means that we were having a bit of extra padding.
One thing I want to explore is to see if we can abuse rustc's non-zero
optimizations to predict the layout from C++, but that's something to explore at
some other point in time and with a lot of care and help from Michael (who sits
next to me and works on rustc ;)).
Differential Revision: https://phabricator.services.mozilla.com/D31742
--HG--
extra : moz-landing-system : lando
Most of it is not used at this point, this leaves the parts that are used by
MathML, which are minimal.
Differential Revision: https://phabricator.services.mozilla.com/D31706
--HG--
extra : moz-landing-system : lando
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.