-
Notifications
You must be signed in to change notification settings - Fork 0
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
Closed
dependabot
wants to merge
1
commit into
master
from
dependabot/npm_and_yarn/testing/xpcshell/node-spdy/examples/twitlog/socket.io-2.3.0
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Bumps [socket.io](https://github.com/socketio/socket.io) from 0.8.7 to 2.3.0. - [Release notes](https://github.com/socketio/socket.io/releases) - [Commits](socketio/socket.io@0.8.7...2.3.0) Signed-off-by: dependabot[bot] <[email protected]>
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
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 If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
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
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
…; 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
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bumps socket.io from 0.8.7 to 2.3.0.
Release notes
Sourced from socket.io's releases.
Commits
47161a6
[chore] Release 2.3.0cf39362
[chore] Bump socket.io-parser to version 3.4.04d01b2c
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.09c1e73c
[chore] Update the license of the chat example (#3410)df05b73
[chore] Release 2.2.0b00ae50
[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...Maintainer changes
This version was pushed to npm by darrachequesne, a new releaser for socket.io since your current version.
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 languageYou can disable automated security fix PRs for this repo from the Security Alerts page.