Bump hosted-git-info from 2.8.8 to 2.8.9 #3
Closed
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
Bumps [hosted-git-info](https://github.com/npm/hosted-git-info) from 2.8.8 to 2.8.9. - [Release notes](https://github.com/npm/hosted-git-info/releases) - [Changelog](https://github.com/npm/hosted-git-info/blob/v2.8.9/CHANGELOG.md) - [Commits](npm/hosted-git-info@v2.8.8...v2.8.9) 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
Jul 16, 2021
…,r=gfx-reviewers,lsalzman Original patch by Erik Kurzinger: D118304 The following is currently not well-defined by the EGL specification: 1. Create context. 2. Make it current with no default framebuffer (as a surface-less context, ie bind EGL_NO_SURFACE for both surfaces) 3. Make it current with a default framebuffer (ie with some draw/read surfaces) After Step #3 what is the current draw buffer state? is it GL_NONE or GL_BACK? With Mesa's EGL implementation, the answer is GL_BACK, and WebRender's EGL backend currently assumes this behavior. However with the proprietary NVIDIA driver the answer is actually GL_NONE, meaning any rendering done after step #3 will be lost. As a fix, Firefox can simple call glDrawBuffer after making a surface current to set the draw buffer appropriately, either to GL_BACK for a double-buffered surface or to GL_FRONT for single-buffered. As mentioned above, this is redundant on Mesa, but should also be harmless. Differential Revision: https://phabricator.services.mozilla.com/D118743
jamienicol
pushed a commit
that referenced
this pull request
Jul 16, 2021
…,r=gfx-reviewers,lsalzman Original patch by Erik Kurzinger: D118304 The following is currently not well-defined by the EGL specification: 1. Create context. 2. Make it current with no default framebuffer (as a surface-less context, ie bind EGL_NO_SURFACE for both surfaces) 3. Make it current with a default framebuffer (ie with some draw/read surfaces) After Step #3 what is the current draw buffer state? is it GL_NONE or GL_BACK? With Mesa's EGL implementation, the answer is GL_BACK, and WebRender's EGL backend currently assumes this behavior. However with the proprietary NVIDIA driver the answer is actually GL_NONE, meaning any rendering done after step #3 will be lost. As a fix, Firefox can simple call glDrawBuffer after making a surface current to set the draw buffer appropriately, either to GL_BACK for a double-buffered surface or to GL_FRONT for single-buffered. As mentioned above, this is redundant on Mesa, but should also be harmless. Differential Revision: https://phabricator.services.mozilla.com/D118743
jamienicol
pushed a commit
that referenced
this pull request
Jul 16, 2021
… GL,r=gfx-reviewers,lsalzman Original patch by Erik Kurzinger: D118304 The following is currently not well-defined by the EGL specification: 1. Create context. 2. Make it current with no default framebuffer (as a surface-less context, ie bind EGL_NO_SURFACE for both surfaces) 3. Make it current with a default framebuffer (ie with some draw/read surfaces) After Step #3 what is the current draw buffer state? is it GL_NONE or GL_BACK? With Mesa's EGL implementation, the answer is GL_BACK, and WebRender's EGL backend currently assumes this behavior. However with the proprietary NVIDIA driver the answer is actually GL_NONE, meaning any rendering done after step #3 will be lost. As a fix, Firefox can simple call glDrawBuffer after making a surface current to set the draw buffer appropriately, either to GL_BACK for a double-buffered surface or to GL_FRONT for single-buffered. As mentioned above, this is redundant on Mesa, but should also be harmless. Differential Revision: https://phabricator.services.mozilla.com/D118743
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 15, 2021
…all `WhiteSpaceVisibilityKeeper::PrepareToSplitBlockElement()` before splitting a text node r=m_kato,smaug It does the following things when caret is collapsed in a text node in a `<p>` or `<div>` element. 1. Split the text node containing caret to insert `<br>` element 2. Insert `<br>` element after it 3. Split ancestor elements which inclusive descendants of the `<p>` or `<div>` 4. Delete the `<br>` element if unnecessary from the left paragraph #3 and #4 are performed by `HTMLEditor::SplitParagraph()` and it calls `WhiteSpaceVisibilityKeeper::PrepareToSplitBlockElement()` correctly before splitting the block. However, in the case (caret is at middle of a text node), the text has already been split to 2 nodes because of #1. Therefore, it fails to handle to keep the white-space visibility. So that I believe that the root cause of this bug is, the method does much complicated things which are required, and doing the redundant things will eat memory space due to undo transactions. However, for now, I'd like to fix this with a simple patch which just call the preparation method before splitting the text node because I'd like to uplift this if it'd be approved (Note that this is not a recent regression, the root cause was created by bug 92686 which was fixed in 17 years ago: <https://searchfox.org/mozilla-central/commit/2e66280faef73e9be218e00758d4eb738395ac83>, but must be annoying bug for users who see this frequently). The new WPTs are pass in Chrome. Differential Revision: https://phabricator.services.mozilla.com/D130950
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/+/860ad5321f87a0aeb6841e57b2fa73fa9ea3c65b [M106] Prevent potential UAF during VideoStreamEncoder teardown. (cherry picked from commit 1cb799c31c882e60d1d3d24863b61811a039d40c) Bug: chromium:1357413 Change-Id: I9ec4d4fbafe1c25530346faf09f5b437fad718cc Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273482 Reviewed-by: Markus Handell <[email protected]> Commit-Queue: Henrik Boström <[email protected]> Auto-Submit: Erik Språng <[email protected]> Reviewed-by: Henrik Boström <[email protected]> Commit-Queue: Markus Handell <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#37948} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274703 Commit-Queue: Erik Språng <[email protected]> Cr-Commit-Position: refs/branch-heads/5249@{#3} 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/+/6fa8a759b4c0c36aed1fdf4bd3442efc7562311a Add an active ICE controller factory to IceTransportInit (#3/n) P2PTransportChannel can then use either of the ICE controller factories configured with field trials. Bug: webrtc:14367, webrtc:14131 Change-Id: I09ab99673d6ef81f56abe88987f5b67d84c24cb5 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271292 Reviewed-by: Jonas Oreland <[email protected]> Reviewed-by: Per Kjellander <[email protected]> Commit-Queue: Sameer Vijaykar <[email protected]> Cr-Commit-Position: refs/heads/main@{#38076}
jamienicol
pushed a commit
that referenced
this pull request
Jan 25, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/0ce0fc9b694ca8eac9494d0264e75f1e730e19a3 [107] Schedule all video decodes with high precision (cherry picked from commit 36a6599a95d634eca27c2f15f194b451403e301d) Bug: chromium:1365820 Change-Id: I91ca7e42c4ce9b49f4b087b898bbfb3cc4cf2935 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276040 Reviewed-by: Ilya Nikolaevskiy <[email protected]> Commit-Queue: Evan Shrubsole <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#38126} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/276480 Reviewed-by: Tomas Gunnarsson <[email protected]> Commit-Queue: Markus Handell <[email protected]> Cr-Commit-Position: refs/branch-heads/5304@{#3} 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/+/363e17b7f5a68fba6e1327831631aace7a9e8706 [Merge-108] [Stats] Update totalPacketSendDelay to only cover time in pacer queue. This metric was always supposed to be the spec's answer to googBucketDelay, and is defined as "The total number of seconds that packets have spent buffered locally before being transmitted onto the network." But our implementation measured the time between capture and send, including encode time. This is incorrect and yields a much larger value than expected. This CL updated the metric to do what the spec says. Implementation-wise we measure the time between pushing and popping each packet from the queue (in modules/pacing/prioritized_packet_queue.cc). The spec says to increment the delay counter at the same time as we increment the packet counter in order for the app to be able to do "delta totalPacketSendDelay / delta packetSent". For this reason, `total_packet_delay` is added to RtpPacketCounter. (Previously, the two counters were incremented on different threads and observers.) Running Google Meet on a good network, I could observe a 2-3 ms average send delay per packet with this implementation compared to 20-30 ms with the old implementation. See b/137014977#comment170 for comparison with googBucketDelay which is a little bit different by design - totalPacketSendDelay is clearly better than googBucketDelay. Since none of this depend on the media kind, we can wire up this metric for audio as well in a follow-up: https://webrtc-review.googlesource.com/c/src/+/280523 (cherry picked from commit d81992197c9e31d9009a0c6ee9d3862479773c06) Bug: webrtc:14593, chromium:1378895 Change-Id: If8fcd82fee74030d0923ee5df2c2aea2264600d4 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280443 Reviewed-by: Erik Språng <[email protected]> Commit-Queue: Henrik Boström <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#38480} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281160 Reviewed-by: Harald Alvestrand <[email protected]> Cr-Commit-Position: refs/branch-heads/5359@{#3} 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/+/e46e37b6f831763aceaf5f5bd081a47cbd562890 [M114] 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) No-Try: true Bug: chromium:1446274, webrtc:12692 Change-Id: I7c514df9f029112c4b1da85826af91217850fb26 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/307340 Reviewed-by: Harald Alvestrand <[email protected]> Commit-Queue: Tomas Gunnarsson <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#40197} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308001 Reviewed-by: Mirko Bonadei <[email protected]> Cr-Commit-Position: refs/branch-heads/5735@{#3} Cr-Branched-From: df7df199abd619e75b9f1d9a7e12fc3f3f748775-refs/heads/main@{#39949}
jamienicol
pushed a commit
that referenced
this pull request
Aug 7, 2023
… and improve testing, a=testonly Automatic update from web-platform-tests Fix cloning of templates with DOM Parts, and improve testing This CL improves the testing of template cloning with Parts, testing these four cases: 1. Main document parsing 2. Template (content fragment) parsing 3. Template/fragment cloning 4. Declarative Shadow DOM parsing and cloning This CL fixes the behavior for #3 above, but leaves #4 broken. The following changes in behavior are made: 1. Part::MoveToRoot() can be used to change the root(), including to set it to nullptr. This happens when a Node tree is removed from the DOM, and it contains Parts that refer to the old root. 2. IsDocumentPartRoot() is now virtual, because during a tree move, the root() for a Part can be made nullptr even when it's a ChildNodePart. 3. Part::disconnected_ is added to keep track of whether the Part has been disconnected, since root() can now be nullptr. 4. (This is a bug fix) When using ChildNodePart::setNextSibling(), the new sibling node wasn't having its Part registered with NodeRareData, which caused a CHECK failure when trying to subsequently clone that Part. This is caught in the new test which clones declaratively-built templates containing Parts. Bug: 1453291 Change-Id: Ic1c1475431cf6bd658f191db78003204412ef78f Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4713668 Reviewed-by: David Baron <[email protected]> Auto-Submit: Mason Freed <[email protected]> Commit-Queue: Mason Freed <[email protected]> Cr-Commit-Position: refs/heads/main@{#1175782} -- wpt-commits: e03faa12a86fced56d076740e95fc7557db5eac4 wpt-pr: 41168
jamienicol
pushed a commit
that referenced
this pull request
Aug 31, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/f0d954f659a77b214b0ff177e6f66bad1d626423 [M115] Fix L1Tx target bitrate bug when the standard API is used. There are now multiple ways to configure VP9 L1Tx: - Legacy API: configure legacy SVC and disable encodings, this gets interpreted as disabling spatial layers (non-standard API hack). - Standard API: configure scalability_mode. This can be done either with a single encoding or multiple encodings. As long as only one encoding is active we get a single L1Tx ssrc, same as legacy API. Due to a bug, the ApplySpatialLayerBitrateLimits() logic which tweaks bitrates was only applied in the legacy API code path, not the standard API code path, despite both code paths configuring L1Tx. The issue is that IsSimulcastOrMultipleSpatialLayers() was checking if `number_of_streams == 1`. This is true in legacy code path but not standard code path. The fix is to look at `numberOfSimulcastStreams == 1` instead, which is set to the correct value regardless of code path used. This CL adds comments documenting the difference between `number_of_streams` and `numberOfSimulcastStreams` to reduce the risk of more mistakes like this in the future. (cherry picked from commit 2fec64484f0c1355db1dde236c3c205985a30a30) Bug: chromium:1455039, b:279161263 Change-Id: I69789b68cc5d45ef1b3becd310687c8dec8e7c87 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308722 Reviewed-by: Ilya Nikolaevskiy <[email protected]> Commit-Queue: Henrik Boström <[email protected]> Reviewed-by: Erik Språng <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#40287} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308920 Cr-Commit-Position: refs/branch-heads/5790@{#3} Cr-Branched-From: 2eacbbc03a4a41ea658661225eb1c8fc07884c33-refs/heads/main@{#40122}
jamienicol
pushed a commit
that referenced
this pull request
Sep 15, 2023
…cuts as soft navigation triggers, a=testonly Automatic update from web-platform-tests [soft navigations] Enable keyboard shortcuts as soft navigation triggers Following the discussion on issue #3 [1], this CL adds support to soft navigations triggered by keyboard shortcuts, by adding unfocused keydown events to the events that can trigger the soft navigation heuristic. [1] WICG/soft-navigations#3 Bug: 1478772 Change-Id: Ib423a3cfc09eaf4dd9a2221b3494ab1016fa8668 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4839506 Commit-Queue: Yoav Weiss <[email protected]> Reviewed-by: Ian Clelland <[email protected]> Cr-Commit-Position: refs/heads/main@{#1193004} -- wpt-commits: 7f165f11361b86ef41b123dbc904ccee26d5f025 wpt-pr: 41816
jamienicol
pushed a commit
that referenced
this pull request
Oct 3, 2023
We cherry-picked this in bug 1830945. Upstream commit: https://webrtc.googlesource.com/src/+/04ee24493d08714bd9bba83fdbdd0c6568abe1cf [M116] In VideoCaptureDS::{Start|Stop}Capture do not lock Sequence- and RaceCheckers ensure thread safety, and show that these locks protect nothing. (cherry picked from commit dcf600d7a5cdf8da51daf5b6f79df1de05002b13) Bug: webrtc:15181, chromium:1457919 Change-Id: I7c26cd9aea5fa72ad9435de5ec1b9135ac22b1e8 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305649 Reviewed-by: Ilya Nikolaevskiy <[email protected]> Commit-Queue: Ilya Nikolaevskiy <[email protected]> Reviewed-by: Per Kjellander <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#40345} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310520 Reviewed-by: Henrik Boström <[email protected]> Cr-Commit-Position: refs/branch-heads/5845@{#3} Cr-Branched-From: f80cf814353d11a9f22bef5ce5e8868f2c72f0d0-refs/heads/main@{#40319}
jamienicol
pushed a commit
that referenced
this pull request
Oct 3, 2023
…rd shortcuts as soft navigation triggers", a=testonly Automatic update from web-platform-tests Revert "[soft navigations] Enable keyboard shortcuts as soft navigation triggers" This reverts commit 6efe71286a014d3d3872bc990e3ea2d08dd46dba. Reason for revert: One check added in this CL causes crash. see crbug.com/1480047 Original change's description: > [soft navigations] Enable keyboard shortcuts as soft navigation triggers > > Following the discussion on issue #3 [1], this CL adds support to soft > navigations triggered by keyboard shortcuts, by adding unfocused keydown > events to the events that can trigger the soft navigation heuristic. > > [1] WICG/soft-navigations#3 > > Bug: 1478772 > Change-Id: Ib423a3cfc09eaf4dd9a2221b3494ab1016fa8668 > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4839506 > Commit-Queue: Yoav Weiss <[email protected]> > Reviewed-by: Ian Clelland <[email protected]> > Cr-Commit-Position: refs/heads/main@{#1193004} Bug: 1478772 Change-Id: I3a518c165e6b19239a6bf7900e94c1ef9c3e5a5a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4859802 Reviewed-by: Ian Clelland <[email protected]> Commit-Queue: Hao Liu <[email protected]> Owners-Override: Daniel Cheng <[email protected]> Bot-Commit: Rubber Stamper <[email protected]> Cr-Commit-Position: refs/heads/main@{#1196100} -- wpt-commits: 40543949faa61279ddd3341accfe9ea866a5987e wpt-pr: 41958
jamienicol
pushed a commit
that referenced
this pull request
Oct 5, 2023
…rd shortcuts as soft navigation triggers, a=testonly Automatic update from web-platform-tests Reland: [soft navigations] Enable keyboard shortcuts as soft navigation triggers Following the discussion on issue #3 [1], this CL adds support to soft navigations triggered by keyboard shortcuts, by adding unfocused keydown events to the events that can trigger the soft navigation heuristic. This is a reland of [2], rebased and which fixes the unguarded ScriptState access in event_dispatcher, which caused a crash. [1] WICG/soft-navigations#3 [2] https://chromium-review.googlesource.com/c/chromium/src/+/4839506 Bug: 1478772, 1480047 Change-Id: I6428e0635222366d880dd908f04f2273b6bf8b44 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4900577 Reviewed-by: Ian Clelland <[email protected]> Commit-Queue: Yoav Weiss <[email protected]> Cr-Commit-Position: refs/heads/main@{#1203903} -- wpt-commits: 04ab10bfca7454a6f6d968cb6c9c697fcdea9de2 wpt-pr: 42213
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/+/d8f2b0380b3ec980af35ce4b92ba6a211ec8c76d [M118] Fire MaybeSignalReadyToSend in a PostTask when recursive Speculative fix. Writing the test for it is more complex. (cherry picked from commit 83894d384763c613e548e6352838406e6e0c2fc1) Bug: chromium:1483874 Change-Id: Icfaf1524b0499c609010753e0b6f3cadbd0e98f9 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321480 Reviewed-by: Per Kjellander <[email protected]> Commit-Queue: Harald Alvestrand <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#40820} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322124 Reviewed-by: Tomas Gunnarsson <[email protected]> Cr-Commit-Position: refs/branch-heads/5993@{#3} 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/+/3df661f79828194d0acb51a1480833bafd9e5066 [121] Allow RTP retransmission for cloned encoded Video Frames Fix the unintended disabling of RTP retransmissions for cloned encoded frames, caused by passing an infinite "expected_retransmission_time". Instead use a constant 10ms for now. For frames encoded locally, this is set from an estimate of the RTT, but we currently don't have access to that here (TODO added to pipe it through) If an integration is cloning and then sending frames it received, it's almost certainly resending received media to other peers on a local network, so 10ms is a fair upperbound. Tested locally with Chrome on Mac, configuring packet drops & observing on chrome://webrtc-internals that retransmission packets are now sent. (cherry picked from commit 3e801c32086be59e502e276ff5d6beea42069582) No-Try: True Bug: chromium:1512631 Change-Id: I2483415dc7e0079f8a7b66f6607f4907698514c4 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/331900 Reviewed-by: Harald Alvestrand <[email protected]> Commit-Queue: Tony Herre <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#41405} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/332261 Reviewed-by: Stefan Holmer <[email protected]> Commit-Queue: Mirko Bonadei <[email protected]> Reviewed-by: Henrik Boström <[email protected]> Cr-Commit-Position: refs/branch-heads/6167@{#3} 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/+/41b1493ddb5d98e9125d5cb002fd57ce76ebd8a7 [M123 MERGE] Demote RTC_CHECK for sctp_mid() to RTC_LOG(LS_ERROR) if unavailable (cherry picked from commit efbfc40029b6986137f9179476955c263da7052a) Bug: chromium:326275823, chromium:325900490 Change-Id: Icfb8850867d1e39f23661422693da4f2829ecc57 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/340460 Reviewed-by: Evan Shrubsole <[email protected]> Commit-Queue: Tomas Gunnarsson <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#41793} No-Try: True Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342560 Reviewed-by: Guido Urdaneta <[email protected]> Commit-Queue: Florent Castelli <[email protected]> Cr-Commit-Position: refs/branch-heads/6312@{#3} Cr-Branched-From: 0355f455a48b141a8277442825ec776a74d66fb7-refs/heads/main@{#41763}
jamienicol
pushed a commit
that referenced
this pull request
Apr 25, 2024
…eStream and related classes, attempt #3, a=testonly Automatic update from web-platform-tests Use typed promises/resolvers for ReadableStream and related classes, attempt #3 This converts IDL-exposed promises in ReadableStream, ReadableStreamBYOBReader, ReadableStreamDefaultReader, and ReadableStreamGenericReader to use typed ScriptPromiseResolver instead of StreamPromiseResolver and to return typed ScriptPromises. Bug: 329702363 Change-Id: I8ad1af1a7c9c909d711881ce7621c6c9fac58931 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5429731 Reviewed-by: Adam Rice <[email protected]> Reviewed-by: Nidhi Jaju <[email protected]> Commit-Queue: Nate Chapin <[email protected]> Cr-Commit-Position: refs/heads/main@{#1289397} -- wpt-commits: 26d974425bf402e6ceb7a28480800d1942236b8c wpt-pr: 45590
jamienicol
pushed a commit
that referenced
this pull request
May 17, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/a55ff9e83e4592010969d428bee656bace8cbc3b [M124] Use predefined SdpVideoFormats when returning supported formats The predefined SdpVideoFormats were not used everywhere, which caused a discrepancy between send/receive capabilities for AV1. This CL solves the immediate problems by making sure send/receive capabilities for AV1 are reported the same way. (cherry picked from commit 82598402e095ec6638b6cf3dc8e7f6d35cc3d737) Fixed: chromium:331565934 Change-Id: I073091b7b5f987c7f434c17276fd84047ec723c2 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344681 Reviewed-by: Harald Alvestrand <[email protected]> Commit-Queue: Johannes Kron <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#41991} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/348720 Cr-Commit-Position: refs/branch-heads/6367@{#3} 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 <[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}
jamienicol
pushed a commit
that referenced
this pull request
Sep 9, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/f237dc146debcfde3d70038c2b66f71bfea8d24b [M128] Ensure calls to QP convergence controller are on the same sequence The original CL overlooked the possibility that the encoder may be reconfigured in the middle of a stream. Restructure the code so that all calls to QP convergence controller happen on the encoder queue. A side effect of this CL is that `EncodedImage::SetAtTargetQuality()` is never called. The information is supplied to the frame cadence adapter directly without this intermediate step. `EncodedImage::SetAtTargetQuality()` and `EncodedImage::IsAtTargetQuality()` are being marked as deprecated in https://webrtc-review.googlesource.com/c/src/+/359660. (cherry picked from commit b47cd6fbe315690756f2f03e7658d4e26fe27b1e) Bug: chromium:359410061 Change-Id: I941b5f60b1a9fd7694dbedf2f3e4ff5253ccf357 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359640 Commit-Queue: Johannes Kron <[email protected]> Reviewed-by: Ilya Nikolaevskiy <[email protected]> Reviewed-by: Markus Handell <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#42788} No-Try: true Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360240 Cr-Commit-Position: refs/branch-heads/6613@{#3} Cr-Branched-From: 1ac162ee20a214bf97f6594a7effcbbc21f1effb-refs/heads/main@{#42664}
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 hosted-git-info from 2.8.8 to 2.8.9.
Changelog
Sourced from hosted-git-info's changelog.
Commits
8d4b369chore(release): 2.8.929adfe5fix: backport regex fix from #76Maintainer changes
This version was pushed to npm by nlf, a new releaser for hosted-git-info 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.