I'm drive-by removing the comment about the frame tree state because I looked
into it, and the answer is: we properly restore it.
The gotcha is that we retain it too much, indeed, we retain it enough that it
can leak. See bug 1397239.
MozReview-Commit-ID: LP6bXkduEZ4
--HG--
extra : rebase_source : f7e18fc35e48b75c07fcc84b939614d379926828
This is pretty much a straight-forward change except for a single thing, the
UpdateInsertionParent calls.
However, I cannot make any sense of them. They go through the inserted children
setting the insertion point, but then ClearInsertionPoints() is called.
ClearInsertionPoints calls XBLChildrenElement::ClearInsertedChildren, which sets
all the insertion points to null anyway.
Thus, I've removed that function completely.
MozReview-Commit-ID: 80daGQfLZrV
--HG--
extra : rebase_source : d52a37a60147ac11794c3cfe1aad5d202e9d2d9f
(Path is actually r=froydnj.)
Bug 1400459 devirtualized nsIAtom so that it is no longer a subclass of
nsISupports. This means that nsAtom is now a better name for it than nsIAtom.
MozReview-Commit-ID: 91U22X2NydP
--HG--
rename : xpcom/ds/nsIAtom.h => xpcom/ds/nsAtom.h
extra : rebase_source : ac3e904a21b8b48e74534fff964f1623ee937c67
This patch merges nsAtom into nsIAtom. For the moment, both names can be used
interchangeably due to a typedef. The patch also devirtualizes nsIAtom, by
making it not inherit from nsISupports, removing NS_DECL_NSIATOM, and dropping
the use of NS_IMETHOD_. It also removes nsIAtom's IIDs.
These changes trigger knock-on changes throughout the codebase, changing the
types of lots of things as follows.
- nsCOMPtr<nsIAtom> --> RefPtr<nsIAtom>
- nsCOMArray<nsIAtom> --> nsTArray<RefPtr<nsIAtom>>
- Count() --> Length()
- ObjectAt() --> ElementAt()
- AppendObject() --> AppendElement()
- RemoveObjectAt() --> RemoveElementAt()
- ns*Hashtable<nsISupportsHashKey, ...> -->
ns*Hashtable<nsRefPtrHashKey<nsIAtom>, ...>
- nsInterfaceHashtable<T, nsIAtom> --> nsRefPtrHashtable<T, nsIAtom>
- This requires adding a Get() method to nsRefPtrHashtable that it lacks but
nsInterfaceHashtable has.
- nsCOMPtr<nsIMutableArray> --> nsTArray<RefPtr<nsIAtom>>
- nsArrayBase::Create() --> nsTArray()
- GetLength() --> Length()
- do_QueryElementAt() --> operator[]
The patch also has some changes to Rust code that manipulates nsIAtom.
MozReview-Commit-ID: DykOl8aEnUJ
--HG--
extra : rebase_source : 254404e318e94b4c93ec8d4081ff0f0fda8aa7d1
In order to let necko postpone the load of favicon, we have to set request context ID to the http channel that is created to load favicon.
This patch starts with passing a request context ID to nsContentUtils::LoadImage and makes other necessary changes to set the request context ID to the channel.
This also introduces JS::GetObjectRealmOrNull, which returns an object's realm,
or null if the object is a cross-compartment wrapper. In the new order,
wrappers can't have realms, since they must be shared across all realms in a
compartment. We're introducing this new function early (even though it's
*currently* possible to assign a realm to wrappers) in order to see in
advance if the possibility of returning null will cause problems.
(It looks like it won't.)
--HG--
extra : rebase_source : e55ebbbc4edf2a18ce267198928246592060e339
extra : source : d6bfce1187aa13dbfab03f9566ff7b05b6705e70
Doing it off a runnable makes the flattened tree inconsistent until that
runnable runs.
Also add an assert in frame construction that would've caught the first
only-unbind patch.
MozReview-Commit-ID: Hnua3aWSMHi
--HG--
extra : rebase_source : 2781e3b0a3f28b6b6a620902e7414dfe682fba51
With previous change, KeyboardEvent is dispatched even when invisible window
has focus. However, nsRootWindow::GetControllerForCommand() returns controller
for focused window even when the window is invisible because it uses
nsFocusManager::GetFocusedDescendant() to retrieve focused window.
Perhaps, we can assume that users won't expect to do something with invisible
window when they type some keys. Then, nsRootWindow::GetControllerForCommand()
should return controller for visible ancestor window if focused window is
invisible.
This patch makes nsFocusManager::GetFocusedDescendant() can return only visible
descendants. However, it already has a bool argument. Therefore, it should
have a flag instead of adding new flag. Most changes of this patch is replacing
its callers.
Then, nsRootWindow::GetControllerForCommand() and nsRootWindow::GetControllers()
should have a bool flag if it should return controller(s) for visible window.
This patch adds a bool flag for it. Fortunately, the interface isn't scriptable.
Finally, this patch makes nsXBLPrototypeHandler::DispatchXBLCommand() and
EventStateManager::DoContentCommandEvent() retrieve controller for visible
window since they are always handles user input.
MozReview-Commit-ID: GygttTHuKRm
--HG--
extra : rebase_source : 1341273c4606298cb9b890b9312d9f5c8a75d144
In a number of places, there's no substantial use of maps any more
after the segue.
The ELEMENT segue tries the FragmentOrElement QI, but that is
redundant with the Element QI.
This lets me use a few higher-level macros.
MozReview-Commit-ID: Gstq3Cm8LDl
--HG--
extra : rebase_source : f0c7dbf5281ce7375b1369b49db095a211569d6c
The motivation of this patch is that clearing mPresContext should be an
implementation detail of XBL style set, so I create a method for that, and
remove ClearPresContext().
MozReview-Commit-ID: Ftta0rcAqu6
--HG--
extra : rebase_source : 0bdb1ac3e2c988e5a0220172f19ab4b006e883d7
This fixed layout/style/test/test_media_queries_dynamic.html after Part 3 is added.
MozReview-Commit-ID: 7ZpSunCnkIc
--HG--
extra : rebase_source : 6acab11ba784b801b90afc0558c32baabcc3f271
The method always returns NS_OK, and no other caller checks the nsresult.
Hence the patch.
MozReview-Commit-ID: CnYCZ8VchG
--HG--
extra : rebase_source : 8626332e2774c1d6f42c7afa5e9679091a3aeaa2
The method always returns NS_OK, and no other caller checks the nsresult.
Hence the patch.
MozReview-Commit-ID: CnYCZ8VchG
--HG--
extra : rebase_source : 062d643308b309dfe442384301860ffeec2dff9f
This is straightforward, with only two notable things.
- `#include "nsXPIDLString.h" is replaced with `#include "nsString.h"`
throughout, because all nsXPIDLString.h did was include nsString.h. The
exception is for files which already include nsString.h, in which case the
patch just removes the nsXPIDLString.h inclusion.
- The patch removes the |xpidl_string| gtest, but improves the |voided| test to
cover some of its ground, e.g. testing Adopt(nullptr).
--HG--
extra : rebase_source : 452cc4a08046a1adb1a8099a7e85a1917de5add8
We should not be declaring forward declarations for nsString classes directly,
instead we should use nsStringFwd.h. This will make changing the underlying
types easier.
--HG--
extra : rebase_source : b2c7554e8632f078167ff2f609392e63a136c299
There's only one case of sync frame construction from ContentRemoved now, and
it's not on the element being removed, but on the whitespace siblings if needed,
and _only_ when they don't support lazy frame construction.
Basically, this switches all the RecreateFramesForContent calls to use
`aAsyncInsert` (which I changed to an enum class for readability), except when
we're already reframing.
Also, it switches ReframeTextIfNeeded to opt-in into lazy frame construction,
since it's used only when aFlags == CONTENT_REMOVED.
This allows to simplify the DestroyFramesFor API (which I'm happy to rename to
something more meaningful, since now it's something like
DestroyFramesForAndRecreateThemAsync), and do some other consistency cleanups.
A bunch of the ContentRemoved callsites were pretty random at passing
aAsyncInsert, and that was some kind of a mess. This patch ensures consistency,
and makes it impossible to do O(n^2) work when removing DOM nodes, which is
nice.
The underlying reason for this is explained in the description of bug 1377848,
and basically allows us to remove a bunch of Servo hacks on the longer term (a
few of them are going away already, yay!).
MozReview-Commit-ID: 2DrUTxGV8RX
--HG--
extra : rebase_source : f428d839a5482477dea22c0fea600d54f3e8799c
Our current machinery for enabling stylo requires a docshell - if there isn't
one, we default to the Gecko style system.
When getComputedStyle operates on an element without a presshell, it uses the
caller's presshell instead. If the element has previously been styled with
one style system (but no longer has a presshell), and the caller uses a
different style backend, using the caller's style system can cause crashes when
we pull bits of cached data off the DOM (like cached style attributes).
So we want to throw when window.getComputedStyle(element) is called for a
(window, element) pair with different style backends (which is what the next
patch in this bug does).
However, that causes a few failures where stylo-backed documents try to do
getComputedStyle on an XHR document (which, without a docshell, will use the
gecko style system).
So this patch does some work to propagate the creator's style backend into
various docshell-less documents. This should allow both chrome (which uses gecko)
and content (which uses stylo) to use getComputedStyle on the response document
for XHRs they create.
Note that the second patch in this bug will make
chromeWin.getComputedStyle(contentObj) throw. If we discover code that does
that, we can just make it invoke the content's getComputedStyle method over Xrays.
MozReview-Commit-ID: 5OsmHJKq5Ui
Editor treated in nsXBLWindowKeyHandler is always HTMLEditor. So, it should treat the editor as is.
MozReview-Commit-ID: 7uE2p8t5cNW
--HG--
extra : rebase_source : 66b2f42d9d0281f4a244f9cd1ceb077e32ac3515
Before if a key input was handled with APZ we wouldn't dispatch it to content,
because it was guaranteed there wouldn't be any key listeners. Now we are
allowing passive key listeners behind a pref, and so we will sometimes handle
a key input in APZ and dispatch it to content. When this happens, XBL shouldn't
do the default action, otherwise we would double scroll.
MozReview-Commit-ID: 2zfszQ3itkp
--HG--
extra : rebase_source : 724b110fd55c5935df589f1cbcc0b3380028a1ed
