There's no reason to ask GL since we should know the answers.
Also GL is tricky on how it handles these semi-deprecated queries.
Official GL stance is "don't ask questions you know the answer to".
MozReview-Commit-ID: F7p73eSTrYw
This patch basically does:
* remove StyleSetHandle and its corresponding files
* revisit #includes of related header files and change correspondingly
* change nsIPresShell::mStyleSet to be UniquePtr<ServoStyleSet>
* change the creating path of ServoStyleSet to pass UniquePtr
* change other mentions of StyleSetHandle to ServoStyleSet*
* remove AsServo() calls on ServoStyleSet
Some unfortunate bits:
* some methods of (Servo)StyleSet only accepts ServoStyleSheet while
many places call into the methods with StyleSheet, so there are many
->AsServo() added to sheets
MozReview-Commit-ID: K4zYnuhOurA
--HG--
extra : rebase_source : 459e8efeb171adad089d94272e143e8c244bd279
extra : source : 65ba2f174fcf7dba4e59c00ee8908b1bd0820a48
"unqualified friend declaration referring to type outside of the nearest enclosing
namespace is a Microsoft extension; add a nested name specifier
[-Wmicrosoft-unqualified-friend]"
GetStyleContext can flush. As such, that flush can kill the pres shell, and the
return value could be null. I have no idea why that code was asserting it didn't
happen, but that assert is completely bogus.
Throw instead, just like GetFontParentStyleContext used to do for Gecko.
MozReview-Commit-ID: 5RxDratKumZ
--HG--
extra : rebase_source : 9ffb1f58888504d92915ecd4254847ae2e3f053b
The canvas prompt is extremely annoying. It happens everyone, automatically. And in
99.9% (not scientific) of cases it is not triggered by user input, but my automatic
tracking scripts.
This commit will automatically decline the canvas read if it was not triggered by
user input.
Just in case this breaks something irrepairably, we have a cutoff pref.
We don't intend to keep this pref forever, and have asked anyone who sets it to
tell us why.
MozReview-Commit-ID: CxNkuraRWpV
--HG--
extra : rebase_source : 12cfc94cecbd378c0859ae50066c6338bcaa6692
The only relevant spec reference unfortunately is for color parsing[1], which
mentions:
> Otherwise, set color to the computed value of the 'color' property of element.
Using IsInComposedDoc there should be fine, since the computed style of an
element is well defined there.
The rest look like implementation limitations, for which should not be an issue
to extend the check for the composed doc.
[1]: https://html.spec.whatwg.org/#parsed-as-a-css-color-value
MozReview-Commit-ID: ADnVPNqf3X1
--HG--
extra : rebase_source : ea72f695afe86820d2d04c2b8eca1d17bc356a71
Everyone calls them with the shell of the current composed document, and this
allows the multi-presShell stuff to just be in UpdateCurrentStyleSources /
DoGetStyleContextNoFlush.
The only reason we need to use OwnerDoc()->GetShell() instead of the composed
doc in GetStyleContext / GetStyleContextNoFlush is Element::GetBindingURL, which
does expect to get the binding URL for stuff outside of the composed doc (and
changing that gave me a useless browser).
That's technically a behavior change on the cases that used to pass nullptr, but
I think all callers are fine with that. I could also just add a special function
for that particular case, it may be worth it.
MozReview-Commit-ID: 2XlnkgdgDCK
Jeff Gilbert
Cosmin Sabou
shindli
Tom Ritter
Xidorn Quan
Jonathan Watt
Tim Nguyen
Emilio Cobos Álvarez
arthur.iakab
Miko Mynttinen
sotaro
Sylvestre Ledru
Csoregi Natalia
Brindusan Cristian
Andrea Marchesini
Lee Salzman
Andreea Pavel
Christian Holler
Adrian Wielgosik
Xidorn Quan