I wrote this patch by first removing UNIFIED_ from layout/style/moz.build, and
then rebuilding, and then addressing build errors one by one.
Nearly all of the build errors were for using the "Document" type without a
proper namespace, and I've addressed this by sprinkling "using namespace"
declarations in the affected .cpp files (and removing a few now-unnecessary
dom:: prefixes on types in those files).
The only other errors were for WorkletGlobalScope.h which needed an #include to
provide the type "DOMHighResTimeStamp", and nsHTMLStyleSheet.h which needed a
forward-declaration for the type "mozilla::dom::Document".
Differential Revision: https://phabricator.services.mozilla.com/D22767
--HG--
extra : moz-landing-system : lando
Add comments and property check for the caller of ActivityTracker.
Depends on D19525
Differential Revision: https://phabricator.services.mozilla.com/D19632
--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.
This has no behavior change, since it just expands to
NS_IMPL_QUERY_TAIL_INHERITING, but it's clearer, and clang-format understands
it.
Also, these are the only uses of this macro, so I don't think we should make
clang-format understand it.
Differential Revision: https://phabricator.services.mozilla.com/D15125
--HG--
extra : moz-landing-system : lando
This matches all other browsers, and the spec.
Added an explicit test for this, and a test that tests what
cssstyledeclaration-mutationrecord-002.html wanted to test, which is that
changing an existing declaration doesn't generate a mutation record.
Differential Revision: https://phabricator.services.mozilla.com/D8500
--HG--
rename : testing/web-platform/tests/css/cssom/cssstyledeclaration-mutationrecord-002.html => testing/web-platform/tests/css/cssom/cssstyledeclaration-mutationrecord-005.html
extra : moz-landing-system : lando
For each file touched in this patch, the file had an #include for nsContentUtils.h, but no other mentions of the string "nsContentUtils", nor any mention of its "ScriptBlocker"-related types. So these files likely don't need their nsContentUtils.h include anymore, and we can remove it to get a marginal win on build time/complexity.
Differential Revision: https://phabricator.services.mozilla.com/D3370
--HG--
extra : moz-landing-system : lando
The idea with this patch is that style code will first call
InlineStyleDeclarationWillChange before style declaration has changed, and SetInlineStyleDeclaration once it has changed.
In order to be able to report old attribute value, InlineStyleDeclarationWillChange reads the value and also calls AttributeWillChange (so that DOMMutationObserser can grab the old value). Later SetInlineStyleDeclaration passes the old value to
SetAttrAndNotify so that mutation events and attributeChanged callbacks are handled correctly.
Because of performance, declaration can't be cloned for reading the old value. And that is why the recently-added callback is used to detect when declaration is about to change (bug 1466963 and followup bug 1468665).
To keep the expected existing behavior, even if declaration isn't changed, but just a new declaration was created (since there wasn't any), we need to still run all these
willchange/set calls. That is when the code has 'if (created)' checks.
Since there are several declaration implementation and only nsDOMCSSAttributeDeclaration needs the about-to-change callback, GetPropertyChangeClosure is the one to initialize the callback closure, and the struct which is then passes as data to the closure.
Apparently we lost mutation event testing on style attribute when the pref was added, so test_style_attr_listener.html is modified to test both pref values.
--HG--
extra : rebase_source : 9e605d43f22e650ac3912fbfb41abb8d5a2a0c8f
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
This patch was generated automatically by the "modeline.py" script, available
here: https://github.com/amccreight/moz-source-tools/blob/master/modeline.py
For every file that is modified in this patch, the changes are as follows:
(1) The patch changes the file to use the exact C++ mode lines from the
Mozilla coding style guide, available here:
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#Mode_Line
(2) The patch deletes any blank lines between the mode line & the MPL
boilerplate comment.
(3) If the file previously had the mode lines and MPL boilerplate in a
single contiguous C++ comment, then the patch splits them into
separate C++ comments, to match the boilerplate in the coding style.
MozReview-Commit-ID: EuRsDue63tK
--HG--
extra : rebase_source : 3356d4b80ff6213935192e87cdbc9103fec6084c
At first I thought that the problem was related to this bug, so I wrote this.
I think it's worth landing.
MozReview-Commit-ID: G6UKp5l5STm
--HG--
extra : rebase_source : 576c2add36e822d3adf281d91cde44303aa5c051
It was inconsistent with gecko side and also we needed to pass nsCompatibility enum along with URLExtraData.
MozReview-Commit-ID: 2ceutBfqBrg
--HG--
extra : rebase_source : f342774ed349c65f377cf85865f5905520784ca5
