There might be up to 2 Always-show-as-action button in ActionBar.
One for menu-options, one for 3rd-party app action-button, if any.
According to our design spec, the two buttons appearance should be
similiar, therefore now we create them by same method.
MozReview-Commit-ID: GPVteQR3hxr
--HG--
extra : rebase_source : f03b2dcda5864221abe301d1b1ce8f8c1c38752d
The inspector's DocumentWalker had several issues when trying to retrieve
children for a given node, especially if the starting node was filtered
out by the filter function of the walker.
If the starting node was provided by options.center or options.start
and if this starting node was filtered out by the walker's filter
then the walker would fallback to the first valid parent of this node.
eg with
parent1 > parent2 > [valid-node, invalid-node, valid-node]
When asking for the children of parent2, if the walker started on
"invalid-node", then the walker would instead use parent2 and in turn
we would retrieve the children of parent 1
To fix that we can either tell the walker wether it should fallback to a
sibling of the starting node or to a parent, or make sure that the nodes
provided to the walker are valid.
A second issue was with the utility methods _readForward and _readBackward.
They both use the next/previousSibling() methods of a walker in order to
collect all the valid siblings of the walker's current node. But they were
always including the current node of the walker in their return array. And
there is no guarantee that the walker's currentNode is actually valid for it's
filter.
eg with a walker containing [invalid-node-1, invalid-node-2, valid-node].
Let's say the walker is currently on valid-node and we call previousSibling
The walker will do 3 steps:
- this.walker.previousSibling() > returns invalid-node-2, fails filtering
- this.walker.previousSibling() > returns invalid-node-1, fails filtering
- this.walker.previousSibling() > returns null, stop looping and return null
But at this stage the internal walker still points to the last visited node
(invalid-node-1). So if _readForward/Backward blindly add the current node
of the walker, we might be returning invalid nodes.
MozReview-Commit-ID: 72Be7DP5ky6
--HG--
extra : rebase_source : 31e7d3321abef04243b741196d4ca6279cefd53a
The cctools-port build scripts were pulling and building the master branch
of the cctools-port repo, which means they'd build whatever was there
when they get triggered. I think this was copied from my build-cctools
script which did the same thing, so it's my fault in the end! This patch
pins a revision in the script so we'll build the same thing until we
explicitly update.
I also fixed the scripts to use git instead of tc-vcs, since tc-vcs prints
misleading error messages, and nothing else uses that anymore.
Finally, I removed the build-cctools script, since all the builds are using
cctools-port now so it doesn't serve any useful purpose.
MozReview-Commit-ID: 5myqHS4duor
--HG--
extra : rebase_source : 11231cbe49c7ba830a880bfa4600f0a24d61471d
The newer Theming API follows the WebExtension install flow, which uses
PopupNotifications to request permission before installation, show progress and
notify upon install completion. This patch makes sure that older LWTs follow that
same flow.
MozReview-Commit-ID: C7X2si0a47J
--HG--
extra : rebase_source : 76f6283818dd69f62c4d59b6b11c5e90d37145a2
Put back in line that was incorrectly removed previously, and add a test.
MozReview-Commit-ID: FEl8fT1uCDm
--HG--
extra : rebase_source : 549b4d9ab9c963ab5a92b81311cffe07fae6953c
By ISOBMFF spec, an init segment is made of an ftyp and a moov box. However the ftyp box serve little purpose as such and only the moov atom contains essential information.
Some streams incorrectly add ftyp box all accross the content, despite the ISOBMFF spec stating (4.3.1):
Box Type: `ftyp’
Container: File
Mandatory: Yes
Quantity: Exactly one (but see below)
Additionally, with this change the ftyp box may not be present in content following earlier spec. So we will now be able to play them.
MozReview-Commit-ID: KijlV5pPLby
--HG--
extra : rebase_source : c5d5ec643879b28b3fdf1b97364d856467ba5948
The init and media segment byte ranges were not offset by the amount of bytes currently parsed. Whenever a new init segment signature was seen we would recreate a container parser.
This would lead to invalid offsets later.
MozReview-Commit-ID: 8U7kTa7SK8O
--HG--
extra : rebase_source : 6b6e665e01db2685a423558b2d09ce36b9052974
Move this change to ActionBarPresenter. Use cross icon as close button
to match design spec.
MozReview-Commit-ID: JgUcKp7p7Bc
--HG--
extra : rebase_source : 8350b2d8684cd967cb7463949017c26db4ef1782
Connect the Servo types and functions for working with @page rules to Gecko.
This also adjusts the Stylo test expectations to match the current state with
@page support.
MozReview-Commit-ID: 513d05m51wK
--HG--
extra : rebase_source : aa92dc1ad4b3949418759b3893a918663ec6ee0c
Adds `ServoPageRule` for use as the CSSOM representation of @page rules parsed
by Servo.
MozReview-Commit-ID: 7AIErJmoZN
--HG--
extra : rebase_source : f47448b9053e6a49023799631ca1d36f058272f4
Extract a `CSSPageRule` base class from the existing Gecko `nsCSSPageRule`
class. This will be used in the next commit as the parent of a new
`ServoPageRule` for the Servo variant.
MozReview-Commit-ID: 1F3FWfVKH29
--HG--
extra : rebase_source : 5186cf2e233f3a757676a0127752faa8cc748cd4
test_page_parser.html tried to check parser behavior with a property that's not
allowed in an @page context, such as `position: absolute`. However, the test
forgot to apply the @page wrapper for this rule, so we weren't checking the
intended case after all.
MozReview-Commit-ID: LSd3aLwZAST
--HG--
extra : rebase_source : f841fcd1ae7e37eaa928e39e116cd9a6a5385f85
Reviewed by upsuper in https://bugzilla.mozilla.org/show_bug.cgi?id=1345206.
- [x] `./mach build -d` does not report any errors
- [x] `./mach test-tidy` does not report any errors
Source-Repo: https://github.com/servo/servo
Source-Revision: 80f6160580477d5ca984071eeeef26866be5c68e
--HG--
extra : subtree_source : https%3A//hg.mozilla.org/projects/converted-servo-linear
extra : subtree_revision : 7d1005d11d0e336b69f1cab1f7e007f774d0ba89
The debug code calls nsStyleContext::GetParent(), which is invalid in stylo.
Let's skip it.
MozReview-Commit-ID: 5opMaSuyoNr
--HG--
extra : rebase_source : e316b5d45ebe634a63ef0e44ed0b7183551551d4