Per https://github.com/w3c/webappsec-secure-contexts/issues/42, the
section considering the window opener when calculating secure context is
to be dropped. Firefox already uses "isSecureContextIfOpenerIgnored" in
most places as this is the actual behavior we want. This patch aligns
with the upcoming spec changes by ignoring the window opener. We also no
longer have to keep information about whether our opener was secure as
that no longer factors in our calculations.
This allows us to fire MozMouseHittest events from tests and then read
the hittest result from the compositor APZTestData. The MozMouseHittest
event was chosen in particular because the existing uses of it are
similar in nature - it is a dummy event that is used to determine what
elements a particular coordinate targets. It is also an event that is
never generated by the OS and so using this event gives us more control
over what ends up in the APZTestData.
MozReview-Commit-ID: KHjIX7EpK2A
--HG--
extra : rebase_source : f7d7d729c1935eefd49ed06d8644ff9ef537f2e1
This reflects the change made to the Web Animations specification in:
9e2053f5531c3415f4cc
(I got it wrong the first time. The second commit fixes the first.)
And discussed in:
https://github.com/w3c/web-animations/issues/196
In summary, we are splitting the "pending" play state out into a separate
boolean member so that it is possible to distinguish between "play-pending" and
"pause-pending" and because most of the time when you check for
animation.playState === 'running' you also really want to include play-pending
animations.
MozReview-Commit-ID: IJSNoZTKW2I
--HG--
extra : rebase_source : 5d17239fd087cfe3cce1c9697eff97d062b6dd4b
This is necessary in order to capture the correct triggering principal for
inline <style> nodes.
MozReview-Commit-ID: 7g1n3bdHVi4
--HG--
extra : rebase_source : eb84775237e662f20112f54b148ef11005746950
This is necessary in order to capture the correct triggering principal for
inline <style> nodes.
MozReview-Commit-ID: 9EaD40vRNkH
--HG--
extra : rebase_source : cdd4a730f24dc57783edcf666ae803379c0d6173
This causes the subject principal that was responsible for setting a CSS
property, or the full cssText of an attribute, to be threaded through the call
chain to the point where CSS parsing happens, so that it can be used as the
triggering principal when loading URLs for that property.
Note that this allows for different properties defined in the same style
attribute to have different triggering principals, depending on the caller
which originally set them, as long as the cssText of that attribute is not
modified. Once it is, all properties revert to the principal of the caller
that modified the CSS text.
MozReview-Commit-ID: ISUyxbqAZMX
--HG--
extra : rebase_source : d4173d76d9afed74889269e3bf029abca54a4abb
The dom.forms.autocomplete.formautofill check in nsContentUtils::InternalSerializeAutocompleteAttribute
will control if values other than "on" and "off" are supported.
MozReview-Commit-ID: 48X3OzvuOpV
--HG--
rename : dom/html/test/forms/test_input_autocomplete.html => dom/html/test/forms/test_autocomplete.html
extra : rebase_source : b759672d2e9ef3b1e63fd999d149cf753df60539
It's not necessary to hide the implementation of the property since nsContentUtils::InternalSerializeAutocompleteAttribute
already does a pref check to decide whether values other than "on"/"off" are supported.
MozReview-Commit-ID: 4yG1tfOJavX
--HG--
extra : rebase_source : b58e600aab991eebf1c3f732fb432fb0aa6d47d7
Per https://github.com/w3c/webappsec-secure-contexts/issues/42, the
section considering the window opener when calculating secure context is
to be dropped. Firefox already uses "isSecureContextIfOpenerIgnored" in
most places as this is the actual behavior we want. This patch aligns
with the upcoming spec changes by ignoring the window opener. We also no
longer have to keep information about whether our opener was secure as
that no longer factors in our calculations.
--HG--
extra : rebase_source : 3d7fa73976571f357e84e369093aecfc10c5872e
extra : amend_source : ca86714f357b653577f3186b6312bfa00f1f45b9
ImageLoadingContent.currentURI returns the "URI" of currentRequest, which is
the URI used to start that request. Some consumers need to know the final URI
of that request instead.
If the image request gets redirected on loading (e.g. an add-on intercepts the
request), currentRequestFinalURI will be the redirected URI, while currentURI
would be the original URI before redirect.
MozReview-Commit-ID: 9lX063uAIp1
--HG--
extra : rebase_source : 91451128abc5c3f29c11d3cabfc98cde6c440ea6
We implemented v1.1 of the U2F specification, which wasn't publicly published
at the time. Bug 1276968 was to come back and fix those links, so here it is.
MozReview-Commit-ID: 8hprQncPwcO
ImageLoadingContent.currentURI returns the "URI" of currentRequest, which is
the URI used to start that request. Some consumers need to know the final URI
of that request instead.
If the image request gets redirected on loading (e.g. an add-on intercepts the
request), currentRequestFinalURI will be the redirected URI, while currentURI
would be the original URI before redirect.
MozReview-Commit-ID: 9lX063uAIp1
--HG--
extra : rebase_source : 6e9752b4df52e3874815557fe727c3fe94af2902
Bogdan Tara
Dan Minor
Tim Taubert
Nico Grunbaum
Brindusan Cristian
Chung-Sheng Fu
Olli Pettay
Kate McKinley
Edgar Chen
Kartikaya Gupta
Byron Campen [:bwc]
Dave Townsend
bechen@mozilla.com
Brian Birtles
Kris Maglione
shindli
Matthew Noorenberghe
Ciure Andrei
Adam Gashlin
Coroiu Cristina
Jesse Schwartzentruber
Samael Wang
Ben Kelly
Brad Werth
Edouard Oger
Boris Zbarsky
J.C. Jones
Andreas Pehrson
Luca Greco
Noemi Erli