Bump json5 from 2.2.1 to 2.2.3 in /tools/esmify #1

dependabot · 2023-08-07T05:10:54Z

Bumps json5 from 2.2.1 to 2.2.3.

Release notes

v2.2.3

Fix: json5@2.2.3 is now the 'latest' release according to npm instead of v1.0.2. (#299)

v2.2.2

Fix: Properties with the name __proto__ are added to objects and arrays. (#199) This also fixes a prototype pollution vulnerability reported by Jonathan Gregson! (#295).

Changelog

Sourced from json5's changelog.

v2.2.3 [code, diff]

Fix: json5@2.2.3 is now the 'latest' release according to npm instead of v1.0.2. (#299)

v2.2.2 [code, diff]

Fix: Properties with the name __proto__ are added to objects and arrays. (#199) This also fixes a prototype pollution vulnerability reported by Jonathan Gregson! (#295).

Commits

c3a7524 2.2.3
94fd06d docs: update CHANGELOG for v2.2.3
3b8cebf docs(security): use GitHub security advisories
f0fd9e1 docs: publish a security policy
6a91a05 docs(template): bug -> bug report
14f8cb1 2.2.2
10cc7ca docs: update CHANGELOG for v2.2.2
7774c10 fix: add proto to objects and arrays
edde30a Readme: slight tweak to intro
97286f8 Improve example in readme
Additional commits viewable in compare view

You can trigger a rebase of this PR by commenting @dependabot rebase.

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

@dependabot rebase will rebase this PR
@dependabot recreate will recreate this PR, overwriting any edits that have been made to it
@dependabot merge will merge this PR after your CI passes on it
@dependabot squash and merge will squash and merge this PR after your CI passes on it
@dependabot cancel merge will cancel a previously requested merge and block automerging
@dependabot reopen will reopen this PR if it is closed
@dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
@dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
@dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the Security Alerts page.

Note
Automatic rebases have been disabled on this pull request as it has been open for over 30 days.

Bumps [json5](https://github.com/json5/json5) from 2.2.1 to 2.2.3. - [Release notes](https://github.com/json5/json5/releases) - [Changelog](https://github.com/json5/json5/blob/main/CHANGELOG.md) - [Commits](json5/json5@v2.2.1...v2.2.3) --- updated-dependencies: - dependency-name: json5 dependency-type: indirect ... Signed-off-by: dependabot[bot] <support@github.com>

…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

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}

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}

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}

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}

Upstream commit: https://webrtc.googlesource.com/src/+/71e3fbf5d750e84d181315a663eb5dbc29a5330c [M119 merge] Reland "Add mitigation for very long frame drop gaps with vp8" This is a reland of commit 0d4b350006eae7dfeeb8c67f16f51b1c62351cee Patchset 1 is the original CL. Patchset 2 contains a small tweak of the target bitrate in the unit test, in order to make in less susceptible to flakiness on runtime environments running a slightly different libvpx. Original change's description: > Add mitigation for very long frame drop gaps with vp8 > > Bug: webrtc:15530 > Change-Id: I11f5e3f31f71301700dbff3fc9285236160bee45 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322320 > Reviewed-by: Sergey Silkin <ssilkin@webrtc.org> > Commit-Queue: Sergey Silkin <ssilkin@webrtc.org> > Auto-Submit: Erik Språng <sprang@webrtc.org> > Cr-Commit-Position: refs/heads/main@{#40866} (cherry picked from commit d7703d950536473627533ed6eab24c2d50054e70) Bug: webrtc:15530 Change-Id: I096b7d952286f7f53852d1ca70aea398b2747784 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322540 Auto-Submit: Erik Språng <sprang@webrtc.org> Commit-Queue: Erik Språng <sprang@webrtc.org> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40874} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322900 Cr-Commit-Position: refs/branch-heads/6045@{#1} Cr-Branched-From: bce7ce7ba054ac0e79fed49b84ef52fb24c31778-refs/heads/main@{#40854}

…ect> / <embed> as subdocuments. r=longsonr These look like two really old bugs. Part of the issue is that <object> / <embed> manage their frame loader quite differently from <iframe>. This means that we may have a PresShell / ViewManager / etc for a frame loader that doesn't yet have a frame associated. For example, this is the viewport creation for the SVG document that reproduces the problem: #0 0x00005cc60e8302e7 in mozilla::ViewportFrame::SetViewInternal(nsView*) (this=0x68599020, aView=0x683d8f00) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/ViewportFrame.h:106 #1 0x00005cc60e842858 in nsIFrame::SetView(nsView*) (this=0x68599020, aView=0x683d8f00) at /home/emilio/src/moz/gecko/layout/generic/nsFrame.cpp:7057 #2 0x00005cc60e77258a in nsCSSFrameConstructor::ConstructRootFrame() (this=0xc72c715e00) at /home/emilio/src/moz/gecko/layout/base/nsCSSFrameConstructor.cpp:2424 #3 0x00005cc60e7342f5 in mozilla::PresShell::Initialize() (this=0x6830e000) at /home/emilio/src/moz/gecko/layout/base/PresShell.cpp:1758 #4 0x00005cc60c9fb02a in nsContentSink::StartLayout(bool) (this=<optimized out>, aIgnorePendingSheets=<optimized out>) at /home/emilio/src/moz/gecko/dom/base/nsContentSink.cpp:1160 #5 0x00005cc60e2c1581 in nsXMLContentSink::HandleStartElement(char16_t const*, char16_t const**, unsigned int, unsigned int, unsigned int, bool) (this=<optimized out>, aName=<optimized out>, aAtts=0x6fde8200, aAttsCount=<optimized out>, aLineNumber=3, aColumnNumber=<optimized out>, aInterruptable=true) at /home/emilio/src/moz/gecko/dom/xml/nsXMLContentSink.cpp:982 #6 0x00005cc60e2c17d7 in non-virtual thunk to nsXMLContentSink::HandleStartElement(char16_t const*, char16_t const**, unsigned int, unsigned int, unsigned int) () at /home/emilio/src/moz/gecko/dom/xml/nsXMLContentSink.cpp:889 #7 0x00005cc60c360307 in nsExpatDriver::HandleStartElement(void*, char16_t const*, char16_t const**) (aUserData=0x224f650d0cc0, aName=0x685aef20 u"http://www.w3.org/2000/svg\xffffdesc", aAtts=0x6fde8200) at /home/emilio/src/moz/gecko/parser/htmlparser/nsExpatDriver.cpp:293 #8 0x00005cc60ee91cea in doContent (parser=0xc72c70f800, startTagLevel=0, enc=<optimized out>, s=<optimized out>, end=0x5bbd31af5020 "\344\344\344", <incomplete sequence \344>, nextPtr=0x7ffca2653288, haveMore=1 '\001') at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:2872 #9 0x00005cc60ee90059 in contentProcessor (parser=0xc72c70f800, start=0xffffffe6 <error: Cannot access memory at address 0xffffffe6>, end=0xc72c511360 "", endPtr=0x1) at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:2528 #10 0x00005cc60ee8f8d5 in doProlog (parser=<optimized out>, enc=0x5cc612ce0930 <little2_encoding_ns>, s=0x5bbd31ab508e "<", end=0x5bbd31af5020 "\344\344\344", <incomplete sequence \344>, tok=<optimized out>, next=<optimized out>, nextPtr=0x7ffca2653288, haveMore=1 '\001', allowClosingDoctype=1 '\001') at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:4591 #11 0x00005cc60ee8d86e in prologProcessor (parser=0xc72c70f800, s=0x5bbd31ab5020 "<", end=0x5bbd31af5020 "\344\344\344", <incomplete sequence \344>, nextPtr=0x7ffca2653288) at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:4311 #12 0x00005cc60ee8cf45 in MOZ_XML_Parse (parser=0xc72c70f800, s=0x5bbd31ab5020 "<", len=262144, isFinal=0) at /home/emilio/src/moz/gecko/parser/expat/lib/xmlparse.c:1894 #13 0x00005cc60c3627bc in nsExpatDriver::ParseBuffer(char16_t const*, unsigned int, bool, unsigned int*) (this=0x224f650d0cc0, aBuffer=0x5bbd31ab5020 u"<?xml version=\"1.0\" encoding=\"UTF-8\" standalone=\"no\"?>\n<svg height=\"2970\" width=\"2100\" viewBox=\"0 0 2100 2970\" version=\"1.1\" xmlns=\"http://www.w3.org/2000/svg\" xmlns:xlink=\"http://www.w3.org/1999/xlin"..., aLength=131072, aIsFinal=false, aConsumed=<optimized out>) at /home/emilio/src/moz/gecko/parser/htmlparser/nsExpatDriver.cpp:875 #14 0x00005cc60c362c91 in nsExpatDriver::ConsumeToken(nsScanner&, bool&) (this=<optimized out>, aScanner=..., aFlushTokens=<optimized out>) at /home/emilio/src/moz/gecko/parser/htmlparser/nsExpatDriver.cpp:970 #15 0x00005cc60c3666a8 in nsParser::Tokenize(bool) (this=0x224f65038e80, aIsFinalChunk=false) at /home/emilio/src/moz/gecko/parser/htmlparser/nsParser.cpp:1410 #16 0x00005cc60c36595e in nsParser::ResumeParse(bool, bool, bool) (this=0x224f65038e80, allowIteration=true, aIsFinalChunk=false, aCanInterrupt=<optimized out>) at /home/emilio/src/moz/gecko/parser/htmlparser/nsParser.cpp:961 #17 0x00005cc60c366c86 in nsParser::OnDataAvailable(nsIRequest*, nsIInputStream*, unsigned long, unsigned int) (this=0x224f65038e80, request=<optimized out>, pIStream=0x6fdfc430, sourceOffset=<optimized out>, aLength=131072) at /home/emilio/src/moz/gecko/parser/htmlparser/nsParser.cpp:1317 #18 0x00005cc60c897cc2 in nsObjectLoadingContent::OnDataAvailable(nsIRequest*, nsIInputStream*, unsigned long, unsigned int) (this=<optimized out>, aRequest=0x68483080, aInputStream=0x6fdfc430, aOffset=0, aCount=131072) at /home/emilio/src/moz/gecko/dom/base/nsObjectLoadingContent.cpp:1055 #19 0x00005cc60b9d18f8 in mozilla::net::HttpChannelChild::DoOnDataAvailable(nsIRequest*, nsISupports*, nsIInputStream*, unsigned long, unsigned int) (this=0x68483000, aRequest=0x68483080, aContext=<optimized out>, aStream=0x6fdfc430, aOffset=0, aCount=743510880) at /home/emilio/src/moz/gecko/netwerk/protocol/http/HttpChannelChild.cpp:968 #20 0x00005cc60b9d5cbf in mozilla::net::HttpChannelChild::OnTransportAndData(nsresult const&, nsresult const&, unsigned long const&, unsigned int const&, nsTString<char> const&) (this=0x68483000, aChannelStatus=<optimized out>, aTransportStatus=@0x683be5bc: -2142568440, aOffset=<optimized out>, aCount=<optimized out>, aData=...) at /home/emilio/src/moz/gecko/netwerk/protocol/http/HttpChannelChild.cpp:867 #21 0x00005cc60badb535 in mozilla::net::ChannelEventQueue::FlushQueue() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/netwerk/ipc/ChannelEventQueue.cpp:90 #22 0x00005cc60b976fda in mozilla::net::ChannelEventQueue::MaybeFlushQueue() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/net/ChannelEventQueue.h:350 #23 0x00005cc60baec442 in mozilla::net::ChannelEventQueue::CompleteResume() (this=0xc72ce2cae0) at /home/emilio/src/moz/gecko/obj-debug/dist/include/mozilla/net/ChannelEventQueue.h:329 #24 mozilla::net::ChannelEventQueue::ResumeInternal()::CompleteResumeRunnable::Run() (this=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/ipc/ChannelEventQueue.cpp:148 #25 0x00005cc60b53d4f1 in mozilla::SchedulerGroup::Runnable::Run() (this=0x685b0200) at /home/emilio/src/moz/gecko/xpcom/threads/SchedulerGroup.cpp:282 #26 0x00005cc60b54ff80 in nsThread::ProcessNextEvent(bool, bool*) (this=0x3dd7f4f3020, aMayWait=<optimized out>, aResult=0x7ffca2653ea7) at /home/emilio/src/moz/gecko/xpcom/threads/nsThread.cpp:1220 #27 0x00005cc60b552f0d in NS_ProcessNextEvent(nsIThread*, bool) (aThread=0x68599020, aMayWait=true) at /home/emilio/src/moz/gecko/xpcom/threads/nsThreadUtils.cpp:481 The parent view may not be set properly if the frame is not current by the time it is created. For example in this case the parent for the root view is non-null and comes from the following MakeWindow call: #0 nsDocumentViewer::MakeWindow(nsSize const&, nsView*) (this=0xc72ca72cd0, aSize=..., aContainerView=0x683ba500) at /home/emilio/src/moz/gecko/layout/base/nsDocumentViewer.cpp:2368 #1 0x00005cc60e789b50 in nsDocumentViewer::InitInternal(nsIWidget*, nsISupports*, mozilla::dom::WindowGlobalChild*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, bool, bool, bool) (this=0xc72ca72cd0, aParentWidget=<optimized out>, aState=0x0, aActor=0x0, aBounds=..., aDoCreation=true, aNeedMakeCX=<optimized out>, aForceSetNewDocument=<optimized out>) at /home/emilio/src/moz/gecko/layout/base/nsDocumentViewer.cpp:933 #2 0x00005cc60e789959 in nsDocumentViewer::Init(nsIWidget*, mozilla::gfx::IntRectTyped<mozilla::gfx::UnknownUnits> const&, mozilla::dom::WindowGlobalChild*) (this=0xc72ca72cd0, aParentWidget=0x7ffca2651020, aBounds=..., aActor=0x7f6216725c00) at /home/emilio/src/moz/gecko/layout/base/nsDocumentViewer.cpp:762 #3 0x00005cc60f4f584f in nsDocShell::SetupNewViewer(nsIContentViewer*, mozilla::dom::WindowGlobalChild*) (this=0x684db000, aNewViewer=<optimized out>, aWindowActor=<optimized out>) at /home/emilio/src/moz/gecko/docshell/base/nsDocShell.cpp:8017 #4 0x00005cc60f4f5204 in nsDocShell::Embed(nsIContentViewer*, mozilla::dom::WindowGlobalChild*) (this=0x684db000, aContentViewer=0x7ffca2651020, aWindowActor=0x683ba500) at /home/emilio/src/moz/gecko/docshell/base/nsDocShell.cpp:5745 #5 0x00005cc60f4dbc7b in nsDocShell::CreateContentViewer(nsTSubstring<char> const&, nsIRequest*, nsIStreamListener**) (this=0x684db000, aContentType=..., aRequest=0x68483080, aContentHandler=<optimized out>) at /home/emilio/src/moz/gecko/docshell/base/nsDocShell.cpp:7819 #6 0x00005cc60f4dab99 in nsDSURIContentListener::DoContent(nsTSubstring<char> const&, bool, nsIRequest*, nsIStreamListener**, bool*) (this=0x683056a0, aContentType=..., aIsContentPreferred=<optimized out>, aRequest=0x68483080, aContentHandler=0xc72c5e8608, aAbortProcess=0x7ffca265139f) at /home/emilio/src/moz/gecko/docshell/base/nsDSURIContentListener.cpp:181 #7 0x00005cc60c2fd8f5 in nsDocumentOpenInfo::TryContentListener(nsIURIContentListener*, nsIChannel*) (this=0xc72c5e85e0, aListener=0x683056a0, aChannel=<optimized out>) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:632 #8 0x00005cc60c2fccd1 in nsDocumentOpenInfo::DispatchContent(nsIRequest*, nsISupports*) (this=0xc72c5e85e0, request=0x68483080, aCtxt=<optimized out>) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:313 #9 0x00005cc60c2fc5aa in nsDocumentOpenInfo::OnStartRequest(nsIRequest*) (this=<optimized out>, request=0x68483080) at /home/emilio/src/moz/gecko/uriloader/base/nsURILoader.cpp:191 #10 0x00005cc60c8975c4 in nsObjectLoadingContent::LoadObject(bool, bool, nsIRequest*) (this=0x4b1b3938b6a8, aNotify=<optimized out>, aForceLoad=<optimized out>, aLoadingChannel=0x68483080) at /home/emilio/src/moz/gecko/dom/base/nsObjectLoadingContent.cpp:2218 #11 0x00005cc60c89681f in nsObjectLoadingContent::OnStartRequest(nsIRequest*) (this=0x4b1b3938b6a8, aRequest=0x68483080) at /home/emilio/src/moz/gecko/dom/base/nsObjectLoadingContent.cpp:1006 #12 0x00005cc60b9d1020 in mozilla::net::HttpChannelChild::DoOnStartRequest(nsIRequest*, nsISupports*) (this=0x68483000, aRequest=0x68483080, aContext=<optimized out>) at /home/emilio/src/moz/gecko/netwerk/protocol/http/HttpChannelChild.cpp:708 #13 0x00005cc60b9d481b in mozilla::net::HttpChannelChild::OnStartRequest(nsresult const&, mozilla::net::nsHttpResponseHead const&, bool const&, mozilla::net::nsHttpHeaderArray const&, mozilla::net::ParentLoadInfoForwarderArgs const&, bool const&, bool const&, bool const&, unsigned long const&, int const&, unsigned int const&, nsTString<char> const&, nsTString<char> const&, mozilla::net::NetAddr const&, mozilla::net::NetAddr const&, unsigned int const&, nsTString<char> const&, long const&, bool const&, bool const&, bool const&, mozilla::net::ResourceTimingStructArgs const&, bool const&, mozilla::Maybe<unsigned int> const&, bool const&, nsILoadInfo::CrossOriginOpenerPolicy const&) However, even though aContainerView is non-null, the view is incorrect, it's the view for the _old_ frame. The view parent/child relationship gets cleared properly in: #1 0x00005cc60e8e82bf in BeginSwapDocShellsForViews (aSibling=0x0) at /home/emilio/src/moz/gecko/layout/generic/nsSubDocumentFrame.cpp:1027 warning: Source file is more recent than executable. #2 0x00005cc60e8e810b in nsSubDocumentFrame::DestroyFrom (this=0x6cd04eaa45a8, aDestructRoot=0x6cd04eaa45a8, aPostDestroyData=...) at /home/emilio/src/moz/gecko/layout/generic/nsSubDocumentFrame.cpp:943 #3 0x00005cc60e7b71a3 in nsIFrame::Destroy (this=0x6cd04eaa45a8) at /home/emilio/src/moz/gecko/layout/generic/nsIFrame.h:657 #4 0x00005cc60e80baac in nsBlockFrame::RemoveFrame (this=0x4b1b39362d88, aListID=<optimized out>, aOldFrame=0x6cd04eaa45a8) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.cpp:5597 #5 0x00005cc60e8df29f in nsPlaceholderFrame::DestroyFrom (this=0x4b1b39363240, aDestructRoot=0x4b1b39363240, aPostDestroyData=...) at /home/emilio/src/moz/gecko/layout/generic/nsPlaceholderFrame.cpp:181 #6 0x00005cc60e80cf19 in nsBlockFrame::DoRemoveFrameInternal (this=<optimized out>, aDeletedFrame=0x0, aFlags=<optimized out>, aPostDestroyData=...) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.cpp:6265 #7 0x00005cc60e82d947 in nsBlockFrame::DoRemoveFrame (this=0x4b1b39362d88, aDeletedFrame=0x683d8f00, aFlags=244338087) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.h:528 #8 0x00005cc60e80ba3a in nsBlockFrame::RemoveFrame (this=0x4b1b39362d88, aListID=<optimized out>, aOldFrame=0x4b1b39363240) at /home/emilio/src/moz/gecko/layout/generic/nsBlockFrame.cpp:5581 #9 0x00005cc60e77fd5c in nsCSSFrameConstructor::ContentRemoved (this=<optimized out>, aChild=0x4b1b3938b600, aOldNextSibling=<optimized out>, aFlags=<optimized out>) at /home/emilio/src/moz/gecko/layout/base/nsCSSFrameConstructor.cpp:7583 #10 0x00005cc60e779a35 in nsCSSFrameConstructor::RecreateFramesForContent (this=0x6fdf9800, aContent=0x4b1b3938b600, aInsertionKind=nsCSSFrameConstructor::InsertionKind::Sync) at /home/emilio/src/moz/gecko/layout/base/nsCSSFrameConstructor.cpp:8593 #11 0x00005cc60e751745 in mozilla::RestyleManager::ProcessRestyledFrames (this=<optimized out>, aChangeList=...) at /home/emilio/src/moz/gecko/layout/base/RestyleManager.cpp:1484 But the temporary state is stored in the _old_ frame-loader, so when we create the new frame, we get to nsSubDocumentFrame::Init, and find nothing, and thus go through nsFrameLoader::Show. But we do have a pres-shell, and nsFrameLoader::Show just early-returns then, and thus we end up with a detached pres shell which is not hooked to the view tree and thus not painted... So there are multiple potential fixes. First (this is the approach this patch takes): * Make nsHideViewer not fail to hide a presentation when the frame loader has changed. This is not an issue per se, but leaves stale views / etc living for too long which is not nice. * Fix up the Show() code path to handle this case properly by parenting the pres-shell and initializing the docshell properly. Second potential fix would be to store the temporary state somewhere else than the frame loader (like the element). This may be a less invasive change somehow, but it looks pretty fishy to me, and not particularly better... Terribly sorry about the lack of test-case, but this is racy as crazy and I had a lot of trouble to even reproduce it in a debug build. This needs the PresShell creation for the subdocument to happen right after setting .data on the <object>, but before processing its reframe. Differential Revision: https://phabricator.services.mozilla.com/D69487

@30fps

Upstream commit: https://webrtc.googlesource.com/src/+/b0cc68e61205fd11a7256a6e85307ec17ad95790 Reduces rate at which TryGetNextFrame returns NULL for WGC This CL is a follow-up of work done in https://webrtc-review.googlesource.com/c/src/+/323882 where the goal was to reduce the amount of FrameDropped error logs in WebRTC.DesktopCapture.Win.WgcCaptureSessionGetFrameResult. The previous work avoids FrameDropped logs for a minimized window being captured with WGC but we still se a large amount of these error (or rather warning) logs. See [1] which comes from Canary. This CL does two different things to improve the situation: 1) It adds kFramePoolEmpty to the existing GetFrameResult::kFrameDropped enum to point out that the warning comes from the frame pool not being able to return a valid new frame. It also makes it more clear that it does not cause an outer/final error as WgcCapturerResult::kFrameDropped. We still keep the inner GetFrameResult::kFrameDropped but it is only produced when the frame pool returns NULL and our external queue is empty. Hence, a real frame-drop error. Note that, it is still easy to provoke kFramePoolEmpty simply by asking for a high resolution at a high rate. The example in [2] comes from a 4K screen @30fps. Hence, we have not fixed anything yet. 2) It also increases the size of the internal frame pool from 1 to 2. This does lead to an almost zero rate of kFramePoolEmpt warnings at the expense of a slightly reduced max capture rate. BUT, with 1 as size, we can "see" a higher max capture rate but it is not a true rate since it comes with a high rate of kFramePoolEmpty errors. Hence, we "emulate" a high capture rate by simply feeding copies of the last frame that we had stored in the external queue. Using 2 leads to a more "true" rate of what we actually can capture in terms of *new* frames and also a substantially lower rate of kFramePoolEmpty. In addition, with 1 as size, if we ask at a too high rate and provide a copy of the last frame, our CPU adaptation will not reduce its rate since we think that things are OK when it is actually not. Also, the samples in [3] and [4] both use 2 as numberOfBuffers as well. Let me also mention that with this small change, I a have not been able to provoke any kFramePoolEmpty error messages. Finally, geDisplayMedia can be called called with constraints where min and max framerate is defined. The mechanism which maintains the min rate is implemented via the RequestRefreshFrame API and it can be sent to the source (DesktopCaptureDevice) back to back with a previous timer interrupt for a capture request. Without this change, these RRFs were also a source of a large amount of kFramePoolEmpty error logs. With 2 buffers instead; this is no longer the case. [1] https://screenshot.googleplex.com/7sfv6HdGXLwyxdj [2] https://paste.googleplex.com/4795680001359872 [3] https://github.com/robmikh/Win32CaptureSample/blob/master/Win32CaptureSample/SimpleCapture.cpp [4] https://learn.microsoft.com/en-us/windows/uwp/audio-video-camera/screen-capture#add-the-screen-capture-capability (cherry picked from commit 4be5927dc788b814dff2a6ca46175254dce59232) Bug: chromium:1314868 Change-Id: I73b823b31a993fd2cd6e007b212826dfe1a80012 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/325521 Commit-Queue: Alexander Cooper <alcooper@chromium.org> Reviewed-by: Alexander Cooper <alcooper@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#41079} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/326960 Commit-Queue: Henrik Andreassson <henrika@webrtc.org> Bot-Commit: rubber-stamper@appspot.gserviceaccount.com <rubber-stamper@appspot.gserviceaccount.com> Reviewed-by: Stefan Holmer <stefan@webrtc.org> Cr-Commit-Position: refs/branch-heads/6099@{#1} Cr-Branched-From: 507f1cc3270d0577f79882acbd78e63e66008f3d-refs/heads/main@{#41042}

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}

Upstream commit: https://webrtc.googlesource.com/src/+/6b419a0536b1a0ccfff3682f997c6f19bcbd9bd8 [M122 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/+/340580 Reviewed-by: Philip Eliasson <philipel@webrtc.org> Commit-Queue: Erik Språng <sprang@webrtc.org> Cr-Commit-Position: refs/branch-heads/6261@{#1} Cr-Branched-From: be2786cd2383b7ec5d158add166275d19e246763-refs/heads/main@{#41596}

…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

…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

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}

@page

…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

dependabot · 2024-06-03T17:20:03Z

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 @dependabot ignore this major version or @dependabot ignore this minor version.

If you change your mind, just re-open this PR and I'll resolve any conflicts on it.

…-worker-reviewers,smaug,profiler-reviewers,aabh,asuth 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

…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

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}

Extend `MacroAssembler::loadFromTypedArray` to support loading from Float16Array. This requires passing an additional temp-register and `LiveRegisterSet` when the target doesn't natively support float32<>float16 conversions. Codegen for `LoadUnboxedScalar` on x86/x64 looks like: movzwl 0x0(%rdx,%rbx,2), %esi vmovd %esi, %xmm0 vpmovzxwq %xmm0, %xmm0 vcvtph2ps %xmm0, %xmm0 vucomiss %xmm0, %xmm0 jnp .Lfrom120 movss .Lfrom128(%rip), %xmm0 And on ARM64: ldr h0, [x2, x3, lsl #1] fcvt s0, h0 fcmp s0, s0 b.vc -> 1015f ldr s0, pc+24 (addr 0x70c2b0a96224) ; .const nan Depends on D215767 Differential Revision: https://phabricator.services.mozilla.com/D215768

Slightly larger changes when compared to the previous two parts, because `MacroAssembler::storeToTypedFloatArray` had to be changed to support conversions instead of performing conversion in its caller: - `CacheIRCompiler::emitStoreTypedArrayElement` used `ScratchFloat32Scope` to convert `double -> float32`, but using the same approach won't work for float16, because `ScratchFloat32Scope` is also needed in `MacroAssembler::storeFloat16` to convert `float32 -> float16`. - Therefore move the conversion `double -> float32` into `StoreToTypedFloatArray` - And the conversions `double -> float16` into `MacroAssembler::storeFloat16`. Codegen for `StoreUnboxedScalar` on x64 looks like: vcvtps2ph $0x4, %xmm0, %xmm15 vmovd %xmm15, %r11d movw %r11w, 0x0(%rdx,%rbx,2) And on ARM64: h31, s0 h31, [x2, x4, lsl #1] Depends on D215769 Differential Revision: https://phabricator.services.mozilla.com/D215770

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}

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}

…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

Upstream commit: https://webrtc.googlesource.com/src/+/21508e08e7545a03c8c35a9299923279e3def319 Fix license metadata for spl_sqrt_floor, portaudio, sigslot (cherry picked from commit 6ea1c96325baada0e6ba0b29456e02f403e15a1e) Bug: b/361140175 Change-Id: I35e76039608fa5094c04ace5f3ad1dba868ccb85 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360900 Reviewed-by: Henrik Andreassson <henrika@webrtc.org> Commit-Queue: Andrew Grieve <agrieve@google.com> Cr-Original-Commit-Position: refs/heads/main@{#42885} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/361520 Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/branch-heads/6668@{#1} Cr-Branched-From: 2cfedb277ae8dd2a8d8dd68aca6f95081c265671-refs/heads/main@{#42810}

Upstream commit: https://webrtc.googlesource.com/src/+/31350c7119fb0e100336e3f22d869e7bd9a0126f [M130] Increase AV1 QP threshold for quality convergence from 40 to 60 Merge approval: https://g-issues.chromium.org/issues/367752722#comment5 (cherry picked from commit e81ba3089755e88292c135733ea187fdd278d858) Bug: chromium:328598314, chromium:367752722 Change-Id: I132b4c30f132ace2bbef6359edd994c1ad75c9ad Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362620 Reviewed-by: Johannes Kron <kron@webrtc.org> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#43035} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/362981 Commit-Queue: Johannes Kron <kron@webrtc.org> Cr-Commit-Position: refs/branch-heads/6723@{#1} Cr-Branched-From: 13e377b804f68aa9c20ea5e449666ea5248e3286-refs/heads/main@{#43019}

…t/last formatted line., a=testonly Automatic update from web-platform-tests [text-box-trim] More spec-compliant first/last formatted line. See https://drafts.csswg.org/css-pseudo-4/#first-text-line 1. For a block container that establishes an inline formatting context, the "first formatted line" is its first line box, if it has one. Otherwise, there is no first formatted line. 2. Otherwise, for a block container that has block children, look inside the first in-flow block child (if any) and do #1 if it establishes an inline formatting context. Otherwise, do #2. In short, we don't need to search for line boxes in blocks after the first block child. If there is no line in the first child, there's no "first formatted line". There's no spec for "last formatted line", but apply the same logic. I.e. if the last block child has no line, there's no "last formatted line". This allows us to simplify things a bit, especially when it comes to re-laying out (kTextBoxTrimEndDidNotApply). The only case where we need this now is for blocks inside inlines: If the last formatted line is inside a block-in-inline, we need to go back and re-lay it out if it turns out to be the last line (which isn't something we can check inside block-in-inline layout). Note: When adding support for block fragmentation, trimming at a fragmentainer's block end will be another case where we need to re-lay out. The motivation for this change was text box trimming inside block fragmentation (upcoming CL), and be able to add support for that and still be reasonably confident that it won't become too complicated. This fixes one existing test. Some other existing tests had to be updated because of this change (they were making incorrect assumptions about first/last formatted line). As a result of that, some new refs had to be added, since other tests were piggy-backing on the same ref. Bug: 40254880, 367766472 Change-Id: I3fcc53af86353725b1f5705a5528493a72bf2e69 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5952979 Commit-Queue: Morten Stenshorne <mstensho@chromium.org> Reviewed-by: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/main@{#1373765} -- wpt-commits: 274bd0d593efebce81292bc6f9a8ca58c578e343 wpt-pr: 48815

dependabot bot added the dependencies Pull requests that update a dependency file label Aug 7, 2023

ErichDonGubler closed this Jun 3, 2024

dependabot bot deleted the dependabot/npm_and_yarn/tools/esmify/json5-2.2.3 branch June 3, 2024 17:20

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Bump json5 from 2.2.1 to 2.2.3 in /tools/esmify #1

Bump json5 from 2.2.1 to 2.2.3 in /tools/esmify #1

dependabot bot commented on behalf of github Aug 7, 2023 •

edited

Loading

dependabot bot commented on behalf of github Jun 3, 2024

Bump json5 from 2.2.1 to 2.2.3 in /tools/esmify #1

Bump json5 from 2.2.1 to 2.2.3 in /tools/esmify #1

Conversation

dependabot bot commented on behalf of github Aug 7, 2023 • edited Loading

v2.2.3

v2.2.2

v2.2.3 [code, diff]

v2.2.2 [code, diff]

dependabot bot commented on behalf of github Jun 3, 2024

dependabot bot commented on behalf of github Aug 7, 2023 •

edited

Loading