-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Conversation
// 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"); | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
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
.
======== 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
…e on windows platform,mozilla#3 code format
(Mass-PR-close) |
Whitespace cleanup
Added ci-build mach command
… 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]
Limit the area of the surface rather than width and height
…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
CloudStorageServiceAPI and CloudStorageManager integration
Bug 1270701-Draw a cursor when a mouse is being used; a=jocheng
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
…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
…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
…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
Add in endpoints for modal dialog support Source-Repo: https://github.com/mozilla/geckodriver Source-Revision: 83b4de3af8ac59ae394d74f64280b3b69d8a3594 --HG-- extra : rebase_source : a3237e8c0d5d5c82360a2835da31a7ac59fa0592
Add in endpoints for modal dialog support Source-Repo: https://github.com/mozilla/geckodriver Source-Revision: 83b4de3af8ac59ae394d74f64280b3b69d8a3594
Add in endpoints for modal dialog support Source-Repo: https://github.com/mozilla/geckodriver Source-Revision: 83b4de3af8ac59ae394d74f64280b3b69d8a3594
Add in endpoints for modal dialog support Source-Repo: https://github.com/mozilla/geckodriver Source-Revision: 83b4de3af8ac59ae394d74f64280b3b69d8a3594
… r=Pike MozReview-Commit-ID: IHhE3xg3nb0 --HG-- extra : rebase_source : 3135b6d5c716e1359ad7fc5ae21d6885e9918543
…ng in 0 r=Pike MozReview-Commit-ID: IHhE3xg3nb0
…ng in 0 r=Pike MozReview-Commit-ID: IHhE3xg3nb0
…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
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}
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}
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}
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}
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}
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}
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}
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}
… 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
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}
…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
…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
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}
…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
…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
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}
…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
* FIDEFE-4626 - Add HCM media queries to built CSS * remove some of the 'default' references from JSON, fix test fixtures * address review comments
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}
* FIDEFE-4626 - Add HCM media queries to built CSS * remove some of the 'default' references from JSON, fix test fixtures * address review comments
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}
…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
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}
…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
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/+/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}
Upstream commit: https://webrtc.googlesource.com/src/+/8445abdf8069cadcbd134369b70d0ebd436ef477 Fix regression caused by default action changed for h264:Nalu:kFiller This commit fixes the issue of discontinuous RTP sequence numbers caused by improper discarding of these nalu types: kFiller/kEndofSequence/kEndOfStream. (cherry picked from commit 521b09bfb720eb9a32d53e90aaf6501249ec445b) Bug: webrtc:368335257 PR: chromium:375352614 Change-Id: Id7a2d34b22ee1c6e1523d8279d9838c57fdeb97f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366501 Reviewed-by: Danil Chapovalov <danilchap@webrtc.org> Commit-Queue: Sergey Silkin <ssilkin@webrtc.org> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#43299} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/366900 Reviewed-by: Erik Språng <sprang@webrtc.org> Commit-Queue: Danil Chapovalov <danilchap@webrtc.org> Cr-Commit-Position: refs/branch-heads/6778@{#3} Cr-Branched-From: 7b1b7a0f51593df7a1a802f489d6a2fb14195bcc-refs/heads/main@{#43221}
We already cherry-picked this when we vendored 79aff54b0f. Upstream commit: https://webrtc.googlesource.com/src/+/711ecf44bb1247977f1ea0d8cda5e767af05b388 [M132] h264: skip empty NAL units, do not reject them BUG=webrtc:380291923,chromium:381016774 (cherry picked from commit b7cb8fe75a0b0f19a003e4f78f83fb7bd8fa84ef) Change-Id: If05268bde2ac0c600dcef479c88ca54dce708dcb Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/368893 Reviewed-by: Danil Chapovalov <danilchap@webrtc.org> Reviewed-by: Sergey Silkin <ssilkin@webrtc.org> Commit-Queue: Philipp Hancke <phancke@meta.com> Cr-Original-Commit-Position: refs/heads/main@{#43451} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/369480 Commit-Queue: Sergey Silkin <ssilkin@webrtc.org> Cr-Commit-Position: refs/branch-heads/6834@{#3} Cr-Branched-From: a5d71009ac1dce7da23813dc9413c03073cfa8ca-refs/heads/main@{#43387}
Note: This is just for a review, not for actually merging in.