Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bug 911098 - Implement addon dubugger UI #3

Closed
wants to merge 2 commits into from

Conversation

Gozala
Copy link
Contributor

@Gozala Gozala commented Jan 14, 2014

Note: This is just for a review, not for actually merging in.

// Assume that if there's a `harness-options.json` file in restartless add-on
// it's a jetpack.
return this.isBootstrapped && this.hasResource("harness-options.json");
});
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@Mossop I believe @erikvold is going to expose isJetpack for native jetpacks anyway, so is there point in delaying it ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd like Blair to review any API addition here.

On Thu, Jan 23, 2014 at 3:01 PM, Irakli Gozalishvili <
notifications@github.com> wrote:

In toolkit/mozapps/extensions/XPIProvider.jsm:

@@ -6594,6 +6594,22 @@ function AddonWrapper(aAddon) {
return ops;
});

  • this.defineGetter("isBootstrapped", function AddonWrapper_isBootstrapped() {
  • return this.operationsRequiringRestart === AddonManager.OP_NEEDS_RESTART_NONE;
  • });
  • this.defineGetter("isJetpack", function AddonWrapper_isJetpack() {
  • // Assume that if there's a harness-options.json file in restartless add-on
  • // it's a jetpack.
  • return this.isBootstrapped && this.hasResource("harness-options.json");
  • });

@Mossop https://github.com/Mossop I believe @erikvoldhttps://github.com/erikvoldis going to expose
isJetpack for native jetpacks anyway, so is there point in delaying it ?


Reply to this email directly or view it on GitHubhttps://github.com//pull/3/files#r9134079
.

@erikvold
Copy link
Contributor

erikvold commented Feb 5, 2014

I believe @erikvold is going to expose isJetpack for native jetpacks anyway, so is there point in delaying it ?

@Mossop @Gozala that is part of the plan

hwine pushed a commit that referenced this pull request Feb 11, 2014
========

https://hg.mozilla.org/integration/gaia-central/rev/3c7ae072e684
Author: Kyle Machulis <kyle@nonpolynomial.com>
Desc: Merge pull request #16096 from qdot/969650-move-customization-sample-to-gaia

Bug 969650 - Add customization sample to gaia

========

https://hg.mozilla.org/integration/gaia-central/rev/8715b511cbd5
Author: Kyle Machulis <kyle@nonpolynomial.com>
Desc: Bug 969950 - Cleaning up distribution sample

========

https://hg.mozilla.org/integration/gaia-central/rev/de97a5d865ef
Author: Kyle Machulis <kyle@nonpolynomial.com>
Desc: Bug 969650 - Subtree merge of yurenju/gaia-distribution-sample

========

https://hg.mozilla.org/integration/gaia-central/rev/eb9ae9a4503f
Author: Yuren Ju <yurenju@gmail.com>
Desc: Merge pull request #3 from jds2501/simbookmarks

Update SIM bookmark customization to include sample mcc mnc US SIM customization, r=@yurenju

========

https://hg.mozilla.org/integration/gaia-central/rev/705efd9c2fcd
Author: jds2501 <jsmith@mozilla.com>
Desc: Update SIM bookmark customization to include sample mcc mnc US SIM customization

========

https://hg.mozilla.org/integration/gaia-central/rev/72e64b8de4b1
Author: Yuren Ju <yurenju@gmail.com>
Desc: Merge pull request #2 from KevinGrandon/master

Add calendar.json r=yurenju

========

https://hg.mozilla.org/integration/gaia-central/rev/56feb8a57eb1
Author: Kevin Grandon <kevingrandon@yahoo.com>
Desc: Add calendar.json

========

https://hg.mozilla.org/integration/gaia-central/rev/90aef8c4de58
Author: gasolin <gasolin@gmail.com>
Desc: Create README.md

========

https://hg.mozilla.org/integration/gaia-central/rev/8f96ae99b519
Author: Yuren Ju <yurenju@gmail.com>
Desc: Merge pull request #1 from gasolin/patch-1

add runtime customize for bookmark setting, r=yurenju

========

https://hg.mozilla.org/integration/gaia-central/rev/80285b122244
Author: gasolin <gasolin@gmail.com>
Desc: add runtime customize for bookmark setting

========

https://hg.mozilla.org/integration/gaia-central/rev/4e64191b5493
Author: Yuren Ju <yurenju@gmail.com>
Desc: Initial commit
irvingreid pushed a commit to Nephyrin/mozilla-git that referenced this pull request Apr 29, 2014
vagouzhou added a commit to vagouzhou/gecko-dev that referenced this pull request Aug 10, 2014
@edmorley
Copy link

(Mass-PR-close)
This PR is against gecko-dev, which is read only. Did you mean to submit it against another repo?
Changes to repos covered by gecko-dev must be made to the hg.mozilla.org repo, which is then mirrored here. Please see:
https://developer.mozilla.org/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F

@edmorley edmorley closed this Aug 19, 2014
martinthomson pushed a commit to martinthomson/gecko-dev that referenced this pull request Sep 17, 2014
walac pushed a commit to walac/gecko-dev that referenced this pull request Oct 22, 2014
hwine pushed a commit that referenced this pull request Jan 12, 2015
… fires, causing orange. r=orange

Example stack, from editor/libeditor/tests/browserscope/test_richtext2.html :

###!!! ASSERTION: should only call on first continuation/ib-sibling: 'nsLayoutUtils::IsFirstContinuationOrIBSplitSibling(this)', file /builds/slave/m-in-l64-d-0000000000000000000/build/src/layout/base/../generic/nsIFrame.h, line 875
#01: AdjustAppendParentForAfterContent [layout/base/nsCSSFrameConstructor.cpp:6059]
#2: nsCSSFrameConstructor::ContentAppended(nsIContent*, nsIContent*, bool) [layout/base/nsCSSFrameConstructor.cpp:7155]
#3: PresShell::ContentAppended(nsIDocument*, nsIContent*, nsIContent*, int) [layout/base/nsPresShell.cpp:4520]
#4: nsNodeUtils::ContentAppended(nsIContent*, nsIContent*, int) [dom/base/nsNodeUtils.cpp:132]
#5: nsINode::doInsertChildAt(nsIContent*, unsigned int, bool, nsAttrAndChildArray&) [dom/base/nsINode.cpp:1544]
#6: nsINode::ReplaceOrInsertBefore(bool, nsINode*, nsINode*, mozilla::ErrorResult&) [dom/base/nsINode.cpp:2209]
#7: mozilla::dom::NodeBinding::appendChild [obj-firefox/dom/bindings/NodeBinding.cpp:600]
rainemak pushed a commit to rainemak/gecko-dev-mirror that referenced this pull request Mar 27, 2015
Limit the area of the surface rather than width and height
rocallahan added a commit that referenced this pull request Jul 7, 2015
…ical

Otherwise we can get a crash with the following stack:

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 14711]
0x5d99974e in mozilla::gl::GLContext::BeforeGLCall (this=0x6dbf0800,
    funcName=0x60f251a4 <mozilla::gl::GLContext::raw_fDeleteProgram(unsigned int)::__PRETTY_FUNCTION__> "void mozilla::gl::GLContext::raw_fDeleteProgram(GLuint)") at /home/roc/mozilla-inbound/gfx/gl/GLContext.h:683
683	        MOZ_ASSERT(IsCurrent());
(gdb) where
#0  0x5d99974e in mozilla::gl::GLContext::BeforeGLCall (this=0x6dbf0800,
    funcName=0x60f251a4 <mozilla::gl::GLContext::raw_fDeleteProgram(unsigned int)::__PRETTY_FUNCTION__> "void mozilla::gl::GLContext::raw_fDeleteProgram(GLuint)") at /home/roc/mozilla-inbound/gfx/gl/GLContext.h:683
#1  0x5d99bed6 in mozilla::gl::GLContext::raw_fDeleteProgram (this=0x6dbf0800, program=210003)
    at /home/roc/mozilla-inbound/gfx/gl/GLContext.h:2232
#2  0x5d99c10a in mozilla::gl::GLContext::fDeleteProgram (this=0x6dbf0800, program=210003)
    at /home/roc/mozilla-inbound/gfx/gl/GLContext.h:2270
#3  0x5daa0ae6 in mozilla::layers::ShaderProgramOGL::~ShaderProgramOGL (this=0x6d7df000, __in_chrg=<optimized out>)
    at /home/roc/mozilla-inbound/gfx/layers/opengl/OGLShaderProgram.cpp:491
#4  0x5da86bdc in mozilla::layers::CompositorOGL::CleanupResources (this=0x67ae4d70)
    at /home/roc/mozilla-inbound/gfx/layers/opengl/CompositorOGL.cpp:177

--HG--
extra : commitid : LPnSogXNNio
extra : rebase_source : 0564dd5688916271c4a709ae6f15ba7ad493a761
weilonge referenced this pull request in weilonge/gecko-dev Nov 10, 2015
CloudStorageServiceAPI and CloudStorageManager integration
JuniorHsu pushed a commit to JuniorHsu/gecko-dev that referenced this pull request Jun 1, 2016
Bug 1270701-Draw a cursor when a mouse is being used; a=jocheng
moz-v2v-gh pushed a commit that referenced this pull request Jun 29, 2016
Masayuki suggests GetCharcterRectsInRange instead of first idea's API by part 2 implementation.

IME wants to need the width per character.  Now nsTextFrame/nsIFrmae has only API to get point of string.  So I want to add this method to calculate simply by comment #3.

If no text frame,  I would like to return error due to no character.  (Caller shouldn't call this API on non-text frame.)

MozReview-Commit-ID: LQHUTzhnGn

--HG--
extra : rebase_source : bc495493c7be73afb05489ad2169e8dcdd6e6da4
extra : histedit_source : e54a7c3bfb100765317a0c8a83b432d5f706ffe1
moz-v2v-gh pushed a commit that referenced this pull request Aug 15, 2016
…dle the case when queried range starts from the end of mRootContent r=smaug

First, when the first node causing text is invisible, OnQueryTextRect() still fails even with this patch. We shouldn't fix it in this bug because it's unusual case but this bug is very important especially for some web service using HTML editor like Gmail.

This patch fixes all cases when the start offset of queried range reaches the end of mRootContent.

1. When the last node causing text is a <br> element (either content <br> element or moz-<br> element), its frame is a placeholder for empty line.  Therefore, this patch sets the rect to the frame rect.

2. When the last node causing text is a text node, the last frame generated for it represents its line (including empty line).  Therefore, this patch sets the rect to the result of GetLineBreakerRectAfter().

3. When the last node causes a line breaker before it, the frame may be a placeholder for it (this is not usual case, when user types Enter key at the end of <p> element, <p><br></p> is generated by Gecko).  In this case, this patch sets a possible caret rect which is guessed from the content box of the frame and its font height.

4. When there are no nodes causing text in mRootContent, this patch sets a possible caret rect like case #3.

MozReview-Commit-ID: FS9cWJQ39DK

--HG--
extra : rebase_source : cb2ea4cfb4c8d5c85a4dd7498aa11bd86b61c2ef
JamesWCCheng pushed a commit to JamesWCCheng/gecko-dev that referenced this pull request Aug 16, 2016
…dle the case when queried range starts from the end of mRootContent r=smaug

First, when the first node causing text is invisible, OnQueryTextRect() still fails even with this patch. We shouldn't fix it in this bug because it's unusual case but this bug is very important especially for some web service using HTML editor like Gmail.

This patch fixes all cases when the start offset of queried range reaches the end of mRootContent.

1. When the last node causing text is a <br> element (either content <br> element or moz-<br> element), its frame is a placeholder for empty line.  Therefore, this patch sets the rect to the frame rect.

2. When the last node causing text is a text node, the last frame generated for it represents its line (including empty line).  Therefore, this patch sets the rect to the result of GetLineBreakerRectAfter().

3. When the last node causes a line breaker before it, the frame may be a placeholder for it (this is not usual case, when user types Enter key at the end of <p> element, <p><br></p> is generated by Gecko).  In this case, this patch sets a possible caret rect which is guessed from the content box of the frame and its font height.

4. When there are no nodes causing text in mRootContent, this patch sets a possible caret rect like case mozilla#3.

MozReview-Commit-ID: FS9cWJQ39DK
kuoe0 pushed a commit to kuoe0/gecko-dev that referenced this pull request Aug 17, 2016
…dle the case when queried range starts from the end of mRootContent r=smaug

First, when the first node causing text is invisible, OnQueryTextRect() still fails even with this patch. We shouldn't fix it in this bug because it's unusual case but this bug is very important especially for some web service using HTML editor like Gmail.

This patch fixes all cases when the start offset of queried range reaches the end of mRootContent.

1. When the last node causing text is a <br> element (either content <br> element or moz-<br> element), its frame is a placeholder for empty line.  Therefore, this patch sets the rect to the frame rect.

2. When the last node causing text is a text node, the last frame generated for it represents its line (including empty line).  Therefore, this patch sets the rect to the result of GetLineBreakerRectAfter().

3. When the last node causes a line breaker before it, the frame may be a placeholder for it (this is not usual case, when user types Enter key at the end of <p> element, <p><br></p> is generated by Gecko).  In this case, this patch sets a possible caret rect which is guessed from the content box of the frame and its font height.

4. When there are no nodes causing text in mRootContent, this patch sets a possible caret rect like case mozilla#3.

MozReview-Commit-ID: FS9cWJQ39DK
moz-v2v-gh pushed a commit that referenced this pull request May 20, 2017
Add in endpoints for modal dialog support

Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 83b4de3af8ac59ae394d74f64280b3b69d8a3594

--HG--
extra : rebase_source : a3237e8c0d5d5c82360a2835da31a7ac59fa0592
aethanyc pushed a commit to aethanyc/gecko-dev that referenced this pull request May 21, 2017
Add in endpoints for modal dialog support

Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 83b4de3af8ac59ae394d74f64280b3b69d8a3594
kuoe0 pushed a commit to kuoe0/gecko-dev that referenced this pull request May 24, 2017
Add in endpoints for modal dialog support

Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 83b4de3af8ac59ae394d74f64280b3b69d8a3594
JerryShih pushed a commit to JerryShih/gecko-dev that referenced this pull request May 25, 2017
Add in endpoints for modal dialog support

Source-Repo: https://github.com/mozilla/geckodriver
Source-Revision: 83b4de3af8ac59ae394d74f64280b3b69d8a3594
leobalter added a commit to leobalter/gecko-dev that referenced this pull request Jul 20, 2017
# This is the 1st commit message:

Test262 export script

# The commit message #2 will be skipped:

# mock files

# The commit message mozilla#3 will be skipped:

# update reportCompare

# The commit message mozilla#4 will be skipped:

# mock files

# The commit message mozilla#5 will be skipped:

# remove debug

# The commit message mozilla#6 will be skipped:

# mock files

# The commit message mozilla#7 will be skipped:

# capturing reftest directives

# The commit message mozilla#8 will be skipped:

# add todos

# The commit message mozilla#9 will be skipped:

# add todos

# The commit message mozilla#10 will be skipped:

# reportCompare is property parsed
moz-v2v-gh pushed a commit that referenced this pull request Nov 18, 2017
… r=Pike

MozReview-Commit-ID: IHhE3xg3nb0

--HG--
extra : rebase_source : 3135b6d5c716e1359ad7fc5ae21d6885e9918543
aethanyc pushed a commit to aethanyc/gecko-dev that referenced this pull request Nov 20, 2017
…ng in 0 r=Pike

MozReview-Commit-ID: IHhE3xg3nb0
JerryShih pushed a commit to JerryShih/gecko-dev that referenced this pull request Nov 21, 2017
…ng in 0 r=Pike

MozReview-Commit-ID: IHhE3xg3nb0
daoshengmu pushed a commit to daoshengmu/gecko-dev that referenced this pull request Nov 21, 2017
…ng in 0 r=Pike

MozReview-Commit-ID: IHhE3xg3nb0
moz-v2v-gh pushed a commit that referenced this pull request Dec 8, 2017
…the last page was processed. r=jwatt

For the last page, here is the final three messages sent between the content
process, RemotePrintJobChild, and the chrome process, RemotePrintJobParent, for
printing:
1. The content process sends *ProcessPage* to the chrome process via
   SendProcessPrint to request the chrome process print the last page.
2. The content process sends *FinalizePrint* to the chrome process via
   SendFinalizePrint to notify the chrome that there are no more outstanding
   print requests, and that the chrome process can release interal resource
   now.
3. The content process receive PageProcessed message from the chrome process.

This calling sequence is fine for sync style PrintTarget (even though the
FinalizePrint message is sent out a bit ealy). Since a sync PrintTarget
completes its print task right after receiving *ProcessPage* message in #1,
sending FinalizePrint before getting PageProcessed response is harmless.

But this message dispatching sequence does cause a problem for async style
PrintTargetEMF. After getting a message sent in #2, PrintTargetEMF release all
resources before getting a EMF conversion response from the PDFium process. So
the last page can not be printed correctly. This patch reorder the #2 and #3
message, that is to send FinalizePrint after the content process received
PageProcessed message of the last page.

MozReview-Commit-ID: 9ZVSrFnuHBU

--HG--
extra : rebase_source : d12161e1c8ac6469fc1ecb9514939bd35979d573
extra : source : 70ce23becf8840408cd72e7f933a167090519c09
moz-v2v-gh pushed a commit that referenced this pull request Feb 15, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/363e17b7f5a68fba6e1327831631aace7a9e8706
    [Merge-108] [Stats] Update totalPacketSendDelay to only cover time in pacer queue.

    This metric was always supposed to be the spec's answer to
    googBucketDelay, and is defined as "The total number of seconds that
    packets have spent buffered locally before being transmitted onto the
    network." But our implementation measured the time between capture and
    send, including encode time. This is incorrect and yields a much larger
    value than expected.

    This CL updated the metric to do what the spec says. Implementation-wise
    we measure the time between pushing and popping each packet from the
    queue (in modules/pacing/prioritized_packet_queue.cc).

    The spec says to increment the delay counter at the same time as we
    increment the packet counter in order for the app to be able to do
    "delta totalPacketSendDelay / delta packetSent". For this reason,
    `total_packet_delay` is added to RtpPacketCounter. (Previously, the
    two counters were incremented on different threads and observers.)

    Running Google Meet on a good network, I could observe a 2-3 ms average
    send delay per packet with this implementation compared to 20-30 ms
    with the old implementation. See b/137014977#comment170 for comparison
    with googBucketDelay which is a little bit different by design -
    totalPacketSendDelay is clearly better than googBucketDelay.

    Since none of this depend on the media kind, we can wire up this metric
    for audio as well in a follow-up:
    https://webrtc-review.googlesource.com/c/src/+/280523

    (cherry picked from commit d81992197c9e31d9009a0c6ee9d3862479773c06)

    Bug: webrtc:14593, chromium:1378895
    Change-Id: If8fcd82fee74030d0923ee5df2c2aea2264600d4
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/280443
    Reviewed-by: Erik Språng <sprang@webrtc.org>
    Commit-Queue: Henrik Boström <hbos@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#38480}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/281160
    Reviewed-by: Harald Alvestrand <hta@webrtc.org>
    Cr-Commit-Position: refs/branch-heads/5359@{#3}
    Cr-Branched-From: fb3bd4a01d7c840dfe7b3efa144c0fbcb6a97fef-refs/heads/main@{#38387}
moz-v2v-gh pushed a commit that referenced this pull request Mar 13, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/4e8a5ac68e8a4ae0588f54f2fdb8cbd1eb5fa50d
    [M109][TurnPort] Check if a matching connection exists before replying.

    Add an override to TurnPort for SendBindingErrorResponse to check
    if a matching connection object exists before continuing. This is
    needed to match with the check in `TurnPort::DispatchPacket` whereby
    we forward calls to `Port` when no matching connections exist.

    (cherry picked from commit 29464b06c50316d8f16c8f5687117cb93a1f376b)

    Bug: chromium:1395625
    Change-Id: Idf1f898c2a93de6bc2832268db1cadd52cae23a9
    No-Try: true
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/287223
    Reviewed-by: Sameer Vijaykar <samvi@google.com>
    Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#38871}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/288560
    Reviewed-by: Harald Alvestrand <hta@webrtc.org>
    Cr-Commit-Position: refs/branch-heads/5414@{#3}
    Cr-Branched-From: a3e51df5f3377bee71b4dcdd1ee8f50c520a9ea8-refs/heads/main@{#38608}
moz-v2v-gh pushed a commit that referenced this pull request Apr 11, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/36b2ad31c8d06c9cbc0d7ec7331b466031d010cb
    Zero extra bytes of FEC recovered packet

    rtc::CopyOnWriteBuffer::SetSize extends buffer with uninitialized memory by design.
    It is up to the user of the rtc::CopyOnWriteBuffer to ensure it is initialized.

    (cherry picked from commit f52e0152397cda785ff311394d8275f210bd5a20)

    No-Try: true
    Bug: chromium:1403397
    Change-Id: Ic0111a84bda32379770ddb1c7d24bee10d96b7a4
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/289041
    Reviewed-by: Rasmus Brandt <brandtr@webrtc.org>
    Commit-Queue: Danil Chapovalov <danilchap@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#38959}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/291540
    Reviewed-by: Per Kjellander <perkj@webrtc.org>
    Cr-Commit-Position: refs/branch-heads/5481@{#3}
    Cr-Branched-From: 2e1a9a4ae0234d4b1ea7a6fd4188afa1fb20379d-refs/heads/main@{#38901}
moz-v2v-gh pushed a commit that referenced this pull request May 12, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/416bc06a6aa3735e33edcec5c1ffb68beb310924
    Disable stop CNG after a timeout.

    This is still a behavior that we want, but a more careful rollout is needed.

    (cherry picked from commit 48d784225972b7dd0542acfad7cd2d0eed25ad1c)

    No-Try: True
    Bug: webrtc:12790, chromium:1418687
    Change-Id: Ic74c7b4945c0cdeda2b17f52301069424ad91162
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/293860
    Commit-Queue: Jakob Ivarsson‎ <jakobi@webrtc.org>
    Reviewed-by: Henrik Lundin <henrik.lundin@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#39333}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294760
    Reviewed-by: Alessio Bazzica <alessiob@webrtc.org>
    Cr-Commit-Position: refs/branch-heads/5563@{#3}
    Cr-Branched-From: 6c032cb8356b0d3f717c4fcf50796241f2bba6c2-refs/heads/main@{#39207}
ChunMinChang added a commit to ChunMinChang/gecko-dev that referenced this pull request Jun 2, 2023
```js
let lastDequeueSize = Infinity;
decoder.ondequeue = () => {
  assert_greater_than(lastDequeueSize, 0, "Dequeue event after queue empty");
  assert_greater_than(lastDequeueSize, decoder.decodeQueueSize,
                      "Dequeue event without decreased queue size");
  lastDequeueSize = decoder.decodeQueueSize;
};
```

The above checkes doesn't really work since the VideoDecoder's
codec-work-queue runs in parallel with the VideoDecoder interface. The
dequeue events can arrive after the last dequeue size has been 0 if the
work queue decodes multiple samples while VideoDecoder is processing
just one dequeue event. Besides, `decodeQueueSize` can change between
the two `decoder.decodeQueueSize` calls since it can be mutated on both
VideoDecoder's owner thread and the codec-work-queue thread. As a
result, these two `decodeQueueSize` can be different, and the
`lastDequeueSize` is not guaranteed to be decreased one at a time per
event, even if the internal decodeQueueSize is decreased one at a time
(on codec-work-queue thread). The value can be decreased more than one
at a time.

The following example demonstrates one case when those checks can fail.

Suppose VideoDecoder *D* runs on thread *T* (main or worker) and
codec-work-queue runs on thread *Q*. In the test, by the time
VideoDecoder is `configure`d successfully and `decode` request are sent,
the codec-work-queue is ready to `decode` the pending samples. Below
illustrates why the wpt checks in the begining don't work

Q) The underlying codec is configured, ready to decode sample #1.
   Schedule a dequeue event. The current queue size is 9.
T) Get a dequeue event #1. Now D.decodeQueueSize is 9.
Q) Decode sample #1 succeeded, ready to decode sample mozilla#2. Schedule a
   dequeue event. The current queue size is 8.
T) `D.decode()` for sample #1 succeeded. Get VideoFrame #1.
T) Get a dequeue event mozilla#2. Now D.decodeQueueSize is 8.
Q) Decode sample mozilla#2 succeeded, ready to decode sample mozilla#3. Schedule a
   dequeue event. The current queue size is 7.
T) `D.decode()` for sample mozilla#2 succeeded. Get VideoFrame mozilla#2.
Q) Decode sample mozilla#3 succeeded, ready to decode sample mozilla#4. Schedule a
   dequeue event. The current queue size is 6.
Q) Decode sample mozilla#4 succeeded, ready to decode sample mozilla#5. Schedule a
   dequeue event. The current queue size is 5.
T) Get a dequeue event mozilla#3. Now D.decodeQueueSize is 5.
T) `D.decode()` for sample mozilla#3 succeeded. Get VideoFrame mozilla#3.
T) Get a dequeue event mozilla#4. Now D.decodeQueueSize is 5.
   => "Dequeue event without decreased queue size" fails here
Q) Decode sample mozilla#5 succeeded, ready to decode sample mozilla#6. Schedule a
   dequeue event. The current queue size is 4.
Q) Decode sample mozilla#6 succeeded, ready to decode sample mozilla#7. Schedule a
   dequeue event. The current queue size is 3.
Q) Decode sample mozilla#7 succeeded, ready to decode sample mozilla#8. Schedule a
   dequeue event. The current queue size is 2.
T) `D.decode()` for sample mozilla#4 succeeded. Get VideoFrame mozilla#4.
T) Get a dequeue event mozilla#5. Now D.decodeQueueSize is 2.
T) `D.decode()` for sample mozilla#5 succeeded. Get VideoFrame mozilla#5.
T) Get a dequeue event mozilla#6. Now D.decodeQueueSize is 2.
   => "Dequeue event without decreased queue size" fails again here
Q) Decode sample mozilla#8 succeeded, ready to decode sample mozilla#9. Schedule a
   dequeue event. The current queue size is 1.
T) `D.decode()` for sample mozilla#6 succeeded. Get VideoFrame mozilla#6.
Q) Decode sample mozilla#9 succeeded, ready to decode sample mozilla#10. Schedule a
   dequeue event. The current queue size is 0.
T) Get a dequeue event mozilla#7. Now D.decodeQueueSize is 0.
T) `D.decode()` for sample mozilla#7 succeeded. Get VideoFrame mozilla#7.
T) Get a dequeue event mozilla#8. D.decodeQueueSize is still 0.
   => "Dequeue event after queue empty" fails here
   => "Dequeue event without decreased queue size" fails here as well

In brief, what VideoDecoder can guarantee are the order of dequeue
event, decode() result, and the flush() result:

1. For sample #N, its dequeue event arrives before it's decode()
   callback
2. The results/callbacks of decode() and flush() are arrived in FIFO
   order

There is no guarantee that `decodeQueueSize` read on the VideoDecoder's
owner thread only decrease one per dequeue event. If the
codec-work-queue decodes sample #1, mozilla#2, ... , #K while the dequeue event
for sample #1 is being dispatched to or handled on the VideoDecoder's
owner thread, the last-dequeueQueueSize can drop more than one compared
to it's previous value, and for the same reason, the dequeue event can
arrive even if the last-dequeueQueueSize has been set to 0.

Differential Revision: https://phabricator.services.mozilla.com/D179514
ChunMinChang added a commit to ChunMinChang/gecko-dev that referenced this pull request Jun 5, 2023
```js
let lastDequeueSize = Infinity;
decoder.ondequeue = () => {
  assert_greater_than(lastDequeueSize, 0, "Dequeue event after queue empty");
  assert_greater_than(lastDequeueSize, decoder.decodeQueueSize,
                      "Dequeue event without decreased queue size");
  lastDequeueSize = decoder.decodeQueueSize;
};
```

The above checkes doesn't really work since the VideoDecoder's
codec-work-queue runs in parallel with the VideoDecoder interface. The
dequeue events can arrive after the last dequeue size has been 0 if the
work queue decodes multiple samples while VideoDecoder is processing
just one dequeue event. Besides, `decodeQueueSize` can change between
the two `decoder.decodeQueueSize` calls since it can be mutated on both
VideoDecoder's owner thread and the codec-work-queue thread. As a
result, these two `decodeQueueSize` can be different, and the
`lastDequeueSize` is not guaranteed to be decreased one at a time per
event, even if the internal decodeQueueSize is decreased one at a time
(on codec-work-queue thread). The value can be decreased more than one
at a time.

The following example demonstrates one case when those checks can fail.

Suppose VideoDecoder *D* runs on thread *T* (main or worker) and
codec-work-queue runs on thread *Q*. In the test, by the time
VideoDecoder is `configure`d successfully and `decode` request are sent,
the codec-work-queue is ready to `decode` the pending samples. Below
illustrates why the wpt checks in the begining don't work

Q) The underlying codec is configured, ready to decode sample #1.
   Schedule a dequeue event. The current queue size is 9.
T) Get a dequeue event #1. Now D.decodeQueueSize is 9.
Q) Decode sample #1 succeeded, ready to decode sample mozilla#2. Schedule a
   dequeue event. The current queue size is 8.
T) `D.decode()` for sample #1 succeeded. Get VideoFrame #1.
T) Get a dequeue event mozilla#2. Now D.decodeQueueSize is 8.
Q) Decode sample mozilla#2 succeeded, ready to decode sample mozilla#3. Schedule a
   dequeue event. The current queue size is 7.
T) `D.decode()` for sample mozilla#2 succeeded. Get VideoFrame mozilla#2.
Q) Decode sample mozilla#3 succeeded, ready to decode sample mozilla#4. Schedule a
   dequeue event. The current queue size is 6.
Q) Decode sample mozilla#4 succeeded, ready to decode sample mozilla#5. Schedule a
   dequeue event. The current queue size is 5.
T) Get a dequeue event mozilla#3. Now D.decodeQueueSize is 5.
T) `D.decode()` for sample mozilla#3 succeeded. Get VideoFrame mozilla#3.
T) Get a dequeue event mozilla#4. Now D.decodeQueueSize is 5.
   => "Dequeue event without decreased queue size" fails here
Q) Decode sample mozilla#5 succeeded, ready to decode sample mozilla#6. Schedule a
   dequeue event. The current queue size is 4.
Q) Decode sample mozilla#6 succeeded, ready to decode sample mozilla#7. Schedule a
   dequeue event. The current queue size is 3.
Q) Decode sample mozilla#7 succeeded, ready to decode sample mozilla#8. Schedule a
   dequeue event. The current queue size is 2.
T) `D.decode()` for sample mozilla#4 succeeded. Get VideoFrame mozilla#4.
T) Get a dequeue event mozilla#5. Now D.decodeQueueSize is 2.
T) `D.decode()` for sample mozilla#5 succeeded. Get VideoFrame mozilla#5.
T) Get a dequeue event mozilla#6. Now D.decodeQueueSize is 2.
   => "Dequeue event without decreased queue size" fails again here
Q) Decode sample mozilla#8 succeeded, ready to decode sample mozilla#9. Schedule a
   dequeue event. The current queue size is 1.
T) `D.decode()` for sample mozilla#6 succeeded. Get VideoFrame mozilla#6.
Q) Decode sample mozilla#9 succeeded, ready to decode sample mozilla#10. Schedule a
   dequeue event. The current queue size is 0.
T) Get a dequeue event mozilla#7. Now D.decodeQueueSize is 0.
T) `D.decode()` for sample mozilla#7 succeeded. Get VideoFrame mozilla#7.
T) Get a dequeue event mozilla#8. D.decodeQueueSize is still 0.
   => "Dequeue event after queue empty" fails here
   => "Dequeue event without decreased queue size" fails here as well

In brief, what VideoDecoder can guarantee are the order of dequeue
event, decode() result, and the flush() result:

1. For sample #N, its dequeue event arrives before it's decode()
   callback
2. The results/callbacks of decode() and flush() are arrived in FIFO
   order

There is no guarantee that `decodeQueueSize` read on the VideoDecoder's
owner thread only decrease one per dequeue event. If the
codec-work-queue decodes sample #1, mozilla#2, ... , #K while the dequeue event
for sample #1 is being dispatched to or handled on the VideoDecoder's
owner thread, the last-dequeueQueueSize can drop more than one compared
to it's previous value, and for the same reason, the dequeue event can
arrive even if the last-dequeueQueueSize has been set to 0.

Differential Revision: https://phabricator.services.mozilla.com/D179514

Depends on D177212
moz-v2v-gh pushed a commit that referenced this pull request Jul 7, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/a1ceae206bd1993f9a2e2c6983cf3496afbf4e35
    Implement support for Chrome task origin tracing. #3.5/4

    This CL migrates unit tests to the new TaskQueueBase interface.

    Bug: chromium:1416199
    Change-Id: Ic15c694b28eb67450ac99fdd56754de1246a4d95
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295621
    Commit-Queue: Markus Handell <handellm@webrtc.org>
    Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
    Reviewed-by: Harald Alvestrand <hta@webrtc.org>
    Cr-Commit-Position: refs/heads/main@{#39434}
moz-v2v-gh pushed a commit that referenced this pull request Jul 7, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/c0f881387046912ddac62ee5c57b7f3024cd86f6
    Implement support for Chrome task origin tracing. #3.6/4

    This CL migrates the task queue paced sender unit test
    to the new TaskQueueBase interface.

    Bug: chromium:1416199
    Change-Id: Id0568bb9a08bf43b92e33fdf45fe75a57e5a7a27
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295722
    Reviewed-by: Harald Alvestrand <hta@webrtc.org>
    Commit-Queue: Markus Handell <handellm@webrtc.org>
    Cr-Commit-Position: refs/heads/main@{#39436}
moz-v2v-gh pushed a commit that referenced this pull request Jul 7, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/ae61aca9b175e9cb5adadf41ab1a7254a57d7afc
    Implement support for Chrome task origin tracing. #3.7/4

    This CL completes migration to the new TaskQueueBase interface
    permitting location tracing in Chrome.

    Bug: chromium:1416199
    Change-Id: Iff7ff5796752a1520384a3db0135a1d4b9438988
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/294540
    Reviewed-by: Harald Alvestrand <hta@webrtc.org>
    Commit-Queue: Markus Handell <handellm@webrtc.org>
    Reviewed-by: Danil Chapovalov <danilchap@webrtc.org>
    Cr-Commit-Position: refs/heads/main@{#39439}
moz-v2v-gh pushed a commit that referenced this pull request Jul 7, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/fb727f3a5f530db428cf3a13a909ef6cbd580528
    Implement support for Chrome task origin tracing. #3.9/4

    This CL forwards repeating task client locations to the passed
    task queue.

    Bug: chromium:1416199
    Change-Id: I437d596f8d327d13498b47dfc0a03812af870331
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295623
    Reviewed-by: Harald Alvestrand <hta@webrtc.org>
    Commit-Queue: Markus Handell <handellm@webrtc.org>
    Cr-Commit-Position: refs/heads/main@{#39443}
moz-v2v-gh pushed a commit that referenced this pull request Jul 7, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/2fa39bdfc98d1658144eaa6382a365b2c2a3506f
    Implement support for Chrome task origin tracing. #3.8/4

    This CL forwards TaskQueue locations to the contained
    task queue.

    Bug: chromium:1416199
    Change-Id: I989ae445a67991bf5a857407135dbe8bacbd3c55
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/295622
    Reviewed-by: Harald Alvestrand <hta@webrtc.org>
    Commit-Queue: Markus Handell <handellm@webrtc.org>
    Cr-Commit-Position: refs/heads/main@{#39446}
moz-v2v-gh pushed a commit that referenced this pull request Aug 2, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/e46e37b6f831763aceaf5f5bd081a47cbd562890
    [M114] Move transceiver iteration loop over to the signaling thread.

    This is required for ReportTransportStats since iterating over the
    transceiver list from the network thread is not safe.

    (cherry picked from commit dba22d31909298161318e00d43a80cdb0abc940f)

    No-Try: true
    Bug: chromium:1446274, webrtc:12692
    Change-Id: I7c514df9f029112c4b1da85826af91217850fb26
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/307340
    Reviewed-by: Harald Alvestrand <hta@webrtc.org>
    Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#40197}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308001
    Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org>
    Cr-Commit-Position: refs/branch-heads/5735@{#3}
    Cr-Branched-From: df7df199abd619e75b9f1d9a7e12fc3f3f748775-refs/heads/main@{#39949}
moz-v2v-gh pushed a commit that referenced this pull request Aug 2, 2023
… and improve testing, a=testonly

Automatic update from web-platform-tests
Fix cloning of templates with DOM Parts, and improve testing

This CL improves the testing of template cloning with Parts, testing
these four cases:

  1. Main document parsing
  2. Template (content fragment) parsing
  3. Template/fragment cloning
  4. Declarative Shadow DOM parsing and cloning

This CL fixes the behavior for #3 above, but leaves #4 broken. The
following changes in behavior are made:

1. Part::MoveToRoot() can be used to change the root(), including
   to set it to nullptr. This happens when a Node tree is removed
   from the DOM, and it contains Parts that refer to the old root.
2. IsDocumentPartRoot() is now virtual, because during a tree move,
   the root() for a Part can be made nullptr even when it's a
   ChildNodePart.
3. Part::disconnected_ is added to keep track of whether the
   Part has been disconnected, since root() can now be nullptr.
4. (This is a bug fix) When using ChildNodePart::setNextSibling(),
   the new sibling node wasn't having its Part registered with
   NodeRareData, which caused a CHECK failure when trying to
   subsequently clone that Part. This is caught in the new test
   which clones declaratively-built templates containing Parts.

Bug: 1453291
Change-Id: Ic1c1475431cf6bd658f191db78003204412ef78f
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4713668
Reviewed-by: David Baron <dbaron@chromium.org>
Auto-Submit: Mason Freed <masonf@chromium.org>
Commit-Queue: Mason Freed <masonf@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1175782}

--

wpt-commits: e03faa12a86fced56d076740e95fc7557db5eac4
wpt-pr: 41168
moz-v2v-gh pushed a commit that referenced this pull request Aug 29, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/f0d954f659a77b214b0ff177e6f66bad1d626423
    [M115] Fix L1Tx target bitrate bug when the standard API is used.

    There are now multiple ways to configure VP9 L1Tx:
    - Legacy API: configure legacy SVC and disable encodings, this gets
      interpreted as disabling spatial layers (non-standard API hack).
    - Standard API: configure scalability_mode. This can be done either
      with a single encoding or multiple encodings. As long as only one
      encoding is active we get a single L1Tx ssrc, same as legacy API.

    Due to a bug, the ApplySpatialLayerBitrateLimits() logic which tweaks
    bitrates was only applied in the legacy API code path, not the standard
    API code path, despite both code paths configuring L1Tx.

    The issue is that IsSimulcastOrMultipleSpatialLayers() was checking if
    `number_of_streams == 1`. This is true in legacy code path but not
    standard code path. The fix is to look at
    `numberOfSimulcastStreams == 1` instead, which is set to the correct
    value regardless of code path used.

    This CL adds comments documenting the difference between
    `number_of_streams` and `numberOfSimulcastStreams` to reduce the risk
    of more mistakes like this in the future.

    (cherry picked from commit 2fec64484f0c1355db1dde236c3c205985a30a30)

    Bug: chromium:1455039, b:279161263
    Change-Id: I69789b68cc5d45ef1b3becd310687c8dec8e7c87
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308722
    Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
    Commit-Queue: Henrik Boström <hbos@webrtc.org>
    Reviewed-by: Erik Språng <sprang@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#40287}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/308920
    Cr-Commit-Position: refs/branch-heads/5790@{#3}
    Cr-Branched-From: 2eacbbc03a4a41ea658661225eb1c8fc07884c33-refs/heads/main@{#40122}
moz-v2v-gh pushed a commit that referenced this pull request Sep 13, 2023
…cuts as soft navigation triggers, a=testonly

Automatic update from web-platform-tests
[soft navigations] Enable keyboard shortcuts as soft navigation triggers

Following the discussion on issue #3 [1], this CL adds support to soft
navigations triggered by keyboard shortcuts, by adding unfocused keydown
events to the events that can trigger the soft navigation heuristic.

[1] WICG/soft-navigations#3

Bug: 1478772
Change-Id: Ib423a3cfc09eaf4dd9a2221b3494ab1016fa8668
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4839506
Commit-Queue: Yoav Weiss <yoavweiss@chromium.org>
Reviewed-by: Ian Clelland <iclelland@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1193004}

--

wpt-commits: 7f165f11361b86ef41b123dbc904ccee26d5f025
wpt-pr: 41816
moz-v2v-gh pushed a commit that referenced this pull request Sep 28, 2023
…rd shortcuts as soft navigation triggers", a=testonly

Automatic update from web-platform-tests
Revert "[soft navigations] Enable keyboard shortcuts as soft navigation triggers"

This reverts commit 6efe71286a014d3d3872bc990e3ea2d08dd46dba.

Reason for revert: One check added in this CL causes crash. see
crbug.com/1480047

Original change's description:
> [soft navigations] Enable keyboard shortcuts as soft navigation triggers
>
> Following the discussion on issue #3 [1], this CL adds support to soft
> navigations triggered by keyboard shortcuts, by adding unfocused keydown
> events to the events that can trigger the soft navigation heuristic.
>
> [1] WICG/soft-navigations#3
>
> Bug: 1478772
> Change-Id: Ib423a3cfc09eaf4dd9a2221b3494ab1016fa8668
> Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4839506
> Commit-Queue: Yoav Weiss <yoavweiss@chromium.org>
> Reviewed-by: Ian Clelland <iclelland@chromium.org>
> Cr-Commit-Position: refs/heads/main@{#1193004}

Bug: 1478772
Change-Id: I3a518c165e6b19239a6bf7900e94c1ef9c3e5a5a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4859802
Reviewed-by: Ian Clelland <iclelland@chromium.org>
Commit-Queue: Hao Liu <haoliuk@chromium.org>
Owners-Override: Daniel Cheng <dcheng@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/heads/main@{#1196100}

--

wpt-commits: 40543949faa61279ddd3341accfe9ea866a5987e
wpt-pr: 41958
moz-v2v-gh pushed a commit that referenced this pull request Oct 2, 2023
We cherry-picked this in bug 1830945.

Upstream commit: https://webrtc.googlesource.com/src/+/04ee24493d08714bd9bba83fdbdd0c6568abe1cf
    [M116] In VideoCaptureDS::{Start|Stop}Capture do not lock

    Sequence- and RaceCheckers ensure thread safety, and show that these
    locks protect nothing.

    (cherry picked from commit dcf600d7a5cdf8da51daf5b6f79df1de05002b13)

    Bug: webrtc:15181, chromium:1457919
    Change-Id: I7c26cd9aea5fa72ad9435de5ec1b9135ac22b1e8
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/305649
    Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
    Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org>
    Reviewed-by: Per Kjellander <perkj@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#40345}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/310520
    Reviewed-by: Henrik Boström <hbos@webrtc.org>
    Cr-Commit-Position: refs/branch-heads/5845@{#3}
    Cr-Branched-From: f80cf814353d11a9f22bef5ce5e8868f2c72f0d0-refs/heads/main@{#40319}
moz-v2v-gh pushed a commit that referenced this pull request Oct 4, 2023
…rd shortcuts as soft navigation triggers, a=testonly

Automatic update from web-platform-tests
Reland: [soft navigations] Enable keyboard shortcuts as soft navigation triggers

Following the discussion on issue #3 [1], this CL adds support to soft
navigations triggered by keyboard shortcuts, by adding unfocused keydown
events to the events that can trigger the soft navigation heuristic.

This is a reland of [2], rebased and which fixes the unguarded
ScriptState access in event_dispatcher, which caused a crash.

[1] WICG/soft-navigations#3
[2] https://chromium-review.googlesource.com/c/chromium/src/+/4839506

Bug: 1478772, 1480047
Change-Id: I6428e0635222366d880dd908f04f2273b6bf8b44
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/4900577
Reviewed-by: Ian Clelland <iclelland@chromium.org>
Commit-Queue: Yoav Weiss <yoavweiss@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1203903}

--

wpt-commits: 04ab10bfca7454a6f6d968cb6c9c697fcdea9de2
wpt-pr: 42213
moz-v2v-gh pushed a commit that referenced this pull request Nov 16, 2023
…chevobbe

Just starting up a debug build you will get 40 copies of this printed.

The uri that we fail to get host of is about:newtab. One stack looks like this

#2: mozilla::BasePrincipal::GetIsLoopbackHost(bool*)
#3: mozilla::net::LoadInfo::LoadInfo(nsIPrincipal*, nsIPrincipal*, nsINode*, unsigned int, nsIContentPolicy::nsContentPolicyType, mozilla::Maybe<mozilla::dom::ClientInfo> const&, mozilla::Maybe<mozilla::dom::ServiceWorkerDescriptor> const&, unsigned int, bool
#4: ShouldLoadCachedImage(imgRequest*, mozilla::dom::Document*, nsIPrincipal*, nsIContentPolicy::nsContentPolicyType, bool)
#5: imgLoader::LoadImage(nsIURI*, nsIURI*, nsIReferrerInfo*, nsIPrincipal*, unsigned long long, nsILoadGroup*, imgINotificationObserver*, nsINode*, mozilla::dom::Document*, unsigned int, nsISupports*, nsIContentPolicy::nsContentPolicyType, nsTSubstring<char16
#6: nsContentUtils::LoadImage(nsIURI*, nsINode*, mozilla::dom::Document*, nsIPrincipal*, unsigned long long, nsIReferrerInfo*, imgINotificationObserver*, int, nsTSubstring<char16_t> const&, imgRequestProxy**, nsIContentPolicy::nsContentPolicyType, bool, bool,
#7: mozilla::css::ImageLoader::LoadImage(mozilla::StyleComputedUrl const&, mozilla::dom::Document&)
#8: mozilla::StyleComputedUrl::ResolveImage(mozilla::dom::Document&, mozilla::StyleComputedUrl const*)
#9: nsStyleImageLayers::ResolveImages(mozilla::dom::Document&, nsStyleImageLayers const*)
#10: mozilla::ComputedStyle::StartImageLoads(mozilla::dom::Document&, mozilla::ComputedStyle const*)

Differential Revision: https://phabricator.services.mozilla.com/D193349
moz-v2v-gh pushed a commit that referenced this pull request Nov 21, 2023
Upstream commit: https://webrtc.googlesource.com/src/+/d8f2b0380b3ec980af35ce4b92ba6a211ec8c76d
    [M118] Fire MaybeSignalReadyToSend in a PostTask when recursive

    Speculative fix. Writing the test for it is more complex.

    (cherry picked from commit 83894d384763c613e548e6352838406e6e0c2fc1)

    Bug: chromium:1483874
    Change-Id: Icfaf1524b0499c609010753e0b6f3cadbd0e98f9
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/321480
    Reviewed-by: Per Kjellander <perkj@webrtc.org>
    Commit-Queue: Harald Alvestrand <hta@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#40820}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/322124
    Reviewed-by: Tomas Gunnarsson <tommi@webrtc.org>
    Cr-Commit-Position: refs/branch-heads/5993@{#3}
    Cr-Branched-From: 5afcec093c1403fe9e3872706d04671cbc6d2983-refs/heads/main@{#40703}
moz-v2v-gh pushed a commit that referenced this pull request Jan 23, 2024
…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
mstriemer pushed a commit to mstriemer/gecko-dev that referenced this pull request Feb 13, 2024
* FIDEFE-4626 - Add HCM media queries to built CSS

* remove some of the 'default' references from JSON, fix test fixtures

* address review comments
moz-v2v-gh pushed a commit that referenced this pull request Feb 22, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/3df661f79828194d0acb51a1480833bafd9e5066
    [121] Allow RTP retransmission for cloned encoded Video Frames

    Fix the unintended disabling of RTP retransmissions for cloned encoded
    frames, caused by passing an infinite "expected_retransmission_time".
    Instead use a constant 10ms for now. For frames encoded locally, this is
    set from an estimate of the RTT, but we currently don't have access to
    that here (TODO added to pipe it through)

    If an integration is cloning and then sending frames it received, it's
    almost certainly resending received media to other peers on a local
    network, so 10ms is a fair upperbound.

    Tested locally with Chrome on Mac, configuring packet drops & observing
    on chrome://webrtc-internals that retransmission packets are now sent.

    (cherry picked from commit 3e801c32086be59e502e276ff5d6beea42069582)

    No-Try: True
    Bug: chromium:1512631
    Change-Id: I2483415dc7e0079f8a7b66f6607f4907698514c4
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/331900
    Reviewed-by: Harald Alvestrand <hta@webrtc.org>
    Commit-Queue: Tony Herre <herre@google.com>
    Cr-Original-Commit-Position: refs/heads/main@{#41405}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/332261
    Reviewed-by: Stefan Holmer <stefan@webrtc.org>
    Commit-Queue: Mirko Bonadei <mbonadei@webrtc.org>
    Reviewed-by: Henrik Boström <hbos@webrtc.org>
    Cr-Commit-Position: refs/branch-heads/6167@{#3}
    Cr-Branched-From: ece5cb83715dea85617114b6d4e981fdee2623ba-refs/heads/main@{#41315}
TGiles pushed a commit to TGiles/gecko-dev that referenced this pull request Mar 5, 2024
* FIDEFE-4626 - Add HCM media queries to built CSS

* remove some of the 'default' references from JSON, fix test fixtures

* address review comments
moz-v2v-gh pushed a commit that referenced this pull request Apr 15, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/41b1493ddb5d98e9125d5cb002fd57ce76ebd8a7
    [M123 MERGE] Demote RTC_CHECK for sctp_mid() to RTC_LOG(LS_ERROR) if unavailable

    (cherry picked from commit efbfc40029b6986137f9179476955c263da7052a)

    Bug: chromium:326275823, chromium:325900490
    Change-Id: Icfb8850867d1e39f23661422693da4f2829ecc57
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/340460
    Reviewed-by: Evan Shrubsole <eshr@webrtc.org>
    Commit-Queue: Tomas Gunnarsson <tommi@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#41793}
    No-Try: True
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/342560
    Reviewed-by: Guido Urdaneta <guidou@webrtc.org>
    Commit-Queue: Florent Castelli <orphis@webrtc.org>
    Cr-Commit-Position: refs/branch-heads/6312@{#3}
    Cr-Branched-From: 0355f455a48b141a8277442825ec776a74d66fb7-refs/heads/main@{#41763}
moz-v2v-gh pushed a commit that referenced this pull request Apr 23, 2024
…eStream and related classes, attempt #3, a=testonly

Automatic update from web-platform-tests
Use typed promises/resolvers for ReadableStream and related classes, attempt #3

This converts IDL-exposed promises in ReadableStream,
ReadableStreamBYOBReader, ReadableStreamDefaultReader, and
ReadableStreamGenericReader to use typed ScriptPromiseResolver
instead of StreamPromiseResolver and to return typed
ScriptPromises.

Bug: 329702363
Change-Id: I8ad1af1a7c9c909d711881ce7621c6c9fac58931
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5429731
Reviewed-by: Adam Rice <ricea@chromium.org>
Reviewed-by: Nidhi Jaju <nidhijaju@chromium.org>
Commit-Queue: Nate Chapin <japhet@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1289397}

--

wpt-commits: 26d974425bf402e6ceb7a28480800d1942236b8c
wpt-pr: 45590
moz-v2v-gh pushed a commit that referenced this pull request May 15, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/a55ff9e83e4592010969d428bee656bace8cbc3b
    [M124] Use predefined SdpVideoFormats when returning supported formats

    The predefined SdpVideoFormats were not used everywhere,
    which caused a discrepancy between send/receive capabilities
    for AV1. This CL solves the immediate problems by making sure
    send/receive capabilities for AV1 are reported the same way.

    (cherry picked from commit 82598402e095ec6638b6cf3dc8e7f6d35cc3d737)

    Fixed: chromium:331565934
    Change-Id: I073091b7b5f987c7f434c17276fd84047ec723c2
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/344681
    Reviewed-by: Harald Alvestrand <hta@webrtc.org>
    Commit-Queue: Johannes Kron <kron@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#41991}
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/348720
    Cr-Commit-Position: refs/branch-heads/6367@{#3}
    Cr-Branched-From: 802552a8030d82ad07b72aa738f814f3a0030810-refs/heads/main@{#41921}
moz-v2v-gh pushed a commit that referenced this pull request May 23, 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
moz-v2v-gh pushed a commit that referenced this pull request Aug 8, 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}
moz-v2v-gh pushed a commit that referenced this pull request Sep 5, 2024
Upstream commit: https://webrtc.googlesource.com/src/+/f237dc146debcfde3d70038c2b66f71bfea8d24b
    [M128] Ensure calls to QP convergence controller are on the same sequence

    The original CL overlooked the possibility that the encoder may be
    reconfigured in the middle of a stream.

    Restructure the code so that all calls to QP convergence controller
    happen on the encoder queue.

    A side effect of this CL is that `EncodedImage::SetAtTargetQuality()`
    is never called. The information is supplied to the frame cadence
    adapter directly without this intermediate step.

    `EncodedImage::SetAtTargetQuality()` and
    `EncodedImage::IsAtTargetQuality()` are being marked as deprecated
    in https://webrtc-review.googlesource.com/c/src/+/359660.

    (cherry picked from commit b47cd6fbe315690756f2f03e7658d4e26fe27b1e)

    Bug: chromium:359410061
    Change-Id: I941b5f60b1a9fd7694dbedf2f3e4ff5253ccf357
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359640
    Commit-Queue: Johannes Kron <kron@webrtc.org>
    Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org>
    Reviewed-by: Markus Handell <handellm@webrtc.org>
    Cr-Original-Commit-Position: refs/heads/main@{#42788}
    No-Try: true
    Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/360240
    Cr-Commit-Position: refs/branch-heads/6613@{#3}
    Cr-Branched-From: 1ac162ee20a214bf97f6594a7effcbbc21f1effb-refs/heads/main@{#42664}
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants