This changes semantics in all sorts of ways (e.g. now we get the right proto
from our |this| value instead of it being baked into the function). But if all
our chrome callers are well-behaved this should be ok.
We _could_ bake the proto id and depth into the function itself by using
js::NewFunctionWithReserved if it were not for Xrays. Those already need the
reserved slots on functions we Xray.
MozReview-Commit-ID: 1bYrKWWIc1P
Right now we do this check pretty much always anyway for isInstance... we do it
twice for anything that actually has [ChromeOnly] bits.
MozReview-Commit-ID: FHbYED4FPJe
This patch basically does:
* Add descriptor setters and generation count to CounterStyleRule in
Servo. (This code is mostly based on the old code inside
nsCSSCounterStyleRule for handling mutation.)
* Use RawServoCounterStyleRule in CounterStyleManager.
* Add ServoCounterStyleRule and remove nsCSSCounterStyleRule.
Test change:
* "fixed" was parsed as and thus serialized to "fixed 1", but Servo
doesn't do so. It preserves whether the number presents. Either way
is probably fine.
MozReview-Commit-ID: EtKTeu32isi
--HG--
extra : rebase_source : ec44f01c581003ce4b6ef69435a05de7f3da5469
This patch does the following things:
* Create a new class ServoFontFaceRule for CSSOM of @font-face rule
which mostly follows how nsCSSFontFaceRule was implemented.
* Remove the old nsCSSFontFaceRule and binding code to create it.
* Have FontFace backed by Servo data via making mRule and mDescriptors
of the class hold RawServoFontFaceRule like ServoFontFaceRule.
To keep this patch small, it effectively just delays the conversion
from Servo data to nsCSSValue from parsing to using. This may cause
worse performance if the font set is flushed repeatedly. Supposing we
don't flush font set very frequently, it may not be a big deal.
We may still want to remove the intermediate nsCSSValue conversion at
some point, and have everything converted to their final form directly
when used, but that can happen in followups.
There are some unfortunate bits from this change:
* We lose style sheet for logging in FontFaceSet. This is probably not
all that worse, because we wouldn't have that before either if the
page doesn't use CSSOM to visit it. But we should figure out some
approach to fix it anyway.
* InspectorFontFace no longer shares the same rule object as CSSOM.
This isn't really a problem if the @font-face rule isn't very mutable.
Unless we want to make the rule returned from InspectorFontFace to be
mutable (i.e. via inspector), not using the same object probably isn't
too bad.
This patch switches the code we use to serialize stuff in FontFace and
CSSFontFaceRule, which leads to some failures in tests. Specifically,
the expected changes including:
* Value of font-family now can be serialized to identifier sequence like
font-family property. The old code always serializes it to string,
but it doesn't seem to have different requirement than the property.
Blink can serialize to identifier as well.
* Family name inside local() is also changed to use the same way as
family names elsewhere (i.e. can be identifier sequence). Blink has
the same behavior as the old code, but I don't think it's a big deal.
* The order of descriptors serialized gets changed. I don't think it
matters at all.
* Empty string as font-family via using string syntax is no longer
considered invalid for FontFace. I don't find it is mentioned anywhere
that it should be specifically treated invalid.
MozReview-Commit-ID: 32Fk3Fi9uTs
--HG--
extra : rebase_source : 6221ec8fc56de357b06dd27e770fb175348a2f77
NullPrincipal::Create() (will null OA) may cause an OriginAttributes bypass.
We change Create() so OriginAttributes is no longer optional, and rename
Create() with no arguments to make it more explicit about what the caller is doing.
MozReview-Commit-ID: 7DQGlgh1tgJ
This fixes an observable bug we had due to doing the steps in a different order
from the spec: the 'prototype' get can have side-effects so needs to happen
after some of the other sanity checks.
MozReview-Commit-ID: 83zNhqfqFRu
The codegen changes are mostly a backout of the changes made in bug 1274159.
The HTMLConstructor implementation is mostly copied from one of the
code-generated ones, with a few modifications:
* Derive the interface name from the proto id instead of hardcoding it.
* Use the proto/constructor ids to get constructor and prototype objects.
* Use ErrorResult instead of FastErrorResult; we don't want the precedent of
using FastErrorResult in non-generated code.
There will be further changes to combine HTMLConstructor and
CreateXULOrHTMLElement, in a separate changeset.
MozReview-Commit-ID: 44D0qw23ioP
I moved the IgnoreErrors decl so it would come after the OOMReporter decl and I
could add the new conversion operator.
MozReview-Commit-ID: B1S6DXmZfvE
Currently static atoms are stored on the heap, but their char buffers are
stored in read-only static memory.
This patch changes the representation of nsStaticAtom (thus making it a
non-trivial subclass of nsAtom). Instead of a pointer to the string, it now has
an mStringOffset field which is a 32-bit offset to the string. (This requires
placement of the string and the atom within the same object so that the offset
is known to be small. The docs and macros in nsStaticAtom.h handle that.)
Static and dynamic atoms now store their chars in different ways: nsStaticAtom
stores them inline, nsDynamicAtom has a pointer to separate storage. So
`mString` and GetStringBuffer() move from nsAtom to nsDynamicAtom.
The change to static atoms means they can be made constexpr and stored in
read-only memory instead of on the heap. On 64-bit this reduces the per-process
overhead by 16 bytes; on 32-bit the saving is 12 bytes. (Further reductions
will be possible in follow-up patches.)
The increased use of constexpr required multiple workarounds for MSVC.
- Multiple uses of MOZ_{PUSH,POP}_DISABLE_INTEGRAL_CONSTANT_OVERFLOW_WARNING to
disable warnings about (well-defined!) overflow of unsigned integer
arithmetic.
- The use of -Zc:externConstexpr on all files defining static atoms, to make
MSVC follow the C++ standard(!) and let constexpr variables have external
linkage.
- The use of -constexpr:steps300000 to increase the number of operations
allowed in a constexpr value, in order to handle gGkAtoms, which requires
hashing ~2,500 atom strings.
The patch also changes how HTML5 atoms are handled. They are now treated as
dynamic atoms, i.e. we have "dynamic normal" atoms and "dynamic HTML5 atoms",
and "dynamic atoms" covers both cases, and both are represented via
nsDynamicAtom. The main difference between the two kinds is that dynamic HTML5
atoms still aren't allowed to be used in various operations, most notably
AddRef()/Release(). All this also required moving nsDynamicAtom into the header
file.
There is a slight performance cost to all these changes: now that nsStaticAtom
and nsDynamicAtom store their chars in different ways, a conditional branch is
required in the following functions: Equals(), GetUTF16String(),
WeakAtom::as_slice().
Finally, in about:memory the "explicit/atoms/static/atom-objects" value is no
longer needed, because that memory is static instead of heap-allocated.
MozReview-Commit-ID: 4AxPv05ngZy
This allows custom elements to work in any document in the parent process that
allows XUL and XBL. The test takes the easy option of moving the existing XUL
custom element test to a run with the custom element pref disabled.
MozReview-Commit-ID: CMiLzmp60jA
--HG--
extra : rebase_source : 735688061116c633b816f4f9d488712408df11a5
extra : source : 794ee6857d83dfe0b18629c12e96a622fc899586
This allows custom elements to work in any document in the parent process that
allows XUL and XBL. The test takes the easy option of moving the existing XUL
custom element test to a run with the custom element pref disabled.
MozReview-Commit-ID: CMiLzmp60jA
--HG--
extra : rebase_source : b9632de82cf79c1df15be09fadf1d25817c8a894
extra : amend_source : 235a76453d1d6782903d5051ee8e234b965dcc36
The change in browser_net_view-source-debugger.js is needed because we now use WebIDL callbacks for MessageListener, and they add async creation stack frames.
--HG--
extra : rebase_source : 0adb349b40a0c51bb3d8f4b9b7d98106a3929cbd
extra : source : a88d94ec010a12c1d829708aaf59a85609478477
The DOMMatrix.cpp changes are because it was sneaking in headers via another
unified file.
MozReview-Commit-ID: GPp9WOywI5D
--HG--
rename : dom/base/nsGenericDOMDataNode.cpp => dom/base/CharacterData.cpp
rename : dom/base/nsGenericDOMDataNode.h => dom/base/CharacterData.h
This way we don't include it in all the binding headers. We only need
jsfriendapi.h for the static_asserts involving JSJitInfo, so we move those to
PrototypeList.cpp.
MozReview-Commit-ID: 7KOmbjwSBOD
By removing the "Atom" suffix, which is redundant.
MozReview-Commit-ID: 4MCX9Icfjrw
--HG--
extra : rebase_source : c3c759a508a8938b59d36dbb20448d2964b98c91
Web-visible WebIDL interfaces require DOM peer review with every change, which
is enforced by a commit hook. ChromeOnly interfaces are not exposed to the
web, and therefore don't require the same strictures.
The current commit hook enforces the review requirement for changes to any
(non-Servo) WebIDL file, and is not smart enough to determine if the change is
web-visible. In order to loosen that restriction, we need the build system to
enforce the requirement that only WebIDL files in certain locations may
contain web-visible interfaces, so that the commit hook can restrict itself to
checking only those directories.
This change restricts the location of web-visible WebIDL interfaces to the
dom/webidl/ and dom/bindings/ roots (along with the corresponding objdir root
for generated interfaces). A follow-up will change the commit hook to only
enforce review requirements on these directories.
MozReview-Commit-ID: CiDxXxN4oO4
--HG--
extra : rebase_source : d836004da9f2def74e7c8cd5d580db2290a938d4
extra : intermediate-source : 608e21fcd1674dae3f8b685cedab85c43ffdb485
extra : source : 6cb20ada1a0aa1f6d621ba3c85ce9946a6f9841f
Web-visible WebIDL interfaces require DOM peer review with every change, which
is enforced by a commit hook. ChromeOnly interfaces are not exposed to the
web, and therefore don't require the same strictures.
The current commit hook enforces the review requirement for changes to any
(non-Servo) WebIDL file, and is not smart enough to determine if the change is
web-visible. In order to loosen that restriction, we need the build system to
enforce the requirement that only WebIDL files in certain locations may
contain web-visible interfaces, so that the commit hook can restrict itself to
checking only those directories.
This change restricts the location of web-visible WebIDL interfaces to the
dom/webidl/ and dom/bindings/ roots (along with the corresponding objdir root
for generated interfaces). A follow-up will change the commit hook to only
enforce review requirements on these directories.
MozReview-Commit-ID: CiDxXxN4oO4
--HG--
extra : source : 6cb20ada1a0aa1f6d621ba3c85ce9946a6f9841f
extra : histedit_source : 1f02888264a936db3e77134c0a7203e911707312%2C6ea38c077b8a7dfaf358bc819d150a20db9bd6b7
Web-visible WebIDL interfaces require DOM peer review with every change, which
is enforced by a commit hook. ChromeOnly interfaces are not exposed to the
web, and therefore don't require the same strictures.
The current commit hook enforces the review requirement for changes to any
(non-Servo) WebIDL file, and is not smart enough to determine if the change is
web-visible. In order to loosen that restriction, we need the build system to
enforce the requirement that only WebIDL files in certain locations may
contain web-visible interfaces, so that the commit hook can restrict itself to
checking only those directories.
This change restricts the location of web-visible WebIDL interfaces to the
dom/webidl/ and dom/bindings/ roots (along with the corresponding objdir root
for generated interfaces). A follow-up will change the commit hook to only
enforce review requirements on these directories.
MozReview-Commit-ID: CiDxXxN4oO4
--HG--
extra : rebase_source : f61b33ae4c973b1c9ec1423bb9baca59725e44b1
The change in browser_net_view-source-debugger.js is needed because we now use WebIDL callbacks for MessageListener, and they add async creation stack frames.
--HG--
extra : rebase_source : d7c026d8a77634ef2566feba78168beb8a66a552
The change in browser_net_view-source-debugger.js is needed because we now use WebIDL callbacks for MessageListener, and they add async creation stack frames.
--HG--
extra : rebase_source : 77672a73a6e1447c763930143116a261f2369e67
KeyframeEffect and KeyframeEffectReadOnly constructors can run in the caller
compartment, which is okay because the current compartment is used in the
following places and all of them are safe:
1. GlobalObject::CallerType(), that is ultimately passed to
nsDocument::IsWebAnimationsEnabled in KeyframeEffectParamsFromUnion,
to decide whether to copy mIterationComposite/mComposite to
KeyframeEffectParams.
GlobalObject::CallerType() can now be different than the target window's one,
if the caller has the system principal and the target is web content, and
in that case nsDocument::IsWebAnimationsEnabled there always returns true
while Web Animations can be disabled on web content.
honoring the mIterationComposite/mComposite properties is OK, since it just
changes the animation behavior, and this is disabled by default until
remaining spec issues are resolved.
2. GlobalObject::Context(), that is ultimately passed to
KeyframeUtils::GetKeyframesFromObject and used while extracting information
from passed-in keyframe object, with iterable/iterator protocols.
Performing that operation in the caller side is okay, since the same thing
can be done on caller, and the operation doesn't perform any GCThing
allocation on the target window global.
KeyframeEffect and KeyframeEffectReadOnly constructors can run in the caller
compartment, which is okay because of the following reasons:
1. The target window global is used for most operation:
* KeyframeEffectReadOnly::ConstructKeyframeEffect uses the target window
global instead of current global.
* KeyframeEffectParamsFromUnion which receives `aGlobal.CallerType()`
In Xray case, Web Animations API can be disabled on web content
(currently disabled on beta/release by default), and in that case some API
won't work even it's triggered from WebExtensions, but it should be fine.
2. GetKeyframesFromObject is executed in the caller's compartment to access
the passed-in JSObject that is keyframe, with iterable/iterator protocols.
This operation doesn't perform any GCThing allocation on the target window
global.
I looked at the diff in the generated code, and the only change is that
SpeechRecognitionEvent's unlink impl goes from:
NS_IMPL_CYCLE_COLLECTION_UNLINK_BEGIN_INHERITED(SpeechRecognitionEvent, Event)
NS_IMPL_CYCLE_COLLECTION_UNLINK(mResults)
tmp->mInterpretation.setUndefined();
NS_IMPL_CYCLE_COLLECTION_UNLINK(mEmma)
NS_IMPL_CYCLE_COLLECTION_UNLINK_END
to:
NS_IMPL_CYCLE_COLLECTION_UNLINK_BEGIN_INHERITED(SpeechRecognitionEvent, Event)
NS_IMPL_CYCLE_COLLECTION_UNLINK(mResults)
NS_IMPL_CYCLE_COLLECTION_UNLINK(mEmma)
+ tmp->mInterpretation.setUndefined();
NS_IMPL_CYCLE_COLLECTION_UNLINK_END
MozReview-Commit-ID: FISIphljlT6
These are cases that are implementing the "convert an exception to a Promise"
steps of the Web IDL spec. Typically the exception is thrown in the current
compartment; the Promise returned should simply match that. Otherwise we can
end up with a situation in which the promise doesn't actaully have access to
its rejection value, which will cause problems if someone uses then() on the
promise: the return value of the then() call will get a sanitized exception
instead of the real one.
We _could_ try to match the actual compartment of the exception, in theory.
But it's not clear why this would be preferable to using the current
compartment, even if there were cases in which the exception _doesn't_ match
the current compartment. Which there likely are not.
MozReview-Commit-ID: Ac2BHIHxfvY
--HG--
rename : dom/promise/tests/test_promise_argument.html => dom/promise/tests/test_promise_retval.html
rename : dom/promise/tests/test_promise_argument_xrays.html => dom/promise/tests/test_promise_retval_xrays.html
We currently don't generate a ::ToJSON() method for WebIDL types with record<K,V>
members. These types should be safe to convert to JSON, as long as type V itself
is. Per spec, type K is always a DOMString, USVString, or ByteString.
This patch was autogenerated by my decomponents.py
It covers almost every file with the extension js, jsm, html, py,
xhtml, or xul.
It removes blank lines after removed lines, when the removed lines are
preceded by either blank lines or the start of a new block. The "start
of a new block" is defined fairly hackily: either the line starts with
//, ends with */, ends with {, <