Automatic update from web-platform-tests
Send `Sec-Fetch-User` only for user-activated, navigational requests.
As per the conversation in mikewest/sec-metadata#23 and
mikewest/sec-metadata#19, this patch drops the `Sec-Fetch-User` header
for non-navigational requests, and for navigational requests that are
not user-activated.
Bug: 947444
Change-Id: Ica4846bda6ccf4e8bce1323803954f4fef9c18a3
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1545871
Reviewed-by: Alex Moshchuk <alexmos@chromium.org>
Commit-Queue: Mike West <mkwst@chromium.org>
Cr-Commit-Position: refs/heads/master@{#646086}
--
wpt-commits: b93752a06f9498f774aed288663259cd738f1a7c
wpt-pr: 16148
Automatic update from web-platform-tests
[LayoutNG] Fix nested legacy oof descendants
Another fix for "Legacy OOF descendant did not get laid out"
The cause here was:
- if #container had a legacy descendant, and
- legacy descendant had an oof descendant whose containing block was
#container, that oof descendant would get added to #container's list
of legacy oof, but would never get laid out.
This bug was hidden, because it would not happen if layout happened
twice, which we often do.
Seen in the wild at https://www.humblebundle.com/ when scrolling down.
Bug: 946986
Change-Id: I183f3d5dfe79b49c5c6aadad0ee2cfcb8bb6849f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1546713
Commit-Queue: Aleks Totic <atotic@chromium.org>
Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org>
Auto-Submit: Aleks Totic <atotic@chromium.org>
Cr-Commit-Position: refs/heads/master@{#646077}
--
wpt-commits: 94cd32e64d89b561b803355c299c9db5908e0cb1
wpt-pr: 16158
Expose the driver vendor information (applies to Linux only at this
moment) to crash report telemetry and about:support. This will be useful
when debugging issues to know specifically what driver is in use.
Also expose the monitor information for Linux. Part 1 provides an
implementation to get the monitor information on said platform.
Differential Revision: https://phabricator.services.mozilla.com/D29472
This reunifies the behaviour changed in bug 1294232 to ensure that the
vendor ID of GfxInfo is the same between graphics hardware. Vendor ID
should always represent Intel, Nvidia, ATI, etc such that callers can
reason about the performance characteristics without being exposed to
the driver implementation for that platform. Now we split off the more
detailed driver information into the "driver vendor" which will contain
more information, such as what implementation is being used (e.g.
mesa/i965 for modern Intel graphics cards). This field is exposed to the
blocklist and will be useful for allowing different rules for different
driver implementations.
We also now provide a default implementation for
GfxInfoBase::FindMonitors for platforms missing support. This will just
list the primary screen size used without listing secondary monitors,
refresh rate, and such.
Differential Revision: https://phabricator.services.mozilla.com/D29471
Historically we calculated the snapping offsets in the GPU shaders.
Because this information is always needed on the CPU side, we now just
pass the values into the shader instead of recalculating again. This
ensures we will use the same set of values consistently and makes it
easier to adjust how we snap in the future.
This patch should have no functional change on the output of WebRender
itself.
Differential Revision: https://phabricator.services.mozilla.com/D28883
We currently do most snapping on the GPU in the shader. However the
picture's local rect needs to take into account the snapping done there,
so we need to calculate this earlier in the pipeline. Instead of using
the clipped primitive local rects to create the picture's own local
rect, we now snap the child local rects first. If no snapping is
required, there should be no functional change. If snapping is required,
there should be fewer visual distortions caused by an inaccurate picture
local rect.
Differential Revision: https://phabricator.services.mozilla.com/D28882
We currently calculate a picture's local rect when we are doing the
first picture traversal. It was composed of the union of the clipped
local rects of its children. However the true local rect of a picture is
the union of the snapped clipped local rects of its children. The
snapping is done in device space, but we won't know the exact transform
until we establish the raster roots, which is based on the picture's
local rect.
As such, we create an estimated local rect which is how we currently
calculate the local rect. Then once the raster roots have been selected,
we recalculate the local rect of the picture based on its children
during update visibility.
This patch should have not contain any functional changes.
Differential Revision: https://phabricator.services.mozilla.com/D28881
Ion does not compile the catch block so the analysis fails to account for code
there.
Differential Revision: https://phabricator.services.mozilla.com/D29475
--HG--
extra : moz-landing-system : lando
I considered adding BaselineInterpreter.{h,cpp} files but there are shared
helper functions so this might get awkward. Maybe once the rest of the code is
in we can experiment with changes in this area.
Differential Revision: https://phabricator.services.mozilla.com/D29158
--HG--
extra : moz-landing-system : lando
Added borders for error / warning messages. Reduced line height in message body. Added more space between device list / message and refresh device button
Differential Revision: https://phabricator.services.mozilla.com/D29652
--HG--
extra : moz-landing-system : lando
This trampoline isn't performance sensitive so platform-specific optimizations
are not worth it.
Differential Revision: https://phabricator.services.mozilla.com/D28601
--HG--
extra : moz-landing-system : lando
Fixed second line that has been cut off in the sidebar item detail of the remote runtime
Differential Revision: https://phabricator.services.mozilla.com/D29649
--HG--
extra : moz-landing-system : lando
This patch makes editors return new error code internally when clipboard event
is dispatched and canceled by script. This is for making each caller stop
handling the edit action. However, it's not actual failure. Therefore, making
public methods return `NS_SUCCESS_DOM_NO_OPERATION` instead via
`EditorBase::ToGenericNSResult()`.
Differential Revision: https://phabricator.services.mozilla.com/D28935
--HG--
extra : moz-landing-system : lando
Currently, this bug does not occur actually because nobody has not accessed
these command classes directly and they are registered only in command table
for HTML editor. However, once rewriting `nsHTMLDocument::ExecCommand()` with
these classes, its `IsCommandEnabled()` should return false if given editor
is `TextEditor`. The reason why we need this fix is, when we make
`ExecCommand()` call `IsCommandEnabled()` and it returns `true`, `ExecCommand()`
needs to call `DoCommand()`. Then, it throws exception if given editor is not
an `HTMLEditor` but the command class is only for `HTMLEditor`.
This patch adds new WPT for testing whether `document.execCommand()` works
with `<input>` and `<textarea>`. The behavior has not been standardized, but
Chromium handles some commands even in it. So, I write the expectations from
the point of view of web developers. (Chrome fails in "cut", "copy" and
"removeformat" cases.)
Differential Revision: https://phabricator.services.mozilla.com/D29473
--HG--
extra : moz-landing-system : lando
