Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bump socket.io from 0.8.7 to 2.3.0 in /testing/xpcshell/node-spdy/examples/twitlog #1

Conversation

dependabot[bot]
Copy link

@dependabot dependabot bot commented on behalf of github Sep 28, 2019

Bumps socket.io from 0.8.7 to 2.3.0.

Release notes

Sourced from socket.io's releases.

2.2.0

Features

  • add cache-control header when serving the client source (#2907)

Bug fixes

  • throw an error when trying to access the clients of a dynamic namespace (#3355)

Milestone: 2.2.0
Diff: 2.1.1...2.2.0
Client release: 2.2.0
Diff engine.io: socketio/engine.io@3.2.0...3.3.1
Diff ws: https://github.com/websockets/ws/compare/3.3.1..6.1.2

2.1.1

Features

(server) add local flag to the socket object (https://github-redirect.dependabot.com/socketio/socket.io/pull/3219)

socket.local.to('room101').emit(/* */);

Bug fixes

(client) fire an error event on middleware failure for non-root namespace (https://github-redirect.dependabot.com/socketio/socket.io-client/pull/1202)

Milestone: 2.1.1
Diff: 2.1.0...2.1.1 (client diff)

2.1.0

Features

  • add a 'binary' flag (#3185)
// by default, the object is recursively scanned to check whether it contains some binary data
// in the following example, the check is skipped in order to improve performance
socket.binary(false).emit('plain-object', object);

// it also works at the namespace level
io.binary(false).emit('plain-object', object);
  • add support for dynamic namespaces (#3195)
io.of(/^\/dynamic-\d+$/).on('connect', (socket) => {
</tr></table> ... (truncated)
Commits
  • 47161a6 [chore] Release 2.3.0
  • cf39362 [chore] Bump socket.io-parser to version 3.4.0
  • 4d01b2c test: remove deprecated Buffer usage (#3481)
  • 8227192 [docs] Fix the default value of the 'origins' parameter (#3464)
  • 1150eb5 [chore] Bump engine.io to version 3.4.0
  • 9c1e73c [chore] Update the license of the chat example (#3410)
  • df05b73 [chore] Release 2.2.0
  • b00ae50 [feat] Add cache-control header when serving the client source (#2907)
  • d3c653d [docs] Add Touch Support to the whiteboard example (#3104)
  • a7fbd1a [fix] Throw an error when trying to access the clients of a dynamic namespace...
  • Additional commits viewable in compare view
Maintainer changes

This version was pushed to npm by darrachequesne, a new releaser for socket.io since your current version.


Dependabot compatibility score

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

  • @dependabot rebase will rebase this PR
  • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
  • @dependabot merge will merge this PR after your CI passes on it
  • @dependabot squash and merge will squash and merge this PR after your CI passes on it
  • @dependabot cancel merge will cancel a previously requested merge and block automerging
  • @dependabot reopen will reopen this PR if it is closed
  • @dependabot ignore this [patch|minor|major] version will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
  • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
  • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
  • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
  • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
  • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

You can disable automated security fix PRs for this repo from the Security Alerts page.

@dependabot dependabot bot added the dependencies Pull requests that update a dependency file label Sep 28, 2019
gecko-dev-updater pushed a commit that referenced this pull request Sep 28, 2019
UltraBlame original commit: 98ca9bd48170aac6a183a165a57b28f05a41b4f5
gecko-dev-updater pushed a commit that referenced this pull request Sep 28, 2019
UltraBlame original commit: 31fa915e4a920e50c2430b79a8dd74b282840921
gecko-dev-updater pushed a commit that referenced this pull request Sep 28, 2019
UltraBlame original commit: 30da794ae32ca71964099e32577ef8f370036ded
gecko-dev-updater pushed a commit that referenced this pull request Sep 28, 2019
UltraBlame original commit: b7d0f477f873814e06c9b77e60264788f582ec44
gecko-dev-updater pushed a commit that referenced this pull request Sep 28, 2019
…e, bug 782877

UltraBlame original commit: 74c6fc2c4ad1993020627a800cf5681707cf5222
@marco-c marco-c closed this Sep 29, 2019
@dependabot @github
Copy link
Author

dependabot bot commented on behalf of github Sep 29, 2019

OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting @dependabot ignore this major version or @dependabot ignore this minor version.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

@dependabot dependabot bot deleted the dependabot/npm_and_yarn/testing/xpcshell/node-spdy/examples/twitlog/socket.io-2.3.0 branch September 29, 2019 01:27
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
UltraBlame original commit: 7e00fac588dcafab6101b9590048c90bd35f62e4
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
UltraBlame original commit: 773937adfcacaafa0aded135ac9b95cc5b93b73c
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
UltraBlame original commit: c936da8dd34aaa0e0173cf5bb3359aae16ef86a3
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
UltraBlame original commit: 3e73c00a7db1b29bf69116839bc72facf9ebf0f7
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
UltraBlame original commit: fa6b60d827d4795c00be982b2d26f014e110f66d
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
UltraBlame original commit: a6d60a556ed4dbcc24e475c0c82ead4304d882f5
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
UltraBlame original commit: d4f61f0a66fd084876fc00fbbfbae9532801d29a
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
UltraBlame original commit: 024f4fcbdfdb1919de16455bf45be9adaf86ccc2
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
UltraBlame original commit: 2199300dce2744caadd111ce4cdf2066d345e577
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
UltraBlame original commit: 064524edbea2edc04bcd13713361eeeb570a605a
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
========

https://hg.mozilla.org/integration/gaia-central/rev/3c7ae072e684
Author: Kyle Machulis <kylenonpolynomial.com>
Desc: Merge pull request #16096 from qdot/969650-move-customization-sample-to-gaia

Bug 969650 - Add customization sample to gaia

========

https://hg.mozilla.org/integration/gaia-central/rev/8715b511cbd5
Author: Kyle Machulis <kylenonpolynomial.com>
Desc: Bug 969950 - Cleaning up distribution sample

========

https://hg.mozilla.org/integration/gaia-central/rev/de97a5d865ef
Author: Kyle Machulis <kylenonpolynomial.com>
Desc: Bug 969650 - Subtree merge of yurenju/gaia-distribution-sample

========

https://hg.mozilla.org/integration/gaia-central/rev/eb9ae9a4503f
Author: Yuren Ju <yurenjugmail.com>
Desc: Merge pull request #3 from jds2501/simbookmarks

Update SIM bookmark customization to include sample mcc mnc US SIM customization, r=yurenju

========

https://hg.mozilla.org/integration/gaia-central/rev/705efd9c2fcd
Author: jds2501 <jsmithmozilla.com>
Desc: Update SIM bookmark customization to include sample mcc mnc US SIM customization

========

https://hg.mozilla.org/integration/gaia-central/rev/72e64b8de4b1
Author: Yuren Ju <yurenjugmail.com>
Desc: Merge pull request #2 from KevinGrandon/master

Add calendar.json r=yurenju

========

https://hg.mozilla.org/integration/gaia-central/rev/56feb8a57eb1
Author: Kevin Grandon <kevingrandonyahoo.com>
Desc: Add calendar.json

========

https://hg.mozilla.org/integration/gaia-central/rev/90aef8c4de58
Author: gasolin <gasolingmail.com>
Desc: Create README.md

========

https://hg.mozilla.org/integration/gaia-central/rev/8f96ae99b519
Author: Yuren Ju <yurenjugmail.com>
Desc: Merge pull request #1 from gasolin/patch-1

add runtime customize for bookmark setting, r=yurenju

========

https://hg.mozilla.org/integration/gaia-central/rev/80285b122244
Author: gasolin <gasolingmail.com>
Desc: add runtime customize for bookmark setting

========

https://hg.mozilla.org/integration/gaia-central/rev/4e64191b5493
Author: Yuren Ju <yurenjugmail.com>
Desc: Initial commit

UltraBlame original commit: 5b5c102a852fc77dd3723965763f1a233308d3cb
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
UltraBlame original commit: 3dd34ac404382ce20611435cf593f3fbca7bdb10
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
…c; r=unfocused

UltraBlame original commit: 73782d1e750ca18b5d803c2b3be2da966c0890ea
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
…y; r=unfocused

UltraBlame original commit: 60de42b54f914c88aa60dfdcae116acfe9dda9fe
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
…ck, children toggle three times (on click #1, click #2 and dblclick events). Ignore the dblclick on arrow. r=vp

UltraBlame original commit: b5345b8463af3140d9c4ca24c40503c35901de93
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
…; r=glandium

FileCopier.copy() was performing a lot of os.path.normpath() operations.
Profiling revealed that os.path.normpath() was the function with the
most wall time CPU usage when processing the tests manifests. Upon
subsequent examination of the code in question, all the paths being used
were already normalized. So, os.path.normpath() wasn't accomplishing
anything.

This patch results in ~300ms reduction in wall time to process the tests
install manifest on a fully populated page cache. Execution time drops
from ~2.8s to ~2.5s.

Profiling reveals that after this patch os.stat() is the #1 wall time
consumer. However, os.path.{join,dirname,normpath} still account for
~1.5x the wall time of os.stat(). There is still room to optimize
this function.

UltraBlame original commit: def38e936db8e43ce8faa85426637b942098dbe3
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
… fires, causing orange. r=orange

Example stack, from editor/libeditor/tests/browserscope/test_richtext2.html :

###!!! ASSERTION: should only call on first continuation/ib-sibling: 'nsLayoutUtils::IsFirstContinuationOrIBSplitSibling(this)', file /builds/slave/m-in-l64-d-0000000000000000000/build/src/layout/base/../generic/nsIFrame.h, line 875
#1: AdjustAppendParentForAfterContent [layout/base/nsCSSFrameConstructor.cpp:6059]
#2: nsCSSFrameConstructor::ContentAppended(nsIContent*, nsIContent*, bool) [layout/base/nsCSSFrameConstructor.cpp:7155]
#03: PresShell::ContentAppended(nsIDocument*, nsIContent*, nsIContent*, int) [layout/base/nsPresShell.cpp:4520]
#04: nsNodeUtils::ContentAppended(nsIContent*, nsIContent*, int) [dom/base/nsNodeUtils.cpp:132]
#05: nsINode::doInsertChildAt(nsIContent*, unsigned int, bool, nsAttrAndChildArray&) [dom/base/nsINode.cpp:1544]
#06: nsINode::ReplaceOrInsertBefore(bool, nsINode*, nsINode*, mozilla::ErrorResult&) [dom/base/nsINode.cpp:2209]
#07: mozilla::dom::NodeBinding::appendChild [obj-firefox/dom/bindings/NodeBinding.cpp:600]

UltraBlame original commit: 98e34be1fb44344c1173d9d3c981b3e5a2da4762
gecko-dev-updater pushed a commit that referenced this pull request Sep 29, 2019
…ical

Otherwise we can get a crash with the following stack:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 14711]
0x5d99974e in mozilla::gl::GLContext::BeforeGLCall (this=0x6dbf0800,
    funcName=0x60f251a4 <mozilla::gl::GLContext::raw_fDeleteProgram(unsigned int)::__PRETTY_FUNCTION__> "void mozilla::gl::GLContext::raw_fDeleteProgram(GLuint)") at /home/roc/mozilla-inbound/gfx/gl/GLContext.h:683
683	        MOZ_ASSERT(IsCurrent());
(gdb) where
#0  0x5d99974e in mozilla::gl::GLContext::BeforeGLCall (this=0x6dbf0800,
    funcName=0x60f251a4 <mozilla::gl::GLContext::raw_fDeleteProgram(unsigned int)::__PRETTY_FUNCTION__> "void mozilla::gl::GLContext::raw_fDeleteProgram(GLuint)") at /home/roc/mozilla-inbound/gfx/gl/GLContext.h:683
#1  0x5d99bed6 in mozilla::gl::GLContext::raw_fDeleteProgram (this=0x6dbf0800, program=210003)
    at /home/roc/mozilla-inbound/gfx/gl/GLContext.h:2232
#2  0x5d99c10a in mozilla::gl::GLContext::fDeleteProgram (this=0x6dbf0800, program=210003)
    at /home/roc/mozilla-inbound/gfx/gl/GLContext.h:2270
#3  0x5daa0ae6 in mozilla::layers::ShaderProgramOGL::~ShaderProgramOGL (this=0x6d7df000, __in_chrg=<optimized out>)
    at /home/roc/mozilla-inbound/gfx/layers/opengl/OGLShaderProgram.cpp:491
#4  0x5da86bdc in mozilla::layers::CompositorOGL::CleanupResources (this=0x67ae4d70)
    at /home/roc/mozilla-inbound/gfx/layers/opengl/CompositorOGL.cpp:177

UltraBlame original commit: b745c996a71d8c56d12e04bdcaa7a508c3940a5c
gecko-dev-updater pushed a commit that referenced this pull request Sep 30, 2019
========

https://hg.mozilla.org/integration/gaia-central/rev/4b3f0f6f7fd0
Author: albertopq <albert.pastorgmail.com>
Desc: Merge pull request #33389 from albertopq/1228288-store-meta

Bug 1228288 - Saving meta data into the places store r=bfrancis

========

https://hg.mozilla.org/integration/gaia-central/rev/4b89becdc423
Author: albertopq <albert.pastorgmail.com>
Desc: Bug 1228288 - Saving meta data into the places store

========

https://hg.mozilla.org/integration/gaia-central/rev/197520ddab1b
Author: Johan Lorenzo <jlorenzomozilla.com>
Desc: Merge pull request #33441 from JohanLorenzo/bug-1228972

Bug 1228972 - Delete tests already ported to Gij - round #1

========

https://hg.mozilla.org/integration/gaia-central/rev/095c3b6b7043
Author: Johan Lorenzo <jlorenzomozilla.com>
Desc: Bug 1228972 - Gallery - Delete tests already ported to Gij - round #1

========

https://hg.mozilla.org/integration/gaia-central/rev/7e4f334f3bfc
Author: Johan Lorenzo <jlorenzomozilla.com>
Desc: Bug 1228972 - Settings - Delete tests already ported to Gij - round #1

========

https://hg.mozilla.org/integration/gaia-central/rev/350ae4e691a5
Author: Johan Lorenzo <jlorenzomozilla.com>
Desc: Bug 1228972 - Music - Delete tests already ported to Gij - round #1

========

https://hg.mozilla.org/integration/gaia-central/rev/091696625757
Author: Johan Lorenzo <jlorenzomozilla.com>
Desc: Bug 1228972 - Lockscreen - Delete tests already ported to Gij - round #1

========

https://hg.mozilla.org/integration/gaia-central/rev/d872fbfb598b
Author: Johan Lorenzo <jlorenzomozilla.com>
Desc: Bug 1228972 - Homescreen - Delete tests already ported to Gij - round #1

========

https://hg.mozilla.org/integration/gaia-central/rev/115588dd811e
Author: Johan Lorenzo <jlorenzomozilla.com>
Desc: Bug 1228972 - System - Delete tests already ported to Gij - round #1

========

https://hg.mozilla.org/integration/gaia-central/rev/c52e75b2b5fa
Author: Johan Lorenzo <jlorenzomozilla.com>
Desc: Bug 1228972 - FTU - Delete tests already ported to Gij - round #1

========

https://hg.mozilla.org/integration/gaia-central/rev/6252beb48658
Author: Johan Lorenzo <jlorenzomozilla.com>
Desc: Bug 1228972 - Cards View - Delete tests already ported to Gij - round #1

========

https://hg.mozilla.org/integration/gaia-central/rev/f946fb9eb23e
Author: Johan Lorenzo <jlorenzomozilla.com>
Desc: Bug 1228972 - Keyboard - Delete tests already ported to Gij - round #1

========

https://hg.mozilla.org/integration/gaia-central/rev/4dd3c6115ed7
Author: Staś Małolepszy <stasmozilla.com>
Desc: Merge pull request #33275 from stasm/1222207-music-localize-headers

Bug 1222207 - Wait for l10n.ready when switching views. r=justindarc f=gandalf

========

https://hg.mozilla.org/integration/gaia-central/rev/da6695ef7a75
Author: Staś Małolepszy <stasmozilla.com>
Desc: Bug 1222207 - Wait for l10n.ready when switching views. r=justindarc f=gandalf

========

https://hg.mozilla.org/integration/gaia-central/rev/4ffe259d99f7
Author: Ray Lin <ralinmozilla.com>
Desc: Merge pull request #33438 from raylin/1210673-media-storgae-to-dialog-service

Bug 1210673 - Replaced dialog with dialog service in media storage se…

========

https://hg.mozilla.org/integration/gaia-central/rev/493e73599d10
Author: Ray Lin <ralinmozilla.com>
Desc: Bug 1210673 - Replaced dialog with dialog service in media storage settings,
r=gasolin

UltraBlame original commit: 193d37e53f6d627082081b0d61944581a39b241e
gecko-dev-updater pushed a commit that referenced this pull request Sep 30, 2019
jprof is an in-tree profiling tool that runs on Linux.

This fixes the error:

Sandbox: seccomp sandbox violation: pid 29698, syscall 38, args 0 140731305513136 0 830 22509600 1.  Killing process.
Sandbox: crash reporter is disabled (or failed); trying stack trace:
Sandbox: frame #1: __GI_setitimer (/build/glibc-GKVZIf/glibc-2.23/time/../sysdeps/unix/syscall-template.S:84)
Sandbox: frame #2: startSignalCounter(unsigned long) (.../mozilla-central/mozilla/tools/jprof/stub/libmalloc.cpp:464)

which occurs during shutdown when running with jprof enabled via the
JPROF_FLAGS environment variable containing JP_DEFER without actually
sending the signal to start jprof.  It presumably occurs sooner if jprof
is actually used either via JP_START or by senging a SIGPROF/SIGALRM.

With the patch, these steps run to completion.

MozReview-Commit-ID: Fx4tzEyqIj2

UltraBlame original commit: eadaa06966fefa5ea284da51a8d58ef2423edf47
gecko-dev-updater pushed a commit that referenced this pull request Oct 4, 2019
…sawin

It's easier this way than fixing who knows how many Webextension APIs that have
learned from Desktop that there is no tab #0 and that therefore refuse to work
in our first tab.

We'll also make a similar change to GeckoView's stub implementation of the tab
API because that affects Custom Tabs and PWAs in Fennec for now.

Differential Revision: https://phabricator.services.mozilla.com/D26431

UltraBlame original commit: f7cce6a270c2a76e51a1ef5fecf8f2c00ade2d3d
gecko-dev-updater pushed a commit that referenced this pull request Oct 4, 2019
…sawin

It's easier this way than fixing who knows how many Webextension APIs that have
learned from Desktop that there is no tab #0 and that therefore refuse to work
in our first tab.

We'll also make a similar change to GeckoView's stub implementation of the tab
API because that affects Custom Tabs and PWAs in Fennec for now.

The tests for tab ID 0 are therefore no longer required - they were added in a
previous attempt to fix the Webextension APIs themselves, which was ultimately
never carried through to completion, though.

Differential Revision: https://phabricator.services.mozilla.com/D26431

UltraBlame original commit: 5519079b4dc05033c01baec3e80ff673c3a44f11
gecko-dev-updater pushed a commit that referenced this pull request Oct 4, 2019
…or fixed, a=testonly

Automatic update from web-platform-tests
[LayoutNG] Fix for DCHECK(NeedsLayout) for fixed

All tests pass, and crashes no longer happen. I believe
that code will not longer crash, but there might be
futher instances of incorrect positioning.

Fix #1
LayoutDescendantCandidates did not sweep newly discovered
candidates. This was done
manually once inside NGOutOfFlowLayoutPart::Run, and
sweep was not performed for LayoutDescendantCandidates
found in Legacy. Fix is to make LayoutDescendantCandidates
perform sweep instead.

Fix #2
fix #1 exposed a bug where duplicate fragments were generated
for a single layout object. This happened when NG was generating
fragments not inside ContainingBlock. Fix one instance of this
inside NGOutOfFlowLayoutPart::IsContainingBlockForDescendant
by making sure that OOF with inline containers are only positioned
inside its ContainingBlock()

Fix #3
NGOutOfFlowLayoutPart::LayoutDescendant offset adjustment.

Bug: 935805
Change-Id: I9f7ebbc7223f40fbbf6ba3739d9385bfd59e3641
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1517093
Commit-Queue: Aleks Totic <atoticchromium.org>
Reviewed-by: Morten Stenshorne <mstenshochromium.org>
Reviewed-by: Koji Ishii <kojiichromium.org>
Cr-Commit-Position: refs/heads/master{#641628}

--

wpt-commits: c748846db4d54c5b1c93659d9458698871a98eea
wpt-pr: 15794

UltraBlame original commit: 0cde4bc00951941966bdcbb02d95d4281b388071
gecko-dev-updater pushed a commit that referenced this pull request Oct 4, 2019
…or fixed, a=testonly

Automatic update from web-platform-tests
[LayoutNG] Fix for DCHECK(NeedsLayout) for fixed

All tests pass, and crashes no longer happen. I believe
that code will not longer crash, but there might be
futher instances of incorrect positioning.

Fix #1
LayoutDescendantCandidates did not sweep newly discovered
candidates. This was done
manually once inside NGOutOfFlowLayoutPart::Run, and
sweep was not performed for LayoutDescendantCandidates
found in Legacy. Fix is to make LayoutDescendantCandidates
perform sweep instead.

Fix #2
fix #1 exposed a bug where duplicate fragments were generated
for a single layout object. This happened when NG was generating
fragments not inside ContainingBlock. Fix one instance of this
inside NGOutOfFlowLayoutPart::IsContainingBlockForDescendant
by making sure that OOF with inline containers are only positioned
inside its ContainingBlock()

Fix #3
NGOutOfFlowLayoutPart::LayoutDescendant offset adjustment.

Bug: 935805
Change-Id: I9f7ebbc7223f40fbbf6ba3739d9385bfd59e3641
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1517093
Commit-Queue: Aleks Totic <atoticchromium.org>
Reviewed-by: Morten Stenshorne <mstenshochromium.org>
Reviewed-by: Koji Ishii <kojiichromium.org>
Cr-Commit-Position: refs/heads/master{#641628}

--

wpt-commits: c748846db4d54c5b1c93659d9458698871a98eea
wpt-pr: 15794

UltraBlame original commit: 19bb7a1ca6b5c75ca2dd3eddb648d2849097070a
gecko-dev-updater pushed a commit that referenced this pull request Oct 4, 2019
…e changes to 'none'", a=testonly

Automatic update from web-platform-tests
Revert "Correctly handle scroll-snap-type changes to 'none'"

This reverts commit 712c3cf3ed8201420acf23f760eaa34be20781cd.

Reason for revert: This patch causes webkit-layout-tests failure on WebKit_Linux_Trusty_ASAN bot:
https://ci.chromium.org/p/chromium/builders/ci/WebKit%20Linux%20Trusty%20ASAN/25720

Unexpected Failures:
* external/wpt/css/css-scroll-snap/scroll-snap-type.html
* virtual/threaded/external/wpt/css/css-scroll-snap/scroll-snap-type.html

STDERR: ==1==ERROR: AddressSanitizer: heap-use-after-free on address 0x61200023f8d8 at pc 0x5620c924e56d bp 0x7ffde3c56830 sp 0x7ffde3c56828
STDERR: READ of size 8 at 0x61200023f8d8 thread T0 (content_shell)
STDERR:     #0 0x5620c924e56c in get ./../../base/memory/scoped_refptr.h:212:27
STDERR:     #1 0x5620c924e56c in Style ./../../third_party/blink/renderer/core/layout/layout_object.h:1615:0
STDERR:     #2 0x5620c924e56c in GetPhysicalSnapType ./../../third_party/blink/renderer/core/page/scrolling/snap_coordinator.cc:88:0
STDERR:     #3 0x5620c924e56c in blink::SnapCoordinator::UpdateSnapContainerData(blink::LayoutBox&) ./../../third_party/blink/renderer/core/page/scrolling/snap_coordinator.cc:107:0
STDERR:     #4 0x5620c924e74b in blink::SnapCoordinator::UpdateAllSnapContainerData() ./../../third_party/blink/renderer/core/page/scrolling/snap_coordinator.cc:76:5

Original change's description:
> Correctly handle scroll-snap-type changes to 'none'
>
>
> Previously when a scroll container's snap type is changed to 'none' its
> data was discarded including all of its snap areas. However this is
> incorrect. Because while the snap type is 'none', the element is still
> a scroll container which per spec [1] means  that is should continue to
> captures the snap areas in its subtree for whom it is the nearest
> ancestor scroll container . The only difference is that it no longer
> snaps.
>
> The fix is that we no longer remove the snap container data just
> because is has a 'none' snap type and instead keep it and its snap
> areas. But we check the snap type before performing any snap.
>
> To ensure this does not introduce any performance regression, this CL
> also includes an optimization where we avoid re-calculating
> snap_container_data when the snap type is 'none'. So keeping these snap
> data should not be cheap.
>
> Note that there is another problem where if the current snap container
> is no longer a scroll container (e.g., overflow: scroll => overflow:
> visible) we release its snap areas and they become "orphan". But if we
> are to do this correctly, we should re-assign these areas to the next
> stroller in the chain. Similarly when an element becomes a scroll
> container, it can potentially take over snap areas from its parent snap
> container.
>
>
> This patch does not address that situation yet but fixes the easier
> problem.
>
> [1] https://drafts.csswg.org/css-scroll-snap/#overview
>
> Bug: 953575
> Test:
>  - wpt/css/css-scroll-snap/scroll-snap-type-change.html => Changing snap-type should work correctly
>  - wpt/css/css-scroll-snap/scroll-snap-type.html => Add a specific test for type 'none' to ensure it does not snap
>
> Change-Id: Ie493ad68ecba818ed41c0ee103ccf44725ff6e3f
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1589899
> Reviewed-by: Majid Valipour <majidvpchromium.org>
> Reviewed-by: David Bokan <bokanchromium.org>
> Commit-Queue: Majid Valipour <majidvpchromium.org>
> Cr-Commit-Position: refs/heads/master{#657460}

TBR=bokanchromium.org,majidvpchromium.org

Change-Id: I3a327f6e342e95d045194d24ceaf49de52b2b921
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug: 953575
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1600437
Reviewed-by: Takashi Sakamoto <tasakgoogle.com>
Commit-Queue: Takashi Sakamoto <tasakgoogle.com>
Cr-Commit-Position: refs/heads/master{#657571}

--

wpt-commits: 59ffeb608fd8491995002d5c1dce17d4e49c5291
wpt-pr: 16724

UltraBlame original commit: a30529ab6ca794ff3db0d1e60cca65bf1696cb87
gecko-dev-updater pushed a commit that referenced this pull request Oct 4, 2019
…directly as far as possible r=smaug

Most commands are dispatched only when the `document` has `contenteditable` or
in `designMode`.  In such case, command context is considered with the following
order:
1. `HTMLEditor` for the document.
2. `TextEditor` if the document has focus and it has `TextEditor`.
3. Other command controller table associated with window or DocShell.

In the case of #1 and #2, `ExecCommand()` can use `EditorCommand` directly
and we only need to send subject principal to the editor only in these cases.

In the case of #3, we need to fall back to traditional path.  There are 2 paths:
1. If it's "paste" command, handle it with `nsCommandManager` to dispatch
   "paste" event.
2. If it's "cur" or "copy", handle it with `DocShell` to dispatch "cut" or "copy"
   event in the window or focused sub-document.

Note that clipboard "cut" and "copy" commands are special cases.  Only them
were handled by `DocShell` instead of `nsCommandManager`  This difference
caused making active element's `TextEditor` is preferred rather than
`HTMLEditor`.  Although this behavior is better than our traditional behavior
because Chromium works as so.  But for now, we should keep our behavior.

Finally, this patch makes `ExecCommand()` creates `nsCommandParams` instance
since now, `EditorCommand` class can take only necessary parameter without it.

Differential Revision: https://phabricator.services.mozilla.com/D29632

UltraBlame original commit: 258c4da663ca41039139ef94be6ec7e7f3f2333d
gecko-dev-updater pushed a commit that referenced this pull request Oct 4, 2019
…localhost., a=testonly

Automatic update from web-platform-tests
Cookie Store API: Fix crashes on http://localhost.

Issue #1:
The "SecureContext" IDL attribute considers localhost to be secure, but
the Cookie Store API assumed that it would only be exposed on
cryptographically secure origins, so a DCHECK caused attempts to
set/delete cookies on http://localhost to crash.

This CL replaces the DCHECK with an exception that is thrown on attempts
to set/delete secure cookies on cryptographically insecure origins.

Issue #2: The "secure" cookie attribute defaulted to true.
Setting/deleting a secure cookie on a cryptographically insecure origin
is prohibited. The cookieStore.delete() API excluded the option to set
the "secure" attribute, however, so there was no way to delete an
insecure cookie.

This CL defaults the "secure" attribute to true on cryptographically
secure origins, and false otherwise.

Bug: 956641
Change-Id: Iff7c22713e8604d60b68d42199a74b2d08235712
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1700357
Commit-Queue: Staphany Park <staphanychromium.org>
Reviewed-by: Victor Costan <pwnallchromium.org>
Cr-Commit-Position: refs/heads/master{#681054}

--

wpt-commits: 2e135c03ff73a7102011f4e610dc7890eb4332a1
wpt-pr: 17988

UltraBlame original commit: cb02577a9d4b821c86d81196c4d2a2181f1cc751
gecko-dev-updater pushed a commit that referenced this pull request Oct 4, 2019
…after overflow recalc, a=testonly

Automatic update from web-platform-tests
[Layout] bugfix: Update scrollable area after overflow recalc

Bug is:

  <container overflow:scroll>
    <target transform:scale(1)>

Initially, container's scrollbars are disabled.
When target changes its scale and grows outside of container,
scrollbars were not updated.
Fix #1 is to call UpdateScrollbarEnabledState. This resulted in
scrollbars being painted, but not clickable.
Fix #2, calling UpdateScrollableAreaSet makes scrollbars
clickable too.
Fix #2 was an educated guess.

Bug: 926167
Change-Id: I02454047c87aaecede9c56db1c02bbd1b21b15c5
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1704218
Commit-Queue: Aleks Totic <atoticchromium.org>
Reviewed-by: Stefan Zager <szagerchromium.org>
Cr-Commit-Position: refs/heads/master{#681091}

--

wpt-commits: a00fc0867640cf60333bc8831fad1170881e67d7
wpt-pr: 17868

UltraBlame original commit: ced9dbc351f58d3d24d3ef4461ed269817839b4f
gecko-dev-updater pushed a commit that referenced this pull request Nov 30, 2019
…hen there's an override container height, a=testonly

Automatic update from web-platform-tests
[css-flexbox] Don't cache definiteness when there's an override container height

See stack trace below. We set the override container logical height to -1
for the initial layout of a flex item so that we compute the correct size
for min-height. However, that messes with our cache for definite heights
because we would always set it to indefinite in such a case.

Instead, just don't cache these values. That way we will later compute the right
thing for resolving flex-basis, etc.

(FlexNG can't come soon enough...)

 #0  blink::LayoutBox::ContainingBlockLogicalHeightForPercentageResolution (this=0x3dda8d434198,
    out_cb=0x7f6e7d42d8c0, out_skipped_auto_height_containing_block=0x0)
    at ../../third_party/blink/renderer/core/layout/layout_box.cc:3833
 #1  0x00007f6ee84ad0a1 in blink::LayoutFlexibleBox::MainAxisLengthIsDefinite (this=0x3dda8d434010,
    child=..., flex_basis=Length(0%, Percent), add_to_cb=false)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:762
 #2  0x00007f6ee84af930 in blink::LayoutFlexibleBox::MainSizeIsDefiniteForPercentageResolution (
    this=0x3dda8d434010, child=...)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1125
 #3  0x00007f6ee84ad7f5 in blink::LayoutFlexibleBox::UseOverrideLogicalHeightForPerentageResolution (
    this=0x3dda8d434010, child=...)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1137
 #4  0x00007f6ee83f2b9d in blink::LayoutBlock::AvailableLogicalHeightForPercentageComputation (
    this=0x3dda8d434198) at ../../third_party/blink/renderer/core/layout/layout_block.cc:2333
 #5  0x00007f6ee845e745 in blink::LayoutBox::ContainingBlockLogicalHeightForPercentageResolution (
    this=0x3dda8d4243d0, out_cb=0x0, out_skipped_auto_height_containing_block=0x0)
    at ../../third_party/blink/renderer/core/layout/layout_box.cc:3830
 #6  0x00007f6ee86dcc5c in blink::LayoutBoxUtils::AvailableLogicalHeight (box=..., cb=0x3dda8d434198)
    at ../../third_party/blink/renderer/core/layout/ng/layout_box_utils.cc:64
 #7  0x00007f6ee86eafea in blink::LayoutNGMixin<blink::LayoutBlockFlow>::ComputeIntrinsicLogicalWidths (
    this=0x3dda8d4243d0, min_logical_width=0px, max_logical_width=0px)
    at ../../third_party/blink/renderer/core/layout/ng/layout_ng_mixin.cc:48
 #8  0x00007f6ee83ef53a in blink::LayoutBlock::ComputePreferredLogicalWidths (this=0x3dda8d4243d0)
    at ../../third_party/blink/renderer/core/layout/layout_block.cc:1509
 #9  0x00007f6ee8451f01 in blink::LayoutBox::MaxPreferredLogicalWidth (this=0x3dda8d4243d0)
    at ../../third_party/blink/renderer/core/layout/layout_box.cc:1395
 #10 0x00007f6ee84adba2 in blink::LayoutFlexibleBox::ComputeInnerFlexBaseSizeForChild (this=0x3dda8d434198,
    child=..., main_axis_border_and_padding=0px, child_layout_type=blink::LayoutFlexibleBox::kForceLayout)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:890
 #11 0x00007f6ee84ae5d1 in blink::LayoutFlexibleBox::ConstructAndAppendFlexItem (this=0x3dda8d434198,
    algorithm=0x7f6e7d42ed70, child=..., layout_type=blink::LayoutFlexibleBox::kForceLayout)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1203
 #12 0x00007f6ee84aa27b in blink::LayoutFlexibleBox::LayoutFlexItems (this=0x3dda8d434198,
    relayout_children=true, layout_scope=...)
    at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:934
 #13 0x00007f6ee84a9cff in blink::LayoutFlexibleBox::UpdateBlockLayout (this=0x3dda8d434198,
    relayout_children=true) at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:369

Bug: 1019138
Change-Id: Ie94e69a5f3fe6accc3623d358315b174088d5597
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1902514
Commit-Queue: David Grogan <dgroganchromium.org>
Auto-Submit: Christian Biesinger <cbiesingerchromium.org>
Reviewed-by: David Grogan <dgroganchromium.org>
Cr-Commit-Position: refs/heads/master{#713296}

--

wpt-commits: 8642cbbba24a10e8a34b4a2720062261f29be5dd
wpt-pr: 20137

UltraBlame original commit: bc2d69b245a2ed6eeeaadab6dcbc852f0c78eb3c
gecko-dev-updater pushed a commit that referenced this pull request Jan 28, 2020
…ot element., a=testonly

Automatic update from web-platform-tests
Implement new effect behavior for the root element.

Intent-to-ship approval:
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/4DC56FN3paU

Changes are:
1. The background of the root element paints into the property tree
state that includes the local border box effect state of the root
element.
2. If #1 is happening, paint a separate backdrop in the ContentsProperties
state of the LayoutView, to allow effects, clips and transforms of the
root element to apply via PaintChunksToCcLayer.

Bug: 898293,988446,1029170,711955

Change-Id: I751e3f9c23d0b06a31cf1b13c3853180bc7ac7e6
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1979258
Commit-Queue: Chris Harrelson <chrishtrchromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhuchromium.org>
Cr-Commit-Position: refs/heads/master{#733661}

--

wpt-commits: 4209d7961bab7dce31baab0918fa9f6dcd74bd8d
wpt-pr: 21242

UltraBlame original commit: e5a0f5814dbe91399bf60d884fb4711ba63cbdc3
gecko-dev-updater pushed a commit that referenced this pull request Feb 27, 2020
…r=m_kato

Its result has 4 meanings:

1. an editable block element for container of `mScanStartPoint`.
2. a topmost inline editable content for container of `mScanStartPoint` if there
is no editable block parent.
3. container of `mScanStartPoint` if it's a block (either editable or
non-editable).
4. container of `mScanStartPoint` if its parent is not editable and a inline
content.

#1, #2 and editable case of #3 make sense because the results are topmost
editable content in current context.  On the other hand, non-editable case
of #3 and #4 are caused by unexpected wrong fallback code.

So, let's make it always returns the content in the former meaning and if
the caller needs the latter one, they should use the container by themselves.
Therefore, for making what's the start of the search, this patch also makes
new method take start content instead of hiding `mScanStartPoint` from the
callers.

Differential Revision: https://phabricator.services.mozilla.com/D63610

UltraBlame original commit: f8505320d2165dd86f8fbb212ffe87397a814aaf
gecko-dev-updater pushed a commit that referenced this pull request Mar 13, 2020
Now that `fix_stacks.py` is being used instead of `fix_macosx_stack.py`,
stack-fixing time has dropped from about 14 minutes to about 30 seconds on my
new MacBook Pro.

Also, print a warning about stacks not being fixed if `MOZ_DISABLE_STACK_FIX`
is set. This warning shows up at the start of the test run.

Also, print a warning about stack fixing slowness, because 30 seconds is long
enough to possibly be surprising. This warning shows up just before the first
stack frame is fixed, like this:
```
Assertion failure: false (BEEP BOOP), at /home/njn/moz/au3/dom/base/nsGlobalWindowOuter.cpp:1342
Initializing stack-fixing for the first stack frame, this may take a while...
#1: nsGlobalWindowOuter::nsGlobalWindowOuter(unsigned long) (/home/njn/moz/au3/dom/base/nsGlobalWindowOuter.cpp:1342)
#2: ...
```

Differential Revision: https://phabricator.services.mozilla.com/D65676

UltraBlame original commit: 9d6c366e7cde369c65ddb85b258dbacbf396e65e
gecko-dev-updater pushed a commit that referenced this pull request Apr 25, 2020
…tive shadow roots, a=testonly

Automatic update from web-platform-tests
Hide the .content() property for declarative shadow roots

With this CL, the .content() property of a declarative shadow root
(a <template shadowroot="open|closed"> element being parsed) will return
null. Note that this <template> element only exists during parsing,
and upon the closing </template> tag being encountered by the parser,
the shadowroot will be created, the <template> contents will be moved
into the shadowroot, and the <template> itself will be deleted. So
this change is only visible from MutationObservers and other script
that runs *during* parsing. This CL prevents that script from accessing
the contents of the (potentially closed) shadow root.

See point #1 at [1] for more context.

[1] whatwg/dom#831 (comment)

Bug: 1042130
Change-Id: Id096d1b65dc94b7a75afdc6143341eb4521da41a
Cq-Do-Not-Cancel-Tryjobs: true
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2133308
Commit-Queue: Mason Freed <masonfreedchromium.org>
Reviewed-by: Kouhei Ueno <kouheichromium.org>
Reviewed-by: Kent Tamura <tkentchromium.org>
Auto-Submit: Mason Freed <masonfreedchromium.org>
Cr-Commit-Position: refs/heads/master{#759495}

--

wpt-commits: c6631ffd84d9d40cbc0a1f2871bf06f1bf547b24
wpt-pr: 22874

UltraBlame original commit: 7a8bc5291980ce2ec34568c0da44c5e57c7dc7a8
gecko-dev-updater pushed a commit that referenced this pull request Sep 16, 2020
…efs that could affect font inflation change. r=kats

When I start setting the pref ui.useOverlayScrollbars in bug 1663537 we trigger this assert

```
###!!! ASSERTION: can't mark frame dirty during reflow: '!mIsReflowing', file /builds/worker/checkouts/gecko/layout/base/PresShell.cpp, line 2677
#1: mozilla::PresShell::MaybeReflowForInflationScreenSizeChange() [layout/base/PresShell.cpp:11148]
#2: mozilla::PresShell::CompleteChangeToVisualViewportSize() [layout/base/PresShell.cpp:11177]
#03: MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&) [layout/base/MobileViewportManager.cpp:504]
#04: MobileViewportManager::RefreshVisualViewportSize() [layout/base/MobileViewportManager.cpp:557]
#05: nsHTMLScrollFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/nsGfxScrollFrame.cpp:1340]
#06: nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, int, nsIFrame::ReflowChildFlags, nsReflowStatus&, nsOverflowContinuationTracker*) [layout/generic/nsContainerFrame.cpp:1115]
#07: mozilla::ViewportFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/ViewportFrame.cpp:297]
#08: mozilla::PresShell::DoReflow(nsIFrame*, bool, mozilla::OverflowChangedTracker*) [layout/base/PresShell.cpp:9650]
#09: mozilla::PresShell::ProcessReflowCommands(bool) [layout/base/PresShell.cpp:9816]
#10: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [layout/base/PresShell.cpp:4239]
#11: nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:2139]
```

This happens after the test is finish when we unset the ui.useOverlayScrollbars pref which (I'm assuming because it must) causes reflow. When running a font-inflation related reftest we also unset the font inflation related prefs that were specified in the reftest.list file. This causes font-inflation to go from enabled to disabled and we detect that for the first time while reflowing the scroll frame.

Instead we should reflow when any pref that could affect font inflation is changed. I scanned the font-inflation code in PresShell and Document::GetViewportInfo for prefs are consulted, but I didn't go a super exhaustive search.

Differential Revision: https://phabricator.services.mozilla.com/D89409

UltraBlame original commit: 6698b842822e238196b46001e4d4770bb8781bec
gecko-dev-updater pushed a commit that referenced this pull request Sep 16, 2020
The test fixes all fell into the follow categories:

A) The test uses requestAnimationFrame to wait one frame and expects scrolling to be complete. With the desktop zooming scrollbars in order for the scrolling to show up on the main thread we need to send the scroll request to the compositor and then hear back from it via an apz repaint request (apz callback helper). Waiting on requestAnimationFrame will complete the first part, but not necessarily the second part. The fix is to wait for a scroll event.

B) Switching tests to wait for scroll events exposes another problem: the test can do things that cause a scroll in order to setup the test (and that may not be obvious that it causes a scroll) before actually proceeding to do the test and do something that causes a scroll and then checks for the scroll change of the second thing. Waiting for a requestAnimationFrame would include both those scrolls without desktop zooming scrollbars, but if we wait for a scroll event we will get the scroll event for the first thing which we are not interested in. So we need to make sure scroll events are cleared out before waiting for any scroll events. We do this by waiting two requestAnimationFrame's and waiting for apz to be flushed. We also use this when a test does something and it wants to test that scrolling is not performed.

The main thing that causes scrolling that may not be obvious: calling node.focus(). With stacks like:

from test_scroll_per_page.html

```
#1: mozilla::ScrollFrameHelper::CompleteAsyncScroll(nsRect const&, mozilla::ScrollOrigin) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x47d6cc0]
#2: mozilla::ScrollFrameHelper::ScrollToWithOrigin(nsPoint, mozilla::ScrollMode, mozilla::ScrollOrigin, nsRect const*, nsIScrollbarMediator::ScrollSnapMode) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x47d7732]
#03: mozilla::layout::ScrollAnchorContainer::ApplyAdjustments() [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4742913]
#04: mozilla::PresShell::FlushPendingScrollAnchorAdjustments() [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4650069]
#05: mozilla::PresShell::ProcessReflowCommands(bool) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x465742b]
#06: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4656af8]
#07: mozilla::dom::Document::FlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1a87d3c]
#08: mozilla::PresShell::ScrollContentIntoView(nsIContent*, mozilla::ScrollAxis, mozilla::ScrollAxis, mozilla::ScrollFlags) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4652b96]
#09: nsFocusManager::ScrollIntoView(mozilla::PresShell*, nsIContent*, unsigned int) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1bedd1c]
#10: nsFocusManager::Focus(nsPIDOMWindowOuter*, mozilla::dom::Element*, unsigned int, bool, bool, bool, bool, bool, nsIContent*) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be6be0]
#11: nsFocusManager::SetFocusInner(mozilla::dom::Element*, int, bool, bool) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be212f]
#12: nsFocusManager::SetFocus(mozilla::dom::Element*, unsigned int) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be32ba]
#13: mozilla::dom::Element::Focus(mozilla::dom::FocusOptions const&, mozilla::dom::CallerType, mozilla::ErrorResult&) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1aaf283]
#14: mozilla::dom::HTMLElement_Binding::focus(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x2d65f3b]
```

from editor/libeditor/tests/test_bug549262.html

```
#1: mozilla::ScrollFrameHelper::CompleteAsyncScroll(nsRect const&, mozilla::ScrollOrigin) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x47d6cc0]
#2: mozilla::ScrollFrameHelper::ScrollToWithOrigin(nsPoint, mozilla::ScrollMode, mozilla::ScrollOrigin, nsRect const*, nsIScrollbarMediator::ScrollSnapMode) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x47d7732]
#03: mozilla::PresShell::ScrollFrameRectIntoView(nsIFrame*, nsRect const&, mozilla::ScrollAxis, mozilla::ScrollAxis, mozilla::ScrollFlags) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x46541bc]
#04: mozilla::PresShell::DoScrollContentIntoView() [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4653776]
#05: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4656b11]
#06: mozilla::dom::Document::FlushPendingNotifications(mozilla::ChangesToFlush) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1a87d3c]
#07: mozilla::PresShell::ScrollContentIntoView(nsIContent*, mozilla::ScrollAxis, mozilla::ScrollAxis, mozilla::ScrollFlags) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x4652b96]
#08: nsFocusManager::ScrollIntoView(mozilla::PresShell*, nsIContent*, unsigned int) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1bedd1c]
#09: nsFocusManager::Focus(nsPIDOMWindowOuter*, mozilla::dom::Element*, unsigned int, bool, bool, bool, bool, bool, nsIContent*) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be6be0]
#10: nsFocusManager::SetFocusInner(mozilla::dom::Element*, int, bool, bool) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be212f]
#11: nsFocusManager::SetFocus(mozilla::dom::Element*, unsigned int) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1be32ba]
#12: mozilla::dom::Element::Focus(mozilla::dom::FocusOptions const&, mozilla::dom::CallerType, mozilla::ErrorResult&) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x1aaf283]
#13: mozilla::dom::HTMLElement_Binding::focus(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&) [/Users/tim/ffopt2/src/obj-x86_64-apple-darwin19.6.0/toolkit/library/build/XUL + 0x2d65f3b]
```

C) Several tests use nsIDOMWindowUtils advanceTimeAndRefresh/restoreNormalRefresh and expect scrolling to be done after a call to advanceTimeAndRefresh. This is basically A), advanceTimeAndRefresh does a refresh driver tick but doesn't allow a repaint request to come back to the main thread.

Differential Revision: https://phabricator.services.mozilla.com/D89403

UltraBlame original commit: 30cd33572b3d5c4bfa8e5883396dc3aa84a62e0b
gecko-dev-updater pushed a commit that referenced this pull request Sep 16, 2020
…efs that could affect font inflation change. r=kats

When I start setting the pref ui.useOverlayScrollbars in bug 1663537 we trigger this assert

```
###!!! ASSERTION: can't mark frame dirty during reflow: '!mIsReflowing', file /builds/worker/checkouts/gecko/layout/base/PresShell.cpp, line 2677
#1: mozilla::PresShell::MaybeReflowForInflationScreenSizeChange() [layout/base/PresShell.cpp:11148]
#2: mozilla::PresShell::CompleteChangeToVisualViewportSize() [layout/base/PresShell.cpp:11177]
#03: MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&) [layout/base/MobileViewportManager.cpp:504]
#04: MobileViewportManager::RefreshVisualViewportSize() [layout/base/MobileViewportManager.cpp:557]
#05: nsHTMLScrollFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/nsGfxScrollFrame.cpp:1340]
#06: nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, int, nsIFrame::ReflowChildFlags, nsReflowStatus&, nsOverflowContinuationTracker*) [layout/generic/nsContainerFrame.cpp:1115]
#07: mozilla::ViewportFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/ViewportFrame.cpp:297]
#08: mozilla::PresShell::DoReflow(nsIFrame*, bool, mozilla::OverflowChangedTracker*) [layout/base/PresShell.cpp:9650]
#09: mozilla::PresShell::ProcessReflowCommands(bool) [layout/base/PresShell.cpp:9816]
#10: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [layout/base/PresShell.cpp:4239]
#11: nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:2139]
```

This happens after the test is finish when we unset the ui.useOverlayScrollbars pref which (I'm assuming because it must) causes reflow. When running a font-inflation related reftest we also unset the font inflation related prefs that were specified in the reftest.list file. This causes font-inflation to go from enabled to disabled and we detect that for the first time while reflowing the scroll frame.

Instead we should reflow when any pref that could affect font inflation is changed. I scanned the font-inflation code in PresShell and Document::GetViewportInfo for prefs are consulted, but I didn't go a super exhaustive search.

Differential Revision: https://phabricator.services.mozilla.com/D89409

UltraBlame original commit: 57470917615238e6a9a0ab2648e6b607ad8064de
gecko-dev-updater pushed a commit that referenced this pull request Sep 16, 2020
…efs that could affect font inflation change. r=kats

When I start setting the pref ui.useOverlayScrollbars in bug 1663537 we trigger this assert

```
###!!! ASSERTION: can't mark frame dirty during reflow: '!mIsReflowing', file /builds/worker/checkouts/gecko/layout/base/PresShell.cpp, line 2677
#1: mozilla::PresShell::MaybeReflowForInflationScreenSizeChange() [layout/base/PresShell.cpp:11148]
#2: mozilla::PresShell::CompleteChangeToVisualViewportSize() [layout/base/PresShell.cpp:11177]
#03: MobileViewportManager::UpdateVisualViewportSize(mozilla::gfx::IntSizeTyped<mozilla::ScreenPixel> const&, mozilla::gfx::ScaleFactor<mozilla::CSSPixel, mozilla::ScreenPixel> const&) [layout/base/MobileViewportManager.cpp:504]
#04: MobileViewportManager::RefreshVisualViewportSize() [layout/base/MobileViewportManager.cpp:557]
#05: nsHTMLScrollFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/nsGfxScrollFrame.cpp:1340]
#06: nsContainerFrame::ReflowChild(nsIFrame*, nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, int, int, nsIFrame::ReflowChildFlags, nsReflowStatus&, nsOverflowContinuationTracker*) [layout/generic/nsContainerFrame.cpp:1115]
#07: mozilla::ViewportFrame::Reflow(nsPresContext*, mozilla::ReflowOutput&, mozilla::ReflowInput const&, nsReflowStatus&) [layout/generic/ViewportFrame.cpp:297]
#08: mozilla::PresShell::DoReflow(nsIFrame*, bool, mozilla::OverflowChangedTracker*) [layout/base/PresShell.cpp:9650]
#09: mozilla::PresShell::ProcessReflowCommands(bool) [layout/base/PresShell.cpp:9816]
#10: mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) [layout/base/PresShell.cpp:4239]
#11: nsRefreshDriver::Tick(mozilla::layers::BaseTransactionId<mozilla::VsyncIdType>, mozilla::TimeStamp) [layout/base/nsRefreshDriver.cpp:2139]
```

This happens after the test is finish when we unset the ui.useOverlayScrollbars pref which (I'm assuming because it must) causes reflow. When running a font-inflation related reftest we also unset the font inflation related prefs that were specified in the reftest.list file. This causes font-inflation to go from enabled to disabled and we detect that for the first time while reflowing the scroll frame.

Instead we should reflow when any pref that could affect font inflation is changed. I scanned the font-inflation code in PresShell and Document::GetViewportInfo for prefs are consulted, but I didn't go a super exhaustive search.

Differential Revision: https://phabricator.services.mozilla.com/D89409

UltraBlame original commit: cb92660b87e5a63ed15e7c2f6b47f03a549d82c6
gecko-dev-updater pushed a commit that referenced this pull request Dec 18, 2020
…ingConfig to ChunkDemuxer AddId, a=testonly

Automatic update from web-platform-tests
[MSE][webcodecs] Plumb AddSourceBufferUsingConfig to ChunkDemuxer AddId

This change:

1) Exposes as static synchronous helpers the WebCodecs MakeMediaConfig
   methods' internals so that MediaSource can use them to obtain
   media::{Audio,Video}DecoderConfigs from WebCodecs
   {Audio,Video}DecoderConfigs.

2) Implements MediaSource::AddSourceBufferUsingConfig for encoded
   configs (not decodedMediaType), plumbing the media decoder config
   through the usual steps in MSE addSourceBuffer, and through new
   methods in WebMediaSource and WebMediaSourceImpl to let
   ChunkDemuxer::AddId know it will be expected to handle WebCodecs
   encoded chunk appends for the associated SourceBuffer.

3) Adds a tentative folder for MSE-for-WebCodecs web_tests and adds
   a test for the current behavior of addSourceBuffer(webcodecs decoder
   config) that this CL adds.

Later changes will continue plumbing of the configs in ChunkDemuxer and
SourceBufferState, and also add implementations and ChunkDemuxer/etc
support for appendEncoded{Audio,Video}Chunks. The h264 parser and avcc
conditionally created in #1, above, could then be used by SourceBuffer
processing of appended EncodedVideoChunks, too.

BUG=1144908

Change-Id: I90c1d90c3a28d5cc1e33b1e50e32f4cfea639784
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2548844
Commit-Queue: Matthew Wolenetz <wolenetzchromium.org>
Reviewed-by: Daniel Cheng <dchengchromium.org>
Reviewed-by: Chrome Cunningham <chcunninghamchromium.org>
Reviewed-by: Dan Sanders <sandersdchromium.org>
Cr-Commit-Position: refs/heads/master{#835058}

--

wpt-commits: 009fb035613e9b4027125e8f30d60f4f1f502f65
wpt-pr: 26642

UltraBlame original commit: ab3d0728e1050d82721db2f31266bd02012636dd
gecko-dev-updater pushed a commit that referenced this pull request May 16, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/5bdb4418e90cf0e9788aa7ca75082e5ea0746e3b
    M111: Add UMA histograms to track usage of fullscreen detection

    Cherry picked from commits:
    b311f6aba82cd93b2d748b8e47c6f8d29a21746d
    fd29662c61b2145d6de4c38eb55e48421a4d427b

    (cherry picked from commit b311f6aba82cd93b2d748b8e47c6f8d29a21746d)

    No-Try: True
    Bug: chromium:1348011
    Change-Id: I3219e74c49ff77e00b2224c8cf82f78d1e0fd9cf
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291708
    Reviewed-by: Harald Alvestrand <htawebrtc.org>
    Commit-Queue: Johannes Kron <kronwebrtc.org>
    Cr-Original-Commit-Position: refs/heads/main{#39254}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/292460
    Cr-Commit-Position: refs/branch-heads/5563{#1}
    Cr-Branched-From: 6c032cb8356b0d3f717c4fcf50796241f2bba6c2-refs/heads/main{#39207}

UltraBlame original commit: 7bf9a2538384e9f5be9a096c8f9fc1c50c092681
gecko-dev-updater pushed a commit that referenced this pull request Jun 16, 2023
…e DOM tree in each time of the loop r=m_kato

There are 2 possible scenarios which are not handled by the method.

1. Moving content node to new `<blockquote>` has already been moved to outside
of the editing host.
2. There is no container to insert new `<blockquote>`, e.g., in an inline
editing host.

In the case #1, we should ignore the ex-child node.  In the case #2, we should
abort it.  Note that Chrome inserts `<blockquote>` even if there is no proper
container.  However, such behavior is disagreed in interop-2023.  Therefore,
it's okay just to abort it for now.

Depends on D180781

Differential Revision: https://phabricator.services.mozilla.com/D180782

UltraBlame original commit: 42f3f3ab11b47f1d56d8bcd6a128398539dd1f23
gecko-dev-updater pushed a commit that referenced this pull request Oct 30, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/d95382fab7dcac8867d9811c4630367c4454cb7d
    [M117][SctpDataChannel] Don't use PostTask for observer registration.

    Instead, use BlockingCall to match with how unregistration is done.
    This is needed because the ThreadWrapper implementation in Chromium, overriding the Thread implementation in WebRTC, does not order sent (blocking) tasks along with posted tasks.

    That makes the functional difference that Thread1 posting and sending
    tasks to Thread2, can not assume that the tasks run in the order they
    were posted and sent. I.e. in this case:

      // Running on Thread1.
      thread2->PostTask([](){ Foo(); });
      thread2->BlockingCall([](){ Bar(); });

    Thread2 may actually execute Bar() first, and then Foo().

    (cherry picked from commit 70cea9bda8b8815be3c5bae4b6fa8053713efcac)

    No-Try: true
    Bug: chromium:1470992
    Change-Id: I1f83f12ce39c09279c0f2b3bc71c3a33e2cb16c5
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/317700
    Commit-Queue: Tomas Gunnarsson <tommiwebrtc.org>
    Reviewed-by: Harald Alvestrand <htawebrtc.org>
    Cr-Original-Commit-Position: refs/heads/main{#40624}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/318360
    Reviewed-by: Mirko Bonadei <mbonadeiwebrtc.org>
    Cr-Commit-Position: refs/branch-heads/5938{#1}
    Cr-Branched-From: 82e5f91a2bdf955aa870142008fbdc9ac12f6acd-refs/heads/main{#40524}

UltraBlame original commit: 490b31781e84dad63fe3cb757a0b6f7b714f1d68
gecko-dev-updater pushed a commit that referenced this pull request Dec 21, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/71e3fbf5d750e84d181315a663eb5dbc29a5330c
    [M119 merge] Reland "Add mitigation for very long frame drop gaps with vp8"

    This is a reland of commit 0d4b350006eae7dfeeb8c67f16f51b1c62351cee

    Patchset 1 is the original CL. Patchset 2 contains a small tweak of the target bitrate in the unit test, in order to make in less susceptible to flakiness on runtime environments running a slightly different libvpx.

    Original change's description:
    > Add mitigation for very long frame drop gaps with vp8
    >
    > Bug: webrtc:15530
    > Change-Id: I11f5e3f31f71301700dbff3fc9285236160bee45
    > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322320
    > Reviewed-by: Sergey Silkin <ssilkinwebrtc.org>
    > Commit-Queue: Sergey Silkin <ssilkinwebrtc.org>
    > Auto-Submit: Erik Språng <sprangwebrtc.org>
    > Cr-Commit-Position: refs/heads/main{#40866}

    (cherry picked from commit d7703d950536473627533ed6eab24c2d50054e70)

    Bug: webrtc:15530
    Change-Id: I096b7d952286f7f53852d1ca70aea398b2747784
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322540
    Auto-Submit: Erik Språng <sprangwebrtc.org>
    Commit-Queue: Erik Språng <sprangwebrtc.org>
    Reviewed-by: Sergey Silkin <ssilkinwebrtc.org>
    Commit-Queue: Sergey Silkin <ssilkinwebrtc.org>
    Cr-Original-Commit-Position: refs/heads/main{#40874}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322900
    Cr-Commit-Position: refs/branch-heads/6045{#1}
    Cr-Branched-From: bce7ce7ba054ac0e79fed49b84ef52fb24c31778-refs/heads/main{#40854}

UltraBlame original commit: 4b8b9916290f67d02a19a0503c6a61bb16a3cbb0
gecko-dev-updater pushed a commit that referenced this pull request Jan 25, 2024
…ect> / <embed> as subdocuments. r=longsonr

These look like two really old bugs.

Part of the issue is that <object> / <embed> manage their frame loader quite
differently from <iframe>. This means that we may have a PresShell /
ViewManager / etc for a frame loader that doesn't yet have a frame associated.

For example, this is the viewport creation for the SVG document that reproduces
the problem:

	#0  0x00005cc60e8302e7 in mozilla::ViewportFrame::SetViewInternal(nsView*) (this=0x68599020, aView=0x683d8f00) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/ViewportFrame.h:106
	#1  0x00005cc60e842858 in nsIFrame::SetView(nsView*) (this=0x68599020, aView=0x683d8f00) at /home/emilio/src/moz/gecko/layout/generic/nsFrame.cpp:7057
	#2  0x00005cc60e77258a in nsCSSFrameConstructor::ConstructRootFrame() (this=0xc72c715e00) at /home/emilio/src/moz/gecko/layout/base/nsCSSFrameConstructor.cpp:2424
	#3  0x00005cc60e7342f5 in mozilla::PresShell::Initialize() (this=0x6830e000) at /home/emilio/src/moz/gecko/layout/base/PresShell.cpp:1758
	#4  0x00005cc60c9fb02a in nsContentSink::StartLayout(bool) (this=<optimized out>, aIgnorePendingSheets=<optimized out>) at /home/emilio/src/moz/gecko/dom/base/nsContentSink.cpp:1160
	#5  0x00005cc60e2c1581 in nsXMLContentSink::HandleStartElement(char16_t const*, char16_t const**, unsigned int, unsigned int, unsigned int, bool)
	    (this=<optimized out>, aName=<optimized out>, aAtts=0x6fde8200, aAttsCount=<optimized out>, aLineNumber=3, aColumnNumber=<optimized out>, aInterruptable=true) at /home/emilio/src/moz/gecko/dom/xml/nsXMLContentSink.cpp:982
	#6  0x00005cc60e2c17d7 in non-virtual thunk to nsXMLContentSink::HandleStartElement(char16_t const*, char16_t const**, unsigned int, unsigned int, unsigned int) () at /home/emilio/src/moz/gecko/dom/xml/nsXMLContentSink.cpp:889
	#7  0x00005cc60c360307 in nsExpatDriver::HandleStartElement(void*, char16_t const*, char16_t const**) (aUserData=0x224f650d0cc0, aName=0x685aef20 u"http://www.w3.org/2000/svg\xffffdesc", aAtts=0x6fde8200)
	    at /home/emilio/src/moz/gecko/parser/htmlparser/nsExpatDriver.cpp:293
	#8  0x00005cc60ee91cea in doContent (parser=0xc72c70f800, startTagLevel=0, enc=<optimized out>, s=<optimized out>, end=0x5bbd31af5020 "\344\344\344", <incomplete sequence \344>, nextPtr=0x7ffca2653288, haveMore=1 '\001')
	    at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:2872
	#9  0x00005cc60ee90059 in contentProcessor (parser=0xc72c70f800, start=0xffffffe6 <error: Cannot access memory at address 0xffffffe6>, end=0xc72c511360 "", endPtr=0x1) at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:2528
	#10 0x00005cc60ee8f8d5 in doProlog
	    (parser=<optimized out>, enc=0x5cc612ce0930 <little2_encoding_ns>, s=0x5bbd31ab508e "<", end=0x5bbd31af5020 "\344\344\344", <incomplete sequence \344>, tok=<optimized out>, next=<optimized out>, nextPtr=0x7ffca2653288, haveMore=1 '\001', allowClosingDoctype=1 '\001') at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:4591
	#11 0x00005cc60ee8d86e in prologProcessor (parser=0xc72c70f800, s=0x5bbd31ab5020 "<", end=0x5bbd31af5020 "\344\344\344", <incomplete sequence \344>, nextPtr=0x7ffca2653288) at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:4311
	#12 0x00005cc60ee8cf45 in MOZ_XML_Parse (parser=0xc72c70f800, s=0x5bbd31ab5020 "<", len=262144, isFinal=0) at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:1894
	#13 0x00005cc60c3627bc in nsExpatDriver::ParseBuffer(char16_t const*, unsigned int, bool, unsigned int*)
	    (this=0x224f650d0cc0, aBuffer=0x5bbd31ab5020 u"<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\n<svg height=\"2970\" width=\"2100\" viewBox=\"0 0 2100 2970\" version=\"1.1\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlin"..., aLength=131072, aIsFinal=false, aConsumed=<optimized out>) at /home/emilio/src/moz/gecko/parser/htmlparser/nsExpatDriver.cpp:875
	#14 0x00005cc60c362c91 in nsExpatDriver::ConsumeToken(nsScanner&, bool&) (this=<optimized out>, aScanner=..., aFlushTokens=<optimized out>) at /home/emilio/src/moz/gecko/parser/htmlparser/nsExpatDriver.cpp:970
	#15 0x00005cc60c3666a8 in nsParser::Tokenize(bool) (this=0x224f65038e80, aIsFinalChunk=false) at /home/emilio/src/moz/gecko/parser/htmlparser/nsParser.cpp:1410
	#16 0x00005cc60c36595e in nsParser::ResumeParse(bool, bool, bool) (this=0x224f65038e80, allowIteration=true, aIsFinalChunk=false, aCanInterrupt=<optimized out>) at /home/emilio/src/moz/gecko/parser/htmlparser/nsParser.cpp:961
	#17 0x00005cc60c366c86 in nsParser::OnDataAvailable(nsIRequest*, nsIInputStream*, unsigned long, unsigned int) (this=0x224f65038e80, request=<optimized out>, pIStream=0x6fdfc430, sourceOffset=<optimized out>, aLength=131072)
	    at /home/emilio/src/moz/gecko/parser/htmlparser/nsParser.cpp:1317
	#18 0x00005cc60c897cc2 in nsObjectLoadingContent::OnDataAvailable(nsIRequest*, nsIInputStream*, unsigned long, unsigned int) (this=<optimized out>, aRequest=0x68483080, aInputStream=0x6fdfc430, aOffset=0, aCount=131072)
	    at /home/emilio/src/moz/gecko/dom/base/nsObjectLoadingContent.cpp:1055
	#19 0x00005cc60b9d18f8 in mozilla::net::HttpChannelChild::DoOnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned long, unsigned int)
	    (this=0x68483000, aRequest=0x68483080, aContext=<optimized out>, aStream=0x6fdfc430, aOffset=0, aCount=743510880) at /home/emilio/src/moz/gecko/netwerk/protocol/http/HttpChannelChild.cpp:968
	#20 0x00005cc60b9d5cbf in mozilla::net::HttpChannelChild::OnTransportAndData(nsresult const&, nsresult const&, unsigned long const&, unsigned int const&, nsTString<char> const&)
	    (this=0x68483000, aChannelStatus=<optimized out>, aTransportStatus=0x683be5bc: -2142568440, aOffset=<optimized out>, aCount=<optimized out>, aData=...) at /home/emilio/src/moz/gecko/netwerk/protocol/http/HttpChannelChild.cpp:867
	#21 0x00005cc60badb535 in mozilla::net::ChannelEventQueue::FlushQueue() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/netwerk/ipc/ChannelEventQueue.cpp:90
	#22 0x00005cc60b976fda in mozilla::net::ChannelEventQueue::MaybeFlushQueue() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/net/ChannelEventQueue.h:350
	#23 0x00005cc60baec442 in mozilla::net::ChannelEventQueue::CompleteResume() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/net/ChannelEventQueue.h:329
	#24 mozilla::net::ChannelEventQueue::ResumeInternal()::CompleteResumeRunnable::Run() (this=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/ipc/ChannelEventQueue.cpp:148
	#25 0x00005cc60b53d4f1 in mozilla::SchedulerGroup::Runnable::Run() (this=0x685b0200) at /home/emilio/src/moz/gecko/xpcom/threads/SchedulerGroup.cpp:282
	#26 0x00005cc60b54ff80 in nsThread::ProcessNextEvent(bool, bool*) (this=0x3dd7f4f3020, aMayWait=<optimized out>, aResult=0x7ffca2653ea7) at /home/emilio/src/moz/gecko/xpcom/threads/nsThread.cpp:1220
	#27 0x00005cc60b552f0d in NS_ProcessNextEvent(nsIThread*, bool) (aThread=0x68599020, aMayWait=true) at /home/emilio/src/moz/gecko/xpcom/threads/nsThreadUtils.cpp:481

The parent view may not be set properly if the frame is not current by the time
it is created. For example in this case the parent for the root view is
non-null and comes from the following MakeWindow call:

	#0  nsDocumentViewer::MakeWindow(nsSize const&, nsView*) (this=0xc72ca72cd0, aSize=..., aContainerView=0x683ba500) at /home/emilio/src/moz/gecko/layout/base/nsDocumentViewer.cpp:2368
	#1  0x00005cc60e789b50 in nsDocumentViewer::InitInternal(nsIWidget*, nsISupports*, mozilla::dom::WindowGlobalChild*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, bool, bool, bool)
	    (this=0xc72ca72cd0, aParentWidget=<optimized out>, aState=0x0, aActor=0x0, aBounds=..., aDoCreation=true, aNeedMakeCX=<optimized out>, aForceSetNewDocument=<optimized out>)
	    at /home/emilio/src/moz/gecko/layout/base/nsDocumentViewer.cpp:933
	#2  0x00005cc60e789959 in nsDocumentViewer::Init(nsIWidget*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::dom::WindowGlobalChild*)
	    (this=0xc72ca72cd0, aParentWidget=0x7ffca2651020, aBounds=..., aActor=0x7f6216725c00) at /home/emilio/src/moz/gecko/layout/base/nsDocumentViewer.cpp:762
	#3  0x00005cc60f4f584f in nsDocShell::SetupNewViewer(nsIContentViewer*, mozilla::dom::WindowGlobalChild*) (this=0x684db000, aNewViewer=<optimized out>, aWindowActor=<optimized out>)
	    at /home/emilio/src/moz/gecko/docshell/base/nsDocShell.cpp:8017
	#4  0x00005cc60f4f5204 in nsDocShell::Embed(nsIContentViewer*, mozilla::dom::WindowGlobalChild*) (this=0x684db000, aContentViewer=0x7ffca2651020, aWindowActor=0x683ba500) at /home/emilio/src/moz/gecko/docshell/base/nsDocShell.cpp:5745
	#5  0x00005cc60f4dbc7b in nsDocShell::CreateContentViewer(nsTSubstring<char> const&, nsIRequest*, nsIStreamListener**) (this=0x684db000, aContentType=..., aRequest=0x68483080, aContentHandler=<optimized out>)
	    at /home/emilio/src/moz/gecko/docshell/base/nsDocShell.cpp:7819
	#6  0x00005cc60f4dab99 in nsDSURIContentListener::DoContent(nsTSubstring<char> const&, bool, nsIRequest*, nsIStreamListener**, bool*)
	    (this=0x683056a0, aContentType=..., aIsContentPreferred=<optimized out>, aRequest=0x68483080, aContentHandler=0xc72c5e8608, aAbortProcess=0x7ffca265139f) at /home/emilio/src/moz/gecko/docshell/base/nsDSURIContentListener.cpp:181
	#7  0x00005cc60c2fd8f5 in nsDocumentOpenInfo::TryContentListener(nsIURIContentListener*, nsIChannel*) (this=0xc72c5e85e0, aListener=0x683056a0, aChannel=<optimized out>) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:632
	#8  0x00005cc60c2fccd1 in nsDocumentOpenInfo::DispatchContent(nsIRequest*, nsISupports*) (this=0xc72c5e85e0, request=0x68483080, aCtxt=<optimized out>) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:313
	#9  0x00005cc60c2fc5aa in nsDocumentOpenInfo::OnStartRequest(nsIRequest*) (this=<optimized out>, request=0x68483080) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:191
	#10 0x00005cc60c8975c4 in nsObjectLoadingContent::LoadObject(bool, bool, nsIRequest*) (this=0x4b1b3938b6a8, aNotify=<optimized out>, aForceLoad=<optimized out>, aLoadingChannel=0x68483080)
	    at /home/emilio/src/moz/gecko/dom/base/nsObjectLoadingContent.cpp:2218
	#11 0x00005cc60c89681f in nsObjectLoadingContent::OnStartRequest(nsIRequest*) (this=0x4b1b3938b6a8, aRequest=0x68483080) at /home/emilio/src/moz/gecko/dom/base/nsObjectLoadingContent.cpp:1006
	#12 0x00005cc60b9d1020 in mozilla::net::HttpChannelChild::DoOnStartRequest(nsIRequest*, nsISupports*) (this=0x68483000, aRequest=0x68483080, aContext=<optimized out>)
	    at /home/emilio/src/moz/gecko/netwerk/protocol/http/HttpChannelChild.cpp:708
	#13 0x00005cc60b9d481b in mozilla::net::HttpChannelChild::OnStartRequest(nsresult const&, mozilla::net::nsHttpResponseHead const&, bool const&, mozilla::net::nsHttpHeaderArray const&, mozilla::net::ParentLoadInfoForwarderArgs const&, bool const&, bool const&, bool const&, unsigned long const&, int const&, unsigned int const&, nsTString<char> const&, nsTString<char> const&, mozilla::net::NetAddr const&, mozilla::net::NetAddr const&, unsigned int const&, nsTString<char> const&, long const&, bool const&, bool const&, bool const&, mozilla::net::ResourceTimingStructArgs const&, bool const&, mozilla::Maybe<unsigned int> const&, bool const&, nsILoadInfo::CrossOriginOpenerPolicy const&)

However, even though aContainerView is non-null, the view is incorrect, it's
the view for the _old_ frame.

The view parent/child relationship gets cleared properly in:

	#1  0x00005cc60e8e82bf in BeginSwapDocShellsForViews (aSibling=0x0) at /home/emilio/src/moz/gecko/layout/generic/nsSubDocumentFrame.cpp:1027
	warning: Source file is more recent than executable.
	#2  0x00005cc60e8e810b in nsSubDocumentFrame::DestroyFrom (this=0x6cd04eaa45a8, aDestructRoot=0x6cd04eaa45a8, aPostDestroyData=...) at /home/emilio/src/moz/gecko/layout/generic/nsSubDocumentFrame.cpp:943
	#3  0x00005cc60e7b71a3 in nsIFrame::Destroy (this=0x6cd04eaa45a8) at /home/emilio/src/moz/gecko/layout/generic/nsIFrame.h:657
	#4  0x00005cc60e80baac in nsBlockFrame::RemoveFrame (this=0x4b1b39362d88, aListID=<optimized out>, aOldFrame=0x6cd04eaa45a8) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.cpp:5597
	#5  0x00005cc60e8df29f in nsPlaceholderFrame::DestroyFrom (this=0x4b1b39363240, aDestructRoot=0x4b1b39363240, aPostDestroyData=...) at /home/emilio/src/moz/gecko/layout/generic/nsPlaceholderFrame.cpp:181
	#6  0x00005cc60e80cf19 in nsBlockFrame::DoRemoveFrameInternal (this=<optimized out>, aDeletedFrame=0x0, aFlags=<optimized out>, aPostDestroyData=...) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.cpp:6265
	#7  0x00005cc60e82d947 in nsBlockFrame::DoRemoveFrame (this=0x4b1b39362d88, aDeletedFrame=0x683d8f00, aFlags=244338087) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.h:528
	#8  0x00005cc60e80ba3a in nsBlockFrame::RemoveFrame (this=0x4b1b39362d88, aListID=<optimized out>, aOldFrame=0x4b1b39363240) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.cpp:5581
	#9  0x00005cc60e77fd5c in nsCSSFrameConstructor::ContentRemoved (this=<optimized out>, aChild=0x4b1b3938b600, aOldNextSibling=<optimized out>, aFlags=<optimized out>)
	    at /home/emilio/src/moz/gecko/layout/base/nsCSSFrameConstructor.cpp:7583
	#10 0x00005cc60e779a35 in nsCSSFrameConstructor::RecreateFramesForContent (this=0x6fdf9800, aContent=0x4b1b3938b600, aInsertionKind=nsCSSFrameConstructor::InsertionKind::Sync)
	    at /home/emilio/src/moz/gecko/layout/base/nsCSSFrameConstructor.cpp:8593
	#11 0x00005cc60e751745 in mozilla::RestyleManager::ProcessRestyledFrames (this=<optimized out>, aChangeList=...) at /home/emilio/src/moz/gecko/layout/base/RestyleManager.cpp:1484

But the temporary state is stored in the _old_ frame-loader, so when we create
the new frame, we get to nsSubDocumentFrame::Init, and find nothing, and thus
go through nsFrameLoader::Show. But we do have a pres-shell, and
nsFrameLoader::Show just early-returns then, and thus we end up with a detached
pres shell which is not hooked to the view tree and thus not painted...

So there are multiple potential fixes. First (this is the approach this patch
takes):

 * Make nsHideViewer not fail to hide a presentation when the frame loader
   has changed. This is not an issue per se, but leaves stale views / etc
   living for too long which is not nice.

 * Fix up the Show() code path to handle this case properly by parenting the
   pres-shell and initializing the docshell properly.

Second potential fix would be to store the temporary state somewhere else than
the frame loader (like the element). This may be a less invasive change
somehow, but it looks pretty fishy to me, and not particularly better...

Terribly sorry about the lack of test-case, but this is racy as crazy and I had
a lot of trouble to even reproduce it in a debug build. This needs the
PresShell creation for the subdocument to happen right after setting .data on
the <object>, but before processing its reframe.

Differential Revision: https://phabricator.services.mozilla.com/D69487

UltraBlame original commit: 50b298a5272a5c248c5f428cfb03087d919f0a7b
gecko-dev-updater pushed a commit that referenced this pull request Jan 25, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/b0cc68e61205fd11a7256a6e85307ec17ad95790
    Reduces rate at which TryGetNextFrame returns NULL for WGC

    This CL is a follow-up of work done in
    https://webrtc-review.googlesource.com/c/src/+/323882 where the goal
    was to reduce the amount of FrameDropped error logs in
    WebRTC.DesktopCapture.Win.WgcCaptureSessionGetFrameResult.

    The previous work avoids FrameDropped logs for a minimized window
    being captured with WGC but we still se a large amount of these error
    (or rather warning) logs. See [1] which comes from Canary.

    This CL does two different things to improve the situation:

    1) It adds kFramePoolEmpty to the existing
    GetFrameResult::kFrameDropped enum to point out that the warning
    comes from the frame pool not being able to return a valid new frame.
    It also makes it more clear that it does not cause an outer/final
    error as WgcCapturerResult::kFrameDropped. We still keep the inner
    GetFrameResult::kFrameDropped but it is only produced when the frame
    pool returns NULL and our external queue is empty. Hence, a real
    frame-drop error. Note that, it is still easy to provoke
    kFramePoolEmpty simply by asking for a high resolution at a high rate.
    The example in [2] comes from a 4K screen 30fps. Hence, we have not
    fixed anything yet.

    2) It also increases the size of the internal frame pool from 1 to 2.
    This does lead to an almost zero rate of kFramePoolEmpt
    warnings at the expense of a slightly reduced max capture rate. BUT,
    with 1 as size, we can "see" a higher max capture rate but it is not
    a true rate since it comes with a high rate of kFramePoolEmpty
    errors. Hence, we "emulate" a high capture rate by simply feeding
    copies of the last frame that we had stored in the external queue.
    Using 2 leads to a more "true" rate of what we actually can capture
    in terms of *new* frames and also a substantially lower rate of
    kFramePoolEmpty.
    In addition, with 1 as size, if we ask at a too high rate and provide
    a copy of the last frame, our CPU adaptation will not reduce its rate
    since we think that things are OK when it is actually not.

    Also, the samples in [3] and [4] both use 2 as numberOfBuffers
    as well.

    Let me also mention that with this small change, I a have not been
    able to provoke any kFramePoolEmpty error messages.

    Finally, geDisplayMedia can be called called with constraints where
    min and max framerate is defined. The mechanism which maintains the
    min rate is implemented via the RequestRefreshFrame API and it can
    be sent to the source (DesktopCaptureDevice) back to back with a
    previous timer interrupt for a capture request. Without this change,
    these RRFs were also a source of a large amount of
    kFramePoolEmpty error logs. With 2 buffers instead; this is no
    longer the case.

    [1] https://screenshot.googleplex.com/7sfv6HdGXLwyxdj
    [2] https://paste.googleplex.com/4795680001359872
    [3] https://github.com/robmikh/Win32CaptureSample/blob/master/Win32CaptureSample/SimpleCapture.cpp
    [4] https://learn.microsoft.com/en-us/windows/uwp/audio-video-camera/screen-capture#add-the-screen-capture-capability

    (cherry picked from commit 4be5927dc788b814dff2a6ca46175254dce59232)

    Bug: chromium:1314868
    Change-Id: I73b823b31a993fd2cd6e007b212826dfe1a80012
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325521
    Commit-Queue: Alexander Cooper <alcooperchromium.org>
    Reviewed-by: Alexander Cooper <alcooperchromium.org>
    Cr-Original-Commit-Position: refs/heads/main{#41079}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/326960
    Commit-Queue: Henrik Andreassson <henrikawebrtc.org>
    Bot-Commit: rubber-stamperappspot.gserviceaccount.com <rubber-stamperappspot.gserviceaccount.com>
    Reviewed-by: Stefan Holmer <stefanwebrtc.org>
    Cr-Commit-Position: refs/branch-heads/6099{#1}
    Cr-Branched-From: 507f1cc3270d0577f79882acbd78e63e66008f3d-refs/heads/main{#41042}

UltraBlame original commit: ea64d0bd5fc3e48d7ea9c11717f2a33521ec76b3
gecko-dev-updater pushed a commit that referenced this pull request Sep 16, 2024
…r=m_kato

This fixes four issues:

1. The test didn't provide enough movement to generate a drag session on the
   source before moving to the target.  This meant that, when they were in
   different windows, Gecko wouldn't send dragleave to the source or dragenter
   to the target.  It also never sent dragenter to the source in the first
   place. This remedies that.
2. dragenter and dragleave weren't properly handled because the test was sending
   dragleaves instead of dragexits (the latter being what Gecko expects and the
   former being synthesized from that -- see e.g. nsNativeDragTarget::DragLeave).
   This now uses dragexits and sets the proper expectations.
3. expectProtectedDataTransferAccess was needlessly complicated and, after #1,
   gave the wrong answers for some events like dragenter called on the source.
4. The event handler wasn't checking for exceptions and the drop handler was
   intentionally causing one, which was causing it to miss the rest of its
   execution.

Differential Revision: https://phabricator.services.mozilla.com/D219550

UltraBlame original commit: f50209dd351a1d3a5d7bcc106c1a2dca07d0db5a
gecko-dev-updater pushed a commit that referenced this pull request Oct 1, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/21508e08e7545a03c8c35a9299923279e3def319
    Fix license metadata for spl_sqrt_floor, portaudio, sigslot

    (cherry picked from commit 6ea1c96325baada0e6ba0b29456e02f403e15a1e)

    Bug: b/361140175
    Change-Id: I35e76039608fa5094c04ace5f3ad1dba868ccb85
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360900
    Reviewed-by: Henrik Andreassson <henrikawebrtc.org>
    Commit-Queue: Andrew Grieve <agrievegoogle.com>
    Cr-Original-Commit-Position: refs/heads/main{#42885}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361520
    Reviewed-by: Mirko Bonadei <mbonadeiwebrtc.org>
    Reviewed-by: Harald Alvestrand <htawebrtc.org>
    Commit-Queue: Mirko Bonadei <mbonadeiwebrtc.org>
    Cr-Commit-Position: refs/branch-heads/6668{#1}
    Cr-Branched-From: 2cfedb277ae8dd2a8d8dd68aca6f95081c265671-refs/heads/main{#42810}

UltraBlame original commit: fff71dac56c57f10e67e8ea3f1ea7eaeb103f0aa
gecko-dev-updater pushed a commit that referenced this pull request Nov 1, 2024
…t/last formatted line., a=testonly

Automatic update from web-platform-tests
[text-box-trim] More spec-compliant first/last formatted line.

See https://drafts.csswg.org/css-pseudo-4/#first-text-line

1. For a block container that establishes an inline formatting context,
the "first formatted line" is its first line box, if it has one.
Otherwise, there is no first formatted line.

2. Otherwise, for a block container that has block children, look inside
the first in-flow block child (if any) and do #1 if it establishes an
inline formatting context. Otherwise, do #2.

In short, we don't need to search for line boxes in blocks after the
first block child. If there is no line in the first child, there's no
"first formatted line".

There's no spec for "last formatted line", but apply the same logic.
I.e. if the last block child has no line, there's no "last formatted
line".

This allows us to simplify things a bit, especially when it comes to
re-laying out (kTextBoxTrimEndDidNotApply). The only case where we need
this now is for blocks inside inlines: If the last formatted line is
inside a block-in-inline, we need to go back and re-lay it out if it
turns out to be the last line (which isn't something we can check inside
block-in-inline layout). Note: When adding support for block
fragmentation, trimming at a fragmentainer's block end will be another
case where we need to re-lay out.

The motivation for this change was text box trimming inside block
fragmentation (upcoming CL), and be able to add support for that and
still be reasonably confident that it won't become too complicated.

This fixes one existing test. Some other existing tests had to be
updated because of this change (they were making incorrect assumptions
about first/last formatted line). As a result of that, some new refs had
to be added, since other tests were piggy-backing on the same ref.

Bug: 40254880, 367766472
Change-Id: I3fcc53af86353725b1f5705a5528493a72bf2e69
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5952979
Commit-Queue: Morten Stenshorne <mstenshochromium.org>
Reviewed-by: Koji Ishii <kojiichromium.org>
Cr-Commit-Position: refs/heads/main{#1373765}

--

wpt-commits: 274bd0d593efebce81292bc6f9a8ca58c578e343
wpt-pr: 48815

UltraBlame original commit: bb11e616218b029dfcef932271989fe21370ee49
gecko-dev-updater pushed a commit that referenced this pull request Nov 1, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/31350c7119fb0e100336e3f22d869e7bd9a0126f
    [M130] Increase AV1 QP threshold for quality convergence from 40 to 60

    Merge approval: https://g-issues.chromium.org/issues/367752722#comment5

    (cherry picked from commit e81ba3089755e88292c135733ea187fdd278d858)

    Bug: chromium:328598314, chromium:367752722
    Change-Id: I132b4c30f132ace2bbef6359edd994c1ad75c9ad
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362620
    Reviewed-by: Johannes Kron <kronwebrtc.org>
    Commit-Queue: Sergey Silkin <ssilkinwebrtc.org>
    Cr-Original-Commit-Position: refs/heads/main{#43035}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362981
    Commit-Queue: Johannes Kron <kronwebrtc.org>
    Cr-Commit-Position: refs/branch-heads/6723{#1}
    Cr-Branched-From: 13e377b804f68aa9c20ea5e449666ea5248e3286-refs/heads/main{#43019}

UltraBlame original commit: c7a40e1939285230978993cbde1e239bc806fe11
gecko-dev-updater pushed a commit that referenced this pull request Nov 27, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/e61bb7312c3ec5af5ecf86bbf504039ed08fe9eb
    Merge corruption detection fixes to M131.

    This CL comprises the following CLs:


    Do not change crypto options in peer_connection.cc

    Bug: webrtc:358039777, chromium:374122158
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365360
    Commit-Queue: Emil Vardar (xWF) <vardargoogle.com>
    Reviewed-by: Henrik Boström <hboswebrtc.org>
    Reviewed-by: Erik Språng <sprangwebrtc.org>
    Cr-Commit-Position: refs/heads/main{#43245}


    Enable corruption detection when the encrypted extension is present

    Credit: https://webrtc-review.googlesource.com/c/src/+/365584 with ASAN issue solved.

    Bug: webrtc:358039777, chromium:374122158
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365680
    Commit-Queue: Emil Vardar (xWF) <vardargoogle.com>
    Reviewed-by: Erik Språng <sprangwebrtc.org>
    Reviewed-by: Ilya Nikolaevskiy <ilnikwebrtc.org>
    Cr-Commit-Position: refs/heads/main{#43244}


    Post corruption score aggregation to worker thread.

    Bug: webrtc:358039777, chromium:374122158
    Change-Id: Iff89c21657939557a10b6a183d632f251086379c
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/365600
    Reviewed-by: Erik Språng <sprangwebrtc.org>
    Commit-Queue: Åsa Persson <asaperssonwebrtc.org>
    Auto-Submit: Emil Vardar (xWF) <vardargoogle.com>
    Reviewed-by: Åsa Persson <asaperssonwebrtc.org>
    Cr-Original-Commit-Position: refs/heads/main{#43238}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366521
    Reviewed-by: Henrik Boström <hboswebrtc.org>
    Commit-Queue: Erik Språng <sprangwebrtc.org>
    Cr-Commit-Position: refs/branch-heads/6778{#1}
    Cr-Branched-From: 7b1b7a0f51593df7a1a802f489d6a2fb14195bcc-refs/heads/main{#43221}

UltraBlame original commit: fc564d503b464c31a3a093272aac0f4ab197ed90
gecko-dev-updater pushed a commit that referenced this pull request Dec 1, 2024
…izer data structures + logic., a=testonly

Automatic update from web-platform-tests
[Sanitizer] Reland: Implement core Sanitizer data structures + logic.

This implements the core Sanitizer logic. This is still missing
spec-mandated handling of "javascript:" URLs, and will have to be
updated as the spec develops. But other than that, the basics are now
there.

------------------

This a re-land of crrev.com/c/5922125. Patch set #1 is the original version,
as reviewed and submitted there. Patch set #2 contains the fix. Analysis of
the bug is in https://issues.chromium.org/issues/356601280#comment16

Bug: 356601280, 379235386, 379246316
Change-Id: I06d4a9a378330cc76015e3922b9e288d9503881a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6021482
Reviewed-by: Yifan Luo <lyfchromium.org>
Reviewed-by: Joey Arhar <jarharchromium.org>
Commit-Queue: Daniel Vogelheim <vogelheimchromium.org>
Cr-Commit-Position: refs/heads/main{#1385522}

--

wpt-commits: 348423995eb22e35d7fbb229a729839675e4ef01
wpt-pr: 49229

UltraBlame original commit: 949d805f0b0f8579ae3bcf59b6872a14ad9a8fa1
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
dependencies Pull requests that update a dependency file
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant