Fix of bug 1320229 allowed to paste longer text than `maxlength` attribute of
`<input>` and `<textarea>` because it was thought that the longer text causes
"too long" invalidate state, makes users notified and prevent to submit
form data.
However, according to Bug 1636855 comment 7 (*1), it breaks a major enterprise
web app, SAP, at least because it sends form data without checking validity of
each form data and discards invalid data on server side silently.
According to bug 1636855 comment 24 (*2), one of new behavior's fault is
on Gecko side too. The style of `<input>` element or `<textarea>` element
which has too long text after pasting is changed when it loses focus.
Therefore, users can post the data before they know pasted data is too
long if sending the form data with `Enter` key or something immediately
after pasting (i.e., without moving focus) web apps handle it by themselves.
On the other hand, the original bug report, bug 1320229, should be solved in
the future especially in password field because users may register password
which is cut by `maxlength` silently and they don't use builtin password
manager, only the pasted password is saved, and then, they won't be able to
login as the account. This is really long standing issue of the web forms.
An article (*3) warned this to web developers in 2011. Therefore, we should
keep going advance for solving this issue at least in Nightly channel to get
more feedback from testers and web developers.
1 https://bugzilla.mozilla.org/show_bug.cgi?id=1636855#c7
2 https://bugzilla.mozilla.org/show_bug.cgi?id=1636855#c24
3 https://www.christophermanning.org/writing/dont-use-maxlength-on-password-inputs
Differential Revision: https://phabricator.services.mozilla.com/D78613
Automatic update from web-platform-tests
[ScrollTimeline] Update compositor timeline from blink timeline
Previously CompositorTimeline was updated on Animation level which
introduced a reverse dependency. This patch moves the update logic up
to AnimationTimeline level to fix this issue.
Bug: 921031
Change-Id: Iaaa92686003c741cad424eb9867a0993193c05c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2225853
Reviewed-by: Majid Valipour <majidvp@chromium.org>
Commit-Queue: Yi Gu <yigu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#774351}
--
wpt-commits: 15536297d85ebc2e9e0235fa69a6e7d4bec93231
wpt-pr: 23920
Automatic update from web-platform-tests
[webdriver] normalize and fix links to the WebDriver spec (#23911)
Spotted while looking for incoming links to the spec:
https://github.com/w3c/webdriver/issues/1462#issuecomment-637441468
(#dfn-set-window-rect changed to #set-window-rect for consistency, not
to enable the ID to be changed.)
--
wpt-commits: 5d0dcf0142d07916584db9c76c2fdec02833e959
wpt-pr: 23911
Automatic update from web-platform-tests
Remove MainThreadScrollingReasons::kHasClipRelatedProperty
We no longer need to skip composited scrolling for css clip and
clip-path since (perhaps) BlinkGenPropertyTrees.
In compositor, when we hit test on a layer with special clip/mask,
we'll still fallback to main thread hit testing/scrolling because only
the main thread knows which area is hit testable. This is achieved by
cc::LayerTreeHostImpl::IsInitialScrollHitTestReliable() returning false.
Bug: 1074395
Change-Id: I91260b063879812ca82928fe783de25c4b6732a3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2225229
Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org>
Reviewed-by: Philip Rogers <pdr@chromium.org>
Reviewed-by: Robert Flack <flackr@chromium.org>
Reviewed-by: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#774232}
--
wpt-commits: 4c2484a55b58a72b74c0b6c55ab0238cf11efb4a
wpt-pr: 23900
Automatic update from web-platform-tests
Fix support for StaticHandler without format_args
--
Support multiple PNGs per reftest comparison
This paves the way for print reftests in which each page will be a
seperate image. At present none of the output formats actually support
multiple images, so we always have to pick a single image to actually
output.
--
Add print-reftest support to the manifest
This adds a new test type to the manifest called print-reftest. Print
reftests are distinguished from normal reftests by filenames
containing -print as the type flag, or by being in directories called
'print'.
--
Vendor pdf.js
This only takes the compiled files necessary for our use case (in
particular build/pdf.js and build/pdf.worker.js from the PDFjs
distribution
--
Add basic print reftest support to marionette executor
Adds support for print reftests, as set out in RFC 41 [1]. This is
based on the WebDriver Print endpoint, using pdf.js to render the
pages of the generated PDF back to PNGs for comparison. The pdf.js
process itself runs in the browser, so there's quite a lot of
back-and-forth traffic involved; this approach is not fast. But we're
unlikely to get too many print reftests, so it's a useful baseline.
https://github.com/web-platform-tests/rfcs/pull/41
--
Add print reftest infrastructure test
--
Support print reftests in Chrome
This uses the underlying CDP command directly since PDF generation
isn't yet supported in Chrome. It also requires the browser to run in
headless mode since PDF generation is only supported in this mode.
--
Move wdspec detection higher in the order of precedence
This is primarilly so that print.py doesn't show up as a print reftest, but
also because wdspec tests are pretty easy to identify unambigously since they're
in a single subtree and are all python files.
--
Rename one WebDriverProtocol class as WdspecProtocol
This naming clash caused a confusing bug; really this class is only for wdspec tests.
--
Fix typo in docstring
Co-authored-by: Stephen McGruer <smcgruer@chromium.org>
--
wpt-commits: 14318a51c8bbb4f93da025d873d0cadcc352f19e, 7f8fed23452026c68eed6d2987eaef13b9a7f561, 13ec04fe7ba89fc2e532c710acb0afbcb4db3715, 96f15e060633d1c2470353acf1e23c31d85897d9, ed440d946653bfbd53eef6cd76314f548bdabeda, 51815349ffae146d3a822a1d9d72046a492709db, c8447fe1835f792d109a019523aca7cdfc6dd72d, b0e3c1ce95151503be5037c2888563f19cc5875e, 7ef00b794ca222b6e59b27997e0bc67c0398a7d6, e06c2c218f9a95d1a18cd175fddd6fe3d3a04d02
wpt-pr: 21901
Automatic update from web-platform-tests
[scroll-timeline] Correctly handle unresolvable cases
For these cases we cannot calculate a meaningful scroll offset:
1. When target is not a descendant of timeline's source.
2. When target has no layout box.
The current draft spec [1] asks for these situations to result into
unresolved scroll offset which keeps timeline inactive.
[1] https://github.com/w3c/csswg-drafts/pull/5124
TEST: wpt/scroll-animations/element-based-offset-unresolved.html
BUG: 1023375
Change-Id: Iec616444dda8dcdd6649e250aa993b439c00885e
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2222884
Reviewed-by: Majid Valipour <majidvp@chromium.org>
Reviewed-by: Yi Gu <yigu@chromium.org>
Commit-Queue: Majid Valipour <majidvp@chromium.org>
Cr-Commit-Position: refs/heads/master@{#774144}
--
wpt-commits: 52575c9d7c3139cab33780e114b5cf9237a47157
wpt-pr: 23889
Automatic update from web-platform-tests
Set color-scheme-senstive initial color via cascade
We currently adjust the computed value of 'color' on the document
element to simulate 'canvastext' behavior. However, there's an
incorrect assumption that it's safe to adjust whenever there are no
'color' declarations in the cascade.
During a transition, the base ComputedStyle is the destination style
for the transitioning element, and on the final frame of the
transition, the StyleEngine simply emits a copy of the base style,
without adding any declaration to the cascade. This causes color-
transitions on the document element to "snap back" to black (or white,
depending on color-scheme) when the transition ends.
This CL fixes this by adding an explicit value (CSSInitialColorValue)
which represents this behavior to the cascade. The value is added only
when computing the base style, which prevents incorrect adjustments on
top of the final transition frame.
Bug: 1087188
Change-Id: Ie0d95aaab5b93f1749e461fad0baf41a184f7cb6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2224222
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Reviewed-by: Kevin Ellis <kevers@chromium.org>
Commit-Queue: Anders Hartvoll Ruud <andruud@chromium.org>
Cr-Commit-Position: refs/heads/master@{#774178}
--
wpt-commits: c20b45a0352c65db0ef7f141edfd68d01f1516e2
wpt-pr: 23906
Automatic update from web-platform-tests
[css-grid] Consider 'auto' height items for grid area estimation
We perform a pre-layout, based on a estimation of the grid area, of the
grid items in two different situations: orthogonal and baseline aligned
items.
In the case of baseline aligned items, we were doing this pre-layout
only in the case of items with relative inline and block sizes. However,
items with 'auto' block-size also depend on this estimated grid area
size to properly compute the baseline offset.
It was discarded in the past due to performance concerns, since the
'auto' height is a very common case. However, this codepath is only
executed for baseline aligned items. Since we already applied several
optimization to the baseline alignment logic, I think we can try this
approach to solve the bug and evaluate potential perf regressions when
they appear.
Bug: 1086132
Change-Id: I73c39e6c3ad6cd74aa50fe33106e25cd63b7625f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2215054
Reviewed-by: Manuel Rego <rego@igalia.com>
Reviewed-by: Oriol Brufau <obrufau@igalia.com>
Commit-Queue: Javier Fernandez <jfernandez@igalia.com>
Cr-Commit-Position: refs/heads/master@{#774139}
--
wpt-commits: b4205f9f8b440e56da7fb2bd6cc26643296b02e1
wpt-pr: 23772
Automatic update from web-platform-tests
MathML: check that spacing is not added unless mrow layout is used. (#23916)
This is different from MathML3 which uses "inferred mrow", although
the MathML3 spec is not clear how spacing would be handled anyway and
whether <inferredmrow><mo></inferredmrow> is embellihed.
--
wpt-commits: 6fba8fd9df16c5152392595e6e4f255628b99c74
wpt-pr: 23916
Automatic update from web-platform-tests
[Sauce] Remove workaround that manually sets selenium version for edge (#23897)
This appears to be a leftover from the previous use of the sauce runner,
assumedly when there was some bug that required a specific version of
selenium to be used (it was sadly undocumented).
Fixes https://github.com/web-platform-tests/wpt/issues/23895
--
wpt-commits: d5aae4ab7f99e024f70aa0d93ca3748809995263
wpt-pr: 23897
Automatic update from web-platform-tests
Fix "blocked-iframe-are-cross-origin.html".
Reported by antoniosartori@, there was an error in the test:
"blocked_iframe-are-cross-origin.html"
In Javascript, lambda capture is done by reference. The reference was
the loop 'variable'. As a result the second test case was run twice.
The first test case couldn't work, because embedded enforcement do not
apply to same-origin iframes.
The patch fixes the test.
TBR=mkwst@chromium.org
Bug: 1041376
Change-Id: Id5f223aa138470cb263eea5b0af9f616a314a374
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2218049
Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org>
Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org>
Cr-Commit-Position: refs/heads/master@{#774065}
--
wpt-commits: 2e45d1610c21b55ac4dcf4c223964d0d8069f3ee
wpt-pr: 23795
Automatic update from web-platform-tests
COEP: do not test exception message
It's implementation-defined, see https://bugzilla.mozilla.org/show_bug.cgi?id=1642149.
--
wpt-commits: 5cf5c990b4e55923a055a04614dec1afa0439f9d
wpt-pr: 23907
Automatic update from web-platform-tests
test if link rel manifest is supported (#23816)
--
wpt-commits: fd60ba25a0726dfea59024d8143240b355c46a55
wpt-pr: 23816
Automatic update from web-platform-tests
Fix when atomic inline with self-painting layer is truncated
When |NGLineTruncator| sets |IsHiddenForPaint|, it does so by
cloning the original fragment. When hiding atomic inlines,
the fragment in the inline formatting context is cloned and
|IsHiddenForPaint| set, but the fragment cached in |LayoutBox|
is kept unchanged, without |IsHiddenForPaint|.
When such fragment has self-painting layer, the one in
|LayoutBox| is painted. To hide such fragments, we moved them
to outside of the clipping area, but this had visible side
effects to |scrollWidth|.
This patch stops moving them, but instead, check the fragment
in the inline formatting context when painting and hit-
testing.
Bug: 1005645
Change-Id: I8d1d55afd2a2f1b6c1b6672d5090476872cb4dee
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2220405
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Reviewed-by: Yoshifumi Inoue <yosin@chromium.org>
Commit-Queue: Koji Ishii <kojii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#773972}
--
wpt-commits: c9b407e11198cb935ed7b3a2bd5b800ea03d56e0
wpt-pr: 23843
Automatic update from web-platform-tests
Correct CSS2/css1/c414-flt-fit-000.xht and reference (#23904)
The reference did not match the test, as it did not have navy
everywhere the test had it. This fixes this by removing the navy from
both test and reference, as it served no purpose.
Additionally, the test depended upon the width of the nbsp relative
to the em-square; having observed this varying, this is now fixed by
making the table monospace in both test and reference.
--
wpt-commits: 1e92a2bbad550d907753eb8fb4eafe6425afd3f5
wpt-pr: 23904
Narcis Beleuzu
Mike Hommey
Masayuki Nakano
Andrei Oprea
Tomislav Jovanovic
Tom Schuster
James Graham
Sebastian Hengst
Csoregi Natalia
Jan de Mooij
moz-wptsync-bot
Yi Gu
Philip Jägenstedt
Xianzhu Wang
autofoolip
Domenic Denicola
Majid Valipour
Anders Hartvoll Ruud
Frédéric Wang
Javier Fernandez
Stephen McGruer
arthursonzogni
Anne van Kesteren
Aaron Gustafson
Koji Ishii
Sam Sneddon