Bump urllib3 from 1.9.1 to 1.26.5 in /testing/mozharness #5
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 [urllib3](https://github.com/urllib3/urllib3) from 1.9.1 to 1.26.5. - [Release notes](https://github.com/urllib3/urllib3/releases) - [Changelog](https://github.com/urllib3/urllib3/blob/main/CHANGES.rst) - [Commits](urllib3/urllib3@1.9.1...1.26.5) --- updated-dependencies: - dependency-name: urllib3 dependency-type: direct:production ... Signed-off-by: dependabot[bot] <[email protected]>
dependabot
bot
added
dependencies
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
Nov 24, 2021
…login manager marks an focus field. r=tgiles In nsAutocompleteController::HandleKeyNavigation, we might trigger a search operation (or open the popup) However, when we find there is already a search result received previously, and the search string is the same as the current one, we won't trigger a new search[1] because the result should be the same. This might be true for most of the cases, but not true when clients that perform the search is differnt. As far as I know, there are at least 3 different autocomplete clients: form history, CC/Address autocomplete, and login manager. For example, the same search string might return a different result when it is searched by the login manager and by the form history component. Here is how the intermittent occurs: 1. The page is loaded 2. Password field is detected so the login manager fetches the login data from the parent asynchronously 3. The testcase continues to run. The username field is focused 4. Autocomplete search for the focus field is triggered. Since the login manager has not yet told FormFillController this is a field we care, we search the form history and get an empty result. 5. Login data is sent from parent to child, _fillForm is called. The LoginManagerChild calls `MarkAsLoginManagerField` 6. Key event occurs on the field. Autocomplete search is triggered again. However, the search is not executed because [1] 7. Popup is not shown. Testcase timeout. When #5 occurs before #3, the autocomplete search in #4 will be processed by the login manager, and we will get the result and open the popup in this case In the current architecture, I don't see an easy way that we can distinguish whether the autocomplete client is different in nsAutocompleteController. So instead of doing it in nsAutocompleteController, this patch fixes this issue in FormFillController. In FormFillController, when we call `MarkAsLoginManagerField` on a focus field, we call ResetInternalState() to tell nsAutocompleteController to clear previous search result. [1] https://searchfox.org/mozilla-central/rev/fb8d77331582639ea6848a61dd8ee812fac31b77/toolkit/components/autocomplete/nsAutoCompleteController.cpp#516-521 Differential Revision: https://phabricator.services.mozilla.com/D131237
|
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 3, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/6ced79beecdf6ec669840f3ca9d9695cfdbf9376 Add additional checks in case of early portal error In case ScreenCast portal fails right at the beginning, we need to check the response before trying to get session handle to avoid accessing non-existing portal data. Also on early failure do not continue making source request if we failed before and don't have session handle. (cherry picked from commit 65a9a515b51be1050bbb6fcb1edfbdff706434bf) Bug: webrtc:13429, chromium:1363783 Change-Id: I2bfbd2c6e96e3cda1e62aa9dc07f66d4c7496b53 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272400 Reviewed-by: Alexander Cooper <[email protected]> Reviewed-by: Mark Foltz <[email protected]> Commit-Queue: Mark Foltz <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#37872} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275961 Commit-Queue: Alexander Cooper <[email protected]> Reviewed-by: Mirko Bonadei <[email protected]> Cr-Commit-Position: refs/branch-heads/5249@{#5} Cr-Branched-From: 7aaeb5a270ba23f5844f7301a50aaff9b6ca6126-refs/heads/main@{#37825}
jamienicol
pushed a commit
that referenced
this pull request
Jan 25, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/64edb15e1e5bb86bbcb78f0e8be0a6559097f3f3 Make P2PTransportChannel implement IceAgentInterface (#5/n) This functionally no-op change adds the methods to allow an active ICE controller to manipulate the connection used by the ICE transport. Most methods reuse existing code, this will be explicitly marked for cleanup with a follow-up CL which adds active ICE controller support. Non-trivial changes are needed for P2PTransportChannel unit tests to cover the new code, and these are also being added in a follow-up CL. Bug: webrtc:14367, webrtc:14131 Change-Id: I4f012efcd8cb5766eb8c6f0872de50f8375f3a73 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275301 Reviewed-by: Jonas Oreland <[email protected]> Commit-Queue: Sameer Vijaykar <[email protected]> Cr-Commit-Position: refs/heads/main@{#38081}
jamienicol
pushed a commit
that referenced
this pull request
Jan 25, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/4005adc6d639035fdd5323861d9a2fc6bd946e99 [M107] ice: include tiebreaker in computation of foundation attribute the foundation attribute is currently calculated as CRC32(baseaddress, protocol, relayprotocol) which is a way to satisfy the requirements from https://www.rfc-editor.org/rfc/rfc5245#section-4.1.1.3 However, this leaks the base address which defeats the MDNS obfuscation described in https://datatracker.ietf.org/doc/draft-ietf-mmusic-mdns-ice-candidates/ since the CRC32 can be reversed using a table lookup as shown in https://github.com/niespodd/webrtc-local-ip-leak/ To defeat that lookup, "seed" the CRC32 with the ICE tie-breaker which is a randomly picked unsigned 64 bit integer described in https://www.rfc-editor.org/rfc/rfc5245#section-5.2 The tie-breaker is not known to Javascript and adding it scopes the foundation within the peer connection as described in section 4.1.1.3 To manually test (preferably with a DCHECK for IceTiebreaker() in ComputeFoundation) - gather candidates twice on https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/ and observe that the foundations are not the same after this change - create two RTCPeerConnections with {iceCandidatePoolSize: 1}, create a datachannel, call setLocalDescription, inspect the candidates and observe that the foundations are not the same after this change. Unit test changes have been split into a separate CL for easier integration. BUG=webrtc:14605,chromium:1378916 (cherry picked from commit 08b882d762edadb9797334859d915c5c1e34896b) Change-Id: I6bbad1635b48997b00ae74d251ae357bf8afd12f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280621 Reviewed-by: Harald Alvestrand <[email protected]> Reviewed-by: Jonas Oreland <[email protected]> Commit-Queue: Harald Alvestrand <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#38485} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281421 Commit-Queue: Philipp Hancke <[email protected]> Cr-Commit-Position: refs/branch-heads/5304@{#5} Cr-Branched-From: 024bd84ca1cf7d3650c27912a3b5bfbb54da152a-refs/heads/main@{#38083}
jamienicol
pushed a commit
that referenced
this pull request
Feb 20, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/93081d594f7efff72958a79251f53731b99e902b [Merge M108] Ensure video frame buffer is still decodable before decoding This ensures that if for some reason, the frame buffer becomes undecodable while waiting to decode a frame, the decoding is halted. This also guards against receiving an empty temporal unit from the frame buffer, even though this should never happen when the frame buffer has a decodable temporal unit. (cherry picked from commit 8fe5579136c82b558022fe7d1393fa248b151eae) Bug: chromium:1378253, chromium:1361623 Change-Id: I8c4c897bf474d5cbda5f0f357781bf1dc0701fe4 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280701 Commit-Queue: Evan Shrubsole <[email protected]> Reviewed-by: Erik Språng <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#38494} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281720 Cr-Commit-Position: refs/branch-heads/5359@{#5} Cr-Branched-From: fb3bd4a01d7c840dfe7b3efa144c0fbcb6a97fef-refs/heads/main@{#38387}
jamienicol
pushed a commit
that referenced
this pull request
Aug 7, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/a624ee1be7a11e795a849edb2a27dc1137d2b63d [M114] Avoid touching channel after OnSctpDataChannelClosed (cherry picked from commit eec1810760ccbdf95c68ed0d2c2ae10a8575551a) Bug: chromium:1454086 Change-Id: I39573b706c4031d091c45a182b13cb3b2dba6233 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309920 Reviewed-by: Harald Alvestrand <[email protected]> Commit-Queue: Tomas Gunnarsson <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#40332} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310922 Reviewed-by: Mirko Bonadei <[email protected]> Cr-Commit-Position: refs/branch-heads/5735@{#5} Cr-Branched-From: df7df199abd619e75b9f1d9a7e12fc3f3f748775-refs/heads/main@{#39949}
jamienicol
pushed a commit
that referenced
this pull request
Aug 31, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/6603550a4279b4b68b8b763523370dc8e010500c [Merge-M115] Support conversion of VP9 non-flexible mode to generic descriptor for non-layered streams only. When VP9 HW encoders don't provide any metadata a minimal non-flexible mode structure is generated for the stream: (https://source.chromium.org/chromium/chromium/src/+/refs/heads/main:third_party/blink/renderer/platform/peerconnection/rtc_video_encoder.cc;l=1275-1298;drc=f80633b34538615fcb73515ad8c4bc56a748abfe). (cherry picked from commit 4e0bf2e5a1946b8f94f4b23b57b3e89a25fce65d) Bug: chromium:1455428, b/286993839, b/287458300 Change-Id: I72628f20927d685e9c8ba1744126d763896bd804 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309380 Commit-Queue: Philip Eliasson <[email protected]> Reviewed-by: Erik Språng <[email protected]> Reviewed-by: Henrik Boström <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#40316} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/309921 Commit-Queue: Henrik Boström <[email protected]> Cr-Commit-Position: refs/branch-heads/5790@{#5} Cr-Branched-From: 2eacbbc03a4a41ea658661225eb1c8fc07884c33-refs/heads/main@{#40122}
jamienicol
pushed a commit
that referenced
this pull request
Oct 3, 2023
We already cherry-picked this when we vendored 8fbabf340d. Upstream commit: https://webrtc.googlesource.com/src/+/626d408ba5d0ae5b1f6b66a7cf244a85ea66c11e [M116] Revert mid check in SdpOfferAnswerHandler::CreateDataChannel. This check was added here: https://webrtc-review.googlesource.com/c/src/+/300544 When createOffer is used before createAnswer, this check would cause SetupDataChannelTransport_n to not be called for the remote channel. (cherry picked from commit 299cdc9057fb8925f1692ac8c7573f51b7872df6) Bug: webrtc:15258, chromium:1458937 Change-Id: Ifdab35d1b0260ff03fef4beff13acf8090d59d8f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310460 Reviewed-by: Harald Alvestrand <[email protected]> Commit-Queue: Tomas Gunnarsson <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#40357} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/312123 Reviewed-by: Mirko Bonadei <[email protected]> Cr-Commit-Position: refs/branch-heads/5845@{#5} Cr-Branched-From: f80cf814353d11a9f22bef5ce5e8868f2c72f0d0-refs/heads/main@{#40319}
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
Mar 4, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/79ba9b0b2b28e49ecc32992ff9163917299beedc [M121] Disable the use of CGDisplayStreamCreate() for desktop capture on Sonoma CGDisplayStreamCreate is an deprecated API. It was believed that the use of it was disabled on Sonoma through the setting allow_iosurface = false [1], which causes the thumbnails to be created by the API CGDisplayCreateImage. This API is not marked as deprecated at the moment. However, although the thumbnails are created through CGDisplayCreateImage, CGDisplayStreamCreate() is still called and runs in the background. This makes the capture chip appear. No capture chip appears if this CL is landed and the ScreenCaptureKit thumbnail capturer is enabled, --enable-features="ScreenCaptureKitMac,ScreenCaptureKitStreamPickerSonoma,ThumbnailCapturerMac:capture_mode/sc_screenshot_manager" [1] https://chromium-review.googlesource.com/c/chromium/src/+/4892397 (cherry picked from commit fb99c6ebb57754e4b764a63dfae7f62ec272ba6b) Bug: chromium:1486851 No-Try: True Change-Id: I3422efffc57dcb3e8965f19a5eca7f2a95d62da1 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/334721 Reviewed-by: Mark Foltz <[email protected]> Commit-Queue: Johannes Kron <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#41563} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/335740 Reviewed-by: Mirko Bonadei <[email protected]> Cr-Commit-Position: refs/branch-heads/6167@{#5} Cr-Branched-From: ece5cb83715dea85617114b6d4e981fdee2623ba-refs/heads/main@{#41315}
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 <[email protected]> Reviewed-by: Xianzhu Wang <[email protected]> Reviewed-by: Ian Kilpatrick <[email protected]> Cr-Commit-Position: refs/heads/main@{#1300711} -- wpt-commits: 601b701a9d708b48a9cddae1ac15963d61be7964 wpt-pr: 46252
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 <[email protected]> Reviewed-by: Jakob Ivarsson <[email protected]> Commit-Queue: Jakob Ivarsson <[email protected]> Cr-Commit-Position: refs/heads/main@{#42433}
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 urllib3 from 1.9.1 to 1.26.5.
Release notes
Sourced from urllib3's releases.
... (truncated)
Changelog
Sourced from urllib3's changelog.
... (truncated)
Commits
d161647Release 1.26.52d4a3feImprove performance of sub-authority splitting in URL2698537Update vendored six to 1.16.007bed79Fix deprecation warnings for Python 3.10 ssl moduled725a9bAdd Python 3.10 to GitHub Actions339ad34Use pytest==6.2.4 on Python 3.10+f271c9cApply latest Black formatting1884878[1.26] Properly proxy EOF on the SSLTransport test suitea891304Release 1.26.48d65ea1Merge pull request from GHSA-5phf-pp7p-vc2rDependabot 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.