gecko-dev/layout/style/nsDOMCSSDeclaration.cpp

412 lines
13 KiB
C++
Raw Normal View History

/* -*- Mode: C++; tab-width: 8; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim: set ts=8 sts=2 et sw=2 tw=80: */
2012-05-21 11:12:37 +00:00
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
/* base class for DOM objects for element.style and cssStyleRule.style */
#include "nsDOMCSSDeclaration.h"
#include "mozilla/DeclarationBlock.h"
#include "mozilla/StyleSheetInlines.h"
#include "mozilla/css/Rule.h"
#include "mozilla/dom/CSS2PropertiesBinding.h"
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
#include "mozilla/dom/MutationEventBinding.h"
#include "nsCSSProps.h"
#include "nsCOMPtr.h"
#include "mozAutoDocUpdate.h"
#include "nsIURI.h"
#include "mozilla/dom/BindingUtils.h"
#include "nsContentUtils.h"
#include "nsQueryObject.h"
#include "mozilla/layers/ScrollLinkedEffectDetector.h"
using namespace mozilla;
nsDOMCSSDeclaration::~nsDOMCSSDeclaration() = default;
/* virtual */ JSObject*
Bug 1117172 part 3. Change the wrappercached WrapObject methods to allow passing in aGivenProto. r=peterv The only manual changes here are to BindingUtils.h, BindingUtils.cpp, Codegen.py, Element.cpp, IDBFileRequest.cpp, IDBObjectStore.cpp, dom/workers/Navigator.cpp, WorkerPrivate.cpp, DeviceStorageRequestChild.cpp, Notification.cpp, nsGlobalWindow.cpp, MessagePort.cpp, nsJSEnvironment.cpp, Sandbox.cpp, XPCConvert.cpp, ExportHelpers.cpp, and DataStoreService.cpp. The rest of this diff was generated by running the following commands: find . -name "*.h" -o -name "*.cpp" | xargs perl -pi -e 'BEGIN { $/ = undef } s/(WrapObjectInternal\(JSContext *\* *(?:aCx|cx|aContext|aCtx|js))\)/\1, JS::Handle<JSObject*> aGivenProto)/g' find . -name "*.h" -o -name "*.cpp" | xargs perl -pi -e 'BEGIN { $/ = undef } s/(WrapObjectInternal\((?:aCx|cx|aContext|aCtx|js))\)/\1, aGivenProto)/g' find . -name "*.h" -o -name "*.cpp" | xargs perl -pi -e 'BEGIN { $/ = undef } s/(WrapNode\(JSContext *\* *(?:aCx|cx|aContext|aCtx|js))\)/\1, JS::Handle<JSObject*> aGivenProto)/g' find . -name "*.h" -o -name "*.cpp" | xargs perl -pi -e 'BEGIN { $/ = undef } s/(WrapNode\((?:aCx|cx|aContext|aCtx|js))\)/\1, aGivenProto)/g' find . -name "*.h" -o -name "*.cpp" | xargs perl -pi -e 'BEGIN { $/ = undef } s/(WrapObject\(JSContext *\* *(?:aCx|cx|aContext|aCtx|js))\)/\1, JS::Handle<JSObject*> aGivenProto)/g' find . -name "*.h" -o -name "*.cpp" | xargs perl -pi -e 'BEGIN { $/ = undef } s/(Binding(?:_workers)?::Wrap\((?:aCx|cx|aContext|aCtx|js), [^,)]+)\)/\1, aGivenProto)/g'
2015-03-19 14:13:33 +00:00
nsDOMCSSDeclaration::WrapObject(JSContext* aCx, JS::Handle<JSObject*> aGivenProto)
{
return dom::CSS2Properties_Binding::Wrap(aCx, this, aGivenProto);
}
NS_IMPL_QUERY_INTERFACE(nsDOMCSSDeclaration,
nsICSSDeclaration)
nsresult
nsDOMCSSDeclaration::GetPropertyValue(const nsCSSPropertyID aPropID,
nsAString& aValue)
{
MOZ_ASSERT(aPropID != eCSSProperty_UNKNOWN,
"Should never pass eCSSProperty_UNKNOWN around");
aValue.Truncate();
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
if (DeclarationBlock* decl =
GetOrCreateCSSDeclaration(eOperation_Read, nullptr)) {
decl->GetPropertyValueByID(aPropID, aValue);
}
return NS_OK;
}
nsresult
nsDOMCSSDeclaration::SetPropertyValue(const nsCSSPropertyID aPropID,
const nsAString& aValue,
nsIPrincipal* aSubjectPrincipal)
{
switch (aPropID) {
case eCSSProperty_background_position:
case eCSSProperty_background_position_x:
case eCSSProperty_background_position_y:
case eCSSProperty_transform:
case eCSSProperty_top:
case eCSSProperty_left:
case eCSSProperty_bottom:
case eCSSProperty_right:
case eCSSProperty_margin:
case eCSSProperty_margin_top:
case eCSSProperty_margin_left:
case eCSSProperty_margin_bottom:
case eCSSProperty_margin_right:
case eCSSProperty_margin_inline_start:
case eCSSProperty_margin_inline_end:
case eCSSProperty_margin_block_start:
case eCSSProperty_margin_block_end:
mozilla::layers::ScrollLinkedEffectDetector::PositioningPropertyMutated();
break;
default:
break;
}
if (aValue.IsEmpty()) {
// If the new value of the property is an empty string we remove the
// property.
return RemovePropertyInternal(aPropID);
}
return ParsePropertyValue(aPropID, aValue, false, aSubjectPrincipal);
}
void
nsDOMCSSDeclaration::GetCssText(nsAString& aCssText)
1998-11-26 01:34:53 +00:00
{
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
DeclarationBlock* decl = GetOrCreateCSSDeclaration(eOperation_Read, nullptr);
aCssText.Truncate();
if (decl) {
decl->ToString(aCssText);
}
1998-11-26 01:34:53 +00:00
}
void
nsDOMCSSDeclaration::SetCssText(const nsAString& aCssText,
nsIPrincipal* aSubjectPrincipal,
ErrorResult& aRv)
1998-11-26 01:34:53 +00:00
{
// We don't need to *do* anything with the old declaration, but we need
// to ensure that it exists, or else SetCSSDeclaration may crash.
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
RefPtr<DeclarationBlock> created;
DeclarationBlock* olddecl =
GetOrCreateCSSDeclaration(eOperation_Modify, getter_AddRefs(created));
if (!olddecl) {
aRv.Throw(NS_ERROR_NOT_AVAILABLE);
return;
}
// For nsDOMCSSAttributeDeclaration, SetCSSDeclaration will lead to
// Attribute setting code, which leads in turn to BeginUpdate. We
// need to start the update now so that the old rule doesn't get used
// between when we mutate the declaration and when we set the new
// rule (see stack in bug 209575).
mozAutoDocUpdate autoUpdate(DocToUpdate(), true);
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
DeclarationBlockMutationClosure closure = {};
MutationClosureData closureData;
GetPropertyChangeClosure(&closure, &closureData);
ParsingEnvironment servoEnv =
GetParsingEnvironment(aSubjectPrincipal);
if (!servoEnv.mUrlExtraData) {
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
if (created) {
// In case we can't set a new declaration, but one was
// created for the old one, we need to set the old declaration to
// get right style attribute handling.
SetCSSDeclaration(olddecl, &closureData);
}
aRv.Throw(NS_ERROR_NOT_AVAILABLE);
return;
}
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
// Need to special case closure calling here, since parsing css text
// doesn't modify any existing declaration and that is why the callback isn't
// called implicitly.
if (closureData.mClosure) {
closureData.mClosure(&closureData);
}
RefPtr<DeclarationBlock> newdecl =
DeclarationBlock::FromCssText(aCssText, servoEnv.mUrlExtraData,
servoEnv.mCompatMode, servoEnv.mLoader);
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
aRv = SetCSSDeclaration(newdecl, &closureData);
1998-11-26 01:34:53 +00:00
}
uint32_t
nsDOMCSSDeclaration::Length()
{
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
DeclarationBlock* decl = GetOrCreateCSSDeclaration(eOperation_Read, nullptr);
if (decl) {
return decl->Count();
}
return 0;
}
void
nsDOMCSSDeclaration::IndexedGetter(uint32_t aIndex, bool& aFound, nsAString& aPropName)
{
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
DeclarationBlock* decl = GetOrCreateCSSDeclaration(eOperation_Read, nullptr);
aFound = decl && decl->GetNthProperty(aIndex, aPropName);
}
NS_IMETHODIMP
nsDOMCSSDeclaration::GetPropertyValue(const nsAString& aPropertyName,
nsAString& aReturn)
{
aReturn.Truncate();
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
if (DeclarationBlock* decl =
GetOrCreateCSSDeclaration(eOperation_Read, nullptr)) {
decl->GetPropertyValue(aPropertyName, aReturn);
}
return NS_OK;
}
void
nsDOMCSSDeclaration::GetPropertyPriority(const nsAString& aPropertyName,
nsAString& aPriority)
{
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
DeclarationBlock* decl = GetOrCreateCSSDeclaration(eOperation_Read, nullptr);
aPriority.Truncate();
if (decl && decl->GetPropertyIsImportant(aPropertyName)) {
aPriority.AssignLiteral("important");
}
}
NS_IMETHODIMP
nsDOMCSSDeclaration::SetProperty(const nsAString& aPropertyName,
const nsAString& aValue,
const nsAString& aPriority,
nsIPrincipal* aSubjectPrincipal)
{
if (aValue.IsEmpty()) {
// If the new value of the property is an empty string we remove the
// property.
// XXX this ignores the priority string, should it?
return RemovePropertyInternal(aPropertyName);
}
// In the common (and fast) cases we can use the property id
nsCSSPropertyID propID = nsCSSProps::LookupProperty(aPropertyName);
if (propID == eCSSProperty_UNKNOWN) {
return NS_OK;
}
bool important;
if (aPriority.IsEmpty()) {
important = false;
} else if (aPriority.EqualsLiteral("important")) {
important = true;
} else {
// XXX silent failure?
return NS_OK;
}
if (propID == eCSSPropertyExtra_variable) {
return ParseCustomPropertyValue(aPropertyName, aValue, important,
aSubjectPrincipal);
}
return ParsePropertyValue(propID, aValue, important, aSubjectPrincipal);
}
NS_IMETHODIMP
nsDOMCSSDeclaration::RemoveProperty(const nsAString& aPropertyName,
nsAString& aReturn)
{
nsresult rv = GetPropertyValue(aPropertyName, aReturn);
NS_ENSURE_SUCCESS(rv, rv);
return RemovePropertyInternal(aPropertyName);
}
/* static */ nsDOMCSSDeclaration::ParsingEnvironment
nsDOMCSSDeclaration::GetParsingEnvironmentForRule(const css::Rule* aRule)
{
StyleSheet* sheet = aRule ? aRule->GetStyleSheet() : nullptr;
if (!sheet) {
return { nullptr, eCompatibility_FullStandards, nullptr };
}
if (nsIDocument* document = sheet->GetAssociatedDocument()) {
return {
sheet->URLData(),
document->GetCompatibilityMode(),
document->CSSLoader(),
};
}
return {
sheet->URLData(),
eCompatibility_FullStandards,
nullptr,
};
}
template<typename Func>
nsresult
nsDOMCSSDeclaration::ModifyDeclaration(nsIPrincipal* aSubjectPrincipal,
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
MutationClosureData* aClosureData,
Func aFunc)
{
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
RefPtr<DeclarationBlock> created;
DeclarationBlock* olddecl =
GetOrCreateCSSDeclaration(eOperation_Modify, getter_AddRefs(created));
if (!olddecl) {
return NS_ERROR_NOT_AVAILABLE;
}
// For nsDOMCSSAttributeDeclaration, SetCSSDeclaration will lead to
// Attribute setting code, which leads in turn to BeginUpdate. We
// need to start the update now so that the old rule doesn't get used
// between when we mutate the declaration and when we set the new
// rule (see stack in bug 209575).
mozAutoDocUpdate autoUpdate(DocToUpdate(), true);
RefPtr<DeclarationBlock> decl = olddecl->EnsureMutable();
bool changed;
ParsingEnvironment servoEnv =
GetParsingEnvironment(aSubjectPrincipal);
if (!servoEnv.mUrlExtraData) {
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
if (created) {
// In case we can't set a new declaration, but one was
// created for the old one, we need to set the old declaration to
// get right style attribute handling.
SetCSSDeclaration(olddecl, aClosureData);
}
return NS_ERROR_NOT_AVAILABLE;
}
changed = aFunc(decl, servoEnv);
if (!changed) {
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
if (created) {
// See comment above about setting old declaration.
SetCSSDeclaration(olddecl, aClosureData);
}
// Parsing failed -- but we don't throw an exception for that.
return NS_OK;
}
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
return SetCSSDeclaration(decl, aClosureData);
}
nsresult
nsDOMCSSDeclaration::ParsePropertyValue(const nsCSSPropertyID aPropID,
const nsAString& aPropValue,
bool aIsImportant,
nsIPrincipal* aSubjectPrincipal)
{
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
DeclarationBlockMutationClosure closure = {};
MutationClosureData closureData;
GetPropertyChangeClosure(&closure, &closureData);
return ModifyDeclaration(
aSubjectPrincipal,
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
&closureData,
[&](DeclarationBlock* decl, ParsingEnvironment& env) {
NS_ConvertUTF16toUTF8 value(aPropValue);
return Servo_DeclarationBlock_SetPropertyById(
decl->Raw(), aPropID, &value, aIsImportant, env.mUrlExtraData,
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
ParsingMode::Default, env.mCompatMode, env.mLoader, closure);
});
}
nsresult
nsDOMCSSDeclaration::ParseCustomPropertyValue(const nsAString& aPropertyName,
const nsAString& aPropValue,
bool aIsImportant,
nsIPrincipal* aSubjectPrincipal)
{
MOZ_ASSERT(nsCSSProps::IsCustomPropertyName(aPropertyName));
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
DeclarationBlockMutationClosure closure = {};
MutationClosureData closureData;
GetPropertyChangeClosure(&closure, &closureData);
return ModifyDeclaration(
aSubjectPrincipal,
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
&closureData,
[&](DeclarationBlock* decl, ParsingEnvironment& env) {
NS_ConvertUTF16toUTF8 property(aPropertyName);
NS_ConvertUTF16toUTF8 value(aPropValue);
return Servo_DeclarationBlock_SetProperty(
decl->Raw(), &property, &value, aIsImportant, env.mUrlExtraData,
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
ParsingMode::Default, env.mCompatMode, env.mLoader, closure);
});
}
nsresult
nsDOMCSSDeclaration::RemovePropertyInternal(nsCSSPropertyID aPropID)
{
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
DeclarationBlock* olddecl =
GetOrCreateCSSDeclaration(eOperation_RemoveProperty, nullptr);
if (!olddecl) {
return NS_OK; // no decl, so nothing to remove
}
// For nsDOMCSSAttributeDeclaration, SetCSSDeclaration will lead to
// Attribute setting code, which leads in turn to BeginUpdate. We
// need to start the update now so that the old rule doesn't get used
// between when we mutate the declaration and when we set the new
// rule (see stack in bug 209575).
mozAutoDocUpdate autoUpdate(DocToUpdate(), true);
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
DeclarationBlockMutationClosure closure = {};
MutationClosureData closureData;
GetPropertyChangeClosure(&closure, &closureData);
RefPtr<DeclarationBlock> decl = olddecl->EnsureMutable();
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
if (!decl->RemovePropertyByID(aPropID, closure)) {
return NS_OK;
}
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
return SetCSSDeclaration(decl, &closureData);
}
nsresult
nsDOMCSSDeclaration::RemovePropertyInternal(const nsAString& aPropertyName)
{
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
DeclarationBlock* olddecl =
GetOrCreateCSSDeclaration(eOperation_RemoveProperty, nullptr);
if (!olddecl) {
return NS_OK; // no decl, so nothing to remove
}
// For nsDOMCSSAttributeDeclaration, SetCSSDeclaration will lead to
// Attribute setting code, which leads in turn to BeginUpdate. We
// need to start the update now so that the old rule doesn't get used
// between when we mutate the declaration and when we set the new
// rule (see stack in bug 209575).
mozAutoDocUpdate autoUpdate(DocToUpdate(), true);
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
DeclarationBlockMutationClosure closure = {};
MutationClosureData closureData;
GetPropertyChangeClosure(&closure, &closureData);
RefPtr<DeclarationBlock> decl = olddecl->EnsureMutable();
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
if (!decl->RemoveProperty(aPropertyName, closure)) {
return NS_OK;
}
Bug 1428246 - The attributeChangedCallback is fired twice for the *first* style attribute change, r=peterv 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
2018-06-26 09:54:00 +00:00
return SetCSSDeclaration(decl, &closureData);
}