It's not only more consistent (since we have a proper ParserContext there), but
also fixes a bunch of bugs where Gecko accidentally exposes and allows setting
internal state because of conversions from nsCSSPropertyID to PropertyId.
This adds the extra complexity of caring about aliases for longer, but that's
probably not a big deal in practice, since we have PropertyDeclarationId.
Source-Repo: https://github.com/servo/servo
Source-Revision: 3864f320e8c6ff707d5b11fe46d67c0677cd112a
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 41922d46e6c30b5ec9f5adebceac0978ab35b6e0
1. Bug 1363595 added support for retrieving accDefaultAction from the cache, but the value was never cached in the first place.
This would have meant that accDefaultAction was returning nothing to clients.
2. Since accDefaultAction is the name of the first action, we can also use this cached value for IAccessibleAction::name for index 0.
MozReview-Commit-ID: 6PGRH45kKdB
--HG--
extra : rebase_source : 52688f1e44ad7613c5dd14903b6240a51aa2d4eb
If the image request gets redirect on loading, HTMLImageElement.currentURI
(which corresponds to nsIImageLoadingContent.currentURI) would return the
original URI before redirect, making "Save Image" in the context menu use
incorrect URI and filename. Use currentRequestFinalURI instead to get
redirected URI.
MozReview-Commit-ID: Bd7Q36sH93b
--HG--
extra : rebase_source : 5a1cc56554d1429f3c5af1c8cecaa1d72471ed21
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
With this patch, we're able to clear the populated form already. However,
we need some ways to invalidate mResults in AutoCompleteController to get
new results instead of cached one for clear button once the form has been
populated.
MozReview-Commit-ID: 8No9FXWJv0p
--HG--
extra : rebase_source : 08f598c1f97ade3a3b0dc99e424d0f711c2d6671
This also changes URIUtils.cpp:DeserializeURI() to use the mutator to instantiate new URIs, instead of using their default constructor.
MozReview-Commit-ID: JQOvIquuQAP
--HG--
extra : rebase_source : e146624c5ae423f7f69a738aaaafaa55dd0940d9
`:dir()` pseudo class param now represented as enum variants.
---
- [X] `./mach build -d` does not report any errors
- [X] `./mach test-tidy` does not report any errors
- [X] These changes fix#16840
- [X] There are tests for these changes
Source-Repo: https://github.com/servo/servo
Source-Revision: 006202732f0bd8d2239bdd51898380bdbe0f0f1a
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : e9778d171eef1db2ebbf52b99d3255d50b2a60ec
In stylo, ComputedUrl and SpecifiedUrl happen to be the same. However, using
ComputedUrl can make code clearer that conversion.rs is for converting
computed values between gecko and servo types.
Source-Repo: https://github.com/servo/servo
Source-Revision: b74e71fdd1b20b66e59f4ccefb0706f89c789d0a
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : a38a7082be57b9435da370e6d84bd7499c35ad5c
HTMLEditRules::MaybeSplitAncestorsForInsert() may be called with a point in a
text and it needs to return given split point as is. Additionally, the given
point may be in a text node. So, it may not be represented with an
nsCOMPtr<nsIContent>.
Therefore, we need to add new member, EditorDOMPoint, to SplitNodeResult and
when MaybeSplitAncestorsForInsert() needs to return the given point as is,
it should use it.
Note that if the methods which return SplitNodeResult split some nodes actually,
the left node and/or the right node may be removed from the DOM tree. In this
case, EditorDOMPoint cannot store such orphan node. Therefore, we cannot
make mNextNode nor mPreviousNode EditorDOMPoint.
MozReview-Commit-ID: LwH8RZzkrmT
--HG--
extra : rebase_source : a5ae2328bef3d887c0bf4e1b9c4a4247b93a4ac0
Now, we can make HTMLEditRules::SplitAsNeeded() use |SplitNodeResult| as its
result and |const EditorRawDOMPoint&| as specifying start of the deepest right
node. Then, the implementation becomes simpler.
And I think that we should rename it to MaybeSplitAncestorsForInsert().
Additionally, this patch makes it stop calling
EditorBase::IsDescendantOfEditorRoot() and HTMLEditor::GetActiveEditingHost()
because they are really expensive. Instead, it should check if the given start
point of the deepest right node is in active editing host before the loop and
if the loop reaches editing host.
MozReview-Commit-ID: KKpj5uyT2J
--HG--
extra : rebase_source : 0c9e9e9e28505b0fb5752e1cd4d42f64d22af3e7
In the following patch, we need to invalidate offset a lot of places after
splitting nodes. Therefore, there should be a helper stack class before that.
MozReview-Commit-ID: BgijAU7OizU
--HG--
extra : rebase_source : 520f29dacdffe5f7137ba7f11b289241b5fbface
First of all, this patches fixes a bug of EditorBase::CreateNode(). It takes
|EditorRawDOMPoint&| but it should be |const EditorRawDOMPoint&| for making
callers can specify temporary instances.
Next, this patch creates |SplitNodeResult| stack class for result of
EditorBase::SplitNodeDeep(). SplitNodeDeep() needs to return previous node
and next node of split point. They are called as left node and right node,
but these calls are really different term usage. Therefore, this patch names:
aOutLeftNode -> SplitNodeResult::GetPreviousNode()
aOutRightNode -> SplitNodeResult::GetNextNode()
and also declares SplitNodeResult::GetLeftNode() and
SplitNodeResult::GetRightNode() which are same meaning as left/right node of
other splitting methods.
Additionally, of course, this patch makes SplitNodeDeep() use
|const EditorRawDOMPoint&| to receive the start point of right node.
MozReview-Commit-ID: FnJpeKgtzm4
--HG--
extra : rebase_source : 3829e5528ef837b13fed305e0df1dbbf00e02a07
Make the loop in EditorBase::SplitNodeDeep() use EditorDOMPoint for making the
code simpler.
MozReview-Commit-ID: 3do3rWV4eIh
--HG--
extra : rebase_source : 480a5b5b133d8a735bda6ddec07e4edf9ef34035
Now, we can merge two if blocks in the loop of EditorBase::SplitNodeDeep() and
get rid of |didSplit| variable.
MozReview-Commit-ID: LJZHF6x2GLR
--HG--
extra : rebase_source : 5f58508f6fc0928236252670c85383a13200fc2c
This doesn't change any meaning of the loop.
It is a bug if the loop meets orphan node before meeting the most ancestor
node to be split which is given as aNode. So, we can check it before trying
to split it.
MozReview-Commit-ID: 1TD7WHCoZh1
--HG--
extra : rebase_source : 17b8d7b3db458e29fb52be5cedb900560e1b70a4
EmptyContainers::yes and EmptyContainers::no are not so clear name what they
mean.
They means whether NodeSplitDeep() creates or won't create empty nodes when
split point is at start edge or end edge of an element.
This patch renames them to SplitAtEdges::eDoNotCreateEmptyContainer and
SplitAtEdges::eAllowToCreateEmptyContainer and make
HTMLEditor::InsertNodeAtPoint() use it instead of an bool argument.
Additionally, the argument of NodeSplitDeep() is now not optional because
this difference is really important when you read around the callers.
MozReview-Commit-ID: 9hpMRkVDvCg
--HG--
extra : rebase_source : ee892361d66c9c9c5ed45ee9d3321474257ac417
