Bump lodash from 3.3.1 to 4.17.19 in /addon-sdk/source #2
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
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
Bumps [lodash](https://github.com/lodash/lodash) from 3.3.1 to 4.17.19. - [Release notes](https://github.com/lodash/lodash/releases) - [Commits](lodash/lodash@3.3.1...4.17.19) Signed-off-by: dependabot[bot] <support@github.com>
dependabot
bot
added
dependencies
jamienicol
deleted the
dependabot/npm_and_yarn/addon-sdk/source/lodash-4.17.19
branch
|
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. |
jamienicol
pushed a commit
that referenced
this pull request
Jan 29, 2021
…only Automatic update from web-platform-tests Make --py3 the default for 'wpt' (#27081) As per https://github.com/web-platform-tests/rfcs/blob/master/rfcs/py_3.md, step #2 of the transition to Python 3-only is to make 'wpt ...' commands run in Python 3 by default. Passing --py2 will now be necessary to run under Python 2. (Until ~Feb 2021, when we will remove py2 support entirely). This does affect some CI runs. Cases where they already specified py3 will remain py3. Cases which are designed to run under py2 had `--py2` added. Cases that didn't currently specify and aren't version specific are upgraded from py2 to py3 (one example is Azure Pipelines Mac infrastructure tests.) Some Azure Pipelines helper scripts are used for both py2 and py3 tasks. As a simple way to keep them working, `--py2` is used for them as it is always available. -- wpt-commits: 61d85c8f90cad174dd83d97399b894554705915e wpt-pr: 27081
jamienicol
pushed a commit
that referenced
this pull request
Jan 29, 2021
…only Automatic update from web-platform-tests Make --py3 the default for 'wpt' (#27081) As per https://github.com/web-platform-tests/rfcs/blob/master/rfcs/py_3.md, step #2 of the transition to Python 3-only is to make 'wpt ...' commands run in Python 3 by default. Passing --py2 will now be necessary to run under Python 2. (Until ~Feb 2021, when we will remove py2 support entirely). This does affect some CI runs. Cases where they already specified py3 will remain py3. Cases which are designed to run under py2 had `--py2` added. Cases that didn't currently specify and aren't version specific are upgraded from py2 to py3 (one example is Azure Pipelines Mac infrastructure tests.) Some Azure Pipelines helper scripts are used for both py2 and py3 tasks. As a simple way to keep them working, `--py2` is used for them as it is always available. -- wpt-commits: 61d85c8f90cad174dd83d97399b894554705915e wpt-pr: 27081
jamienicol
pushed a commit
that referenced
this pull request
Jan 29, 2021
…testonly Automatic update from web-platform-tests wpt computing-row-measure-0.html fix 2 tests in this test suite seem inconsistent: test#2 asserts that tbody.height=10px > tr.height=1px > td.height=1px implies td.offsetHeight = 1px test#4 asserts that tbody.height=10px > tr > td.height=1px implies td.offsetHeight = 10px Edge 17 is the only browser that agrees with #2 and #4 FF agrees with #2, but not #4 Chrome agrees with #4, but not #2 Safari agrees with #4, but not #2 To me, #2 and #4 seem to be in conflict. Either tbody height propagates to rows, or it does not. The problem is that #2 is overconstrained. My suggestion is that tbody height always propagates to tr. Bug: 958381 Change-Id: I28bfd108c67968d31d0372b536c316c997d2d958 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2586097 Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Commit-Queue: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/master@{#845515} -- wpt-commits: 133ca044f481c49a8efd3f14f34f4b6a1b316f58 wpt-pr: 27265
jamienicol
pushed a commit
that referenced
this pull request
Jun 9, 2021
Here's what's going on (relevant browser is browser 36). [rr 502130 274898]RestoreDocShellState(browser=36, bc=94, ) [rr 502130 274902]RemoteWebNavigation.currentURI browser=36 bc=94 http://mochi.test:8888/#1 [rr 502130 274906]BrowsingContext::LoadURI(browser=36, bc=94, about:blank) From a previous restore we correctly wait for: 0 _restoreTabContent( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":5984:30] <failed to get 'this' value> 1 _sendRestoreTabContent( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":6002:11] <failed to get 'this' value> 2 restoreTabContent( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4684:9] <failed to get 'this' value> 3 restoreTab( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4565:13] <failed to get 'this' value> 4 restoreTabs( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> aSelectTab = "1") ["resource:///modules/sessionstore/SessionStore.jsm":4413:11] <failed to get 'this' value> 5 ssi_restoreWindow( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4189:11] <failed to get 'this' value> 6 _restoreWindowsFeaturesAndTabs( <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4275:11] <failed to get 'this' value> 7 _restoreWindowsInReversedZOrder( <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4299:9] <failed to get 'this' value> 8 ssi_restoreWindows/<( <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4359:11] [rr 502506 275264]BrowsingContext::LoadURI(browser=36, bc=94, about:blank) [rr 502506 275268]DocumentChannelChild::AsyncOpen(browser=36, bc=94, about:blank) [rr 502130 275388]RemoteWebNavigation.currentURI browser=36 bc=94 http://mochi.test:8888/#1 [rr 502506 275629]BrowserChild::OnLocationChange(browser=36, bc=94, about:blank) [rr 502130 276944]updateForLocationChange browser=36 bc=94 - about:blank [rr 502130 277084]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank [rr 502130 277358]RestoreDocShellState(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html) [rr 502506 277378]BrowserChild::OnLocationChange(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html) [rr 502130 277390]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank [rr 502130 277554]BrowserParent::LoadURL(browser=36, bc=94, about:blank) From: #18 0x00007ff0bdb1efcc in mozilla::dom::BrowserParent::LoadURL(nsDocShellLoadState*) (this=0x7ff08f2b9800, aLoadState=0x7ff094e1d580) at /home/emilio/src/moz/gecko/dom/ipc/BrowserParent.cpp:861 #19 0x00007ff0bc1117f9 in nsFrameLoader::ReallyStartLoadingInternal() (this=0x7ff08f283400) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoader.cpp:718 #20 0x00007ff0bc11129f in nsFrameLoader::ReallyStartLoading() (this=0x7ff08f283400) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoader.cpp:640 #21 0x00007ff0bc0002f5 in mozilla::dom::Document::MaybeInitializeFinalizeFrameLoaders() (this=0x7ff0a17e2000) at /home/emilio/src/moz/gecko/dom/base/Document.cpp:9008 #22 0x00007ff0bc057891 in mozilla::detail::RunnableMethodArguments<>::applyImpl<mozilla::dom::Document, void (mozilla::dom::Document::*)()>(mozilla::dom::Document*, void (mozilla::dom::Document::*)(), mozilla::Tuple<>&, std::integer_sequence<unsigned long>) (o=<optimized out>, m=<optimized out>, args=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:1150 #23 mozilla::detail::RunnableMethodArguments<>::apply<mozilla::dom::Document, void (mozilla::dom::Document::*)()>(mozilla::dom::Document*, void (mozilla::dom::Document::*)()) (this=<optimized out>, o=<optimized out>, m=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:1156 #24 mozilla::detail::RunnableMethodImpl<mozilla::dom::Document*, void (mozilla::dom::Document::*)(), true, (mozilla::RunnableKind)0>::Run() (this=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:1203 #25 0x00007ff0bbef8209 in nsContentUtils::RemoveScriptBlocker() () at /home/emilio/src/moz/gecko/dom/base/nsContentUtils.cpp:5696 #26 0x00007ff0bc11c427 in nsAutoScriptBlocker::~nsAutoScriptBlocker() (this=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsContentUtils.h:3499 #27 nsFrameLoaderOwner::ChangeRemotenessCommon(nsFrameLoaderOwner::ChangeRemotenessContextType const&, mozilla::dom::RemotenessChangeOptions const&, bool, bool, mozilla::dom::BrowsingContextGroup*, std::function<void ()>&, mozilla::ErrorResult&) (this=<optimized out>, this@entry=0x7ff0a041b608, aContextType=@0x7ffe238847fc: nsFrameLoaderOwner::ChangeRemotenessContextType::PRESERVE, aOptions= ..., aSwitchingInProgressLoad=false, aIsRemote=<optimized out>, aGroup=<optimized out>, aGroup@entry=0x0, aFrameLoaderInit=..., aRv=...) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoaderOwner.cpp:191 #28 0x00007ff0bc11c81f in nsFrameLoaderOwner::ChangeRemoteness(mozilla::dom::RemotenessOptions const&, mozilla::ErrorResult&) (this=0x7ff0a041b608, aOptions=..., rv=...) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoaderOwner.cpp:250 #29 0x00007ff0bcb59003 in mozilla::dom::XULFrameElement_Binding::changeRemoteness(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&)Traceback (most recent call last): File "/home/emilio/src/moz/gecko/js/src/gdb/mozilla/Root.py", line 55, in to_string ptr = ptr.dereference() gdb.error: value has been optimized out (cx_=<optimized out>, obj= , void_self=<optimized out>, args=...) at XULFrameElementBinding.cpp:513 #30 0x00007ff0bcecc02a in mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) (cx=0x1, cx@entry=0x7ff0a871b000, argc=<optimized out>, vp=<optimized out>) at /home/emilio/src/moz/gecko/dom/bindings/BindingUtils.cpp:3297 #31 0x00007ff0bf67b1f1 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) From: 0 updateBrowserRemoteness( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["chrome://browser/content/tabbrowser.js":1937:15] <failed to get 'this' value> 1 updateBrowserRemotenessByURL( <Failed to get argument while inspecting stack frame> aURL = ""http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html"") ["chrome://browser/content/tabbrowser.js":2052:20] <failed to get 'this' value> 2 restoreTabContent( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4662:38] <failed to get 'this' value> 3 restoreTab( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4565:13] <failed to get 'this' value> 4 restoreTabs( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> aSelectTab = "2") ["resource:///modules/sessionstore/SessionStore.jsm":4413:11] <failed to get 'this' value> 5 ssi_restoreWindow( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4189:11] <failed to get 'this' value> 6 _restoreWindowsFeaturesAndTabs( <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4275:11] <failed to get 'this' value> 7 _restoreWindowsInReversedZOrder( <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4299:9] <failed to get 'this' value> 8 ssi_restoreWindows/<( <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4359:11] This load triggers a remoteness change. [rr 502130 277558]RemoteWebNavigation.currentURI browser=36 bc=94 undefined [rr 502130 277561]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank [rr 502130 277564]RestoreDocShellState(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html) [rr 502130 277568]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank [rr 502130 277572]BrowsingContext::LoadURI(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html) This is the load that should actually end up in the browsing context. [rr 502578 280053]DocumentChannelChild::AsyncOpen(browser=36, bc=94, about:blank) From the previous remoteness update. [rr 502130 280138]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank [rr 502130 280141]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank [rr 502130 280143]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank [rr 502130 280146]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank At this point, we try to use the BFCache, and end up replacing the browsing context: #0 mozilla::dom::CanonicalBrowsingContext::AllowedInBFCache(mozilla::Maybe<unsigned long> const&) (this=0x7ff08f2b5800, aChannelId=...) at /home/emilio/src/moz/gecko/docshell/base/CanonicalBrowsingContext.cpp:2158 #1 0x00007ff0bb3157c1 in mozilla::net::DocumentLoadListener::MaybeTriggerProcessSwitch(bool*) (this=this@entry=0x7ff093b74090, aWillSwitchToRemote=aWillSwitchToRemote@entry=0x7ffe23887838) at /home/emilio/src/moz/gecko/netwerk/ipc/DocumentLoadListener.cpp:1723 #2 0x00007ff0bb317feb in mozilla::net::DocumentLoadListener::OnStartRequest(nsIRequest*) (this=0x7ff093b74090, aRequest=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/netwerk/ipc/DocumentLoadListener.cpp:2263 #3 0x00007ff0bb238a0c in mozilla::net::ParentChannelListener::OnStartRequest(nsIRequest*) (this=0x7ff08d5c4ee0, aRequest=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/netwerk/protocol/http/ParentChannelListener.cpp:91 #4 0x00007ff0bb9abec2 in nsDocumentOpenInfo::OnStartRequest(nsIRequest*) (this=<optimized out>, request=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:166 #5 0x00007ff0bb32baf0 in mozilla::net::ParentProcessDocumentOpenInfo::OnDocumentStartRequest(nsIRequest*) (this=0x7ff093bc5b80, request=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/netwerk/ipc/DocumentLoadListener.cpp:292 #6 0x00007ff0bae6446c in nsBaseChannel::OnStartRequest(nsIRequest*) (this=<optimized out>, request=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/base/nsBaseChannel.cpp:833 #7 0x00007ff0bae82bdd in nsInputStreamPump::OnStateStart() (this=this@entry=0x7ff08f2593c0) at /home/emilio/src/moz/gecko/netwerk/base/nsInputStreamPump.cpp:481 #8 0x00007ff0bae828d9 in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (this=0x7ff08f2593c0, stream=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/base/nsInputStreamPump.cpp:390 #9 0x00007ff0bae8339b in non-virtual thunk to nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) () at /home/emilio/src/moz/gecko/netwerk/base/nsInputStreamPump.cpp:632 #10 0x00007ff0bacd29d5 in mozilla::NonBlockingAsyncInputStream::RunAsyncWaitCallback(mozilla::NonBlockingAsyncInputStream::AsyncWaitRunnable*, already_AddRefed<nsIInputStreamCallback>) (this=this@entry=0x7ff094eb5a50, aRunnable=aRunnable@entry=0x7ff08f228560, aCallback=...) at /home/emilio/src/moz/gecko/xpcom/io/NonBlockingAsyncInputStream.cpp:397 #11 0x00007ff0bacdf2ec in mozilla::NonBlockingAsyncInputStream::AsyncWaitRunnable::Run() (this=0x7ff08f228560) at /home/emilio/src/moz/gecko/xpcom/io/NonBlockingAsyncInputStream.cpp:33 #12 0x00007ff0bad48d04 in mozilla::RunnableTask::Run() (this=0x7ff093bc5980) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:482 #13 0x00007ff0bad316d4 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (this=<optimized out>, this@entry=0x7ff0c54f2400, aProofOfLock=...) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:766 #14 0x00007ff0bad3091d in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (this=this@entry=0x7ff0c54f2400, aProofOfLock=...) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:621 #15 0x00007ff0bad30a83 in mozilla::TaskController::ProcessPendingMTTask(bool) (this=0x7ff0c54f2400, aMayWait=false) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:405 #16 0x00007ff0bad4388f in mozilla::TaskController::InitializeInternal()::$_0::operator()() const (this=<optimized out>) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:138 #17 mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_0>::Run() (this=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:534 #18 0x00007ff0bad3b7f6 in nsThread::ProcessNextEvent(bool, bool*) (this=0x7ff0c541d680, aMayWait=false, aResult=0x7ffe23888437) at /home/emilio/src/moz/gecko/xpcom/threads/nsThread.cpp:1159 #19 0x00007ff0bad3f384 in NS_ProcessNextEvent(nsIThread*, bool) (aThread=0x7ff08f2b5800, aThread@entry=0x7ff0c541d680, aMayWait=false) at /home/emilio/src/moz/gecko/xpcom/threads/nsThreadUtils.cpp:548 #20 0x00007ff0bb43dfe0 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7ff0c54d12c0, aDelegate=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/glue/MessagePump.cpp:85 #21 0x00007ff0bb3be7b7 in MessageLoop::RunInternal() (this=this@entry=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/chromium/src/base/message_loop.cc:335 #22 0x00007ff0bb3be707 in MessageLoop::RunHandler() (this=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/chromium/src/base/message_loop.cc:328 #23 MessageLoop::Run() (this=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/chromium/src/base/message_loop.cc:310 #24 0x00007ff0bded2bdb in nsBaseAppShell::Run() (this=0x7ff0a880c580) at /home/emilio/src/moz/gecko/widget/nsBaseAppShell.cpp:137 #25 0x00007ff0bf449d85 in nsAppStartup::Run() (this=0x7ff0a883de20) at /home/emilio/src/moz/gecko/toolkit/components/startup/nsAppStartup.cpp:273 #26 0x00007ff0bf5428b6 in XREMain::XRE_mainRun() (this=<optimized out>, this@entry=0x7ffe238887c0) at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:5239 #27 0x00007ff0bf5433ef in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) (this=this@entry=0x7ffe238887c0, argc=argc@entry=5, argv=argv@entry=0x7ffe23889a68, aConfig=<optimized out>) at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:5437 #28 0x00007ff0bf54385e in XRE_main(int, char**, mozilla::BootstrapConfig const&) (argc=-1816706824, argv=0x7ff0c56441a0, aConfig=...) at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:5496 #29 0x0000562d08f8e415 in do_main(int, char**, char**) (argc=-1816706824, argv=0x7ffe23889a68, envp=<optimized out>) at /home/emilio/src/moz/gecko/browser/app/nsBrowserApp.cpp:224 [rr 502130 280199]CanonicalBrowsingContext::ReplacedBy(94 -> 104) [rr 502130 280344]didChangeRemoteness browser=36, bc=104 [rr 502130 280348]RemoteWebNavigation.currentURI browser=36 bc=104 undefined [rr 502130 280625]RedirectToRealChannel(36, about:blank) [rr 502578 280695]BrowserChild::OnLocationChange(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html) [rr 502578 280699]BrowsingContext::LoadURI(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html) [rr 502578 280703]DocumentChannelChild::AsyncOpen(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html) This is the LoadURI call for the "final" load, however it went to the wrong browsing context, as we just replaced this! [rr 502130 280803]updateForLocationChange browser=36 bc=104 - http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html [rr 502130 280807]RemoteWebNavigation.currentURI browser=36 bc=104 http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html [rr 502578 281334]BrowserChild::OnLocationChange(browser=36, bc=104, about:blank) And this one is from the process switch. [rr 502130 281461]updateForLocationChange browser=36 bc=104 - about:blank [rr 502130 281465]RemoteWebNavigation.currentURI browser=36 bc=104 about:blank [rr 502130 282028] ⰲ겿{"action":"test_status","time":1621467211822,"thread":null,"pid":null,"source":"mochitest","test":"chrome://mochitests/content/browser/browser/base/content/test/tabs/browser_new_tab_insert_position.js","subtest":"tab pos 0 matched http://mochi.test:8888/#0","status":"PASS","message":"","js_source":"TestRunner.js"}ⰲ겿 [rr 502130 282031]RemoteWebNavigation.currentURI browser=36 bc=104 about:blank [rr 502130 282033]RemoteWebNavigation.currentURI browser=36 bc=104 about:blank [rr 502130 282117] So this is certainly the easy fix, but I think we should generally try to deal with this better, somehow? Differential Revision: https://phabricator.services.mozilla.com/D115560
jamienicol
pushed a commit
that referenced
this pull request
Jun 23, 2021
Automatic update from web-platform-tests Safe slot reassigment 1. Use GetWithoutInvalidation() instead of Get() in DCHECKs. We should never call Get() inside of a DCHECK(), because this can lead to a different code path depending on whether DCHECKs are enabled. 2. Get() should not cause immediate side effects. At most, it should queue up an invalidation for later processing. Fixing #1 and #2 were required in order to get past a first set of errors introduced by the new test. 3. The actual fix -- avoid infinite loop by calling a special new SlotAssignmentWillChange(), rather than ChildrenChanged(), where a minimal GetWithoutInvalidation() is called that does not lead to IsShadowContentRelevantForAccessibility() => FirstChild() => RecalcAssignedNodes() => ChildrenChanged() ... (infinite loop). A simpler potential fix is in CL:2965317 but requires more research. It's also mentioned in a TODO comment. Bug: 1219311 Change-Id: Iafaa289f241a851404ce352715d2970172a2e5f8 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2961158 Reviewed-by: Joey Arhar <jarhar@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Commit-Queue: Aaron Leventhal <aleventhal@chromium.org> Cr-Commit-Position: refs/heads/master@{#892778} -- wpt-commits: 7b9ca7da96108c39142ebf9b6d639d9725beebf4 wpt-pr: 29388
jamienicol
pushed a commit
that referenced
this pull request
Oct 27, 2021
…t-in add-on (server side). r=rpl
- `test_redirect_{final,two_hops,three_hops}` correspond to SSR #1
- `test_no_event_when_search_engine_not_used` corresponds to SSR #2
- `test_redirect_chain_does_not_start_on_first_request` corresponds to SSR #3
- `test_two_extensions_reported` corresponds to SSR #4
Differential Revision: https://phabricator.services.mozilla.com/D129176
jamienicol
pushed a commit
that referenced
this pull request
Nov 5, 2021
…ort", a=testonly Automatic update from web-platform-tests Reland #2 "[LCP] Add animated image support" This is a manual reland of https://chromium-review.googlesource.com/c/chromium/src/+/3247449 The difference from the previous reland is that the browser tests now include 2 separate timeouts and a double rAF, to ensure that the presentation timestamp taken is far enough from both the time the first frame is sent as well as from the time the second frame is sent. More importantly, the test now actually is looking at the UKM metric, rather than at the histogram. Original change's description: > [LCP] Add animated image support > > This CL adds support for better handling of animated images in LCP: > * A new attribute is exposing the first animated frame's paint time > (behind a flag). > * `startTime` is not changed. > * The PageLoadMetrics reported for LCP are set to that first frame paint > time for animated images (behind another flag). > * Entries are not emitted until the image is loaded. > > Relevant spec issue: > w3c/largest-contentful-paint#83 Bug: 1260953 Change-Id: I34070bd90a74ed44281da63b547f13d9669f389b Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3250690 Reviewed-by: Nicolás Peña Moreno <npm@chromium.org> Commit-Queue: Yoav Weiss <yoavweiss@chromium.org> Cr-Commit-Position: refs/heads/main@{#936516} -- wpt-commits: ae80b50422c2c9c32697c529c34b3c1d46965ee1 wpt-pr: 31415
jamienicol
pushed a commit
that referenced
this pull request
Feb 7, 2022
… a=testonly Automatic update from web-platform-tests AnonymousIframe: WPT BroadcastChannel #2 (#32346) The previous patch: https://chromium-review.googlesource.com/c/chromium/src/+/3371612/6 checked an AnonymousIframe and an Iframe wasn't sharing the same partition. This one test: - Two sibling same-origin anonymous iframe share the same partition. - Two same-origin nested anonymous iframe share the same partition. - Two same-origin anonymous iframe from different popup do not share the same partition. Bug: 1285331,1226469 Change-Id: I7ebc3a5bbb5e1f12d0ceaac9d89c1deb30174a37 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3379159 Reviewed-by: Andrew Williams <awillia@google.com> Commit-Queue: Arthur Sonzogni <arthursonzogni@chromium.org> Cr-Commit-Position: refs/heads/main@{#960946} Co-authored-by: Arthur Sonzogni <arthursonzogni@chromium.org> -- wpt-commits: 3da9d044be5abc2d9fb2fe9a26f3c9f0d995f76d wpt-pr: 32346
jamienicol
pushed a commit
that referenced
this pull request
Mar 1, 2022
…e ordering, a=testonly
Automatic update from web-platform-tests
App history: tweak and test event/promise ordering
By adding new exhaustive tests under ordering/, it was revealed that the ordering between navigatesuccess/navigateerror and the committed/finished promises was not always consistent:
1. Simply adding a currentchange event handler would cause microtasks to run during commit, which changed some ordering.
2. Calling transitionWhile() would take us from the zero-promise case to the 1+-promise case in ScriptPromise::All(). As the new comment explains, both the spec and implementation have an observably-different fast path for the 0-promise case which caused changes in ordering.
In the course of fixing this, I found out that the did_finish_before_commit_ code in app_history_api_navigation.{h,cc} was actually not a mitigation for the case it stated, where promises passed to transitionWhile() would settle faster than the browser-process roundtrip for same-document traversals. That is in fact impossible, since we only fire the navigate event after the browser-process roundtrip has completed. Instead, they were a mitigation for (1).
This commit then ensures consistent ordering, tested with new rather-exhaustive tests, in the following manner:
* We move the firing of currentchange to before resolving the committed promise. This eliminates (1) and allows us to delete the did_finish_before_commit_ tracking.
* We always ensure we pass 1+ promises to ScriptPromise::All(). This eliminates (2).
A consequence of this is that we are now more likely to get rejected finished promises, in cases like
await appHistory.navigate("#1").committed;
await appHistory.navigate("#2").committed;
Before, the finished promise for the #1 navigation would go through the fast path per (2), and fulfill before the navigation to #2 canceled it. Now that does not happen, so code like the above will give an unhandled promise rejection for #1's finished promise.
To avoid this, we unconditionally mark finished promises as handled. This follows some web platform precedent, e.g. stream closed promises, where the promise is one of several information channels (in this case the developer might also find out via the AbortSignal or the navigateerror event). We do *not* do this for the committed promise though, as if a commit fails, that's probably something more deeply wrong, and cannot be ignored.
All of these changes will require spec updates.
For the tests, we introduce a new ordering/ directory which contains cross-cutting ordering tests, and we consolidate a few tests into the newly-introduced variant-driven exhaustive ones. A couple of other tests were affected by these changes too or fixed as a drive-by.
Change-Id: I8a50ca28d009e0a8a2c94331cd17f29b0a8dc463
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3405377
Reviewed-by: Nate Chapin <japhet@chromium.org>
Commit-Queue: Domenic Denicola <domenic@chromium.org>
Cr-Commit-Position: refs/heads/main@{#963772}
--
wpt-commits: 3638c168c6db3f12a8d72f1e70e2d66ced788528
wpt-pr: 32504
jamienicol
pushed a commit
that referenced
this pull request
Mar 8, 2022
…e ordering, a=testonly
Automatic update from web-platform-tests
App history: tweak and test event/promise ordering
By adding new exhaustive tests under ordering/, it was revealed that the ordering between navigatesuccess/navigateerror and the committed/finished promises was not always consistent:
1. Simply adding a currentchange event handler would cause microtasks to run during commit, which changed some ordering.
2. Calling transitionWhile() would take us from the zero-promise case to the 1+-promise case in ScriptPromise::All(). As the new comment explains, both the spec and implementation have an observably-different fast path for the 0-promise case which caused changes in ordering.
In the course of fixing this, I found out that the did_finish_before_commit_ code in app_history_api_navigation.{h,cc} was actually not a mitigation for the case it stated, where promises passed to transitionWhile() would settle faster than the browser-process roundtrip for same-document traversals. That is in fact impossible, since we only fire the navigate event after the browser-process roundtrip has completed. Instead, they were a mitigation for (1).
This commit then ensures consistent ordering, tested with new rather-exhaustive tests, in the following manner:
* We move the firing of currentchange to before resolving the committed promise. This eliminates (1) and allows us to delete the did_finish_before_commit_ tracking.
* We always ensure we pass 1+ promises to ScriptPromise::All(). This eliminates (2).
A consequence of this is that we are now more likely to get rejected finished promises, in cases like
await appHistory.navigate("#1").committed;
await appHistory.navigate("#2").committed;
Before, the finished promise for the #1 navigation would go through the fast path per (2), and fulfill before the navigation to #2 canceled it. Now that does not happen, so code like the above will give an unhandled promise rejection for #1's finished promise.
To avoid this, we unconditionally mark finished promises as handled. This follows some web platform precedent, e.g. stream closed promises, where the promise is one of several information channels (in this case the developer might also find out via the AbortSignal or the navigateerror event). We do *not* do this for the committed promise though, as if a commit fails, that's probably something more deeply wrong, and cannot be ignored.
All of these changes will require spec updates.
For the tests, we introduce a new ordering/ directory which contains cross-cutting ordering tests, and we consolidate a few tests into the newly-introduced variant-driven exhaustive ones. A couple of other tests were affected by these changes too or fixed as a drive-by.
Change-Id: I8a50ca28d009e0a8a2c94331cd17f29b0a8dc463
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3405377
Reviewed-by: Nate Chapin <japhet@chromium.org>
Commit-Queue: Domenic Denicola <domenic@chromium.org>
Cr-Commit-Position: refs/heads/main@{#963772}
--
wpt-commits: 3638c168c6db3f12a8d72f1e70e2d66ced788528
wpt-pr: 32504
jamienicol
pushed a commit
that referenced
this pull request
May 25, 2022
…2 test on WPT.fyi, a=testonly Automatic update from web-platform-tests Try again to fix the backdrop-animate-002 test on WPT.fyi This test fails with off-by-one values on the green background. This is attempt #2 to fix that, by adding fuzziness. Bug: 1323293 Change-Id: I9f51f257ef0064b6cd144a32ae01b148ed881112 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3638193 Reviewed-by: Philip Rogers <pdr@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1001695} -- wpt-commits: 3238a6af508efb8e621676df5e2f803e760fb263 wpt-pr: 34020
jamienicol
pushed a commit
that referenced
this pull request
Jan 3, 2023
This commit was cherry-picked in the previous release branch for v105 (42be4ae879, branch-heads/5195). Upstream commit: https://webrtc.googlesource.com/src/+/cefe4777a077279418f2325f60ae9c7619ecba9b Limit input size for the rtp video layers allocation fuzzer (cherry picked from commit 02c99982c8e5a88ca14cc217254f3d9b3c792646) Bug: chromium:1355892 Change-Id: Ib0c48d27fb1e79212d2354e0249511aeeb53f650 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272961 Commit-Queue: Danil Chapovalov <danilchap@webrtc.org> Reviewed-by: Per Kjellander <perkj@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#37913} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274400 Reviewed-by: Danil Chapovalov <danilchap@webrtc.org> Commit-Queue: Per Kjellander <perkj@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/branch-heads/5249@{#2} Cr-Branched-From: 7aaeb5a270ba23f5844f7301a50aaff9b6ca6126-refs/heads/main@{#37825}
jamienicol
pushed a commit
that referenced
this pull request
Jan 13, 2023
… invoker, a=testonly Automatic update from web-platform-tests Fix focus traversal for self-referential invoker In the case that a popover contains an invoker that points back to that invoker, the tab navigation code used to get confused. E.g.: ``` <div id="menu" popover> <button autofocus popoverhidetarget="menu">Button #1</button> <button popoverhidetarget="menu">Button #2</button> </div> ``` In this case, trying to tab between the first and second button would break because the second button appeared to be an invoker for a new popover, when in reality it was an invoker for the same popover. Fixed: 1399601 Bug: 1307772 Change-Id: I276370d7c8eee0dd32f0c89da202a0d3777bf911 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4133482 Commit-Queue: Mason Freed <masonf@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1089080} -- wpt-commits: f938eec99e167202dc5e9e4e8067ab4d53e10834 wpt-pr: 37766
jamienicol
pushed a commit
that referenced
this pull request
Jan 25, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/094ee30504a6a26d7bc9f0968bfc2c20bfd9874d Add an active ICE controller interface (#2/n) This interface will be implemented by "new" ICE controllers that actively manage the connection used by the transport. Bug: webrtc:14367, webrtc:14131 Change-Id: I0858884b0decd2a17ae9ca8617a043a085c61d54 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271291 Commit-Queue: Sameer Vijaykar <samvi@google.com> Reviewed-by: Jonas Oreland <jonaso@webrtc.org> Cr-Commit-Position: refs/heads/main@{#38066}
jamienicol
pushed a commit
that referenced
this pull request
Jan 25, 2023
We already cherry-picked this when we vendored a22c2a0c58. Upstream commit: https://webrtc.googlesource.com/src/+/ec86e953c4b1eb0efd5b0a06834eaa8f73d3660d [merge to M107] Revert "rtp sender: don't send BYE on deactivating streams" This reverts commit a22c2a0c581cbe3f612f7a7d9fb9840186cc1e06. Reason for revert: breaks upstream project Original change's description: > rtp sender: don't send BYE on deactivating streams > > as this breaks RTCP assumptions about SSRCs being no longer > active as defined in > https://www.rfc-editor.org/rfc/rfc3550#section-6.6 > > This should not be sent in reaction to temporarily disabling > a stream via RTCRtpParameters.active as this does not mean that > the participant is leaving the session as defined in > https://www.rfc-editor.org/rfc/rfc3550#section-6.3.7 > and does not indicate end of participation as defined in > https://www.rfc-editor.org/rfc/rfc3550#section-6.1 > which stipulates BYE should be the last packet sent from this SSRC. > > BUG=webrtc:11082 > > Change-Id: Ia5144857f85303643146b0759184f0f3f50b66e4 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273348 > Reviewed-by: Harald Alvestrand <hta@webrtc.org> > Commit-Queue: Philipp Hancke <phancke@microsoft.com> > Cr-Commit-Position: refs/heads/main@{#38059} (cherry picked from commit 03e6cccc28d76f28c926ce7cadaeba2c6a6cacf4) Bug: webrtc:11082 Change-Id: Iaaff0c0d7bb857fe9ce78ebcc716f3c6f1bc5c4a Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275640 Reviewed-by: Henrik Boström <hbos@webrtc.org> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> Commit-Queue: Philipp Hancke <phancke@microsoft.com> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Cr-Original-Commit-Position: refs/heads/main@{#38097} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276045 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/branch-heads/5304@{#2} Cr-Branched-From: 024bd84ca1cf7d3650c27912a3b5bfbb54da152a-refs/heads/main@{#38083}
jamienicol
pushed a commit
that referenced
this pull request
Jan 25, 2023
…cker - r=timhuang Attempt #2 with a lot of refactoring included Differential Revision: https://phabricator.services.mozilla.com/D165296
jamienicol
pushed a commit
that referenced
this pull request
Feb 7, 2023
1. Ship the Sanitization (currently on in Nightly
but without crashing) to the trains
2. Enabling crashing in Nightly
#1 will start omitting the preference values in
Content Processes. An affected user will have
their browser behave differently - it will be as
if the preference has no value. So for e.g. the
font preferences, their font customizations will
be gone. If they file a bug about this happening
and an engineer connects the problem to pref
sanitization we could debug the issue and maybe
understand it.
#2 will mean that an affected user (of which
there are currently none we think) will have a
content process crash when they access a
forbidden preference. The crash reason will
contain the name of the preference, and the
stack which would help us better understand
why we crashed.
Differential Revision: https://phabricator.services.mozilla.com/D167287
jamienicol
pushed a commit
that referenced
this pull request
Feb 14, 2023
Differential Revision: https://phabricator.services.mozilla.com/D169648
jamienicol
pushed a commit
that referenced
this pull request
Feb 20, 2023
We already cherry-picked this when we vendored b82c45815a. Upstream commit: https://webrtc.googlesource.com/src/+/ffceb9b4ad5a111cd2410107d929ccf4adff8f7c [TurnPort] Check if turn entry was found when deleting a connection. This is a simple way to avoid crashing, but the underlying issue of why the entry has been removed, is a bit more complex to fix and will be fixed in a follow-up CL. Using no-try to land since the win_asan bot is failing for an unrelated reason and all other bots have passed. (cherry picked from commit 9c606497d155d6304933517576f051f84d50e907) No-try: true Bug: chromium:1374310 Change-Id: I9dc0cf9e1acdcc3b3a205104346cc835b3f79c1b Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279283 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#38405} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280221 Reviewed-by: Artem Titov <titovartem@webrtc.org> Cr-Commit-Position: refs/branch-heads/5359@{#2} Cr-Branched-From: fb3bd4a01d7c840dfe7b3efa144c0fbcb6a97fef-refs/heads/main@{#38387}
jamienicol
pushed a commit
that referenced
this pull request
Mar 1, 2023
…iewers,pehrsons Make the new API available to everyone and just return an empty capturer in case when building without PipeWire. It will not make any difference because using X11 based capturers on Wayland is useless anyway so if we fail for missing PipeWire on Wayland, it will have the same outcome. Differential Revision: https://phabricator.services.mozilla.com/D171192
jamienicol
pushed a commit
that referenced
this pull request
Jun 27, 2023
…ding error in page.py test, a=testonly Automatic update from web-platform-tests [wdspec] browsingContext.print: fix rounding error in page.py test (#40504) * [wdspec] browsingContext.print: fix rounding error in page.py test [pytest](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/webdriver/tests/support/image.py) uses: def cm_to_px(cm): return round(cm * 96 / 2.54) [js](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/tools/wptrunner/wptrunner/print_pdf_runner.html) uses: const viewport = page.getViewport({ scale: 96. / 72. }); ... canvas.height = viewport.height; canvas.width = viewport.width; This produces a rounding error, even though the dimension is correct: > assert cm_to_px(expected_dimensions["height"]) == height E assert 454 == 453 E +454 E -453 The inconsistency of rounding in both ends becomes clear when we eliminate "round" in the pytest side: > assert cm_to_px(expected_dimensions["height"]) == height E assert 453.54330708661416 == 453 E +453.54330708661416 E -453 There are multiple ways to fix this issue. Option #1: Use "floor" instead of "round" in pytest. Option #2: Use a range in the assertion comparison, allowing a difference of up to +-1.0. This is what this PR does. The comparison is performed in [`assert_pdf_dimensions`](https://github.com/web-platform-tests/wpt/blob/b6107cc1ac8b9c2800b4c8e58af719b8e4d9b8db/webdriver/tests/support/fixtures_bidi.py#L210). The problematic part is .96 / .72 which evaluates to 4/3 = 1.333333.... * use floor in cm_to_px instead of round * compare to floor and to round instead of a range * Revert "compare to floor and to round instead of a range" This reverts commit 63f894e6d1881616e0f13b7a40ddcb30b772eba8. * Revert "use floor in cm_to_px instead of round" This reverts commit 7e65d918b25575060ca50009d261d1e76dca6cae. -- wpt-commits: fb57353809aa19c0659ece5563d05ed20706d1fc wpt-pr: 40504
jamienicol
pushed a commit
that referenced
this pull request
Aug 7, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/ecab2a49da48f0279a3b6422dab602614630005e [m114] Attempt to recycle a stopped data m-line before creating a new one which avoids an infinitely growing SDP if the remote end rejects the datachannel section. This will reactivate the m-line even if all datachannels are closed. BUG=chromium:1442604 (cherry picked from commit 522380ff734174faab694e1b67c9d20fffa8738e) No-Try: True Change-Id: If60f93b406271163df692d96102baab701923602 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304241 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Philipp Hancke <phancke@microsoft.com> Reviewed-by: Henrik Boström <hbos@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40029} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305420 Commit-Queue: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/branch-heads/5735@{#2} Cr-Branched-From: df7df199abd619e75b9f1d9a7e12fc3f3f748775-refs/heads/main@{#39949}
jamienicol
pushed a commit
that referenced
this pull request
Aug 31, 2023
We already cherry-picked this when we vendored e46e37b6f8. Upstream commit: https://webrtc.googlesource.com/src/+/ba943f71e64a93558a51e75d18917f363b8672e9 [M115] Move transceiver iteration loop over to the signaling thread. This is required for ReportTransportStats since iterating over the transceiver list from the network thread is not safe. (cherry picked from commit dba22d31909298161318e00d43a80cdb0abc940f) Bug: chromium:1446274, webrtc:12692 Change-Id: I7c514df9f029112c4b1da85826af91217850fb26 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/307340 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40197} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308000 Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/branch-heads/5790@{#2} Cr-Branched-From: 2eacbbc03a4a41ea658661225eb1c8fc07884c33-refs/heads/main@{#40122}
jamienicol
pushed a commit
that referenced
this pull request
Oct 3, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/279a05475d3bdc90ecbe4ba03a640411562b8626 [M116] In VideoCaptureImpl and subclasses add thread and lock annotations This annotates all unannotated members in VideoCaptureImpl and its subclasses with either of: - api_checker_: access on the api thread only - capture_checker_: access in callbacks/on the capture thread while capture is active, on the api thread otherwise - a Mutex if it is already protected by it (cherry picked from commit eee10391cac9c63be3ec6c6b6fe0a8b097c859b1) Bug: webrtc:15181 Change-Id: I5084e7752a4716c29b85a9b403a88696f66d811f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305647 Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Per Kjellander <perkj@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40335} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310500 Reviewed-by: Henrik Boström <hbos@webrtc.org> Cr-Commit-Position: refs/branch-heads/5845@{#2} Cr-Branched-From: f80cf814353d11a9f22bef5ce5e8868f2c72f0d0-refs/heads/main@{#40319}
jamienicol
pushed a commit
that referenced
this pull request
Oct 3, 2023
…g anchor element's siblings, a=testonly
Automatic update from web-platform-tests
Fix :has() invalidation bug when removing anchor element's siblings
This CL fixes a :has() invalidation bug when the following conditions
are met:
1. A style rule uses a :has() pseudo class. The :has() test result is
affected by the anchor element's relationship to its sibling
element at fixed distance. (e.g. '.a:has(+ .b) {}')
2. The :has() pseudo class was tested on an anchor element and it
didn't matched.
3. If a sibling of the anchor element is removed, the :has() will
match the anchor element.
(e.g. '<div class=a></div><div id=target></div><div class=b></div>')
4. Remove a sibling of the anchor element so that the :has() matches
the anchor element. (e.g. 'target.remove();')
For the removal, StyleEngine have to schedule :has() invalidation
even if the removed element doesn't have any identifier stored in
RuleFeatureSet. But it is not efficient to schedule :has()
invalidation for every element removal.
To avoid unnecessary :has() invalidation, StyleEngine checks whether
its parent has the 'ChildrenAffectedByDirectAdjacentRules' flag set
or not.
Currently, the SelectorChecker sets the flag only when it consumes
a direct adjacent combinator(+). This works most cases but it doesn't
work in this case (condition #2) because the SelectorChecker stops
the :has() argument selector matching before consuming the direct
adjacent combinator. Due to this, the parent of the anchor element
doesn't have the 'ChildrenAffectedByDirectAdjacentRules' flag set
and the StyleEngine doesn't schedule the :has() invalidation for the
removal.
To fix the error, when the SelectorChecker tests a :has() pseudo
class on an anchor element and the :has() is affected by the anchor
element's relationship to a sibling at fixed distance, the
SelectorChecker sets the flag of the parent to indicate that
StyleEngine need to schedule :has() invalidation whenever any child
of the element is removed.
Bug: 1480643
Change-Id: I5ec2e3c1db2773020368415f68bca1503367e669
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4864627
Commit-Queue: Byungwoo Lee <blee@igalia.com>
Reviewed-by: Rune Lillesveen <futhark@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1198137}
--
wpt-commits: 2f5741f704e062180e3424c1126ba5b30cf6dd07
wpt-pr: 42012
jamienicol
pushed a commit
that referenced
this pull request
Oct 24, 2023
We already cherry-picked this when we vendored 402f60c2ea. Upstream commit: https://webrtc.googlesource.com/src/+/70aa7e99e4af06e9a2273793179dfcfddad11898 [Merge to 117] CHECK against overwrites in send_modules_map_ (cherry picked from commit 9d8fb97b3ca56ec9920271d8e545ae2ac76b143c) No-try: true Bug: chromium:1477075 Change-Id: Ia05a868bfab9e99ef66704e8d6bce516a7a43b0a Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/318440 Reviewed-by: Sergey Silkin <ssilkin@webrtc.org> Commit-Queue: Harald Alvestrand <hta@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40673} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/319100 Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org> Cr-Commit-Position: refs/branch-heads/5938@{#2} Cr-Branched-From: 82e5f91a2bdf955aa870142008fbdc9ac12f6acd-refs/heads/main@{#40524}
jamienicol
pushed a commit
that referenced
this pull request
Nov 20, 2023
…chevobbe Just starting up a debug build you will get 40 copies of this printed. The uri that we fail to get host of is about:newtab. One stack looks like this #2: mozilla::BasePrincipal::GetIsLoopbackHost(bool*) #3: mozilla::net::LoadInfo::LoadInfo(nsIPrincipal*, nsIPrincipal*, nsINode*, unsigned int, nsIContentPolicy::nsContentPolicyType, mozilla::Maybe<mozilla::dom::ClientInfo> const&, mozilla::Maybe<mozilla::dom::ServiceWorkerDescriptor> const&, unsigned int, bool #4: ShouldLoadCachedImage(imgRequest*, mozilla::dom::Document*, nsIPrincipal*, nsIContentPolicy::nsContentPolicyType, bool) #5: imgLoader::LoadImage(nsIURI*, nsIURI*, nsIReferrerInfo*, nsIPrincipal*, unsigned long long, nsILoadGroup*, imgINotificationObserver*, nsINode*, mozilla::dom::Document*, unsigned int, nsISupports*, nsIContentPolicy::nsContentPolicyType, nsTSubstring<char16 #6: nsContentUtils::LoadImage(nsIURI*, nsINode*, mozilla::dom::Document*, nsIPrincipal*, unsigned long long, nsIReferrerInfo*, imgINotificationObserver*, int, nsTSubstring<char16_t> const&, imgRequestProxy**, nsIContentPolicy::nsContentPolicyType, bool, bool, #7: mozilla::css::ImageLoader::LoadImage(mozilla::StyleComputedUrl const&, mozilla::dom::Document&) #8: mozilla::StyleComputedUrl::ResolveImage(mozilla::dom::Document&, mozilla::StyleComputedUrl const*) #9: nsStyleImageLayers::ResolveImages(mozilla::dom::Document&, nsStyleImageLayers const*) #10: mozilla::ComputedStyle::StartImageLoads(mozilla::dom::Document&, mozilla::ComputedStyle const*) Differential Revision: https://phabricator.services.mozilla.com/D193349
jamienicol
pushed a commit
that referenced
this pull request
Nov 24, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/597e7ba370a973f64f822aa247cb2355de7c5f47 [M118] Obfuscate prflx raddr when using mdns BUG=chromium:1478690 (cherry picked from commit a8e3111d8c6622eeb930c32ab7a2e6be51b3d801) Change-Id: I7a1caad7bbd2fc82507b61b59be71546494a304c Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/319580 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Henrik Boström <hbos@webrtc.org> Commit-Queue: Philipp Hancke <phancke@microsoft.com> Cr-Original-Commit-Position: refs/heads/main@{#40724} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320580 Cr-Commit-Position: refs/branch-heads/5993@{#2} Cr-Branched-From: 5afcec093c1403fe9e3872706d04671cbc6d2983-refs/heads/main@{#40703}
jamienicol
pushed a commit
that referenced
this pull request
Mar 4, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/9f1e1925f33a8dd0d7b84f805be6d7f15ff28b0e dcsctp: Fix not using iteraters after NackItem OutstandingData::NackItem nacks a chunk, and if that chunk reaches its partial reliability critera, it will abandon the entire message. If that message hasn't been sent in full, a placeholder "end" message is inserted (see https://crbug.com/webrtc/12812). And when the message is inserted, any iterators may be invalidated (if e.g. std::deque would want to grow the deque). So ensure that there are no iterators used after having called NackItem. By changing the interface of NackItem, and not passing an Item, but just the TSN, this is encouraged. NackAll was rewritten as a two-pass algorithm to first collect TSNs, then iterating that list, looking up the items in the second pass (constant complexity). (cherry picked from commit 161d2c84528ec9eb0c19bfb51024bca54353abc4) No-Try: True Bug: chromium:1510364 Change-Id: I5156b6d6a683184f290e71c98f16bc68ea2a562f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/331320 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Sam Zackrisson <saza@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#41374} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/331960 Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/branch-heads/6167@{#2} Cr-Branched-From: ece5cb83715dea85617114b6d4e981fdee2623ba-refs/heads/main@{#41315}
jamienicol
pushed a commit
that referenced
this pull request
Apr 19, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/45e49ef5371ed67ee3278244248133bf9783d65c [M123] Fix handling of rejected m-lines without transport description A fingerprint should not be required for m-lines which are rejected. BUG=chromium:326493639,webrtc:11066 (cherry picked from commit 845d6bef52ec08dfd9c87d3eff5ae5c07c3fe55d) Change-Id: I7428c91a144ca46650e13d72868f160652a98339 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/340322 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Florent Castelli <orphis@webrtc.org> Commit-Queue: Philipp Hancke <phancke@microsoft.com> Cr-Original-Commit-Position: refs/heads/main@{#41794} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/341023 Cr-Commit-Position: refs/branch-heads/6312@{#2} Cr-Branched-From: 0355f455a48b141a8277442825ec776a74d66fb7-refs/heads/main@{#41763}
jamienicol
pushed a commit
that referenced
this pull request
Apr 30, 2024
…est is affected by rounded corners, a=testonly Automatic update from web-platform-tests Fall back to main thread if scroll hit test is affected by rounded corners We had two issues: 1. Before we had fast rounded corners, we always created mask layers for rounded corner clips, and the mask layer made the scroll begin unreliable and fall back to the main thread. With fast rounded corners, the scrolls were treated as reliable without checking if the point is in or out of the rounded corners. 2. If the scroller has a rounded corner by itself (instead of from an ancestor), as we only create InnerBorderRadiusClip for the contents, the compositor doesn't actually know which part of the layer bounds is transparent to hit test (e.g. if the scroller has a border which is outside of the InnerBorderRadiusClip). Now with HitTestOpaqueness, such layers have HitTestOpaqueness::kMixed. This CL changes the behavior of LayerTreeImpl::FindLayersUpToFirstOpaqueToHitTest (renamed from FindLayerUpToFirstScrollableOrOpaqueToHitTest): - For issue #1: LayerImpl::OpaqueToHitTest() also checks whether the layer is affected by any fast rounded corners; - For issue #2: FindLayerUpToFirstOpaqueToHitTest checks only OpaqueToHitTest() (without checking IsScrollerOrScrollbar()) because a hit test on a scrollable layer is reliable only if it's opaque to hit test. Bug: 40277896 Change-Id: I1acb16f2c6790760661e8239ea1599035f83ea51 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5466909 Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: Steve Kobes <skobes@chromium.org> Cr-Commit-Position: refs/heads/main@{#1291538} -- wpt-commits: 9e7e1bd19fecd541ce4192e24039b746a88ce3df wpt-pr: 45797
jamienicol
pushed a commit
that referenced
this pull request
May 13, 2024
…ug,dom-core Bug #1: AbstractRange::(Mark|Unmark)Descendants should always use the shadow tree of web-exposed shadow root, instead of using light DOM elements of the host. Bug #2: aRange could possibly create mCrossShadowBoundaryRange first (due to boundaries are in different tree), and later moves the boundaries to the same tree. When this happens, we should remove mCrossShadowBoundaryRange and use the default range to represent it. Differential Revision: https://phabricator.services.mozilla.com/D207608
jamienicol
pushed a commit
that referenced
this pull request
May 14, 2024
…ug,dom-core Bug #1: AbstractRange::(Mark|Unmark)Descendants should always use the shadow tree of web-exposed shadow root, instead of using light DOM elements of the host. Bug #2: aRange could possibly create mCrossShadowBoundaryRange first (due to boundaries are in different tree), and later moves the boundaries to the same tree. When this happens, we should remove mCrossShadowBoundaryRange and use the default range to represent it. Differential Revision: https://phabricator.services.mozilla.com/D207608
jamienicol
pushed a commit
that referenced
this pull request
May 17, 2024
We already cherry-picked this when we vendored fea41f540c. Upstream commit: https://webrtc.googlesource.com/src/+/93e9ac6285bceef08e4c44c221ec57e8f7995b2f [M124] Revert "pc: Include SCTP queued bytes in buffered_amount" This breaks file transfers with Chrome Remote Desktop, as reported in the internal bug tracker. This reverts commit fea41f540c72d15c4f499fead611a0c5e65db8ec. Bug: chromium:331346276 Change-Id: Ib41351a474bc40e7688d14dc445f53e68b5833ae Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344501 Commit-Queue: Victor Boivie <boivie@webrtc.org> Reviewed-by: Florent Castelli <orphis@webrtc.org> Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> Cr-Commit-Position: refs/branch-heads/6367@{#2} Cr-Branched-From: 802552a8030d82ad07b72aa738f814f3a0030810-refs/heads/main@{#41921}
jamienicol
pushed a commit
that referenced
this pull request
May 24, 2024
…inting background., a=testonly Automatic update from web-platform-tests Get border/padding from fragment when painting background. Since @page border box layout objects aren't in the the layout tree, any code that wants to walk up the tree to find the containing block will be in for a surprise. This would happen if percentage-based @page padding was used [1]. Recomputing padding during painting when we have already done it during layout is rather pointless anyway. Read it out directly from the fragment. [1] #1 blink::LayoutBox::ContainingBlockLogicalWidthForContent() #2 blink::LayoutBoxModelObject::ComputedCSSPadding() #3 blink::LayoutBoxModelObject::PaddingTop() #4 blink::LayoutBoxModelObject::PaddingOutsets() #5 blink::BoxPainterBase::PaintFillLayer() #6 blink::BoxPainterBase::PaintFillLayers() #7 blink::BoxFragmentPainter::PaintBackground() Bug: 40286153 Change-Id: I1e6e92c2ce1d81aab2673ec9a877eac455534102 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5526469 Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/main@{#1300711} -- wpt-commits: 601b701a9d708b48a9cddae1ac15963d61be7964 wpt-pr: 46252
jamienicol
pushed a commit
that referenced
this pull request
Jul 29, 2024
…-worker-reviewers,smaug,profiler-reviewers,aabh,asuth,perftest-reviewers,sparky
Use profiler markers to collect timing data. Markers of known name:
AUTO_PROFILER_MARKER_TEXT("interesting thing #1", DOM, {}, ""_ns);
AUTO_PROFILER_MARKER_TEXT("interesting thing #2", DOM, {}, ""_ns);
can be inspected from the perftest:
await startProfiler();
interestingThings();
let pdata = await stopProfiler();
let duration_ms = inspectProfile(pdata, [
"interesting thing #1",
"interesting thing #2"
]);
Differential Revision: https://phabricator.services.mozilla.com/D211368
jamienicol
pushed a commit
that referenced
this pull request
Aug 21, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/876d0c9881eab8e7f8389812eb3738bdd374aa22 Fix use-of-uninitialized-value in NetEq tests. The new version of MSan (rolled by [1]) detects the following: ``` ==39908==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x5591400a52ef in GetPlayoutDelayMs ./../../modules/audio_coding/neteq/decision_logic.cc:466:35 #1 0x5591400a52ef in webrtc::DecisionLogic::ExpectedPacketAvailable(webrtc::NetEqController::NetEqStatus) ./../../modules/audio_coding/neteq/decision_logic.cc:311:36 #2 0x5591400a39e9 in webrtc::DecisionLogic::GetDecision(webrtc::NetEqController::NetEqStatus const&, bool*) ./../../modules/audio_coding/neteq/decision_logic.cc:0:0 #3 0x55913cf590c9 in webrtc::DecisionLogicTest_PreemptiveExpand_Test::TestBody() ./../../modules/audio_coding/neteq/decision_logic_unittest.cc:139:3 #4 0x55913ef28283 in HandleExceptionsInMethodIfSupported<testing::Test, void> ./../../third_party/googletest/src/googletest/src/gtest.cc:0:3 #5 0x55913ef28283 in testing::Test::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:2710:5 #6 0x55913ef2ab46 in testing::TestInfo::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:2856:11 #7 0x55913ef2da34 in testing::TestSuite::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:3034:30 #8 0x55913ef621e8 in testing::internal::UnitTestImpl::RunAllTests() ./../../third_party/googletest/src/googletest/src/gtest.cc:5964:44 #9 0x55913ef60f54 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> ./../../third_party/googletest/src/googletest/src/gtest.cc:0:0 #10 0x55913ef60f54 in testing::UnitTest::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:5543:10 #11 0x55913ee1a944 in RUN_ALL_TESTS ./../../third_party/googletest/src/googletest/include/gtest/gtest.h:2334:73 #12 0x55913ee1a944 in webrtc::(anonymous namespace)::TestMainImpl::Run(int, char**) ./../../test/test_main_lib.cc:203:21 #13 0x55913cbd36b8 in main ./../../test/test_main.cc:72:16 #14 0x7fdb18c73082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16 #15 0x55913cb3e1a9 in _start ??:0:0 ``` [1] - https://webrtc-review.googlesource.com/c/src/+/353620 Bug: b/344970813 Change-Id: I9b5d7791e68b4c494168ba9f007a3099ae21fed4 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/353581 Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org> Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org> Cr-Commit-Position: refs/heads/main@{#42433}
jamienicol
pushed a commit
that referenced
this pull request
Sep 9, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/e7686023a186ac233ed1284da45cc166c0df4e1a [M128] PipeWire camera: Annotate functions with PipeWire calls to avoid CFI Similar to PipeWire implementation of desktop capture, we have to avoid CFI check for calls of dlopened PipeWire library. This avoid crashing PipeWire camera backend when "is_official_build=true" option is used as this turns on "is_cfi=true" enabling control flow integrity. iOS bots are broken due to xcode version mismatch. But the change is linux-only, so they are irrelevant. Disabling presubmit checks. (cherry picked from commit 9e755f0e19a9f3fdd5015283b5328fc65a7bfe1c) No-Try: true Bug: chromium:354776214 Change-Id: I7a9fc1c2d77c4ee0e8fe0586369b7246e0bb9180 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/358103 Commit-Queue: Jan Grulich <grulja@gmail.com> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Alexander Cooper <alcooper@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#42706} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359162 Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Jan Grulich <grulja@gmail.com> Cr-Commit-Position: refs/branch-heads/6613@{#2} Cr-Branched-From: 1ac162ee20a214bf97f6594a7effcbbc21f1effb-refs/heads/main@{#42664}
This pull request was closed.
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 lodash from 3.3.1 to 4.17.19.
Release notes
Sourced from lodash's releases.
Commits
d7fbc52Bump to v4.17.192e1c0f2Add npm-package1b6c282Bump to v4.17.18a370ac8Bump to v4.17.171144918Rebuild lodash and docs3a3b0fdBump to v4.17.16c84fe82fix(zipObjectDeep): prototype pollution (#4759)e7b28eaSanitize sourceURL so it cannot affect evaled code (#4518)0cec225Fix lodash.isEqual for circular references (#4320) (#4515)94c3a81Document matches* shorthands for over* methods (#4510) (#4514)Maintainer changes
This version was pushed to npm by mathias, a new releaser for lodash 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 rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot mergewill merge this PR after your CI passes on it@dependabot squash and mergewill squash and merge this PR after your CI passes on it@dependabot cancel mergewill cancel a previously requested merge and block automerging@dependabot reopenwill reopen this PR if it is closed@dependabot closewill close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill 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 labelswill set the current labels as the default for future PRs for this repo and language@dependabot use these reviewerswill set the current reviewers as the default for future PRs for this repo and language@dependabot use these assigneeswill set the current assignees as the default for future PRs for this repo and language@dependabot use this milestonewill 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.