To avoid trimming pixels at the top / left.
This makes it closer to non-WR[1], and fixes both the checkboxes getting
cut off and the master password field.
[1]: non-WR at least at 124 scaling on a hiDPI display is still perfect, though I saw nin symmetric borders at other resolutions, so we might be able to improve here further.
Differential Revision: https://phabricator.services.mozilla.com/D7251
--HG--
extra : moz-landing-system : lando
Adding a test to check whether the wakelock state is correct under different situations. However,
the lock state of power manager doesn't equal to the actual platform lock. Now we don't have any
way to detect whether platform lock is set correctly or not, but we can at least make sure the
specific topic's state in power manager is correct.
Differential Revision: https://phabricator.services.mozilla.com/D7355
--HG--
extra : moz-landing-system : lando
There are two reasons for this:
1) It's faster than running the connectedCallback in the middle of document parse, at least for
<radiogroups> in about:preferences
2) It provides a construction sequence more similar to XBL, so the translation from XBL <constructor>
to CE connectedCallback is more likely to be correct. This is because when there is markup like:
<parent-ce><child-ce></child-ce></parent-ce>
the parent-ce node is empty during the first connectedCallback. If we wait for DOMContentLoaded
then the parent-ce has the child-ce node below it.
Differential Revision: https://phabricator.services.mozilla.com/D7944
--HG--
extra : moz-landing-system : lando
This is designed to produce minimal output; just show which tests are
running and then provide details at the end for tests that gave an
unexpected result.
This is designed to produce minimal output; just show which tests are
running and then provide details at the end for tests that gave an
unexpected result.
Automatic update from web-platform-testsFixed object-src tests
As part of checking if the linked bug is still an issue, I have taken
the opportunity to fix the current mostly non-sensical tests.
Bug: 240058
Change-Id: I716d43d38be6dd161aa0437dbda03f2c77eb6d88
Reviewed-on: https://chromium-review.googlesource.com/c/1225886
Commit-Queue: Andy Paicu <andypaicu@chromium.org>
Reviewed-by: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596662}
--
wpt-commits: 2a988396ac8b119e11fdb7d84b00eff0ed81bfe2
wpt-pr: 13026
Automatic update from web-platform-testsAdd offsetLeft/offsetTop tests for non-atomic inlines.
Added a comment to LayoutInline, pointing out that LayoutNG seems to be
doing the right thing already, while legacy is wrong.
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: I0f906dab6efa7b3d4c72a297926d542f77251052
Reviewed-on: https://chromium-review.googlesource.com/c/1261575
Reviewed-by: Koji Ishii <kojii@chromium.org>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596657}
--
wpt-commits: f2ffe05524fd50e3d73d2cf67c3670b8120e6556
wpt-pr: 13357
Automatic update from web-platform-tests[LayoutNG] Correct getClientRects for inlines in vertical-rl.
In LayoutInline::GenerateLineBoxRects(), when collecting rectangles, for
each rectangle, we need to flip its block axis offset, to make it
relative to the block-start of the container, because this is what's
expected by the callback.
GenerateLineBoxRects() is used to implement Element.getClientRects()
(among other things). Added a test that used to fail with LayoutNG,
since this obviously lacked test coverage.
Also had to fix LayoutText::AbsoluteQuadsForRange(), or
fast/writing-mode/flipped-blocks-text-map-local-to-container.html
would regress. It used to pass because getClientRects for a text node
and getClientRects for an inline (separate code paths) had the same bug.
Also had to update NGPhysicalBoxFragment::AddSelfOutlineRects(). Now
that GenerateLineBoxRects() (called from LayoutInline::AddOutlineRects())
behaves consistently and always produces rectangles with the block offset
relative to the block-start of the container (rather than physical top or
left for NG), we need to flip vertical-rl rects to become purely physical
on our own.
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: I6a5d6ab6012c20b3a2fd943cb9cd3c6ee53bf052
Reviewed-on: https://chromium-review.googlesource.com/c/1257917
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Reviewed-by: Aleks Totic <atotic@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596576}
--
wpt-commits: a13506a26c944343ab0c51f6c13d8489b1df53d9
wpt-pr: 13344
Automatic update from web-platform-tests[LayoutNG] Correct clip-path reference box calculation.
We used coordinates relatively to the line box, while we were expected
by the caller to be relative to the containing block. Flipping for
writing mode was bogus for NG (but needed by legacy), since NG uses
truly physical coordinates.
Hardened tests to contain a leading line and padding, and leading
content on the first line of the clipped child.
Bug: 641907
Change-Id: I2b1b9ff4ea92a6405fcdffcf139842458b46442f
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Reviewed-on: https://chromium-review.googlesource.com/c/1257913
Reviewed-by: Koji Ishii <kojii@chromium.org>
Reviewed-by: Fredrik Söderquist <fs@opera.com>
Commit-Queue: Morten Stenshorne <mstensho@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596554}
--
wpt-commits: e9a0828c85819340f721f121aac19ab8eefa3439
wpt-pr: 13345
Automatic update from web-platform-testsMerge pull request #12957 from bocoup/csp-cleanup
[csp] Remove cookies following test completion
Approved by @andypaicu in
https://github.com/web-platform-tests/wpt/pull/12957
--
wpt-commits: 660a69402170f880e9cd17d9c8a5998b47d446bf
wpt-pr: 12957
Automatic update from web-platform-testsPython 3: Fix Content-Length header in slice().
This prevents a http.client.IncompleteRead error in the test.
--
wpt-commits: 685c5052e8b1fdc0170eb56770c85594508c685d
wpt-pr: 13348
Automatic update from web-platform-tests[html] Correct file generation logic
Previously, a very large asset was removed from WPT in favor of a Python
script which was intended to generate the equivalent data dynamically
[1]. This script had an error which caused it to generate files that far
exceeded the requested size (for example, "1kb" was interpreted as
approximately 1.1e1024 bytes instead of 1024 bytes).
Replace the generic script with a more targeted one which creates a
response that suites the needs of the corresponding test.
[1] https://github.com/web-platform-tests/wpt/pull/503
--
wpt-commits: 572fdb90e9fc9204e46bcd8169a14c24ba673693
wpt-pr: 13350
Automatic update from web-platform-testsMake Element#innerText to not collapse white space around inline-block
This patch makes |Element#innerText| not to collapse white space around inline-
block for improving interop.
Note: The spec doesn't explicitly mention about this.
Changes of AX test expectations added missing space after <input>.
TBR=dmazzoni@chromium.org
Bug: 890020
Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_layout_ng
Change-Id: I74a47fd5ba3a22ff17d9c36838a81b4277ac47cc
Reviewed-on: https://chromium-review.googlesource.com/c/1250825
Reviewed-by: Xiaocheng Hu <xiaochengh@chromium.org>
Commit-Queue: Yoshifumi Inoue <yosin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596485}
--
wpt-commits: a7d4565da88d4ebec1825279223fca9e7a4b2fac
wpt-pr: 13327
Automatic update from web-platform-tests[css-text] A leading white-space should break before handling overflow
Leading white-spaces are indeed breaking opportunities that should
prevent, if there are no other css properties forcing it, breaking text
in the middle of a word when honoring the word-wrap/overflow-wrap CSS
property.
We are doing so if the leading white-space sequence is longer than 1
character, but when we have a single leading white-space, we are missing
that breaking opportunity and we may lead to cases, like the one
described in the bug.
The root cause of the issue with single leading white-space breaking
opportunities is that the RewindToMidWordBreak expects certain width to
be committed in order to choose opportunities in previous runs if none
of the ones detected by the ICU LazyLineBreakIterator prevents the
overflow.
However, this breaking opportunity should be considered together
with other provided by the word-break CSS property (eg, break-word or
break-all), as it was agreed in the discussion [1] with the CSS WG.
This CL solves the issue identifying the single leading white-space
braking opportunity in a new class field flag, and using it to consider
this opportunity inside the mid-word breaking logic, or prevent to run
it completely in the cases where 'break-all' is not set.
This is basically a reland of 6ea2a2e7f3ef01e0c98424ce272a732ade92ad1a
but with some changes to avoid regressions like the one reported in
issue #866109.
[1] https://github.com/w3c/csswg-drafts/issues/2907
Bug: 854624
Change-Id: I1cc0f55050d54ea1e76c655cf6b3ef8bcc0b0e2c
Reviewed-on: https://chromium-review.googlesource.com/c/1209745
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Reviewed-by: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596406}
--
wpt-commits: e201d802a5cb75d4cf618b8f5e1efe0e34c4ba3b
wpt-pr: 12894
Automatic update from web-platform-testsPython 3: Encode text content in Response.iter_content().
--
wpt-commits: a49e7638c45072077a92916ae41a26873e15d59a
wpt-pr: 13337
Automatic update from web-platform-testsSwitch WebKit browser product to WebDriver executors (#13339)
Switch away from Selenium executors to WebDriverTestharnessExecutor and WebDriverRefTestExecutor for the WebKit browser product.
The browserVersion value is hard-coded to the 2.20 release series for the GTK+ port of WebKit as that's when the WebDriver functionality was introduced.
--
wpt-commits: dc97ad5a7865a4849678baf67c380a3cc7bb420b
wpt-pr: 13339
Automatic update from web-platform-testsInclude ended tracks when cloning MediaStreams.
This CL also covers the MediaStream constructor.
In addition, tests are moved to WPT.
Bug: 770908
Change-Id: I6db9a86e9ee839efc2b04b00ae8fc57f07d852c3
Reviewed-on: https://chromium-review.googlesource.com/c/1256796
Commit-Queue: Guido Urdaneta <guidou@chromium.org>
Reviewed-by: Harald Alvestrand <hta@chromium.org>
Cr-Commit-Position: refs/heads/master@{#596247}
--
wpt-commits: 425430423cbe2cc78a34b2e4732a0d4361052219
wpt-pr: 13321