We can't have a null content in
ScrollbarActivity::StopListeningForScrollAreaEvents, because only viewport
frames have a null GetContent().
MozReview-Commit-ID: 9iAg0ivVqqG
And then fix up everything else that needs to change as well.
MozReview-Commit-ID: GDMfERqdQAc
--HG--
extra : rebase_source : 01fe06c3182245a409099a53383d92bf4fa0155c
Chromeutils.RequestPerformanceMetrics() is now composed of two parts:
- calls content processes via IPDL to get their counters
- directly dispatch counters from the parent process
MozReview-Commit-ID: HlgcEOzkyAq
--HG--
extra : rebase_source : 60e81a27cd3a1bf1378e6b977529964507633b63
This new module simplifies how we interact with PerformanceInfo counters:
- CollectPerformanceInfo: returns all PerformanceInfo instances
- NotifyPerformanceInfo: converts PerformanceInfo in XPCOM and notify them
MozReview-Commit-ID: JedKEtsbQTF
--HG--
extra : rebase_source : c87ad34f116a789f909c480963fb99cae3fafa6d
On Mac, when dragging an image, add the image request's MIME type to
the transfer so that the MIME-extension check can be done in the
parent process to avoid content sandboxing issues.
MozReview-Commit-ID: 3cb4fCr6GnL
--HG--
extra : rebase_source : 43720237b467765401b5504c57bbc1b43d4dfdc0
Adds a new TYPE_SPECULATIVE to nsIContentPolicy uses it as the type for
speculative connection channels from the IO service. I believe I've added it to
all the content policies in tree to make sure it behaves the same as TYPE_OTHER
used to.
The webextension test shows that the webextension proxy API sees speculative
lookups requested through the IO service.
MozReview-Commit-ID: DQ4Kq0xdUOD
--HG--
extra : rebase_source : d9460fdac118bc68f0db79749a16f181b580f2e7
This will make it possible to migrate existing bindings without also needing to
mass-rewrite frontend code at the same time.
MozReview-Commit-ID: IBBqC4eeDDX
--HG--
extra : rebase_source : e901ac665208b3a683668c1bb33a26dcf479580c
This attribute was added in bug 1432966 when we started sanitizing
chrome usage of innerHTML to allow devtools to use custom attributes
in React via dangerouslySetInnerHTML.
Devtools removed its usage of dangerouslySetInnerHTML in bug 1434155, so
document.allowUnsafeHTML is no longer used and can be removed.
MozReview-Commit-ID: 8xTVZDmPqRa
--HG--
extra : rebase_source : 3d427133ccb8975163b4459af57b5d96ef54c93e
The webconsole UI generates a large number of scrollbars, and considering their children as
potential Custom Elements causes a slowdown when setting innerHTML="" when devtools closes.
MozReview-Commit-ID: 2QCcXCnTHA2
--HG--
extra : rebase_source : 5226e5689195a047ebcb9903b4565df13b6b1aa0
This reworks bug 1440561 so that we only precompute loads that belong to our
user font set, avoiding messing up with fonts in the cache that belong to other
pages.
The loadability of a font is precomputed in PreTraverse in the same way as we
did, but only for the fonts that we may end up loading. This is stored in
FontFaceSet now.
Also, the principal shenanigans that this code did are reworked to be explicit
about when the document principal changes in ResetToURI, instead of having a
member around and a mutable variable. This makes the code easier to follow.
MozReview-Commit-ID: 9ofTbaLDUF7
The various AtomsTables in nsTreeSanitizer only contain static atoms. Knowing
this, we can optimize things:
- They can contain raw nsStaticAtom pointers instead of refcounted nsAtom
pointers.
- When looking up, we can/must first check if the atom we are looking for is
static. If not, we know it can't be in the table. This is done by the new
Contains() method.
This change also lets us add more `const` to various places that interact with
the tables.
MozReview-Commit-ID: EFxWN2GU78L
--HG--
extra : rebase_source : f2a0bdbb4c5179dd396476263e6a6b57adb13360
This is much shorter than nsTHashtable<nsRefPtrHashKey<nsAtom>>, which is
repeated often.
MozReview-Commit-ID: 85MR0PQ6klI
--HG--
extra : rebase_source : b9d157b2deb68f4d9aee94bdcff6737caf4336ba
The dirty bit fiddling is nontrivial, but it's pretty much what we do for
invalidation and allows to keep this incrementally easily.
The only caller that we cared about for the GetFlattenedTreeParent check in
DestroyFramesForAndRestyle was the old ShadowRoot invalidation functions that
went away.
MozReview-Commit-ID: GmgPPJ6d2qX
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
nsIClipboardDragDropHooks and nsIClipboardDragDropHookList allow XUL apps
to customize drag and drop operation and paste operation. However, this
feature was used only by ChatZilla and it doesn't work on Gecko anymore.
So, we can get rid of them from our tree.
MozReview-Commit-ID: Ibs3V1gI8Ry
--HG--
extra : rebase_source : 83428293d59aaca432d76c71b214aa7799f7f9de
:-moz-native-anonymous can just use is_in_native_anonymous_subtree()
which is an existing function duplicating IsInNativeAnonymousSubtree().
IsRootOfUseElementShadowTree() in C++ code only has a single reference
from nsCSSPseudoClasses::MatchesElement() so we can just move it to the
Rust side. And actually Rust code has existing duplicate logic for
blocks_ancestor_combinators().
MozReview-Commit-ID: 8M1hHrYJT6Y
--HG--
extra : rebase_source : bf53ac7d8b15b0d1f7447a6056986d89b1cb4e57
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 GetSelection changes are so we have a Selection that we can get an nsRange
from via GetRangeAt, so we can call nsRange::CloneRange.
MozReview-Commit-ID: 6rqdJ29Yyuc
I got a bit carried away with fixing up consumers to use nsINode... But as a
result removing these methods all together made sense.
MozReview-Commit-ID: 2z9Q6D7GY92
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
nsStyleStructList.h was initially made generated in bug 873368 to avoid
manually maintaining boilerplate for if-dispatch, while the if-dispatch
was replaced by jump table in bug 1171842, so the boilerplate went away.
However, in bug 1122781 (before bug 1171842), boilerplate for dependency
check, so it still needs to be generated.
The dependency table is removed in the previous patch, so we no longer
have any boilerplate in the style struct list, and thus it doesn't need
to be generated anymore.
MozReview-Commit-ID: GkbJZ98ojbE
--HG--
extra : rebase_source : a148b97c051bb6c88846cf6ba617c4edef70ca24
extra : source : f1c7d19cde195fb90ac2627d16ed69d020de01b9
updateLayerTree() is called from the callback of MozAfterPaint in
reftest-content.js all the time except when we specify reftest-no-sync-layers
or reftest-no-flush. If there is a throttled animation,
FlushPendingNotifications flushes the animation, thus it will fire another
MozAfterPaint event. It means we will end up waiting for the throttled
animation to finish. This reiteration MozAfterPaint events can be easily
observed in WebRender since WebRender fires MozAfterPaint event without
checking invalidation change. Whereas current Gecko fires MozAfterPaint only
if invalidation change happens and reftests for such throttled animations
specify the same value for 'from' and 'to' value, so it hasn't been a problem
there.
The FlushPendingNotifications in updateLayerTree() was introduced in bug
1083635 <https://hg.mozilla.org/mozilla-central/rev/5bebfbefb3c2> to
sync-decode images so it shouldn't matter if there are still throttled
animations.
MozReview-Commit-ID: B9KgNCX0kWq
--HG--
extra : rebase_source : 7e40a94b7ead05c708f21fb4bc897d50becd74dc
Channel layout is derived by the content being played. The concept of preferred layout is meaningless. Either we have a layout defined, or we don't. There's no in-between.
So we remove it.
MozReview-Commit-ID: CSCAInNmzMS
When dragging an image, add the image request's MIME type to the transfer
so that the MIME-extension check can be done in the parent process.
Move the MIME-extension check to the parent process to avoid
issues caused by content process sandboxing.
MozReview-Commit-ID: 3cb4fCr6GnL
--HG--
extra : rebase_source : ec49b8c83613be844fe4cd88a5024ac41a845199
For now we preserve the current code structure and function signatures to make
review simpler. That's about to get cleaned up.
MozReview-Commit-ID: 4epLHQiEwDV
test_bug609794.html was testing a behavior that the method before the current
method of attaching InstallTrigger to windows depended on. We don't really
need that behavior, which is good, because this change is not producing it.
MozReview-Commit-ID: GPzif89UYYl
The only caller of nsDOMConstructor::nsDOMConstructor is
nsDOMConstructor::Create which has no callers.
Also removes the now-unused nsDOMConstructorSH class.
MozReview-Commit-ID: GgOO8ugXFKb
We only have classinfo left for DOMConstructor and DOMPrototype, both of which
use nsDOMConstructorSH, which overrides PostCreatePrototype.
To avoid -Werror build failures, this changeset also removes static functions
that were only reachable from PostCreatePrototype.
MozReview-Commit-ID: JpJOuMHAAuo
We don't resolve it normally, because nsDOMConstructorSH overrides
PostCreatePrototype to be a no-op, so nsWindowSH::GlobalResolve never actually
defines the relevant property on the window. We also hide it in
nsWindowSH::NameStructEnabled. But in the Xray-to-window case we attempt to
define it. We shouldn't do that.
MozReview-Commit-ID: 3tnMnSQuvuT
The only caller is nsDOMClassInfo::RegisterClassProtos. The only caller of
that is nsDOMClassInfo::Init. In nsDOMClassInfo::Init this is called after we
have done the RegisterClassName call for "DOMConstructor".
Since the only bits of classinfo left are DOMConstructor and DOMPrototype, and
both use nsIDOMDOMConstructor as their interface, we call RegisterClassProto
with "DOMConstructor" as aClassName, find the existing nsGlobalNameStruct, and
return without doing anything. So this entire codepath can be removed.
MozReview-Commit-ID: JfXmIex7tLC
The change from "docShell" to "mDocShell" for the SetName call in the
OwnerIsMozBrowserFrame case in nsFrameLoader::MaybeCreateDocShell is a
drive-by correctness fix for a bug the rename of "docShell" to "parentDocShell"
caught: setting the name of our _parent_ docshell based on the name attr of our
owner makes no sense.
MozReview-Commit-ID: DwnWt8jTokV
Adds the IPDL layer to asynchronously retrieve in the parent process the performance counters.
MozReview-Commit-ID: RbKstNx8pi
--HG--
extra : rebase_source : d7c00f2ef16623dbbd88ede0f6636ca56501e151
Adds the IPDL layer to asynchronously retrieve in the parent process the performance counters.
MozReview-Commit-ID: RbKstNx8pi
--HG--
extra : rebase_source : f81058b9bdd67c2f77bb5cd45d3838bc12f406ea
It seems silly to have a tiny utils class with a single function in its own
module. This patch moves it into nsStaticAtom.h/nsAtomTable.cpp. It also
renames nsAtomListUtils as nsStaticAtomUtils. Finally, it uses templates to
remove the need for the `aCount` parameter at callsites.
MozReview-Commit-ID: DvJVoZFv89c
--HG--
extra : rebase_source : 1f1dd27d56e46c71c30c10102ac6132a721e23d1
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 is mostly a straightforward copy. The only change is what happens with
the return value of CloneDataNode: it's cast to Text directly, and the
null-check is replaced by an assert.
MozReview-Commit-ID: B5rnhEOneZn
Summary:
When the host is bound to the document, it'll also re-BindToTree the shadow
tree, which will update the stylesheets and all that.
Reviewers: xidorn
Bug #: 1446507
Differential Revision: https://phabricator.services.mozilla.com/D742
MozReview-Commit-ID: fBLq5owB7U
Summary:
I'm happy to keep it around if you think having the test_mutationobservers check
is useful.
MozReview-Commit-ID: LbWvJiO9LRZ
Reviewers: smaug
Bug #: 1446597
Differential Revision: https://phabricator.services.mozilla.com/D750
We'll start to dispatch keydown event and keyup event even during composition.
So, for testing those events won't break our UI, we should make
EventUtils.synhtesizeComposition() and EventUtils.synthesizeCompositionChange()
dispatch keydown event and keyup event even if callers don't specify keyboard
event explicitly.
Typically, "keydown" event is marked as "processed by IME", i.e., keyCode
value is set to DOM_VK_PROCESSKEY and key is set to "Process", with our
widget which handles native IME and key input. On the other hand, "keyup"
is NOT marked as so.
Therefore, this patch makes TextInputProcessor emulates this behavior without
any new special flags. And for making possible to emulate special cases,
this patch adds two flags to nsITextInputProcessor. One is
KEY_DONT_MARK_KEYDOWN_AS_PROCESSED. The other is KEY_MARK_KEYUP_AS_PROCESSED.
Unfortunately, those flags have opposite meaning but this must be better than
making necessary to one flag for emulating usual keydown/keyup events.
Finally, this makes some tests specify better keyboard information to
synthesizeComposition() and synthesizeCompositionChange() to emulate
actual keyboard events during composition.
MozReview-Commit-ID: ItYaXILkNQE
--HG--
extra : rebase_source : e50cc77c1efbc12686d7ea334d41926c7392b30d
Summary: The member is already in nsIDocument anyway.
Reviewers: bzbarsky
Bug #: 1446601
Differential Revision: https://phabricator.services.mozilla.com/D751
MozReview-Commit-ID: 90Ad5wiCeMS
The nsCSSFrameConstructor bits are now handled in PresShell::Destroy along with
the other refresh driver observers.
I cleaned up the nsRefreshDriver methods because they were using infallible
append anyway, and that simplified the logic.
MozReview-Commit-ID: 1eDUUXjUUS9
Currently we can only have one type of WebRenderUserData on an Item. We already
have a hash table of WebRenderUserData so it's not hard to include type in the
hash to support one per type.
MozReview-Commit-ID: geJ0BeWv8b
This pref was introduced in case we encountered compatibility issues from
changing the return value of Animation.playState (bug 1412765). Now that the
change to Animation.playState has shipped to release channel without any known
problems we should drop this pref.
MozReview-Commit-ID: CwMWRRtIf6u
--HG--
extra : rebase_source : b26c59a51880406c2b94baad8da2eafeb3ae3202
The path service was created to allow us to track resources that were part of
legacy add-ons, and to map URIs ponting to those resources to add-on IDs, so
that we could apply special behavior to them.
We have better ways to track resources belonging to WebExtensions, so this
code does not benefit them in any significant way.
The only remaining legacy extensions are system add-ons, which we control, and
do not need the path service in order to track.
MozReview-Commit-ID: BKXkcaM7jJx
--HG--
extra : rebase_source : c8cb0f7cec919b767bbcfe5433a6838523747676
The compartment-per-addon code was added so that we could segregate at least
some of the code from system-privileged add-ons into tagged compartments, even
when it ran in browser windows. That allowed us to apply certain special
behavior to them, such as enabling e10s shims, and to track some performance
characteristics.
The only remaining chrome-privileged add-ons now are system add-ons controlled
by us, and the shim system and per-compartment performance metrics are gone,
it no longer serves a purpose.
MozReview-Commit-ID: Ap186bWAaqP
--HG--
extra : rebase_source : c5bf81b44dd42b7cebce2784b7dd98480b41b593
This list of atoms isn't particularly DOM-ish, and having it in xpcom/ will
help with the next patch.
MozReview-Commit-ID: 1Y3Fhn9lNbh
--HG--
rename : dom/base/nsGkAtomList.h => xpcom/ds/nsGkAtomList.h
rename : dom/base/nsGkAtoms.cpp => xpcom/ds/nsGkAtoms.cpp
rename : dom/base/nsGkAtoms.h => xpcom/ds/nsGkAtoms.h
extra : rebase_source : 0a0f6ab4432e0d58ea4662299b750a8c52325ad5
Summary:
Before that bug, we carefully told layout about all distribution changes before
they happened, so layout could cleanup frames and styles synchronously properly
(since otherwise there's no way afterwards to figure out what the tree shape
was).
That bug made it not do it correctly, causing this.
I obviously need to write a bunch of tests for this...
Reviewers: smaug
Bug #: 1438210
Differential Revision: https://phabricator.services.mozilla.com/D724
MozReview-Commit-ID: 8uupNhoFwme
There are only a handful of them, and two of them are duplicates of atoms
within nsGkAtoms anyway.
MozReview-Commit-ID: Cb90STdeGdK
--HG--
extra : rebase_source : 6ebc6996b129e70907f634e1876725c9e5da41ab
In each case, the atom had an obvious name and a weird name. Where possible, I
kept the obvious name and commented out the weird name, viz:
- `mixed` over `_mixed` for "mixed"
- `el` over `el_` for "el"
- `other` over `other_` for "other"
- `remote` over `Remote` for "remote"
But for several of them I didn't do that, because the weird name is used
within the HTML5 parser -- which is a huge pain to modify because it involves
code generated by code from another repo -- so I kept the weird name and
commented out the obvious name, viz:
- `list_` over `list` for "list"
- `svgSwitch` over `_switch` for "switch"
- `set_` over `set` for "set"
MozReview-Commit-ID: Jp3CpdWXNDm
--HG--
extra : rebase_source : 421ce5316772f1951488307e81f2ceee696d363d
This changes the pluginreg.dat format to include the blocklist state.
There is now only the saved blocklist state in a plugin tag instance, rather than
looking it up from in there using the blocklist service, so it was renamed from
mCachedBlocklistState to mBlocklistState. We pass the 'right' state to the plugin
instance when the plugintag is constructed. If we don't have state, we mark it as
unblocked.
mCachedBlocklistStateChanged was never read so it's being removed.
Bug 1439519 adds a 'blocklist-loaded' notification that is fired once the blocklist is loaded.
The plugin host implementation will listen to this in the parent process and update the
blocklist state of all the plugins, and broadcast changes to the child process, just like when
we update the blocklist from the server. We now also avoid re-sending plugin content to the
content processes if the plugin state hasn't changed as a result of the blocklist having been
loaded.
Finally, because new plugins should still get an up-to-date blocklist state, and
telemetry should get up-to-date data about which plugins are and aren't enabled
once we have that data, we ensure that once we've loaded the blocklist async,
we schedule an idle task to parse it and consider it loaded.
All this means that plugin blocklist information could be mistaken between the points where
a new plugin is installed and we first run Firefox with the new plugin, and the point where
we load the blocklist. Given the trade-offs, that size of window (tiny) seems OK, also given
that there's already a much larger window in blocklist updates (which only happen once every 24h).
MozReview-Commit-ID: 1gsojRkUzTw
--HG--
extra : rebase_source : 4709916b4674ada54f8a495fd2d16fcef8c58d20
Summary: It uses two node bits that can be better suited for something else.
Reviewers: xidorn, smaug
Bug #: 1444905
Differential Revision: https://phabricator.services.mozilla.com/D709
MozReview-Commit-ID: HIPDtHm6xpM
The wpt changes come from https://github.com/w3c/web-platform-tests/pull/9920
and are needed to keep Element-classlist.html passing.
The change to testing/web-platform/mozilla/tests/dom/classList.html is pulling
those changes into our weird forked version of that test...
MozReview-Commit-ID: CvQlBRuieUY
Adds a PeformanceCounter class that is used in DocGroup and WorkerPrivate
to track runnables execution and dispatch counts.
MozReview-Commit-ID: 51DLj6ORD2O
--HG--
extra : rebase_source : b481c9aa3b735569722bb7472872ec2d22adcb89
Most of the noise is from the fact that clang-format on parser/html/*.{h,cpp}
reformatted all sorts of stuff. Not running it caused lots of format changes
from the generator... I guess we changed the format rules since the last time
this got run?
MozReview-Commit-ID: IA2G87zUIKN
We attach it to WorkerPrivate and DOMNavigationTiming so it will be re-used
when it should.
WorkerPrivate is used in the Performance APIs, Performance Storage Worker,
and Event.
DOMNavigationTiming is used only in the Performance APIs, but the crucial
part is that when the individual DOMNavigationTiming object is re-used,
so will the context seed. This in particular came up with the
nav2_test_document_open.html Web Platform Test which illustrated the fact
that even if you .open() a new document, the performance navigation data
is not supposed to change.
MozReview-Commit-ID: GIv6biEo2jY
--HG--
extra : rebase_source : da2ad8d9d6e0172679c6af14dba72938e9d2012c
Boris Zbarsky
Gijs Kruitbosch
Emilio Cobos Álvarez
Andreea Pavel
Ciure Andrei
Xidorn Quan
Noemi Erli
Nicholas Nethercote
Bobby Holley
Ben Kelly
Hiroyuki Ikezoe
Cosmin Sabou
Tarek Ziadé
Christoph Kerschbaumer
Robert Longson
Haik Aftandilian
Dave Townsend
Brian Grinstead
arthur.iakab
Johann Hofmann
Peter Van der Beken
Mike Conley
Narcis Beleuzu
Neil Deakin
Gurzau Raul
Olli Pettay
Jonathan Watt
Tom Ritter
Masayuki Nakano
Margareta Eliza Balazs
Bogdan Tara
Henri Sivonen
Coroiu Cristina
Brindusan Cristian
Jean-Yves Avenard
Miko Mynttinen
Adrian Wielgosik
Catalin Badea
Andrea Marchesini
Csoregi Natalia
Tiberius Oros
Tooru Fujisawa
Jeff Muizelaar
Sylvestre Ledru
Sebastian Hengst
Brian Birtles
shindli
Kris Maglione
Jonathan Kingston
Hector Zhao