The addition of unicode-plaintext to the pre element will make RTL text to appear from right to left. The html[dir] pre rule will make sure that this addition won't break the 'switch page direction' functionality.
MozReview-Commit-ID: 2JXJjqt2iuX
--HG--
extra : rebase_source : 98c85228ce50fa145bfaa77051532f69e92ba98d
Bug 1259889 Part 2 [1] cannot be reverted cleanly, so I manually undo those
changes in this patch. That is, remove the ability for html.css to
invalidate dynamically since it was added specifically for details element.
Although reftest-stylo.list explicit mentions "DO NOT EDIT!", but I still
remove details pref from the file, since it doesn't harm to edit it anyway.
[1] https://hg.mozilla.org/mozilla-central/rev/30aaf3805b56
MozReview-Commit-ID: FsyTGQTxujh
--HG--
extra : rebase_source : 25e5a05a8a5a47642772da69f427631fa07e232d
CLOSED TREE
Backed out changeset 235ea1c681db (bug 1271765)
Backed out changeset 02d34b18d76b (bug 1271765)
Backed out changeset 088113647629 (bug 1271765)
After the splitting of text overlay and the caret images, the caret image should
be placed from the top of #image div.
Delete those "top" style for Fennec since they're not needed anymore in current
setup.
MozReview-Commit-ID: Dn6jgqaFfek
--HG--
extra : rebase_source : 92b697db26cb7311fbd22a63e9f0ed71e6a434f4
The touch area of the caret element includes the caret image and the
text above the image. This patch split these two areas, and call the
area covering the text "text overlay".
MozReview-Commit-ID: KWNAwVRP7fN
--HG--
extra : rebase_source : 674dbec65e1c4b04413f9f35fe46aeea46480831
The children of the caret element already have unique class name like
"image" or "bar", we could change the class name to be id, and use id to
locate them.
MozReview-Commit-ID: HLZecyAEYXv
--HG--
extra : rebase_source : 04b59a4d639ad45d2b564f48de15c2f23752fdaf
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
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
Per html spec, the disclosure triangle can be generated via "display:
list-item", I removed the code to generate the triangle in
SummaryFrame::SetInitialChildList(). That is, when a web page set
"display: block" to the summary, the triangle will disappear, too.
Now SummaryFrame does nothing and is going to be removed in Part 2.
Also summary element should not increment the counter as hinted as
"counter-increment: list-item 0" in the spec. Hence the change in
nsBlockFrame::RenumberListsFor().
The rendering hint in html spec:
https://html.spec.whatwg.org/multipage/rendering.html#the-details-and-summary-elements
MozReview-Commit-ID: DELGYFe3zGX
--HG--
rename : layout/reftests/details-summary/open-summary-block-style.html => layout/reftests/details-summary/open-summary-block-style-ref.html
extra : rebase_source : 4bd5493fb6a1108eea31aef1d89f563f781b753f
We need to re-evaluate html.css whenever "dom.details_element.enabled"
is changed to make the disclosure triangle for summary elements show up.
Reftests for details and summary will need the a live pref to work.
MozReview-Commit-ID: 9SN1fQBuwA7
--HG--
extra : rebase_source : c8eafde9d3a97908c44099219603f76087d484b9
