This patch was generated by the command:
find * -type f -exec sed -i -f ../mozpropsub {} \;
in the root of the repository, with the file ../mozpropsub containing:
s/-moz-padding-end\>/padding-inline-end/g
s/-moz-padding-start\>/padding-inline-start/g
s/-moz-margin-end\>/margin-inline-end/g
s/-moz-margin-start\>/margin-inline-start/g
s/-moz-border-end\>/border-inline-end/g
s/-moz-border-end-color\>/border-inline-end-color/g
s/-moz-border-end-style\>/border-inline-end-style/g
s/-moz-border-end-width\>/border-inline-end-width/g
s/-moz-border-start\>/border-inline-start/g
s/-moz-border-start-color\>/border-inline-start-color/g
s/-moz-border-start-style\>/border-inline-start-style/g
s/-moz-border-start-width\>/border-inline-start-width/g
s/\<MozPaddingEnd\>/paddingInlineEnd/g
s/\<MozPaddingStart\>/paddingInlineStart/g
s/\<MozMarginEnd\>/marginInlineEnd/g
s/\<MozMarginStart\>/marginInlineStart/g
s/\<MozBorderEnd\>/borderInlineEnd/g
s/\<MozBorderEndColor\>/borderInlineEndColor/g
s/\<MozBorderEndStyle\>/borderInlineEndStyle/g
s/\<MozBorderEndWidth\>/borderInlineEndWidth/g
s/\<MozBorderStart\>/borderInlineStart/g
s/\<MozBorderStartColor\>/borderInlineStartColor/g
s/\<MozBorderStartStyle\>/borderInlineStartStyle/g
s/\<MozBorderStartWidth\>/borderInlineStartWidth/g
The diffs for the following files:
layout/style/nsCSSPropAliasList.h
layout/style/test/property_database.js
layout/style/test/test_value_computation.html
were then manually removed from the patch.
MozReview-Commit-ID: 8fbYnlZcn9U
This patch was generated by the command:
find . -name "*.css" -exec sed -i -f mozpropsub {} \;
in the root of a mozilla-central tree, with the file mozpropsub
containing the contents:
s/-moz-padding-end\>/padding-inline-end/g
s/-moz-padding-start\>/padding-inline-start/g
s/-moz-margin-end\>/margin-inline-end/g
s/-moz-margin-start\>/margin-inline-start/g
s/-moz-border-end\>/border-inline-end/g
s/-moz-border-end-color\>/border-inline-end-color/g
s/-moz-border-end-style\>/border-inline-end-style/g
s/-moz-border-end-width\>/border-inline-end-width/g
s/-moz-border-start\>/border-inline-start/g
s/-moz-border-start-color\>/border-inline-start-color/g
s/-moz-border-start-style\>/border-inline-start-style/g
s/-moz-border-start-width\>/border-inline-start-width/g
While I didn't manually review all the changes, I did review the list of
files, and manually reviewed the changes in the files that I thought
were more interesting.
Note that there are a few tests that should be fixed up as well, but
I'll do that in a later patch.
MozReview-Commit-ID: EiQTuuV0MNQ
This adds a few basic tests for expectations of when we do and don't
restyle, construct frames, and reflow in response to changes of media
queries. They don't give us a lot of coverage, but often the tiny bits
of coverage at the beginning are the most useful.
In general, I'd like us to have more tests for specific optimizations,
i.e., for specific things that we expect not to happen in certain cases.
The elementsRestyled, framesConstructed, and framesReflowed getters on
DOMWindowUtils are a good way to make such measurements for a number of
things in layout; that's why I added them.
(Inspired a bit by bug 1259641.)
MozReview-Commit-ID: JFtlPO1eyoD
This adds support for #rgba and #rrggbbaa colors to CSS. This feature
is specified in https://drafts.csswg.org/css-color-4/#hex-notation .
This adds new types to nsCSSValue so that we can serialize the syntax
that was specified, as we do for other distinctions in how colors are
specified.
It does not change the behavior of the hashless color quirk, which
continues to support only 3 and 6 digit colors as specified in
https://quirks.spec.whatwg.org/#the-hashless-hex-color-quirk (step 4).
This changes property_database.js to remove various uses of 4 and 8
digit colors as invalid values. It then adds them in slightly fewer
places as valid values, but more thoroughly testing both initial and
non-initial values on 'color'.
It marks two canvas tests explicitly testing this feature as no longer
known to fail by removing their .ini files.
Finally, it adjusts the web platform test testing the hashless color
quirk to no longer treat 4 and 8 digit colors with hashes as invalid
values. Removing the relevant test items seems like the right thing
since they're in a section where 3 and 6 digit colors were skipped but
other lengths were tested. Modifying this imported test is OK since:
<jgraham> dbaron: Commit the change you want to m-c, it is
(semi-)automatically upstreamed every so often (typically
about once a week)
MozReview-Commit-ID: IFq4HxaRkil
This patch tells all callers to use the existing behavior, so it is
intended not to change behavior. Callers that will be modified in later
patches are marked with "FIXME" comments that will be removed in those
later patches (patches 3 and 4).
MozReview-Commit-ID: FaLryfxaeHv
I'm acting under the assumption that this is what's closest to what the
code does now, except without asserting in ~ErrorResult. It also seems
closest to what event listeners will do, both based on examining code
(EventListenerManager::HandleEventSubType, which I'm hoping is the right
code to look at, calls StealNSResult, and then stores it in a member
that's ignored by most callers) and based on testing (for both click
events, and for media query listeners with this patch, the exception
gets reported to the console as an unhandled exception). That said, I'm
not particularly well versed in the current error handling rules so I
may well be off here.
This code should presumably go away when we change this code to use
EventListeners in bug 1265622, so I don't think there's any spec that
covers this.
Without the patch, the mochitest hits the fatal assertion (after
reporting hitting the expected uncaught exception). With the
patch the test passes. (Tested locally.)
MozReview-Commit-ID: 5kxp6jzGzX8
--HG--
extra : transplant_source : n%B4%AE%99D%FB%B9NM%C0%A2%F0%D4%B7%8C%E7%DE4E%60
We use _pretty_path when specifying the targets of generated files, so
we need to use _pretty_path for the inputs as well. Otherwise make won't
know that they refer to the same file, and result in "No rule to make
target" errors.
MozReview-Commit-ID: JTdLFbkX1J0
Theoretically we should do the same for nsTreeBodyFrame, but that frame type is
harder to detect and I'm not sure it's worth adding code to support updating
background-position on XUL trees.
MozReview-Commit-ID: 8HPT53MX6bO
--HG--
extra : rebase_source : 1e84e83616832debe8f6da394630a5a2e014e7df
This revert the new C++11 syntax used in Part 19. which should fix build
errors for msvc 2013.
https://msdn.microsoft.com/en-us/library/9f53ks1w.aspx
--HG--
extra : amend_source : 95d5565f549358d26ffa7136fb4f8a1be1c66050
Theoretically we should do the same for nsTreeBodyFrame, but that frame type is
harder to detect and I'm not sure it's worth adding code to support updating
background-position on XUL trees.
MozReview-Commit-ID: 8HPT53MX6bO
--HG--
extra : rebase_source : 1e84e83616832debe8f6da394630a5a2e014e7df
In the initializer list of the copy constructor, mStrokeDasharray and
mStrokeDasharrayLength are both initialized to nullptr and 0
respectively. If aSource.mStrokeDasharray has value, they're further be
set to proper values later in the function body. In this way, the two
'else' clauses can be removed.
MozReview-Commit-ID: DGybV7zFcyo
--HG--
extra : rebase_source : fe7d6e73323e226ab304d1a45e29d192cdc8f39c
Eliminate the explicit destructor / placement new calls in SetType().
MozReview-Commit-ID: 1CtjX1AEbFR
--HG--
extra : rebase_source : 85c46087bb0aa1debe08789caecf15066a0f4704
mCachedOutlineWidth was not initialized. I set it to 0.
MozReview-Commit-ID: fqaoZj1iMm
--HG--
extra : rebase_source : 54b158e52fb2600602a93c8a6921716a16b4b32b
Theoretically we should do the same for nsTreeBodyFrame, but that frame type is
harder to detect and I'm not sure it's worth adding code to support updating
background-position on XUL trees.
MozReview-Commit-ID: 8HPT53MX6bO
--HG--
extra : rebase_source : 1e84e83616832debe8f6da394630a5a2e014e7df
Just like CSSPseudoElementType, which uses a special type to represent the
maximum length. We can replace "CSSPseudoClassType::NotPseudo + 1" with
"CSSPseudoClassType::MAX", which means the maximum length.
MozReview-Commit-ID: 4xH0avpWPqX
--HG--
extra : rebase_source : bc8b6a5bb5a84782dea891054b8ea4c5d7ea3db8
notPseudo is easy to be confused with NotPseudo, so using negation would be
better.
MozReview-Commit-ID: BtlS1A5YgD3
--HG--
extra : rebase_source : 9c9233fefd826f3c912ef4b31bf096f2d2c4d693
Unlike when returning an nsCOMPtr in a ternary operator or passing to a
function, I used .get() here, since the operation is actually unsafe and
deserves to be marked explicitly.
This adds testing for transitions on background-position-x/y, and makes sure we
no longer call check_distance for background-position, because
background-position is now a shorthand and no longer has its own distance
computation.
MozReview-Commit-ID: 82KVruCghGe
--HG--
extra : rebase_source : c7c85abc9bb7ff1987d7372635c0a9702715b761
This adds testing for transitions on background-position-x/y, and makes sure we
no longer call check_distance for background-position, because
background-position is now a shorthand and no longer has its own distance
computation.
MozReview-Commit-ID: 82KVruCghGe
--HG--
extra : rebase_source : 65e52287c141044df8ae490d461ebef3e8d403ec
Enlarge the touch target of the caret to the left, bottom, and right by
59% (13px) per bug 1262755 comment 7.
Since the touch target becomes larger, the carets on the <input> in
previous test might cause the next test to fail on <textarea> because it
will press on the caret when trying to focus on <textarea>. Add <br>
elements to testAccessibleCarets.html to separate these test fields.
MozReview-Commit-ID: JIwmuHJ2QsQ
--HG--
extra : rebase_source : 6fbfede7cc0e395402b5858d74480dcdd5606c35
Add a pref "layout.accessiblecaret.always_show_when_scrolling" defaults
to true on all platforms except b2g. When it is set to false, the carets
will be hidden during scrolling, which is the current behavior before
applying this change.
The pref "layout.accessiblecaret.extendedvisibility" was added for
Fennec to keep ActionBar open when carets temporarily hiding during
panning or zooming. Now we make carets always show by default, so the
pref can be removed. However, the floating toolbar still need to be
notified when the scrolling begins, so we dispatch "scroll" instead.
In gtest, the preference changes were in the middle of the test
function. To make the preference change clearer, I add new pref changes
or move the existing ones to the beginning of the test functions.
The 250ms transition effect added in ua.css is per request of UX
designer in bug 1249201 comment 12.
MozReview-Commit-ID: 8NGvDLPbtNY
--HG--
extra : rebase_source : 3f7a9ebdf4c70b0282dbf9e8f18cbe5cca656dbe
Enlarge the touch target of the caret to the left, bottom, and right by
59% (13px) per bug 1262755 comment 7.
Since the touch target becomes larger, the carets on the <input> in
previous test might cause the next test to fail on <textarea> because it
will press on the caret when trying to focus on <textarea>. Add two <br>
to testAccessibleCarets.html to separate the <input> and <textarea>.
MozReview-Commit-ID: JIwmuHJ2QsQ
--HG--
extra : rebase_source : 73b662980a5be55a4e3e31506437f2c26f65cd85
Keith Yeung
Mats Palmgren
CJKu
stefanh@inbox.com
Chris Peterson
L. David Baron
Carsten "Tomcat" Book
Phil Ringnalda
Xidorn Quan
Matt Woodrow
Cameron McCormack
Hiroyuki Ikezoe
Ryan VanderMeulen
Bobby Holley
Astley Chen
Mike Shal
Emilio Cobos Álvarez
Kyle Huey
Markus Stange
Daniel Holbert
Andi-Bogdan Postelnicu
Ting-Yu Lin
Brian Birtles
Jonathan Watt
Boris Chiou
Aryeh Gregor
Wes Kocher
Jared Wein
Ms2ger
Emilio Cobos Álvarez
Mantaroh Yoshinaga
Christoph Kerschbaumer
Botond Ballo
Wei-Cheng Pan
Jeremy Chen