Bump lodash from 3.3.1 to 4.17.15 in /addon-sdk/source #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?s=60&v=4){kind=small}
Bumps [lodash](https://github.com/lodash/lodash) from 3.3.1 to 4.17.15. - [Release notes](https://github.com/lodash/lodash/releases) - [Commits](lodash/lodash@3.3.1...4.17.15) Signed-off-by: dependabot[bot] <support@github.com>
dependabot
bot
added
dependencies
jamienicol
deleted the
dependabot/npm_and_yarn/addon-sdk/source/lodash-4.17.15
branch
|
OK, I won't notify you again about this release, but will get in touch when a new version is available. If you'd rather skip all updates until the next major or minor version, let me know by commenting If you change your mind, just re-open this PR and I'll resolve any conflicts on it. |
jamienicol
pushed a commit
that referenced
this pull request
Dec 4, 2019
…hen there's an override container height, a=testonly
Automatic update from web-platform-tests
[css-flexbox] Don't cache definiteness when there's an override container height
See stack trace below. We set the override container logical height to -1
for the initial layout of a flex item so that we compute the correct size
for min-height. However, that messes with our cache for definite heights
because we would always set it to indefinite in such a case.
Instead, just don't cache these values. That way we will later compute the right
thing for resolving flex-basis, etc.
(FlexNG can't come soon enough...)
#0 blink::LayoutBox::ContainingBlockLogicalHeightForPercentageResolution (this=0x3dda8d434198,
out_cb=0x7f6e7d42d8c0, out_skipped_auto_height_containing_block=0x0)
at ../../third_party/blink/renderer/core/layout/layout_box.cc:3833
#1 0x00007f6ee84ad0a1 in blink::LayoutFlexibleBox::MainAxisLengthIsDefinite (this=0x3dda8d434010,
child=..., flex_basis=Length(0%, Percent), add_to_cb=false)
at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:762
#2 0x00007f6ee84af930 in blink::LayoutFlexibleBox::MainSizeIsDefiniteForPercentageResolution (
this=0x3dda8d434010, child=...)
at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1125
#3 0x00007f6ee84ad7f5 in blink::LayoutFlexibleBox::UseOverrideLogicalHeightForPerentageResolution (
this=0x3dda8d434010, child=...)
at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1137
#4 0x00007f6ee83f2b9d in blink::LayoutBlock::AvailableLogicalHeightForPercentageComputation (
this=0x3dda8d434198) at ../../third_party/blink/renderer/core/layout/layout_block.cc:2333
#5 0x00007f6ee845e745 in blink::LayoutBox::ContainingBlockLogicalHeightForPercentageResolution (
this=0x3dda8d4243d0, out_cb=0x0, out_skipped_auto_height_containing_block=0x0)
at ../../third_party/blink/renderer/core/layout/layout_box.cc:3830
#6 0x00007f6ee86dcc5c in blink::LayoutBoxUtils::AvailableLogicalHeight (box=..., cb=0x3dda8d434198)
at ../../third_party/blink/renderer/core/layout/ng/layout_box_utils.cc:64
#7 0x00007f6ee86eafea in blink::LayoutNGMixin<blink::LayoutBlockFlow>::ComputeIntrinsicLogicalWidths (
this=0x3dda8d4243d0, min_logical_width=0px, max_logical_width=0px)
at ../../third_party/blink/renderer/core/layout/ng/layout_ng_mixin.cc:48
#8 0x00007f6ee83ef53a in blink::LayoutBlock::ComputePreferredLogicalWidths (this=0x3dda8d4243d0)
at ../../third_party/blink/renderer/core/layout/layout_block.cc:1509
#9 0x00007f6ee8451f01 in blink::LayoutBox::MaxPreferredLogicalWidth (this=0x3dda8d4243d0)
at ../../third_party/blink/renderer/core/layout/layout_box.cc:1395
#10 0x00007f6ee84adba2 in blink::LayoutFlexibleBox::ComputeInnerFlexBaseSizeForChild (this=0x3dda8d434198,
child=..., main_axis_border_and_padding=0px, child_layout_type=blink::LayoutFlexibleBox::kForceLayout)
at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:890
#11 0x00007f6ee84ae5d1 in blink::LayoutFlexibleBox::ConstructAndAppendFlexItem (this=0x3dda8d434198,
algorithm=0x7f6e7d42ed70, child=..., layout_type=blink::LayoutFlexibleBox::kForceLayout)
at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:1203
#12 0x00007f6ee84aa27b in blink::LayoutFlexibleBox::LayoutFlexItems (this=0x3dda8d434198,
relayout_children=true, layout_scope=...)
at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:934
#13 0x00007f6ee84a9cff in blink::LayoutFlexibleBox::UpdateBlockLayout (this=0x3dda8d434198,
relayout_children=true) at ../../third_party/blink/renderer/core/layout/layout_flexible_box.cc:369
Bug: 1019138
Change-Id: Ie94e69a5f3fe6accc3623d358315b174088d5597
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1902514
Commit-Queue: David Grogan <dgrogan@chromium.org>
Auto-Submit: Christian Biesinger <cbiesinger@chromium.org>
Reviewed-by: David Grogan <dgrogan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#713296}
--
wpt-commits: 8642cbbba24a10e8a34b4a2720062261f29be5dd
wpt-pr: 20137
jamienicol
pushed a commit
that referenced
this pull request
Feb 2, 2020
…ot element., a=testonly Automatic update from web-platform-tests Implement new effect behavior for the root element. Intent-to-ship approval: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/4DC56FN3paU Changes are: 1. The background of the root element paints into the property tree state that includes the local border box effect state of the root element. 2. If #1 is happening, paint a separate backdrop in the ContentsProperties state of the LayoutView, to allow effects, clips and transforms of the root element to apply via PaintChunksToCcLayer. Bug: 898293,988446,1029170,711955 Change-Id: I751e3f9c23d0b06a31cf1b13c3853180bc7ac7e6 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1979258 Commit-Queue: Chris Harrelson <chrishtr@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Cr-Commit-Position: refs/heads/master@{#733661} -- wpt-commits: 4209d7961bab7dce31baab0918fa9f6dcd74bd8d wpt-pr: 21242
jamienicol
pushed a commit
that referenced
this pull request
Feb 27, 2020
…r=m_kato Its result has 4 meanings: 1. an editable block element for container of `mScanStartPoint`. 2. a topmost inline editable content for container of `mScanStartPoint` if there is no editable block parent. 3. container of `mScanStartPoint` if it's a block (either editable or non-editable). 4. container of `mScanStartPoint` if its parent is not editable and a inline content. #1, #2 and editable case of #3 make sense because the results are topmost editable content in current context. On the other hand, non-editable case of #3 and #4 are caused by unexpected wrong fallback code. So, let's make it always returns the content in the former meaning and if the caller needs the latter one, they should use the container by themselves. Therefore, for making what's the start of the search, this patch also makes new method take start content instead of hiding `mScanStartPoint` from the callers. Differential Revision: https://phabricator.services.mozilla.com/D63610
jamienicol
pushed a commit
that referenced
this pull request
Mar 17, 2020
Now that `fix_stacks.py` is being used instead of `fix_macosx_stack.py`, stack-fixing time has dropped from about 14 minutes to about 30 seconds on my new MacBook Pro. Also, print a warning about stacks not being fixed if `MOZ_DISABLE_STACK_FIX` is set. This warning shows up at the start of the test run. Also, print a warning about stack fixing slowness, because 30 seconds is long enough to possibly be surprising. This warning shows up just before the first stack frame is fixed, like this: ``` Assertion failure: false (BEEP BOOP), at /home/njn/moz/au3/dom/base/nsGlobalWindowOuter.cpp:1342 Initializing stack-fixing for the first stack frame, this may take a while... #1: nsGlobalWindowOuter::nsGlobalWindowOuter(unsigned long) (/home/njn/moz/au3/dom/base/nsGlobalWindowOuter.cpp:1342) #2: ... ``` Differential Revision: https://phabricator.services.mozilla.com/D65676
jamienicol
pushed a commit
that referenced
this pull request
Jun 9, 2021
Here's what's going on (relevant browser is browser 36). [rr 502130 274898]RestoreDocShellState(browser=36, bc=94, ) [rr 502130 274902]RemoteWebNavigation.currentURI browser=36 bc=94 http://mochi.test:8888/#1 [rr 502130 274906]BrowsingContext::LoadURI(browser=36, bc=94, about:blank) From a previous restore we correctly wait for: 0 _restoreTabContent( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":5984:30] <failed to get 'this' value> 1 _sendRestoreTabContent( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":6002:11] <failed to get 'this' value> 2 restoreTabContent( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4684:9] <failed to get 'this' value> 3 restoreTab( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4565:13] <failed to get 'this' value> 4 restoreTabs( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> aSelectTab = "1") ["resource:///modules/sessionstore/SessionStore.jsm":4413:11] <failed to get 'this' value> 5 ssi_restoreWindow( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4189:11] <failed to get 'this' value> 6 _restoreWindowsFeaturesAndTabs( <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4275:11] <failed to get 'this' value> 7 _restoreWindowsInReversedZOrder( <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4299:9] <failed to get 'this' value> 8 ssi_restoreWindows/<( <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4359:11] [rr 502506 275264]BrowsingContext::LoadURI(browser=36, bc=94, about:blank) [rr 502506 275268]DocumentChannelChild::AsyncOpen(browser=36, bc=94, about:blank) [rr 502130 275388]RemoteWebNavigation.currentURI browser=36 bc=94 http://mochi.test:8888/#1 [rr 502506 275629]BrowserChild::OnLocationChange(browser=36, bc=94, about:blank) [rr 502130 276944]updateForLocationChange browser=36 bc=94 - about:blank [rr 502130 277084]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank [rr 502130 277358]RestoreDocShellState(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html) [rr 502506 277378]BrowserChild::OnLocationChange(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html) [rr 502130 277390]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank [rr 502130 277554]BrowserParent::LoadURL(browser=36, bc=94, about:blank) From: #18 0x00007ff0bdb1efcc in mozilla::dom::BrowserParent::LoadURL(nsDocShellLoadState*) (this=0x7ff08f2b9800, aLoadState=0x7ff094e1d580) at /home/emilio/src/moz/gecko/dom/ipc/BrowserParent.cpp:861 #19 0x00007ff0bc1117f9 in nsFrameLoader::ReallyStartLoadingInternal() (this=0x7ff08f283400) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoader.cpp:718 #20 0x00007ff0bc11129f in nsFrameLoader::ReallyStartLoading() (this=0x7ff08f283400) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoader.cpp:640 #21 0x00007ff0bc0002f5 in mozilla::dom::Document::MaybeInitializeFinalizeFrameLoaders() (this=0x7ff0a17e2000) at /home/emilio/src/moz/gecko/dom/base/Document.cpp:9008 #22 0x00007ff0bc057891 in mozilla::detail::RunnableMethodArguments<>::applyImpl<mozilla::dom::Document, void (mozilla::dom::Document::*)()>(mozilla::dom::Document*, void (mozilla::dom::Document::*)(), mozilla::Tuple<>&, std::integer_sequence<unsigned long>) (o=<optimized out>, m=<optimized out>, args=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:1150 #23 mozilla::detail::RunnableMethodArguments<>::apply<mozilla::dom::Document, void (mozilla::dom::Document::*)()>(mozilla::dom::Document*, void (mozilla::dom::Document::*)()) (this=<optimized out>, o=<optimized out>, m=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:1156 #24 mozilla::detail::RunnableMethodImpl<mozilla::dom::Document*, void (mozilla::dom::Document::*)(), true, (mozilla::RunnableKind)0>::Run() (this=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:1203 #25 0x00007ff0bbef8209 in nsContentUtils::RemoveScriptBlocker() () at /home/emilio/src/moz/gecko/dom/base/nsContentUtils.cpp:5696 #26 0x00007ff0bc11c427 in nsAutoScriptBlocker::~nsAutoScriptBlocker() (this=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsContentUtils.h:3499 #27 nsFrameLoaderOwner::ChangeRemotenessCommon(nsFrameLoaderOwner::ChangeRemotenessContextType const&, mozilla::dom::RemotenessChangeOptions const&, bool, bool, mozilla::dom::BrowsingContextGroup*, std::function<void ()>&, mozilla::ErrorResult&) (this=<optimized out>, this@entry=0x7ff0a041b608, aContextType=@0x7ffe238847fc: nsFrameLoaderOwner::ChangeRemotenessContextType::PRESERVE, aOptions= ..., aSwitchingInProgressLoad=false, aIsRemote=<optimized out>, aGroup=<optimized out>, aGroup@entry=0x0, aFrameLoaderInit=..., aRv=...) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoaderOwner.cpp:191 #28 0x00007ff0bc11c81f in nsFrameLoaderOwner::ChangeRemoteness(mozilla::dom::RemotenessOptions const&, mozilla::ErrorResult&) (this=0x7ff0a041b608, aOptions=..., rv=...) at /home/emilio/src/moz/gecko/dom/base/nsFrameLoaderOwner.cpp:250 #29 0x00007ff0bcb59003 in mozilla::dom::XULFrameElement_Binding::changeRemoteness(JSContext*, JS::Handle<JSObject*>, void*, JSJitMethodCallArgs const&)Traceback (most recent call last): File "/home/emilio/src/moz/gecko/js/src/gdb/mozilla/Root.py", line 55, in to_string ptr = ptr.dereference() gdb.error: value has been optimized out (cx_=<optimized out>, obj= , void_self=<optimized out>, args=...) at XULFrameElementBinding.cpp:513 #30 0x00007ff0bcecc02a in mozilla::dom::binding_detail::GenericMethod<mozilla::dom::binding_detail::NormalThisPolicy, mozilla::dom::binding_detail::ThrowExceptions>(JSContext*, unsigned int, JS::Value*) (cx=0x1, cx@entry=0x7ff0a871b000, argc=<optimized out>, vp=<optimized out>) at /home/emilio/src/moz/gecko/dom/bindings/BindingUtils.cpp:3297 #31 0x00007ff0bf67b1f1 in CallJSNative(JSContext*, bool (*)(JSContext*, unsigned int, JS::Value*), js::CallReason, JS::CallArgs const&) From: 0 updateBrowserRemoteness( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["chrome://browser/content/tabbrowser.js":1937:15] <failed to get 'this' value> 1 updateBrowserRemotenessByURL( <Failed to get argument while inspecting stack frame> aURL = ""http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html"") ["chrome://browser/content/tabbrowser.js":2052:20] <failed to get 'this' value> 2 restoreTabContent( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4662:38] <failed to get 'this' value> 3 restoreTab( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4565:13] <failed to get 'this' value> 4 restoreTabs( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> aSelectTab = "2") ["resource:///modules/sessionstore/SessionStore.jsm":4413:11] <failed to get 'this' value> 5 ssi_restoreWindow( <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4189:11] <failed to get 'this' value> 6 _restoreWindowsFeaturesAndTabs( <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4275:11] <failed to get 'this' value> 7 _restoreWindowsInReversedZOrder( <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4299:9] <failed to get 'this' value> 8 ssi_restoreWindows/<( <Failed to get argument while inspecting stack frame> ) ["resource:///modules/sessionstore/SessionStore.jsm":4359:11] This load triggers a remoteness change. [rr 502130 277558]RemoteWebNavigation.currentURI browser=36 bc=94 undefined [rr 502130 277561]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank [rr 502130 277564]RestoreDocShellState(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html) [rr 502130 277568]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank [rr 502130 277572]BrowsingContext::LoadURI(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html) This is the load that should actually end up in the browsing context. [rr 502578 280053]DocumentChannelChild::AsyncOpen(browser=36, bc=94, about:blank) From the previous remoteness update. [rr 502130 280138]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank [rr 502130 280141]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank [rr 502130 280143]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank [rr 502130 280146]RemoteWebNavigation.currentURI browser=36 bc=94 about:blank At this point, we try to use the BFCache, and end up replacing the browsing context: #0 mozilla::dom::CanonicalBrowsingContext::AllowedInBFCache(mozilla::Maybe<unsigned long> const&) (this=0x7ff08f2b5800, aChannelId=...) at /home/emilio/src/moz/gecko/docshell/base/CanonicalBrowsingContext.cpp:2158 #1 0x00007ff0bb3157c1 in mozilla::net::DocumentLoadListener::MaybeTriggerProcessSwitch(bool*) (this=this@entry=0x7ff093b74090, aWillSwitchToRemote=aWillSwitchToRemote@entry=0x7ffe23887838) at /home/emilio/src/moz/gecko/netwerk/ipc/DocumentLoadListener.cpp:1723 #2 0x00007ff0bb317feb in mozilla::net::DocumentLoadListener::OnStartRequest(nsIRequest*) (this=0x7ff093b74090, aRequest=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/netwerk/ipc/DocumentLoadListener.cpp:2263 #3 0x00007ff0bb238a0c in mozilla::net::ParentChannelListener::OnStartRequest(nsIRequest*) (this=0x7ff08d5c4ee0, aRequest=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/netwerk/protocol/http/ParentChannelListener.cpp:91 #4 0x00007ff0bb9abec2 in nsDocumentOpenInfo::OnStartRequest(nsIRequest*) (this=<optimized out>, request=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:166 #5 0x00007ff0bb32baf0 in mozilla::net::ParentProcessDocumentOpenInfo::OnDocumentStartRequest(nsIRequest*) (this=0x7ff093bc5b80, request=0x7ff0a0b7a3c8) at /home/emilio/src/moz/gecko/netwerk/ipc/DocumentLoadListener.cpp:292 #6 0x00007ff0bae6446c in nsBaseChannel::OnStartRequest(nsIRequest*) (this=<optimized out>, request=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/base/nsBaseChannel.cpp:833 #7 0x00007ff0bae82bdd in nsInputStreamPump::OnStateStart() (this=this@entry=0x7ff08f2593c0) at /home/emilio/src/moz/gecko/netwerk/base/nsInputStreamPump.cpp:481 #8 0x00007ff0bae828d9 in nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) (this=0x7ff08f2593c0, stream=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/base/nsInputStreamPump.cpp:390 #9 0x00007ff0bae8339b in non-virtual thunk to nsInputStreamPump::OnInputStreamReady(nsIAsyncInputStream*) () at /home/emilio/src/moz/gecko/netwerk/base/nsInputStreamPump.cpp:632 #10 0x00007ff0bacd29d5 in mozilla::NonBlockingAsyncInputStream::RunAsyncWaitCallback(mozilla::NonBlockingAsyncInputStream::AsyncWaitRunnable*, already_AddRefed<nsIInputStreamCallback>) (this=this@entry=0x7ff094eb5a50, aRunnable=aRunnable@entry=0x7ff08f228560, aCallback=...) at /home/emilio/src/moz/gecko/xpcom/io/NonBlockingAsyncInputStream.cpp:397 #11 0x00007ff0bacdf2ec in mozilla::NonBlockingAsyncInputStream::AsyncWaitRunnable::Run() (this=0x7ff08f228560) at /home/emilio/src/moz/gecko/xpcom/io/NonBlockingAsyncInputStream.cpp:33 #12 0x00007ff0bad48d04 in mozilla::RunnableTask::Run() (this=0x7ff093bc5980) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:482 #13 0x00007ff0bad316d4 in mozilla::TaskController::DoExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (this=<optimized out>, this@entry=0x7ff0c54f2400, aProofOfLock=...) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:766 #14 0x00007ff0bad3091d in mozilla::TaskController::ExecuteNextTaskOnlyMainThreadInternal(mozilla::detail::BaseAutoLock<mozilla::Mutex&> const&) (this=this@entry=0x7ff0c54f2400, aProofOfLock=...) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:621 #15 0x00007ff0bad30a83 in mozilla::TaskController::ProcessPendingMTTask(bool) (this=0x7ff0c54f2400, aMayWait=false) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:405 #16 0x00007ff0bad4388f in mozilla::TaskController::InitializeInternal()::$_0::operator()() const (this=<optimized out>) at /home/emilio/src/moz/gecko/xpcom/threads/TaskController.cpp:138 #17 mozilla::detail::RunnableFunction<mozilla::TaskController::InitializeInternal()::$_0>::Run() (this=<optimized out>) at /home/emilio/src/moz/gecko/obj-debug/dist/include/nsThreadUtils.h:534 #18 0x00007ff0bad3b7f6 in nsThread::ProcessNextEvent(bool, bool*) (this=0x7ff0c541d680, aMayWait=false, aResult=0x7ffe23888437) at /home/emilio/src/moz/gecko/xpcom/threads/nsThread.cpp:1159 #19 0x00007ff0bad3f384 in NS_ProcessNextEvent(nsIThread*, bool) (aThread=0x7ff08f2b5800, aThread@entry=0x7ff0c541d680, aMayWait=false) at /home/emilio/src/moz/gecko/xpcom/threads/nsThreadUtils.cpp:548 #20 0x00007ff0bb43dfe0 in mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) (this=0x7ff0c54d12c0, aDelegate=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/glue/MessagePump.cpp:85 #21 0x00007ff0bb3be7b7 in MessageLoop::RunInternal() (this=this@entry=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/chromium/src/base/message_loop.cc:335 #22 0x00007ff0bb3be707 in MessageLoop::RunHandler() (this=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/chromium/src/base/message_loop.cc:328 #23 MessageLoop::Run() (this=0x7ff0c54353e0) at /home/emilio/src/moz/gecko/ipc/chromium/src/base/message_loop.cc:310 #24 0x00007ff0bded2bdb in nsBaseAppShell::Run() (this=0x7ff0a880c580) at /home/emilio/src/moz/gecko/widget/nsBaseAppShell.cpp:137 #25 0x00007ff0bf449d85 in nsAppStartup::Run() (this=0x7ff0a883de20) at /home/emilio/src/moz/gecko/toolkit/components/startup/nsAppStartup.cpp:273 #26 0x00007ff0bf5428b6 in XREMain::XRE_mainRun() (this=<optimized out>, this@entry=0x7ffe238887c0) at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:5239 #27 0x00007ff0bf5433ef in XREMain::XRE_main(int, char**, mozilla::BootstrapConfig const&) (this=this@entry=0x7ffe238887c0, argc=argc@entry=5, argv=argv@entry=0x7ffe23889a68, aConfig=<optimized out>) at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:5437 #28 0x00007ff0bf54385e in XRE_main(int, char**, mozilla::BootstrapConfig const&) (argc=-1816706824, argv=0x7ff0c56441a0, aConfig=...) at /home/emilio/src/moz/gecko/toolkit/xre/nsAppRunner.cpp:5496 #29 0x0000562d08f8e415 in do_main(int, char**, char**) (argc=-1816706824, argv=0x7ffe23889a68, envp=<optimized out>) at /home/emilio/src/moz/gecko/browser/app/nsBrowserApp.cpp:224 [rr 502130 280199]CanonicalBrowsingContext::ReplacedBy(94 -> 104) [rr 502130 280344]didChangeRemoteness browser=36, bc=104 [rr 502130 280348]RemoteWebNavigation.currentURI browser=36 bc=104 undefined [rr 502130 280625]RedirectToRealChannel(36, about:blank) [rr 502578 280695]BrowserChild::OnLocationChange(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html) [rr 502578 280699]BrowsingContext::LoadURI(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html) [rr 502578 280703]DocumentChannelChild::AsyncOpen(browser=36, bc=94, http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html) This is the LoadURI call for the "final" load, however it went to the wrong browsing context, as we just replaced this! [rr 502130 280803]updateForLocationChange browser=36 bc=104 - http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html [rr 502130 280807]RemoteWebNavigation.currentURI browser=36 bc=104 http://example.com/browser/browser/base/content/test/tabs/file_new_tab_page.html [rr 502578 281334]BrowserChild::OnLocationChange(browser=36, bc=104, about:blank) And this one is from the process switch. [rr 502130 281461]updateForLocationChange browser=36 bc=104 - about:blank [rr 502130 281465]RemoteWebNavigation.currentURI browser=36 bc=104 about:blank [rr 502130 282028] ⰲ겿{"action":"test_status","time":1621467211822,"thread":null,"pid":null,"source":"mochitest","test":"chrome://mochitests/content/browser/browser/base/content/test/tabs/browser_new_tab_insert_position.js","subtest":"tab pos 0 matched http://mochi.test:8888/#0","status":"PASS","message":"","js_source":"TestRunner.js"}ⰲ겿 [rr 502130 282031]RemoteWebNavigation.currentURI browser=36 bc=104 about:blank [rr 502130 282033]RemoteWebNavigation.currentURI browser=36 bc=104 about:blank [rr 502130 282117] So this is certainly the easy fix, but I think we should generally try to deal with this better, somehow? Differential Revision: https://phabricator.services.mozilla.com/D115560
jamienicol
pushed a commit
that referenced
this pull request
Jun 23, 2021
…for Removed()'d nodes, a=testonly Automatic update from web-platform-tests Improved de-duping of ChildrenChanged() for Removed()'d nodes 1. Only process ChildrenChanged() for the included root of a change. For example, if a <div id="root" style="display:none"> will be included because it is a potential relation target. If descendants change, the only ChildrenChanged() necessary to process is on #root. 2. Share common code for detaching a node and queuing up the appropriate children changes. This simplifies ProcessInvalidatedObjects() by removing one of the inner loops, and enables a follow-up CL to remove the outer loop as well. #1 results in a massive speedup for display none toggles. In combination with other recent changes in DetachAndRemoveFromChildrenOfAncestors(), is 7x faster for many-nodes-toggle-display-none in perf_tests . This change alone accounts for about half of the overall improvement. Follow-ups: - Restore lifecycle check by processing deferred children changes via nodes_with_pending_children_changed_ and not queuing via the traditional mechanism. While doing this, look for opportunities to consolidate more children changed events. - Remove outer loop from ProcessInvalidatedObjects(). Bug: None Change-Id: I80466fda792cd0ca6dd051065a42ba702e4cc8b1 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2946971 Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Commit-Queue: Aaron Leventhal <aleventhal@chromium.org> Cr-Commit-Position: refs/heads/master@{#891343} -- wpt-commits: e80db1ba70c30f1be0193cc8d163dfd85057d353 wpt-pr: 29314
jamienicol
pushed a commit
that referenced
this pull request
Jun 23, 2021
Automatic update from web-platform-tests Safe slot reassigment 1. Use GetWithoutInvalidation() instead of Get() in DCHECKs. We should never call Get() inside of a DCHECK(), because this can lead to a different code path depending on whether DCHECKs are enabled. 2. Get() should not cause immediate side effects. At most, it should queue up an invalidation for later processing. Fixing #1 and #2 were required in order to get past a first set of errors introduced by the new test. 3. The actual fix -- avoid infinite loop by calling a special new SlotAssignmentWillChange(), rather than ChildrenChanged(), where a minimal GetWithoutInvalidation() is called that does not lead to IsShadowContentRelevantForAccessibility() => FirstChild() => RecalcAssignedNodes() => ChildrenChanged() ... (infinite loop). A simpler potential fix is in CL:2965317 but requires more research. It's also mentioned in a TODO comment. Bug: 1219311 Change-Id: Iafaa289f241a851404ce352715d2970172a2e5f8 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2961158 Reviewed-by: Joey Arhar <jarhar@chromium.org> Reviewed-by: Mason Freed <masonf@chromium.org> Reviewed-by: Dominic Mazzoni <dmazzoni@chromium.org> Commit-Queue: Aaron Leventhal <aleventhal@chromium.org> Cr-Commit-Position: refs/heads/master@{#892778} -- wpt-commits: 7b9ca7da96108c39142ebf9b6d639d9725beebf4 wpt-pr: 29388
jamienicol
pushed a commit
that referenced
this pull request
Jul 20, 2021
… inline CBs in a multicol, a=testonly Automatic update from web-platform-tests [LayoutNG] Relative offset for OOFs with inline CBs in a multicol Relative offsets should be applied after fragmentation. Since we perform layout for OOFs once they reach the fragmentation context root (if applicable), we fail to apply any relative offsets at the correct time in the case of inline containing blocks. See CL:2851595 for how this was handled for the non-inline case. The changes required to accomplish this for inline containing blocks include: 1. We currently store an accumulated relative offset in NGContainingBlock inside the OOF node, which is any relative offset from the containing block to the fragmentation context root. We also need to store an accumulated relative offset from the inline container to the containing block in order to properly apply all relative offsets at the time of fragmentation. A new struct, NGInlineContainer, was added to the OOF node to hold the inline container object and the accumulated relative offset to the containing block. 2. A relative offset was also added to the InlineContainingBlockGeometry struct so that we have access to the relative offset from #1 when creating the ContainingBlockInfo for the inline container. 3. The way that relative offsets are applied to inlines, it didn't seem straightforward to separate the relative offset from the normal offset, like we had in CL:2851595. Instead, store the relative offset for the inline and subtract it out from the OOF static position once it reaches the containing block, and subtract it from the containing block rect offset when determining the ContainingBlockInfo for the inline container. 4. Store the total relative offset (from the inline container to the fragmentation context root) in ContainingBlockInfo. This relative offset will then be applied after fragmentation is complete for the OOF as a result of CL:2851595. Bug: 1079031 Change-Id: I7198fec4c01e05ca54c51b2f215569b75b0b869e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2995308 Commit-Queue: Alison Maher <almaher@microsoft.com> Reviewed-by: Morten Stenshorne <mstensho@chromium.org> Reviewed-by: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/master@{#902060} -- wpt-commits: 67a78f560e0e0ec601193aa78d7031937bce78f7 wpt-pr: 29548
jamienicol
pushed a commit
that referenced
this pull request
Jul 21, 2021
… inline CBs in a multicol, a=testonly Automatic update from web-platform-tests [LayoutNG] Relative offset for OOFs with inline CBs in a multicol Relative offsets should be applied after fragmentation. Since we perform layout for OOFs once they reach the fragmentation context root (if applicable), we fail to apply any relative offsets at the correct time in the case of inline containing blocks. See CL:2851595 for how this was handled for the non-inline case. The changes required to accomplish this for inline containing blocks include: 1. We currently store an accumulated relative offset in NGContainingBlock inside the OOF node, which is any relative offset from the containing block to the fragmentation context root. We also need to store an accumulated relative offset from the inline container to the containing block in order to properly apply all relative offsets at the time of fragmentation. A new struct, NGInlineContainer, was added to the OOF node to hold the inline container object and the accumulated relative offset to the containing block. 2. A relative offset was also added to the InlineContainingBlockGeometry struct so that we have access to the relative offset from #1 when creating the ContainingBlockInfo for the inline container. 3. The way that relative offsets are applied to inlines, it didn't seem straightforward to separate the relative offset from the normal offset, like we had in CL:2851595. Instead, store the relative offset for the inline and subtract it out from the OOF static position once it reaches the containing block, and subtract it from the containing block rect offset when determining the ContainingBlockInfo for the inline container. 4. Store the total relative offset (from the inline container to the fragmentation context root) in ContainingBlockInfo. This relative offset will then be applied after fragmentation is complete for the OOF as a result of CL:2851595. Bug: 1079031 Change-Id: I7198fec4c01e05ca54c51b2f215569b75b0b869e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2995308 Commit-Queue: Alison Maher <almaher@microsoft.com> Reviewed-by: Morten Stenshorne <mstensho@chromium.org> Reviewed-by: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/master@{#902060} -- wpt-commits: 67a78f560e0e0ec601193aa78d7031937bce78f7 wpt-pr: 29548
jamienicol
pushed a commit
that referenced
this pull request
Sep 29, 2021
The test case inadvertently asked to grow memory #1 rather than growing the default memory by 1 page. Differential Revision: https://phabricator.services.mozilla.com/D126647
jamienicol
pushed a commit
that referenced
this pull request
Oct 6, 2021
…d() API, a=testonly Automatic update from web-platform-tests [Region Capture #1] Add new produceCropId() API This patch adds a new produceCropId() API to mediaDevices. This API is called with a DIV or IFRAME element, and adds a new base::UnguessableToken value to that element's rare data structure. This token value will be used in followup patches in order to keep track of an element's location in the page and viewport. Based on the following design document: https://docs.google.com/document/d/1dULARMnMZggfWqa_Ti_GrINRNYXGIli3XK9brzAKEV8/ Bug: 1247761 Change-Id: I01cd67e2d4e3dfa7a86289f876e48c8b55095d0a Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3173396 Commit-Queue: Jordan Bayles <jophba@chromium.org> Reviewed-by: Elad Alon <eladalon@chromium.org> Reviewed-by: mark a. foltz <mfoltz@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#925544} -- wpt-commits: c0c366c3c0ddb5166ad7d242bb31d06270e026b9 wpt-pr: 30917
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
Mar 1, 2022
…e ordering, a=testonly
Automatic update from web-platform-tests
App history: tweak and test event/promise ordering
By adding new exhaustive tests under ordering/, it was revealed that the ordering between navigatesuccess/navigateerror and the committed/finished promises was not always consistent:
1. Simply adding a currentchange event handler would cause microtasks to run during commit, which changed some ordering.
2. Calling transitionWhile() would take us from the zero-promise case to the 1+-promise case in ScriptPromise::All(). As the new comment explains, both the spec and implementation have an observably-different fast path for the 0-promise case which caused changes in ordering.
In the course of fixing this, I found out that the did_finish_before_commit_ code in app_history_api_navigation.{h,cc} was actually not a mitigation for the case it stated, where promises passed to transitionWhile() would settle faster than the browser-process roundtrip for same-document traversals. That is in fact impossible, since we only fire the navigate event after the browser-process roundtrip has completed. Instead, they were a mitigation for (1).
This commit then ensures consistent ordering, tested with new rather-exhaustive tests, in the following manner:
* We move the firing of currentchange to before resolving the committed promise. This eliminates (1) and allows us to delete the did_finish_before_commit_ tracking.
* We always ensure we pass 1+ promises to ScriptPromise::All(). This eliminates (2).
A consequence of this is that we are now more likely to get rejected finished promises, in cases like
await appHistory.navigate("#1").committed;
await appHistory.navigate("#2").committed;
Before, the finished promise for the #1 navigation would go through the fast path per (2), and fulfill before the navigation to #2 canceled it. Now that does not happen, so code like the above will give an unhandled promise rejection for #1's finished promise.
To avoid this, we unconditionally mark finished promises as handled. This follows some web platform precedent, e.g. stream closed promises, where the promise is one of several information channels (in this case the developer might also find out via the AbortSignal or the navigateerror event). We do *not* do this for the committed promise though, as if a commit fails, that's probably something more deeply wrong, and cannot be ignored.
All of these changes will require spec updates.
For the tests, we introduce a new ordering/ directory which contains cross-cutting ordering tests, and we consolidate a few tests into the newly-introduced variant-driven exhaustive ones. A couple of other tests were affected by these changes too or fixed as a drive-by.
Change-Id: I8a50ca28d009e0a8a2c94331cd17f29b0a8dc463
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3405377
Reviewed-by: Nate Chapin <japhet@chromium.org>
Commit-Queue: Domenic Denicola <domenic@chromium.org>
Cr-Commit-Position: refs/heads/main@{#963772}
--
wpt-commits: 3638c168c6db3f12a8d72f1e70e2d66ced788528
wpt-pr: 32504
jamienicol
pushed a commit
that referenced
this pull request
Mar 8, 2022
…e ordering, a=testonly
Automatic update from web-platform-tests
App history: tweak and test event/promise ordering
By adding new exhaustive tests under ordering/, it was revealed that the ordering between navigatesuccess/navigateerror and the committed/finished promises was not always consistent:
1. Simply adding a currentchange event handler would cause microtasks to run during commit, which changed some ordering.
2. Calling transitionWhile() would take us from the zero-promise case to the 1+-promise case in ScriptPromise::All(). As the new comment explains, both the spec and implementation have an observably-different fast path for the 0-promise case which caused changes in ordering.
In the course of fixing this, I found out that the did_finish_before_commit_ code in app_history_api_navigation.{h,cc} was actually not a mitigation for the case it stated, where promises passed to transitionWhile() would settle faster than the browser-process roundtrip for same-document traversals. That is in fact impossible, since we only fire the navigate event after the browser-process roundtrip has completed. Instead, they were a mitigation for (1).
This commit then ensures consistent ordering, tested with new rather-exhaustive tests, in the following manner:
* We move the firing of currentchange to before resolving the committed promise. This eliminates (1) and allows us to delete the did_finish_before_commit_ tracking.
* We always ensure we pass 1+ promises to ScriptPromise::All(). This eliminates (2).
A consequence of this is that we are now more likely to get rejected finished promises, in cases like
await appHistory.navigate("#1").committed;
await appHistory.navigate("#2").committed;
Before, the finished promise for the #1 navigation would go through the fast path per (2), and fulfill before the navigation to #2 canceled it. Now that does not happen, so code like the above will give an unhandled promise rejection for #1's finished promise.
To avoid this, we unconditionally mark finished promises as handled. This follows some web platform precedent, e.g. stream closed promises, where the promise is one of several information channels (in this case the developer might also find out via the AbortSignal or the navigateerror event). We do *not* do this for the committed promise though, as if a commit fails, that's probably something more deeply wrong, and cannot be ignored.
All of these changes will require spec updates.
For the tests, we introduce a new ordering/ directory which contains cross-cutting ordering tests, and we consolidate a few tests into the newly-introduced variant-driven exhaustive ones. A couple of other tests were affected by these changes too or fixed as a drive-by.
Change-Id: I8a50ca28d009e0a8a2c94331cd17f29b0a8dc463
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3405377
Reviewed-by: Nate Chapin <japhet@chromium.org>
Commit-Queue: Domenic Denicola <domenic@chromium.org>
Cr-Commit-Position: refs/heads/main@{#963772}
--
wpt-commits: 3638c168c6db3f12a8d72f1e70e2d66ced788528
wpt-pr: 32504
jamienicol
pushed a commit
that referenced
this pull request
Jun 23, 2022
Automatic update from web-platform-tests
Make popups animation-friendly
Now, popups will follow this process when showing/hiding:
showPopup():
1. Move the popup to the top layer, and remove the UA display:none
style.
2. Update style. (Transition initial style can be specified in this
state.)
3. Set the :top-layer pseudo class.
4. Update style. (Animations/transitions happen here.)
hidePopup():
1. Capture any already-running animations via getAnimations().
2. Remove the :top-layer pseudo class.
3. Update style. (Animations/transitions start here.)
4. If the hidePopup() call is not due to a "force out" situation,
getAnimations() again, remove any from step #1, and then wait here
until all of them finish or are cancelled.
4. Remove the popup from the top layer, and add the UA display:none
style.
5. Update style.
See this issue for more details:
openui/open-ui#335
Bug: 1307772
Change-Id: Ia20eb6e9533c1a0b1029ca1279d42fe2648300af
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3688871
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1014235}
--
wpt-commits: 297b9403e0ab65348de01169d1a4e3cf078af7b9
wpt-pr: 34304
jamienicol
pushed a commit
that referenced
this pull request
Jul 7, 2022
… pop up hide event, a=testonly
Automatic update from web-platform-tests
Allow hide animations to be started from pop up hide event
See [1] for the origin of this change, which makes it possible to
trigger pop up hide animations from within the `hide` event handler.
For example:
popup.addEventListener('hide', () => {
popup.animate({
transform: 'translateY(-50px)',
opacity: 0,
}, 200);
});
To accomplish that, the hide process now looks like this:
1. Capture any already-running animations via getAnimations(),
including animations on descendent elements.
2. Remove the :top-layer pseudo class.
3. Fire the 'hide' event.
4. If the hidePopup() call is *not* the result of the pop-up being
"forced out" of the top layer, e.g. by a modal dialog or fullscreen
element:
a. Restore focus to the previously-focused element.
b. Update style. (Animations/transitions start here.)
c. Call getAnimations() again, remove any from step #1, and then wait
until all of them finish or are cancelled.
5. Remove the pop-up from the top layer, and add the UA display:none
style.
6. Update style.
[1] https://chromium-review.googlesource.com/c/chromium/src/+/3688871/9/third_party/blink/renderer/core/dom/element.cc#2660
Bug: 1307772
Change-Id: I910535b13cfc3c8f8498ed64dae73caa75dd7317
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/3708419
Reviewed-by: Robert Flack <flackr@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Commit-Queue: Robert Flack <flackr@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1018685}
--
wpt-commits: d4a7c77961af00b9a4ba78b0f80d771a519f78c6
wpt-pr: 34561
jamienicol
pushed a commit
that referenced
this pull request
Nov 17, 2022
Upstream commit: https://webrtc.googlesource.com/src/+/42be4ae879ed6870dfc5ca554d11062b536da717 Limit input size for the rtp video layers allocation fuzzer (cherry picked from commit 02c99982c8e5a88ca14cc217254f3d9b3c792646) Bug: chromium:1355892 Change-Id: Ib0c48d27fb1e79212d2354e0249511aeeb53f650 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272961 Commit-Queue: Danil Chapovalov <danilchap@webrtc.org> Reviewed-by: Per Kjellander <perkj@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#37913} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/274602 Reviewed-by: Danil Chapovalov <danilchap@webrtc.org> Cr-Commit-Position: refs/branch-heads/5195@{#1} Cr-Branched-From: dc5cf31cad576376abd3aa6306169453cfd85ba5-refs/heads/main@{#37586}
jamienicol
pushed a commit
that referenced
this pull request
Dec 14, 2022
…ltiple `test()`s, a=testonly
Automatic update from web-platform-tests
WPT: Allow `window.onload` to contain multiple `test()`s
******************************************************************
*** SHERIFFS: please don't revert this CL if it causes web_tests
to flake/fail. If that happens, the cause is a bad
test. Please mark that test as flaky/fail in
TestExpectations, with a new crbug. Please block the
new bug against crbug.com/1395228. Thanks!
******************************************************************
Prior to this CL, a test like this:
```
<script>
window.onload = () => {
test((t) => { ... }, 'test 1');
test((t) => { ... }, 'test 2');
test((t) => { ... }, 'test 3');
};
</script>
```
would not run anything after test #1. The issue is that the testharness
immediately adds a window load handler that marks `all_loaded = true`,
and that ends the tests as soon as the first result from the first test
is processed. (The test runner waits for the first test because
`Tests.prototype.all_done()` also waits until `this.tests.length > 0`.)
There were various mitigating corner cases, such as if you started
the list of tests with a promise_test(), that would increment a
counter that kept the rest of the tests alive. Etc.
With this CL, the testharness-added window.onload handler runs a
setTimeout(0), so that `all_loaded` is only set to true after all of
the tests are loaded by any window.onload handler.
This exposed a few tests that should have been failing but were
masked by the lack of test coverage - bugs have been filed for
those. Also, several tests that were working around this via various
means are also cleaned up in this CL. I'm sure there are more of
those.
Bug: 1395228,1395226,1307772
Change-Id: I6f12b5922186af4e1e06808ad23b47ceac68559c
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4074305
Reviewed-by: Weizhong Xia <weizhong@google.com>
Auto-Submit: Mason Freed <masonf@chromium.org>
Reviewed-by: Mason Freed <masonf@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1081558}
--
wpt-commits: e085ff159a16b0a40c38cf745d511c4687bb3937
wpt-pr: 37299
jamienicol
pushed a commit
that referenced
this pull request
Jan 3, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/d3ff606f4f7be9ef3058e13fd1a487ea997753d4 [Merge-106] Add "WebRTC-BurstyPacer/burst:20ms" field trial. This experiment will tell if we still see the performance gains that we saw with the "bursty slacked pacer" even if we don't apply slack (since the "slack without burst" showed little impact at Stable). The hope is that without slack all quality regressions will go away but that bursting will still provide the desired performance benefits. (cherry picked from commit d34605b0a4e4f5cac3829425e862610e279b807f) Bug: chromium:1354491 Change-Id: I95f05d040713addaaa1856c8e374a01c27311612 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/272366 Commit-Queue: Henrik Boström <hbos@webrtc.org> Reviewed-by: Erik Språng <sprang@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#37845} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/273460 Cr-Commit-Position: refs/branch-heads/5249@{#1} Cr-Branched-From: 7aaeb5a270ba23f5844f7301a50aaff9b6ca6126-refs/heads/main@{#37825}
jamienicol
pushed a commit
that referenced
this pull request
Jan 13, 2023
…ntain multiple `test()`s", a=testonly Automatic update from web-platform-tests Revert "WPT: Allow `window.onload` to contain multiple `test()`s" This reverts commit 4a03c6c459fdbf11976a424aa02a1d094484134c. Reason for revert: This has caused tests in upstream WPT to fail, blocking unrelated PRs. It was still possible to upstream this because those tests weren't triggered on the change due to a bug: web-platform-tests/wpt#37623 There was an attempted fix for this: web-platform-tests/wpt#37549 But, quoting jgraham from the WPT Matrix chat: > the actual fix failed a test I wrote and now I need to spend some more time investigating Original change's description: > WPT: Allow `window.onload` to contain multiple `test()`s > > ****************************************************************** > *** SHERIFFS: please don't revert this CL if it causes web_tests > to flake/fail. If that happens, the cause is a bad > test. Please mark that test as flaky/fail in > TestExpectations, with a new crbug. Please block the > new bug against crbug.com/1395228. Thanks! > ****************************************************************** > > Prior to this CL, a test like this: > > ``` > <script> > window.onload = () => { > test((t) => { ... }, 'test 1'); > test((t) => { ... }, 'test 2'); > test((t) => { ... }, 'test 3'); > }; > </script> > ``` > > would not run anything after test #1. The issue is that the testharness > immediately adds a window load handler that marks `all_loaded = true`, > and that ends the tests as soon as the first result from the first test > is processed. (The test runner waits for the first test because > `Tests.prototype.all_done()` also waits until `this.tests.length > 0`.) > There were various mitigating corner cases, such as if you started > the list of tests with a promise_test(), that would increment a > counter that kept the rest of the tests alive. Etc. > > With this CL, the testharness-added window.onload handler runs a > setTimeout(0), so that `all_loaded` is only set to true after all of > the tests are loaded by any window.onload handler. > > This exposed a few tests that should have been failing but were > masked by the lack of test coverage - bugs have been filed for > those. Also, several tests that were working around this via various > means are also cleaned up in this CL. I'm sure there are more of > those. > > Bug: 1395228,1395226,1307772 > Change-Id: I6f12b5922186af4e1e06808ad23b47ceac68559c > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4074305 > Reviewed-by: Weizhong Xia <weizhong@google.com> > Auto-Submit: Mason Freed <masonf@chromium.org> > Reviewed-by: Mason Freed <masonf@chromium.org> > Commit-Queue: Mason Freed <masonf@chromium.org> > Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> > Cr-Commit-Position: refs/heads/main@{#1081558} Bug: 1395228,1395226,1307772 Change-Id: Icbddad3a8bb47473bcbc331f424661b9041addf2 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4111318 Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: Philip Jägenstedt <foolip@chromium.org> Cr-Commit-Position: refs/heads/main@{#1085925} -- wpt-commits: 5c571b86bc98819157b584132bca1b80ca4503cb wpt-pr: 37624
jamienicol
pushed a commit
that referenced
this pull request
Jan 13, 2023
… invoker, a=testonly Automatic update from web-platform-tests Fix focus traversal for self-referential invoker In the case that a popover contains an invoker that points back to that invoker, the tab navigation code used to get confused. E.g.: ``` <div id="menu" popover> <button autofocus popoverhidetarget="menu">Button #1</button> <button popoverhidetarget="menu">Button #2</button> </div> ``` In this case, trying to tab between the first and second button would break because the second button appeared to be an invoker for a new popover, when in reality it was an invoker for the same popover. Fixed: 1399601 Bug: 1307772 Change-Id: I276370d7c8eee0dd32f0c89da202a0d3777bf911 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4133482 Commit-Queue: Mason Freed <masonf@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Commit-Queue: Joey Arhar <jarhar@chromium.org> Reviewed-by: Joey Arhar <jarhar@chromium.org> Cr-Commit-Position: refs/heads/main@{#1089080} -- wpt-commits: f938eec99e167202dc5e9e4e8067ab4d53e10834 wpt-pr: 37766
jamienicol
pushed a commit
that referenced
this pull request
Jan 25, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/b88c3b5e02cc50c7dae29f1184b4ee6e7fc58cbc Add an ICE agent interface (#1/n) This interface will be implemented by P2PTransportChannel in a follow-up CL. It will allow an ICE controller to request actions to manipulate the connection used by the transport. Bug: webrtc:14367, webrtc:1413 Change-Id: I5cd171bd09c8dfc88588f8fc06e87d74a90b5216 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/271290 Reviewed-by: Jonas Oreland <jonaso@webrtc.org> Commit-Queue: Sameer Vijaykar <samvi@google.com> Cr-Commit-Position: refs/heads/main@{#38062}
jamienicol
pushed a commit
that referenced
this pull request
Jan 25, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/eb485a627145e2bd65e0b1428ec6301325ff5697 [107] VideoStreamEncoder: set at target quality based on codec. The Chromium RTCVideoEncoder unfortunately doesn't set if the result is at target quality, and the definition of the threshold is buried in libvpx_vp8_encoder.h. This change * Updates VideoStreamEncoder to postprocess an incoming EncodedImage by interpreting the incoming QP information instead. * Updates the related VideoStreamEncoder test to simulate an encoder producing images around the QP threshold. * Updates the steady state VP8 screencast QP threshold to a central include file. * Moves this and previously existing EncodedImage post-processing to a new method AugmentEncodedImage. (cherry picked from commit e1a198b41dceab7818592b32288975489b3a9d12) Bug: b/245029833, chromium:1364573 Change-Id: I69ae29ffe501e84f28908f7d9a8cfd066ba82b43 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275380 Reviewed-by: Erik Språng <sprang@webrtc.org> Commit-Queue: Markus Handell <handellm@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#38091} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/275775 Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Cr-Commit-Position: refs/branch-heads/5304@{#1} Cr-Branched-From: 024bd84ca1cf7d3650c27912a3b5bfbb54da152a-refs/heads/main@{#38083}
jamienicol
pushed a commit
that referenced
this pull request
Feb 7, 2023
1. Ship the Sanitization (currently on in Nightly
but without crashing) to the trains
2. Enabling crashing in Nightly
#1 will start omitting the preference values in
Content Processes. An affected user will have
their browser behave differently - it will be as
if the preference has no value. So for e.g. the
font preferences, their font customizations will
be gone. If they file a bug about this happening
and an engineer connects the problem to pref
sanitization we could debug the issue and maybe
understand it.
#2 will mean that an affected user (of which
there are currently none we think) will have a
content process crash when they access a
forbidden preference. The crash reason will
contain the name of the preference, and the
stack which would help us better understand
why we crashed.
Differential Revision: https://phabricator.services.mozilla.com/D167287
jamienicol
pushed a commit
that referenced
this pull request
Feb 20, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/bfb453af77e67b597506b77982d33ff26ebe8909 [Merge-108] [Stats] Add googTimingFrameInfo to the modern API. This is exposing something that is already exposed in the legacy getStats() API and is only available if the "video-timing" header extension is used. Adding this metric here should unblock legacy getStats() API deprecation. The follow-up to unship or standardize this metric is tracked by https://crbug.com/webrtc/14586. (cherry picked from commit c5f8f800a28536d09eb1978afa69208365dc22b6) Bug: webrtc:14587, chromium:1376604 Change-Id: Ic3d45b0558d7caf4be2856a4cd95b88db312f85e Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279860 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Henrik Boström <hbos@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#38444} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/279900 Cr-Commit-Position: refs/branch-heads/5359@{#1} Cr-Branched-From: fb3bd4a01d7c840dfe7b3efa144c0fbcb6a97fef-refs/heads/main@{#38387}
jamienicol
pushed a commit
that referenced
this pull request
Jun 27, 2023
…ding error in page.py test, a=testonly Automatic update from web-platform-tests [wdspec] browsingContext.print: fix rounding error in page.py test (#40504) * [wdspec] browsingContext.print: fix rounding error in page.py test [pytest](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/webdriver/tests/support/image.py) uses: def cm_to_px(cm): return round(cm * 96 / 2.54) [js](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/tools/wptrunner/wptrunner/print_pdf_runner.html) uses: const viewport = page.getViewport({ scale: 96. / 72. }); ... canvas.height = viewport.height; canvas.width = viewport.width; This produces a rounding error, even though the dimension is correct: > assert cm_to_px(expected_dimensions["height"]) == height E assert 454 == 453 E +454 E -453 The inconsistency of rounding in both ends becomes clear when we eliminate "round" in the pytest side: > assert cm_to_px(expected_dimensions["height"]) == height E assert 453.54330708661416 == 453 E +453.54330708661416 E -453 There are multiple ways to fix this issue. Option #1: Use "floor" instead of "round" in pytest. Option #2: Use a range in the assertion comparison, allowing a difference of up to +-1.0. This is what this PR does. The comparison is performed in [`assert_pdf_dimensions`](https://github.com/web-platform-tests/wpt/blob/b6107cc1ac8b9c2800b4c8e58af719b8e4d9b8db/webdriver/tests/support/fixtures_bidi.py#L210). The problematic part is .96 / .72 which evaluates to 4/3 = 1.333333.... * use floor in cm_to_px instead of round * compare to floor and to round instead of a range * Revert "compare to floor and to round instead of a range" This reverts commit 63f894e6d1881616e0f13b7a40ddcb30b772eba8. * Revert "use floor in cm_to_px instead of round" This reverts commit 7e65d918b25575060ca50009d261d1e76dca6cae. -- wpt-commits: fb57353809aa19c0659ece5563d05ed20706d1fc wpt-pr: 40504
jamienicol
pushed a commit
that referenced
this pull request
Aug 7, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/9d996824465410b4f25cf1d20bdee01d7091533a [M114] Fix bug of messages being delivered before data channel is open If the caller calls RegisterObserver() on the network thread while the state is not kOpen but there are queued received data, those received data will be immediately delivered to the observer before the state is transitioned to kOpen, which may break the observer's assertions and cause problems. The problem turns out to be that, when SctpDataChannel::RegisterObserver calls DeliverQueuedReceivedData(), the data will be passed to the observer without checking the |state_| first, meanwhile SctpDataChannel::UpdateState does effectively check the state and null-check |observer_| before delivering the received data. This CL fixes this by simply making DeliverQueuedReceivedData() also check `state_ == kOpen`. In case the state transitions to kOpen after RegisterObserver() is called, the first DeliverQueuedReceivedData() call will be no-op, while the second DeliverQueuedReceivedData() call will do the work. (cherry picked from commit 20838941240536b52e24e47ce99ad6c2175dba1a) No-Try: True Bug: chromium:1442696 Change-Id: If25ce6a038d704939b1a8ae73d7ced110448b050 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/304687 Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org> Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40036} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305380 Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/branch-heads/5735@{#1} Cr-Branched-From: df7df199abd619e75b9f1d9a7e12fc3f3f748775-refs/heads/main@{#39949}
jamienicol
pushed a commit
that referenced
this pull request
Aug 14, 2023
…id extra InsertedInto calls, a=testonly Automatic update from web-platform-tests Add append_to argument to Clone() to avoid extra InsertedInto calls Because of the order of operations for Clone(), previous to this CL, the typical sequence would be: 1. Clone the element 2. Clone the children of the element (recursing to step #1). 3. AppendChild() each cloned child to its parent cloned element. 4. (in the caller of Clone) AppendChild the cloned element to its eventual parent. Because each AppendChild triggers a call to Node::InsertedInto() for *all descendants of the appended element* [1], the fact that the tree is constructed bottom-up (leaf nodes first) means that InsertedInto() is called N^2 times, where N is the depth of the cloned tree. Because clone-and-append is a very common pattern, this CL adds an `append_to` argument to `Clone()`, which appends to the parent before appending the children. This CL also adds a perf test for this scenario (cloning a deep tree). Locally, on a debug build, this test gives 0.13 runs/s before this CL, and 0.40 runs/s after, for a 3.1X speedup. [1] https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/renderer/core/dom/container_node.cc;l=1006;drc=5d60017dba57e86d477634812e1340127734f8a7 Bug: 1453291 Change-Id: Icdd75c45aa5ecc4fe8bb5d1ff0b7a2b27bec2171 Cq-Do-Not-Cancel-Tryjobs: true Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4728983 Reviewed-by: David Baron <dbaron@chromium.org> Commit-Queue: David Baron <dbaron@chromium.org> Auto-Submit: Mason Freed <masonf@chromium.org> Commit-Queue: Mason Freed <masonf@chromium.org> Cr-Commit-Position: refs/heads/main@{#1177922} -- wpt-commits: d73d9dc406f6eaf5cb52facc67f7884587b1dfac wpt-pr: 41265
jamienicol
pushed a commit
that referenced
this pull request
Aug 31, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/ad3838a9b5cafa6820408a8a3a97aa667f608111 Revert "pipewire capturer: Reduce the amount of copying" This reverts commit 8856410b6d54b546bdb3185587474f0f9b3a7c2e. Reason for revert: chromium:1447540 Original change's description: > pipewire capturer: Reduce the amount of copying > > Improves the capture latency by reducing the amount of > copying needed from the frame. We keep track of the > damaged region of previous frame and union it with > the damaged region of this frame and only copy this > union of the frame over. X11 capturer already has > such synchronization in place. > > The change is beneficial especially when there are > small changes on the screen (e.g. clock ticking). > For a 4k screen with 128 cores, I observed the > capture latencies drop from 5 - 8 ms to 0 ms when the > system is left idle. This is in line with the X11 > capturer. > > Bug: chromium:1291247 > Change-Id: Iffb441f9e1902d2658031f5f35b5372ee8e94073 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/299720 > Reviewed-by: Alexander Cooper <alcooper@chromium.org> > Commit-Queue: Salman Malik <salmanmalik@chromium.org> > Cr-Commit-Position: refs/heads/main@{#39968} (cherry picked from commit a7d10811cdf1a0a22760b2297fbd2502b49bd75f) Bug: chromium:1447540 Change-Id: Id1bfd3fc39fea2bb1f232cad5218f90e144920e7 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/306263 Commit-Queue: Mark Foltz <mfoltz@chromium.org> Commit-Queue: Alexander Cooper <alcooper@chromium.org> Auto-Submit: Alexander Cooper <alcooper@chromium.org> Reviewed-by: Mark Foltz <mfoltz@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#40123} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/306582 Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/5790@{#1} 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 43670de877. Upstream commit: https://webrtc.googlesource.com/src/+/ebf9a1faf81f30f9fb6d1a9390545e562c62ec06 [M116] 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 <hta@webrtc.org> Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40332} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310920 Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/branch-heads/5845@{#1} Cr-Branched-From: f80cf814353d11a9f22bef5ce5e8868f2c72f0d0-refs/heads/main@{#40319}
jamienicol
pushed a commit
that referenced
this pull request
Oct 24, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/d95382fab7dcac8867d9811c4630367c4454cb7d [M117][SctpDataChannel] Don't use PostTask for observer registration. Instead, use BlockingCall to match with how unregistration is done. This is needed because the ThreadWrapper implementation in Chromium, overriding the Thread implementation in WebRTC, does not order sent (blocking) tasks along with posted tasks. That makes the functional difference that Thread1 posting and sending tasks to Thread2, can not assume that the tasks run in the order they were posted and sent. I.e. in this case: // Running on Thread1. thread2->PostTask([](){ Foo(); }); thread2->BlockingCall([](){ Bar(); }); Thread2 may actually execute Bar() first, and then Foo(). (cherry picked from commit 70cea9bda8b8815be3c5bae4b6fa8053713efcac) No-Try: true Bug: chromium:1470992 Change-Id: I1f83f12ce39c09279c0f2b3bc71c3a33e2cb16c5 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/317700 Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40624} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/318360 Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/branch-heads/5938@{#1} Cr-Branched-From: 82e5f91a2bdf955aa870142008fbdc9ac12f6acd-refs/heads/main@{#40524}
jamienicol
pushed a commit
that referenced
this pull request
Nov 24, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/7349579c4272d22b88c7dbb497b9bc2acfc5a26f [M118] FrameCadenceAdapter: stop delayed refresh frame calls on dtor. The FrameCadenceAdapter starts a delayed task to request a new refresh frame on receiving frame drop. However, the resulting RepeatingTaskHandle was not Stop()ed on destruction, leading to UAF. (cherry picked from commit fb98b01061e7eec51a800b53d4346827f89336a5) Fixed: chromium:1478944 Change-Id: Iba441420953e989cfc7fcfd2f358b5b30f375786 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320200 Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40747} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/320420 Reviewed-by: Henrik Andreassson <henrika@webrtc.org> Cr-Commit-Position: refs/branch-heads/5993@{#1} 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/+/004a624023ce8b01c0f9d8a62fc13390d604ce34 [121] Ensure cloning and then sending audio encoded frames propagates CSRCs (cherry picked from commit 5f3ac435518cd5c05a74b58419fe6cfc504fc7da) Bug: chromium:1508337 Change-Id: I9f28fc0958d28bc97f9378a46fbec3e45148736f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330260 Reviewed-by: Guido Urdaneta <guidou@webrtc.org> Commit-Queue: Tony Herre <herre@google.com> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#41337} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/330564 Commit-Queue: Guido Urdaneta <guidou@webrtc.org> Cr-Commit-Position: refs/branch-heads/6167@{#1} Cr-Branched-From: ece5cb83715dea85617114b6d4e981fdee2623ba-refs/heads/main@{#41315}
jamienicol
pushed a commit
that referenced
this pull request
Apr 19, 2024
We already cherry-picked this when we vendored 6b419a0536. Upstream commit: https://webrtc.googlesource.com/src/+/c026167f59bcf4b438d2235e452a76593d62c4e3 [M123 merge] Limit max frame size in DAV1D decoder (cherry picked from commit 74a4038eaddcac773b9fc172ad446df6eb704b11) Bug: chromium:325284120 Change-Id: Iea0aea0a17bb0b1f73b3c1cbd408b7a6cd2b216e Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/340180 Commit-Queue: Sergey Silkin <ssilkin@webrtc.org> Reviewed-by: Erik Språng <sprang@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#41776} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/340600 Reviewed-by: Philip Eliasson <philipel@webrtc.org> Commit-Queue: Erik Språng <sprang@webrtc.org> Cr-Commit-Position: refs/branch-heads/6312@{#1} Cr-Branched-From: 0355f455a48b141a8277442825ec776a74d66fb7-refs/heads/main@{#41763}
jamienicol
pushed a commit
that referenced
this pull request
Apr 30, 2024
…est is affected by rounded corners, a=testonly Automatic update from web-platform-tests Fall back to main thread if scroll hit test is affected by rounded corners We had two issues: 1. Before we had fast rounded corners, we always created mask layers for rounded corner clips, and the mask layer made the scroll begin unreliable and fall back to the main thread. With fast rounded corners, the scrolls were treated as reliable without checking if the point is in or out of the rounded corners. 2. If the scroller has a rounded corner by itself (instead of from an ancestor), as we only create InnerBorderRadiusClip for the contents, the compositor doesn't actually know which part of the layer bounds is transparent to hit test (e.g. if the scroller has a border which is outside of the InnerBorderRadiusClip). Now with HitTestOpaqueness, such layers have HitTestOpaqueness::kMixed. This CL changes the behavior of LayerTreeImpl::FindLayersUpToFirstOpaqueToHitTest (renamed from FindLayerUpToFirstScrollableOrOpaqueToHitTest): - For issue #1: LayerImpl::OpaqueToHitTest() also checks whether the layer is affected by any fast rounded corners; - For issue #2: FindLayerUpToFirstOpaqueToHitTest checks only OpaqueToHitTest() (without checking IsScrollerOrScrollbar()) because a hit test on a scrollable layer is reliable only if it's opaque to hit test. Bug: 40277896 Change-Id: I1acb16f2c6790760661e8239ea1599035f83ea51 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5466909 Commit-Queue: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: Steve Kobes <skobes@chromium.org> Cr-Commit-Position: refs/heads/main@{#1291538} -- wpt-commits: 9e7e1bd19fecd541ce4192e24039b746a88ce3df wpt-pr: 45797
jamienicol
pushed a commit
that referenced
this pull request
May 13, 2024
…ug,dom-core Bug #1: AbstractRange::(Mark|Unmark)Descendants should always use the shadow tree of web-exposed shadow root, instead of using light DOM elements of the host. Bug #2: aRange could possibly create mCrossShadowBoundaryRange first (due to boundaries are in different tree), and later moves the boundaries to the same tree. When this happens, we should remove mCrossShadowBoundaryRange and use the default range to represent it. Differential Revision: https://phabricator.services.mozilla.com/D207608
jamienicol
pushed a commit
that referenced
this pull request
May 14, 2024
…ug,dom-core Bug #1: AbstractRange::(Mark|Unmark)Descendants should always use the shadow tree of web-exposed shadow root, instead of using light DOM elements of the host. Bug #2: aRange could possibly create mCrossShadowBoundaryRange first (due to boundaries are in different tree), and later moves the boundaries to the same tree. When this happens, we should remove mCrossShadowBoundaryRange and use the default range to represent it. Differential Revision: https://phabricator.services.mozilla.com/D207608
jamienicol
pushed a commit
that referenced
this pull request
May 17, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/4edf7bab66dcef8191a8275e007baedee5ff1374 [M124] Adjust min vp9 simulcast bitrate to closer mimic SVC behaviour If SVC is used, the minimum bitrate would be 30kbps, instead of 49, as configured in svc_config.h, because the overall stream will get min_bitrate from the default VP8 simulcast configuration, and this 30kbps will be allocated to the stream for svc_rate_allocator to divide between layers. However, with the configuration before this change, 49kbps would be always allocated to the lowest simulcast stream. (cherry picked from commit f49a8262cc4b89549375cde7b962bbf5ee3c0d07) Bug: webrtc:15852, chromium:330672089 Change-Id: I1c77f45654af8850180a83f8e3f4428cc42d086e Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343760 Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#41940} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/343981 Cr-Commit-Position: refs/branch-heads/6367@{#1} Cr-Branched-From: 802552a8030d82ad07b72aa738f814f3a0030810-refs/heads/main@{#41921}
jamienicol
pushed a commit
that referenced
this pull request
May 24, 2024
…inting background., a=testonly Automatic update from web-platform-tests Get border/padding from fragment when painting background. Since @page border box layout objects aren't in the the layout tree, any code that wants to walk up the tree to find the containing block will be in for a surprise. This would happen if percentage-based @page padding was used [1]. Recomputing padding during painting when we have already done it during layout is rather pointless anyway. Read it out directly from the fragment. [1] #1 blink::LayoutBox::ContainingBlockLogicalWidthForContent() #2 blink::LayoutBoxModelObject::ComputedCSSPadding() #3 blink::LayoutBoxModelObject::PaddingTop() #4 blink::LayoutBoxModelObject::PaddingOutsets() #5 blink::BoxPainterBase::PaintFillLayer() #6 blink::BoxPainterBase::PaintFillLayers() #7 blink::BoxFragmentPainter::PaintBackground() Bug: 40286153 Change-Id: I1e6e92c2ce1d81aab2673ec9a877eac455534102 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5526469 Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org> Reviewed-by: Ian Kilpatrick <ikilpatrick@chromium.org> Cr-Commit-Position: refs/heads/main@{#1300711} -- wpt-commits: 601b701a9d708b48a9cddae1ac15963d61be7964 wpt-pr: 46252
jamienicol
pushed a commit
that referenced
this pull request
Jul 2, 2024
…ed frames., a=testonly Automatic update from web-platform-tests Disable WebRTC RTCPeerConnection in fenced frames. WebRTC is one form of network communication that should be disabled when window.fence.disableUntrustedNetwork is called in a fenced frame. However, 1. We don't have any identified use cases for WebRTC in fenced frames 2. The revocation process would be more involved than other forms of network access, which would provide little benefit per #1. 3. Entirely disabling WebRTC PeerConnection instead is beneficial for privacy and does not break existing fenced frame use cases. This CL disables RTCPeerConnection construction entirely in fenced frames, regardless of whether window.fence.disableUntrustedNetwork was called or not. The change is behind an existing flag so that it does not ship until other forms of network revocation do. Disabling RTCPeerConnection *can* be handled entirely by the renderer, but a compromised renderer could potentially circumvent this to construct a peer connection anyway. A follow-up CL will add a browser-side control to ensure that this does not occur. Change-Id: Iaa2caaddeee70852179332dd89c5dbbac3ffcfbf Bug: 41488151 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5527514 Reviewed-by: Guido Urdaneta <guidou@chromium.org> Commit-Queue: Andrew Verge <averge@chromium.org> Reviewed-by: Liam Brady <lbrady@google.com> Reviewed-by: Shivani Sharma <shivanisha@chromium.org> Cr-Commit-Position: refs/heads/main@{#1319162} -- wpt-commits: bf8449f4dd09ec5c37c774981d884e67695cbbdd wpt-pr: 46169
jamienicol
pushed a commit
that referenced
this pull request
Jul 9, 2024
We cherry-picked this in bug 1896575 Upstream commit: https://webrtc.googlesource.com/src/+/a18e38fed2307edd6382760213fa3ddf199fa181 Video capture PipeWire: drop corrupted PipeWire buffers Use SPA_CHUNK_FLAG_CORRUPTED and SPA_META_HEADER_FLAG_CORRUPTED flags to determine corrupted buffers or corrupted buffer data. We used to only rely on compositors setting chunk->size, but this doesn't make sense for dmabufs where they have to make up arbitrary values. It also looks this is not reliable and can cause glitches as we end up processing corrupted buffers. (cherry picked from commit cfbd6b0884db2eab893831e7bde5cfe640fe52db) Bug: chromium:341928670 Change-Id: Ida0c6a5e7a37e19598c6d5884726200f81b94962 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349881 Commit-Queue: Mark Foltz <mfoltz@chromium.org> Reviewed-by: Mark Foltz <mfoltz@chromium.org> Reviewed-by: Alexander Cooper <alcooper@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#42292} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/351563 Commit-Queue: Alexander Cooper <alcooper@chromium.org> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Cr-Commit-Position: refs/branch-heads/6478@{#1} Cr-Branched-From: 16fb7903e546051483720548168cd40cded7a040-refs/heads/main@{#42290}
jamienicol
pushed a commit
that referenced
this pull request
Jul 29, 2024
…-worker-reviewers,smaug,profiler-reviewers,aabh,asuth,perftest-reviewers,sparky
Use profiler markers to collect timing data. Markers of known name:
AUTO_PROFILER_MARKER_TEXT("interesting thing #1", DOM, {}, ""_ns);
AUTO_PROFILER_MARKER_TEXT("interesting thing #2", DOM, {}, ""_ns);
can be inspected from the perftest:
await startProfiler();
interestingThings();
let pdata = await stopProfiler();
let duration_ms = inspectProfile(pdata, [
"interesting thing #1",
"interesting thing #2"
]);
Differential Revision: https://phabricator.services.mozilla.com/D211368
jamienicol
pushed a commit
that referenced
this pull request
Aug 21, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/876d0c9881eab8e7f8389812eb3738bdd374aa22 Fix use-of-uninitialized-value in NetEq tests. The new version of MSan (rolled by [1]) detects the following: ``` ==39908==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x5591400a52ef in GetPlayoutDelayMs ./../../modules/audio_coding/neteq/decision_logic.cc:466:35 #1 0x5591400a52ef in webrtc::DecisionLogic::ExpectedPacketAvailable(webrtc::NetEqController::NetEqStatus) ./../../modules/audio_coding/neteq/decision_logic.cc:311:36 #2 0x5591400a39e9 in webrtc::DecisionLogic::GetDecision(webrtc::NetEqController::NetEqStatus const&, bool*) ./../../modules/audio_coding/neteq/decision_logic.cc:0:0 #3 0x55913cf590c9 in webrtc::DecisionLogicTest_PreemptiveExpand_Test::TestBody() ./../../modules/audio_coding/neteq/decision_logic_unittest.cc:139:3 #4 0x55913ef28283 in HandleExceptionsInMethodIfSupported<testing::Test, void> ./../../third_party/googletest/src/googletest/src/gtest.cc:0:3 #5 0x55913ef28283 in testing::Test::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:2710:5 #6 0x55913ef2ab46 in testing::TestInfo::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:2856:11 #7 0x55913ef2da34 in testing::TestSuite::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:3034:30 #8 0x55913ef621e8 in testing::internal::UnitTestImpl::RunAllTests() ./../../third_party/googletest/src/googletest/src/gtest.cc:5964:44 #9 0x55913ef60f54 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> ./../../third_party/googletest/src/googletest/src/gtest.cc:0:0 #10 0x55913ef60f54 in testing::UnitTest::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:5543:10 #11 0x55913ee1a944 in RUN_ALL_TESTS ./../../third_party/googletest/src/googletest/include/gtest/gtest.h:2334:73 #12 0x55913ee1a944 in webrtc::(anonymous namespace)::TestMainImpl::Run(int, char**) ./../../test/test_main_lib.cc:203:21 #13 0x55913cbd36b8 in main ./../../test/test_main.cc:72:16 #14 0x7fdb18c73082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16 #15 0x55913cb3e1a9 in _start ??:0:0 ``` [1] - https://webrtc-review.googlesource.com/c/src/+/353620 Bug: b/344970813 Change-Id: I9b5d7791e68b4c494168ba9f007a3099ae21fed4 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/353581 Auto-Submit: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Jakob Ivarsson <jakobi@webrtc.org> Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org> Cr-Commit-Position: refs/heads/main@{#42433}
jamienicol
pushed a commit
that referenced
this pull request
Aug 21, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/e0b28a6a81a989c1f5c89e30fcd247870047390d [Merge 127] Reset the speech encoder when creating a comfort noise encoder. This is to make sure that the two encoders are "in sync" (the CNG encoder can be created from an existing speech encoder). This is a speculative fix for a crash in the CNG encoder where a packet is unexpectedly emitted from the speech encoder. (cherry picked from commit 0fd67312ea078b3b997306d56284b85492b37650) Bug: webrtc:42225071, chromium:338342746 Change-Id: I42571e56e032897f7f083f04d785f6a08ebfb813 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/355160 Commit-Queue: Jakob Ivarsson <jakobi@webrtc.org> Reviewed-by: Tomas Lundqvist <tomasl@google.com> Cr-Original-Commit-Position: refs/heads/main@{#42516} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/355863 Reviewed-by: Daniel Johansson <dajo@webrtc.org> Cr-Commit-Position: refs/branch-heads/6533@{#1} Cr-Branched-From: 63c380918687cd4c233e9eb856e98ba4c0589722-refs/heads/main@{#42455}
jamienicol
pushed a commit
that referenced
this pull request
Aug 21, 2024
…indows r=win-reviewers,gstoll This implements PresentSystemSettings, LocationIsPermittedHint and SystemWillPromptForPermissionHint for Windows. The Windows APIs are not always available -- some are currently only available in Windows 11 Canary builds (slated for September release). In the event that APIs are not available, this should do nothing. At present, this is detailed here: https://learn.microsoft.com/en-us/windows/win32/nativewifi/wi-fi-access-location-changes There are two issues that this is intended to handle: 1. The system will display a one-time (or so) dialog to the user when Firefox requests geolocation but doesn't have permission. For that case, we inform the user that they will be asked to grant location permission again. This system dialog is only presented in versions of Windows that support all of the relevant APIs. 2. We open system settings to the right page and post a cancelable modal dialog on the tab if the user grants geolocation to the page but geolocation permission isn't currently granted in the OS. This case will not happen if case #1 did. Unfortunately, we can't get information about the permission status without a location request on old versions of Windows, so this also does nothing unless the recent APIs are supported (in this case, AppCapability::CheckAccess). This work is necessitated not only by the new (occasional) system dialog but also by Microsoft's plans to block wifi scanning if geolocation isn't available. We have used wifi scanning as part of a fallback when system geolocation isn't available -- that approach is no longer viable here. A user would confusingly get repeated errors or very poor results (e.g. IP lookup results) without information as to why, if that happened. This is what happens in the current Windows Canary build if system geolocation is turned off. The fallback remains useful on other platforms, although Linux is in flux (but it is not in the scope of this bug). Differential Revision: https://phabricator.services.mozilla.com/D216474
jamienicol
pushed a commit
that referenced
this pull request
Aug 29, 2024
…indows r=win-reviewers,gstoll This implements PresentSystemSettings, LocationIsPermittedHint and SystemWillPromptForPermissionHint for Windows. The Windows APIs are not always available -- some are currently only available in Windows 11 Canary builds (slated for September release). In the event that APIs are not available, this should do nothing. At present, this is detailed here: https://learn.microsoft.com/en-us/windows/win32/nativewifi/wi-fi-access-location-changes There are two issues that this is intended to handle: 1. The system will display a one-time (or so) dialog to the user when Firefox requests geolocation but doesn't have permission. For that case, we inform the user that they will be asked to grant location permission again. This system dialog is only presented in versions of Windows that support all of the relevant APIs. 2. We open system settings to the right page and post a cancelable modal dialog on the tab if the user grants geolocation to the page but geolocation permission isn't currently granted in the OS. This case will not happen if case #1 did. Unfortunately, we can't get information about the permission status without a location request on old versions of Windows, so this also does nothing unless the recent APIs are supported (in this case, AppCapability::CheckAccess). This work is necessitated not only by the new (occasional) system dialog but also by Microsoft's plans to block wifi scanning if geolocation isn't available. We have used wifi scanning as part of a fallback when system geolocation isn't available -- that approach is no longer viable here. A user would confusingly get repeated errors or very poor results (e.g. IP lookup results) without information as to why, if that happened. This is what happens in the current Windows Canary build if system geolocation is turned off. The fallback remains useful on other platforms, although Linux is in flux (but it is not in the scope of this bug). Differential Revision: https://phabricator.services.mozilla.com/D216474
jamienicol
pushed a commit
that referenced
this pull request
Sep 9, 2024
We already cherry-picked this when we vendored 46b43e0072. Upstream commit: https://webrtc.googlesource.com/src/+/bef5d63112748d963af30b7ac39bf3628b6ce9ef [M128] Revert "Update support for missing HIGH profiles and 1080p" M128 merge approval: https://issues.chromium.org/issues/354143228#comment11 This reverts commit 46b43e007296737751aea10685f92ddf4df63e0d. Reason for revert: chromium:354143228 Original change's description: > Update support for missing HIGH profiles and 1080p > > The High and ConstrainedHigh profiles are missing from the decoder capabilities. Also level 3.1 doesn't allow 1080p > > Bug: webrtc:347724928 > Change-Id: I3f33468327d2aaf352fc80f69d2ee31481bafcb5 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/355001 > Reviewed-by: Sergey Silkin <ssilkin@webrtc.org> > Reviewed-by: Åsa Persson <asapersson@webrtc.org> > Commit-Queue: Sergey Silkin <ssilkin@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#42528} (cherry picked from commit 12f9d5ce601a13cd45d56f40ed9ed94f3a90d91e) Bug: chromium:354143228, webrtc:347724928 Change-Id: I4d55b2982aca2e94ec983473336c4fa2a72d842f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357861 Reviewed-by: Danil Chapovalov <danilchap@webrtc.org> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#42675} No-Try: True Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/358021 Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by: Åsa Persson <asapersson@webrtc.org> Cr-Commit-Position: refs/branch-heads/6613@{#1} Cr-Branched-From: 1ac162ee20a214bf97f6594a7effcbbc21f1effb-refs/heads/main@{#42664}
jamienicol
pushed a commit
that referenced
this pull request
Sep 12, 2024
…r=m_kato This fixes four issues: 1. The test didn't provide enough movement to generate a drag session on the source before moving to the target. This meant that, when they were in different windows, Gecko wouldn't send dragleave to the source or dragenter to the target. It also never sent dragenter to the source in the first place. This remedies that. 2. dragenter and dragleave weren't properly handled because the test was sending dragleaves instead of dragexits (the latter being what Gecko expects and the former being synthesized from that -- see e.g. nsNativeDragTarget::DragLeave). This now uses dragexits and sets the proper expectations. 3. expectProtectedDataTransferAccess was needlessly complicated and, after #1, gave the wrong answers for some events like dragenter called on the source. 4. The event handler wasn't checking for exceptions and the drop handler was intentionally causing one, which was causing it to miss the rest of its execution. Differential Revision: https://phabricator.services.mozilla.com/D219550
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bumps lodash from 3.3.1 to 4.17.15.
Release notes
Sourced from lodash's releases.
Commits
ddfd9b1Bump to v4.17.15.b185fceRebuild lodash and docs.be87d30Bump to v4.17.14.a6fe6b1Rebuild lodash and docs.e371828Bump to v4.17.13.357e899Rebuild lodash and docs.fd9a062Bump to v4.17.12.e77d681Rebuild lodash and docs.629d186Update OpenJS references.2406eacFix minified build.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 ignore this [patch|minor|major] versionwill close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this 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.