There's nothing preventing the flat tree from changing while the document
doesn't have a shell. In that case, we really really don't want to lose track
of elements with stale style data, since then we'll mess up.
It's ok to _not_ clear the style data when the document goes into the BFCache
though, because the document is thrown away if other document runs script and
touches the cached DOM.
MozReview-Commit-ID: 4W3xDAnnLPL
A ghost window is a window that is:
a) detached
b) we think it should have gone away
c) it has been in that state for a while
Right now, criterion b holds if the detached window does not have the
same eTLD as any window that is not detached. However, this can cause
false positives when a page leaks a cross-origin iframe.
This patch changes criterion b to be that it holds if the window is
not in the same tab group as any non-detached window. This should
match better with the goal of ghost windows, which is to identify when
pages don't go away after their tab is closed.
MozReview-Commit-ID: GG8d0WkXDUt
--HG--
extra : rebase_source : a9464b91bf565e2fe46062b4ce3b591b10e38f25
There's nothing preventing the flat tree from changing while the document
doesn't have a shell. In that case, we really really don't want to lose track
of elements with stale style data, since then we'll mess up.
It's ok to _not_ clear the style data when the document goes into the BFCache
though, because the document is thrown away if other document runs script and
touches the cached DOM.
MozReview-Commit-ID: 4W3xDAnnLPL
This was needed before as the base to nsGlobalWindow, but now that
nsGlobalWindow doesn't exist, and we only have specific versions, we no longer
need this type.
MozReview-Commit-ID: 6IJmJtnSkMr
--HG--
extra : rebase_source : d21068aa7da89a6d49ead2477b91577809f5856a
There are many helper methods and structs in nsGlobalWindow.cpp. Many of these
are used by only the inner or only the outer window, while some are used by
both. In the case of the items used by both, I extracted them into
nsGlobalWindow.cpp, which includes nsGlobalWindowInner.cpp and
nsGlobalWindowOuter.cpp as the compilation unit entry point.
In the case of items used by just one or the other, I removed them from the
other file, and deleted the bodies of functions which used them, replacing them,
with a MOZ_CRASH.
This gets gecko building again, so that we can make further incremental
improvements.
MozReview-Commit-ID: 8QnJ1PX6TAO
--HG--
extra : rebase_source : 0eac00ad757f825a22a1af95d0a01d6fa92d824d
After the window split is complete, the inner window linked list won't be
homogenously typed anymore, as there will be an nsGlobalWindowOuter member in
addition to the nsGlobalWindowInner members. This patch changes the code to
perform PRCList* pointer comparisons before casting to nsGlobalWindowInner to
avoid this issue.
MozReview-Commit-ID: 56q5XodtGe7
Skip files under intl/icu/ because they're imported from third party.
DONTBUILD because this is a whitespace-only change.
MozReview-Commit-ID: GSd6oeFSTO7
--HG--
extra : rebase_source : 38c20bf6099c18b2fcb4c324d470b279addf8891
Otherwise we may inappropriately style it or what not. This asserts with the
patches of bug 1414999 plus the cleanup of bug 1418456, since we no longer do
StyleNewChildren (which walks over the flattened tree children).
Too bad that GetXBLBinding is a virtual call in Gecko, probably can do just
MAY_BE_IN_BINDING_MGR...
MozReview-Commit-ID: CNU0YdKeaR0
ImageLoadingContent.currentURI returns the "URI" of currentRequest, which is
the URI used to start that request. Some consumers need to know the final URI
of that request instead.
If the image request gets redirected on loading (e.g. an add-on intercepts the
request), currentRequestFinalURI will be the redirected URI, while currentURI
would be the original URI before redirect.
MozReview-Commit-ID: 9lX063uAIp1
--HG--
extra : rebase_source : 6e9752b4df52e3874815557fe727c3fe94af2902
ImageLoadingContent.currentURI returns the "URI" of currentRequest, which is
the URI used to start that request. Some consumers need to know the final URI
of that request instead.
If the image request gets redirected on loading (e.g. an add-on intercepts the
request), currentRequestFinalURI will be the redirected URI, while currentURI
would be the original URI before redirect.
MozReview-Commit-ID: 9lX063uAIp1
--HG--
extra : rebase_source : 91451128abc5c3f29c11d3cabfc98cde6c440ea6
The "current URL" in the spec:
https://html.spec.whatwg.org/multipage/embedded-content.html#dom-img-currentsrc
maps to imgIRequest.URI, not currentURI.
Rename imgIRequest.currentURI to finalURI to prevent such confusion.
MozReview-Commit-ID: CjBh2V4z8K9
--HG--
extra : rebase_source : 01277d16ef12845e12cc846f9dd4a21ceeca283b
Even with this patch, in Gecko getUnanimatedComputedStyle flushes pendings
styles somehow. Also in Stylo the function flushes pending styles if the
target element hasn't yet styled or Servo style data has cleared for some
reasons (e.g. the element is in display:none subtree).
MozReview-Commit-ID: HCizzM0JnFz
--HG--
extra : rebase_source : 81f130f35794d6ddcf6b7e7f70566d521ea63d31
Before this patch, 'content: ""' was applied to the ::before element after
calling getUnanimatedComputedStyle() with '::before' argument so the function
was called for inexistent pseudo element.
Gecko generates ::before and ::after element even if the content property for
the element is none (bug 1387931), so Gecko is not affected by this patch at
all. Whereas Stylo has returned the parent style as the pseudo style for the
inexistent pseudo, it will be fixed by bug 1418867 and a test case will be
added in that bug since SimpleTest does not have todo for doesThrow().
MozReview-Commit-ID: 7uJcCrtu9ke
--HG--
extra : rebase_source : 96f3d1428323e8a7d96b0dee3e7256360251e555
Before this patch, we had been only testing the null element case.
MozReview-Commit-ID: DYB8DtGBIwC
--HG--
extra : rebase_source : c0b8774f795c64b6d525820e6737ed3beed2dda0
This flag would be used to help us decide whether website could be allowed the autoplay.
The media related implementation would be implemented in bug1382574.
MozReview-Commit-ID: GGIauBufs5A
--HG--
extra : rebase_source : c407ceed311fc3fb0140e5da44fd69e457a5098f
This needs to dumb down the parsing in order to match what we do in Gecko and
pass more tests.
The remaining tests are just because of calc() in media queries and "or" media
expressions.
MozReview-Commit-ID: CXGdYVbojBL
There's nothing preventing the flat tree from changing while the document
doesn't have a shell. In that case, we really really don't want to lose track
of elements with stale style data, since then we'll mess up.
It's ok to _not_ clear the style data when the document goes into the BFCache
though, because the document is thrown away if other document runs script and
touches the cached DOM.
MozReview-Commit-ID: 4W3xDAnnLPL
EditorBase::CreateNode() should take EditorRawDOMPoint as insertion point of
the new element instead of a set of container, child and offset of the child
in the container.
This patch initializes EditorRawDOMPoint with original 3 arguments as far as
possible. If the relation of them are broken, MOZ_ASSERT in RawRangeBoundary
constructor detects existing bugs.
MozReview-Commit-ID: 2N55S6pRv7k
--HG--
extra : rebase_source : 2b14a7715815ca0007635b8f791ca9edbe5b65f1
In the test file 1411473.html, there are 3 calls to
nsImageLoadingContent::LoadImage
1. Triggered by setting src attribute, and this sets the mCurrentRequest.
2. Triggered by setting crossOrigin attribute, this forcibly reloads the image,
and this sets the mPendingRequest.
3. Triggered by loading the image which is adopted into a new created data
document by
'document.implementation.createDocument('', '', null).adoptNode(img)'
However in the 3rd call, when it calls nsImageLoadingContent::LoadImage, It
will bail out in the aDocument->IsLoadedAsData() part
http://searchfox.org/mozilla-central/rev/5a60492a53667fc61a62af1847d005a210b7a4f6/dom/base/nsImageLoadingContent.cpp#942
And when it calls SetBlockedRequest, at this time we have a non-null
mCurrentRequest and a non-null mPendingRequest, so this triggers the
assertion of mPendingRequest should be null when we got blocked, which
is added in bug 1267075.
Since data document is not the active document,
per https://html.spec.whatwg.org/multipage/images.html#updating-the-image-data,
Step 1, we should skip the image loading in HTMLImageElement.
In some places, editor computes index from child node for collapsing selection
at the child node. However, it's expensive. Therefore, editor should use
Selection::Collapse(const RawRangeBoundary&) as far as possible.
MozReview-Commit-ID: LF2MwASuXzZ
--HG--
extra : rebase_source : b7afc35c0d9d88845391b6f18de57cbff1935ae4
Selection should have Collapse() methods which take RawRangeBoundary instead of
a set of container and offset in it. Then, if caller know only child node but
doesn't know offset in the container, neither callers, Selections nor nsRange
needs to compute offset. This makes them avoid calling expensive method,
nsINode::IndexOf().
MozReview-Commit-ID: 79IRajLe1FE
--HG--
extra : rebase_source : a8ce52ff1654974461d5ecfed98b73d9cca34133
EditorUtils::IsDescendantOf() current takes a pointer to offset or a pointer to
child content if the caller needs to know the child of the most ancestor node.
However, some callers should get a child as EditorDOMPoint or EditorRawDOMPoint.
Then, they can be used for some editor methods which need to take child node
for performance optimization.
This patch makes EditorUtils::IsDescendantOf() as only two overloads. One takes
pointer to EditorRawDOMPoint as optional out argument. The other takes pointer
to EditorDOMPoint as an out param.
Additionally, this creates new constructor of AutoTrackDOMPoint for making it
can treat EditorDOMPoint directly.
MozReview-Commit-ID: IsAGTUvKI19
--HG--
extra : rebase_source : 97469a21b974c6a1dd515ab472bbc4a88c1899c8
RangeBoundaryBase shouldn't compute mRef when it's initialized with offset.
E.g., some users of the template class may initialize it with a container and
offset in it but it may not refer mRef or may refer after modifying offset.
On the other hand, RangeBoundaryBase::InvalidateOffset() is a special method.
It assumes that mRef is always initialized when it's called but can be
invalidate mOffset until retrieved actually. This is necessary for
nsRange::mStart and nsRange::mEnd since the offset may be changed when
some nodes are inserted before the referring node.
So, now, InvalidateOffset() should be a protected method and make nsRange a
friend class of RangeBoundaryBase. Then, when nsRange sets mStart and/or mEnd,
nsRange itself should guarantee that their mRefs are initialized.
MozReview-Commit-ID: Alr4YkDXIND
--HG--
extra : rebase_source : 7e6828374db7989ae91b9e485571ec553f7435af
A lot of methods in editor returns a child offset with an out param when it
returns its container and offset in the container. This is ugly hack for
performance of nsINode::IndexOf(). However, there are a lot of regression
since the relation between offset and child node can be broken really easily.
So, we should make EditorDOMPoint as a subclass of RangeBoundary and manage
a set of container, reference child and its offset in it (e.g.,
SetNextSibling() added by this patch).
Note that RangeBoundary's performance is not good for temporary use if we set
a point with offset, it immediately retrieves mRef. The following patch will
improve this performance.
MozReview-Commit-ID: 7mcJ1P1OjVr
--HG--
rename : editor/libeditor/EditorUtils.h => editor/libeditor/EditorDOMPoint.h
extra : rebase_source : 785094fcfc592d9e5b48cbc36ed225dbb8bb4111
This makes it a bit more straight-forward to change the system font scale,
preserving the sync MediaFeatureChanged event.
This also avoids notifying media queries when the shell is not initialized.
In particular, the patch in bug 1404545 allows calling MediaFeatureValuesChanged
on a still-initializing pres-shell. This is nasty, and all this initialization
order is kind of a mess, but I'm not reworking it for now...
Also, this drops the invalidation of font-inflation when a doctype is added to
the document. GetViewportInfo() already relies on the doctype not changing, as
noted in a comment.
MozReview-Commit-ID: Knw7dM1B04Y
There are several ways that expanded principals can be used as triggering
principals for requests. While that works fine for security checks, it also
sometimes causes them to be inherited, and used as result principals in
contexts where expanded principals aren't allowed.
This patch changes our inheritance behavior so that expanded principals are
downgraded to the most appropriate constituent principal when they would
otherwise be inherited.
The logic for choosing the most appropriate principal is a bit suspect, and
may eventually need to be changed to always select the last whitelist
principal, but I chose it to preserve the current principal downgrade behavior
used by XMLHttpRequest for the time being.
MozReview-Commit-ID: 9fvAKr2e2fa
--HG--
extra : rebase_source : c30df1b3851c11fed5a1d6a7fb158cec14933182
This is a significant rework of how do we compute the insertion point of a
node.
We handle pseudos in the same function instead of out of band, and also recurse
up when the parent has display: contents, which simplifies the code IMO.
MozReview-Commit-ID: 1rSfv1Tq5gO
Based on patch by Andrew Comminos [:acomminos] <andrew@comminos.com>
MozReview-Commit-ID: 8mBFfQwYSKz
--HG--
extra : rebase_source : 323c9e9822885d56dabb0a9733f826268908b8e3
Currently, widget doesn't show VKB when input context change is caused by JS.
However, if it's caused by an event handler of a user input, user may expect
to open VKB. For example, if a touch event in fake editor causes moving
focus to actual editable node, user expect to show VKB.
Therefore, InputContextAction should declare two causes. One is unknown but
occurred during handling non-keyboard event. The other is unknown but occurred
during handling keyboard event.
However, EventStateManager doesn't have an API to check if it's being handling
a keyboard event. Therefore, this patch adds it first.
AutoHandlingUserInputStatePusher sends event type to StartHandlingUserInput()
and StopHandlingUserInput() of EventStateManager and sUserKeyboardEventDepth
manages the number of nested keyboard event handling. Therefore,
EventStateManager::IsHandlingKeyboardInput() can return if it's handling a
keyboard event.
IMEStateManager uses this new API to adjust the cause of changes of input
context.
Finally, InputContextAction::IsUserInput() is renamed to IsHandlingUserInput()
for consistency with EventStateManager and starts to return true when the
input context change is caused by script while it's handling a user input.
MozReview-Commit-ID: 5JsLqdqeGah
--HG--
extra : rebase_source : 9fcf7687d1bf90eeebbf6eac62d4488ff64b083c
Based on patch by Andrew Comminos [:acomminos] <andrew@comminos.com>
MozReview-Commit-ID: 8mBFfQwYSKz
--HG--
extra : rebase_source : 323c9e9822885d56dabb0a9733f826268908b8e3
Currently, RangeBoundaryBase can store either only mRef or mOffset. However,
== operator of RangeBoudaryBase still compares mRef simply. However, if one
has only mRef and the other has only mOffset, it returns false.
This patch makes == operator checks if both mOffset have been set. If so,
this checks both mOffset.value() and mRef are matched. However, if mRef of
only one of them is nullptr, this doesn't make it check mRef because computing
mRef needs some cost and initializing mRef from the other fixes the referring
child stronger. If the user of the operator sets only mOffset and wait DOM
tree changes, computing mRef may break such callers.
If one has only mRef and the other has only mOffset, this patch makes it
compute mRef. This is not the best behavior, perhaps. However, there is no
way to compare these instances. If this becomes a problem, we should make it
create temporary instance, but it'll waste runtime cost. So, let's avoid using
this approach for now.
Finally, making it check both mRef simply.
MozReview-Commit-ID: 4nsW5SYDTiZ
--HG--
extra : rebase_source : b16ec01bdefc8fd847fc43513581aeb0efbf4e21
These were originally exposed directly as static methods on nsGlobalWindow, but
as they are clearly associated with either the inner or outer window, it makes
more sense for them to be called as such.
MozReview-Commit-ID: LFq8EfnhDlo
This is a large patch which tries to switch many of the external consumers of
nsGlobalWindow to instead use the new Inner or Outer variants.
MozReview-Commit-ID: 99648Lm46T5
We convert a _simplified_ specified transform list into a gfx matrix
by Servo backend. The _simplified_ means DOMMatrix only accepts a
transform list without any relative lengths, percentage, or other
keywords; otherwise, we throw a SyntaxError DOMException.
MozReview-Commit-ID: K8d30W0i60b
--HG--
extra : rebase_source : d0975eb53753405046c68c8bf89906ae93f2a675
According to the spec:
https://drafts.fxtf.org/geometry/#dommatrixreadonly,
we should use IsIdentity(), to pass most of the test cases.
MozReview-Commit-ID: 7qBAmuxwhUn
--HG--
extra : rebase_source : a04a994c39015733ebec13204d8415b470d42e67
Now, we use the CSS parser, instead of SVG parser, so we also need to
update the tests of DOMMatrix, i.e. we don't support unitless tranform
list on CSS parser.
MozReview-Commit-ID: 86F992rIa4J
--HG--
extra : rebase_source : 0f3b529b605ab765ea9c10c93cfb09f09234e7c3
If we don't enable autoplay, we have no need to delay it.
MozReview-Commit-ID: DgYCi1UyF5O
--HG--
extra : rebase_source : bfafba2f28e88e8e8c06d5d28958d430e2e2fb43
We check for them when the node doesn't have the MAY_BE_IN_BINDING_MNGR flag,
but the flag is not precise, so in presence of dynamic changes that somehow make
the node assigned, then unassigned, like changing the binding, it may not be
correct.
MozReview-Commit-ID: 9jyqCnR0yFn
--HG--
extra : rebase_source : 91e2e7b9b3bfb057d8213030ca17f8bff96adcb0
Migrated to simply use PopupNotifications.jsm. Additionally, this
changes the behavior to always have two buttons and a remember
checkbox. When selecting allow with remember, it will behave like
the always allow option previously, but when selecting block with
remember, it will move that page into a quiet mode with respect
to Flash - i.e., no plugin overlays will show anymore, and instead
you will just see the plugin icon in the URL bar, which you can
continue to interact with as before.
MozReview-Commit-ID: EUFlI7nM09t
--HG--
extra : rebase_source : 4f6fdaa602ea6c398cc646ba98282ee5c154956e
It's a sub-class of nsAtom, useful for cases where you know you are dealing
exclusively with static atoms. The nice thing about it is that you can use
raw nsStaticAtom pointers instead of RefPtr<>. (In fact, the AddRef/Release
implementations ensure that we'll crash if we use RefPtr<nsStaticAtom>.)
MozReview-Commit-ID: 4Q6QHX5h44V
--HG--
extra : rebase_source : e4237f85b4821b684db0ef84d1f9c5e17cdee428
This was automatically generated by the script modeline.py.
MozReview-Commit-ID: BgulzkGteAL
--HG--
extra : rebase_source : a4b9d16a4c06c4e85d7d85f485221b1e4ebdfede
These were detected by the script used to generate part 2.
MozReview-Commit-ID: VMcT154f6f
--HG--
extra : rebase_source : 2f5fc8a314302fcacac840a8dbe0ff874d518e51
This is a follow-up patch for bug 1392970. Since we only set CustomElementDefinition on a custom element
which is "custom", we could add more assertion to ensure that.
MozReview-Commit-ID: 2sLP53bAYVV
--HG--
extra : rebase_source : 523761aa7312ddfaaf91f79e39c44ddce5cf9335
Right now, NS_GENERIC_FACTORY_SINGLETON_CONSTRUCTOR expects singleton
constructors to return already-addrefed raw pointers, and while it accepts
constructors that return already_AddRefed, most existing don't do so.
Meanwhile, the convention elsewhere is that a raw pointer return value is
owned by the callee, and that the caller needs to addref it if it wants to
keep its own reference to it.
The difference in convention makes it easy to leak (I've definitely caused
more than one shutdown leak this way), so it would be better if we required
the singleton getters to return an explicit already_AddRefed, which would
behave the same for all callers.
This also cleans up several singleton constructors that left a dangling
pointer to their singletons when their initialization methods failed, when
they released their references without clearing their global raw pointers.
MozReview-Commit-ID: 9peyG4pRYcr
--HG--
extra : rebase_source : 2f5bd89c17cb554541be38444672a827c1392f3f
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
Every time a document is destroyed, we record whether MathML was enabled,
which is set to true when a MathML element was bound to the document.
'mathml.doc_count' will report how many such documents existed during a
session. It should be compared to MIXED_CONTENT_PAGE_LOAD, which counts the total number of all page loads.
MozReview-Commit-ID: Euf1apT2LhC
--HG--
extra : rebase_source : b8a55a4d8b59ddcb112aa85218c7b495c18b2627
Noemi Erli
Jan de Mooij
Ciure Andrei
John Dai
Csoregi Natalia
Jon Coppeard
Andrea Marchesini
Emilio Cobos Álvarez
Brindusan Cristian
arthur.iakab
Andrew McCreight
Jason Orendorff
Sebastian Hengst
Nika Layzell
Jonathan Watt
btara
Coroiu Cristina
Boris Zbarsky
Ting-Yu Lin
Chris Peterson
Edgar Chen
Gijs Kruitbosch
Samael Wang
Timothy Guan-tin Chien
Hiroyuki Ikezoe
Alastor Wu
Ben Kelly
Margareta Eliza Balazs
Brad Werth
Andreas Pehrson
Ryan VanderMeulen
Neil Deakin
Kris Maglione
Andreea Pavel
Masayuki Nakano
Yoshi Huang
Mats Palmgren
btian
Catalin Badea
Phil Ringnalda
Daosheng Mu
Martin Stransky
Attila Craciun
Dorel Luca
Johann Hofmann
Boris Chiou
Tooru Fujisawa
Andrew Osmond
Kyle Machulis
Doug Thayer
Bevis Tseng
Henri Sivonen
ZER0
Nicholas Nethercote
Jesse Ruderman
Gerald Squelart
Kartikaya Gupta