the path forward #1

i3roly · 2024-06-01T17:22:01Z

ensure the changes i've made work properly (no avx-capable mac for a few more days).
introduce/change/edit macro enable/disable AVX support, ensuring support for older intel macs #4
check and see if we can enforce 10.9 target libgkrust, libosclientcerts_static, libipcclientcerts_static, libbuiltins_static #5
try to match @blueboxd and push firefox compatibility as-far back as 10.6
(edited for politeness, mainly to ensure any potential contributors aren't scared of retribution by the haters)

…ug,dom-core Bug #1: AbstractRange::(Mark|Unmark)Descendants should always use the shadow tree of web-exposed shadow root, instead of using light DOM elements of the host. Bug #2: aRange could possibly create mCrossShadowBoundaryRange first (due to boundaries are in different tree), and later moves the boundaries to the same tree. When this happens, we should remove mCrossShadowBoundaryRange and use the default range to represent it. Differential Revision: https://phabricator.services.mozilla.com/D207608

Upstream commit: https://webrtc.googlesource.com/src/+/89e26b72494b97b1a50e5c960147550896ed14af [m125] webrtc stats: fix video remote-outbound-rtp timestamp which had a 70 year offset (i.e. 2094 instead of 2024) which broke the webrtc-internal stats graphs. A similar adjustment is done for audio in audio/channel_receive.cc BUG=webrtc:12529,chromium:336222282 (cherry picked from commit 77313800c72fa1e33c30e952800e4157e9ad44a4) Change-Id: I0ce43cc8b451185bc056cf9e54757ef22d006c99 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/347780 Reviewed-by: Florent Castelli <[email protected]> Commit-Queue: Philipp Hancke <[email protected]> Reviewed-by: Harald Alvestrand <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#42114} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/348702 Commit-Queue: Harald Alvestrand <[email protected]> Cr-Commit-Position: refs/branch-heads/6422@{#1} Cr-Branched-From: b831eb816ef847d09d446ef4168e36b13af163f8-refs/heads/main@{#42072}

…-worker-reviewers,smaug,profiler-reviewers,aabh,asuth Use profiler markers to collect timing data. Markers of known name: AUTO_PROFILER_MARKER_TEXT("interesting thing #1", DOM, {}, ""_ns); AUTO_PROFILER_MARKER_TEXT("interesting thing #2", DOM, {}, ""_ns); can be inspected from the perftest: await startProfiler(); interestingThings(); let pdata = await stopProfiler(); let duration_ms = inspectProfile(pdata, [ "interesting thing #1", "interesting thing #2" ]); Differential Revision: https://phabricator.services.mozilla.com/D211368

…ed frames., a=testonly Automatic update from web-platform-tests Disable WebRTC RTCPeerConnection in fenced frames. WebRTC is one form of network communication that should be disabled when window.fence.disableUntrustedNetwork is called in a fenced frame. However, 1. We don't have any identified use cases for WebRTC in fenced frames 2. The revocation process would be more involved than other forms of network access, which would provide little benefit per #1. 3. Entirely disabling WebRTC PeerConnection instead is beneficial for privacy and does not break existing fenced frame use cases. This CL disables RTCPeerConnection construction entirely in fenced frames, regardless of whether window.fence.disableUntrustedNetwork was called or not. The change is behind an existing flag so that it does not ship until other forms of network revocation do. Disabling RTCPeerConnection *can* be handled entirely by the renderer, but a compromised renderer could potentially circumvent this to construct a peer connection anyway. A follow-up CL will add a browser-side control to ensure that this does not occur. Change-Id: Iaa2caaddeee70852179332dd89c5dbbac3ffcfbf Bug: 41488151 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/5527514 Reviewed-by: Guido Urdaneta <[email protected]> Commit-Queue: Andrew Verge <[email protected]> Reviewed-by: Liam Brady <[email protected]> Reviewed-by: Shivani Sharma <[email protected]> Cr-Commit-Position: refs/heads/main@{#1319162} -- wpt-commits: bf8449f4dd09ec5c37c774981d884e67695cbbdd wpt-pr: 46169

We cherry-picked this in bug 1896575 Upstream commit: https://webrtc.googlesource.com/src/+/a18e38fed2307edd6382760213fa3ddf199fa181 Video capture PipeWire: drop corrupted PipeWire buffers Use SPA_CHUNK_FLAG_CORRUPTED and SPA_META_HEADER_FLAG_CORRUPTED flags to determine corrupted buffers or corrupted buffer data. We used to only rely on compositors setting chunk->size, but this doesn't make sense for dmabufs where they have to make up arbitrary values. It also looks this is not reliable and can cause glitches as we end up processing corrupted buffers. (cherry picked from commit cfbd6b0884db2eab893831e7bde5cfe640fe52db) Bug: chromium:341928670 Change-Id: Ida0c6a5e7a37e19598c6d5884726200f81b94962 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/349881 Commit-Queue: Mark Foltz <[email protected]> Reviewed-by: Mark Foltz <[email protected]> Reviewed-by: Alexander Cooper <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#42292} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/351563 Commit-Queue: Alexander Cooper <[email protected]> Bot-Commit: [email protected] <[email protected]> Cr-Commit-Position: refs/branch-heads/6478@{#1} Cr-Branched-From: 16fb7903e546051483720548168cd40cded7a040-refs/heads/main@{#42290}

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

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

…-worker-reviewers,smaug,profiler-reviewers,aabh,asuth,perftest-reviewers,sparky Use profiler markers to collect timing data. Markers of known name: AUTO_PROFILER_MARKER_TEXT("interesting thing #1", DOM, {}, ""_ns); AUTO_PROFILER_MARKER_TEXT("interesting thing #2", DOM, {}, ""_ns); can be inspected from the perftest: await startProfiler(); interestingThings(); let pdata = await stopProfiler(); let duration_ms = inspectProfile(pdata, [ "interesting thing #1", "interesting thing #2" ]); Differential Revision: https://phabricator.services.mozilla.com/D211368

Upstream commit: https://webrtc.googlesource.com/src/+/876d0c9881eab8e7f8389812eb3738bdd374aa22 Fix use-of-uninitialized-value in NetEq tests. The new version of MSan (rolled by [1]) detects the following: ``` ==39908==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x5591400a52ef in GetPlayoutDelayMs ./../../modules/audio_coding/neteq/decision_logic.cc:466:35 #1 0x5591400a52ef in webrtc::DecisionLogic::ExpectedPacketAvailable(webrtc::NetEqController::NetEqStatus) ./../../modules/audio_coding/neteq/decision_logic.cc:311:36 #2 0x5591400a39e9 in webrtc::DecisionLogic::GetDecision(webrtc::NetEqController::NetEqStatus const&, bool*) ./../../modules/audio_coding/neteq/decision_logic.cc:0:0 #3 0x55913cf590c9 in webrtc::DecisionLogicTest_PreemptiveExpand_Test::TestBody() ./../../modules/audio_coding/neteq/decision_logic_unittest.cc:139:3 #4 0x55913ef28283 in HandleExceptionsInMethodIfSupported<testing::Test, void> ./../../third_party/googletest/src/googletest/src/gtest.cc:0:3 #5 0x55913ef28283 in testing::Test::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:2710:5 #6 0x55913ef2ab46 in testing::TestInfo::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:2856:11 #7 0x55913ef2da34 in testing::TestSuite::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:3034:30 #8 0x55913ef621e8 in testing::internal::UnitTestImpl::RunAllTests() ./../../third_party/googletest/src/googletest/src/gtest.cc:5964:44 #9 0x55913ef60f54 in HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool> ./../../third_party/googletest/src/googletest/src/gtest.cc:0:0 #10 0x55913ef60f54 in testing::UnitTest::Run() ./../../third_party/googletest/src/googletest/src/gtest.cc:5543:10 #11 0x55913ee1a944 in RUN_ALL_TESTS ./../../third_party/googletest/src/googletest/include/gtest/gtest.h:2334:73 #12 0x55913ee1a944 in webrtc::(anonymous namespace)::TestMainImpl::Run(int, char**) ./../../test/test_main_lib.cc:203:21 #13 0x55913cbd36b8 in main ./../../test/test_main.cc:72:16 #14 0x7fdb18c73082 in __libc_start_main /build/glibc-LcI20x/glibc-2.31/csu/../csu/libc-start.c:308:16 #15 0x55913cb3e1a9 in _start ??:0:0 ``` [1] - https://webrtc-review.googlesource.com/c/src/+/353620 Bug: b/344970813 Change-Id: I9b5d7791e68b4c494168ba9f007a3099ae21fed4 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/353581 Auto-Submit: Mirko Bonadei <[email protected]> Reviewed-by: Jakob Ivarsson‎ <[email protected]> Commit-Queue: Jakob Ivarsson‎ <[email protected]> Cr-Commit-Position: refs/heads/main@{#42433}

Upstream commit: https://webrtc.googlesource.com/src/+/e0b28a6a81a989c1f5c89e30fcd247870047390d [Merge 127] Reset the speech encoder when creating a comfort noise encoder. This is to make sure that the two encoders are "in sync" (the CNG encoder can be created from an existing speech encoder). This is a speculative fix for a crash in the CNG encoder where a packet is unexpectedly emitted from the speech encoder. (cherry picked from commit 0fd67312ea078b3b997306d56284b85492b37650) Bug: webrtc:42225071, chromium:338342746 Change-Id: I42571e56e032897f7f083f04d785f6a08ebfb813 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/355160 Commit-Queue: Jakob Ivarsson‎ <[email protected]> Reviewed-by: Tomas Lundqvist <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#42516} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/355863 Reviewed-by: Daniel Johansson <[email protected]> Cr-Commit-Position: refs/branch-heads/6533@{#1} Cr-Branched-From: 63c380918687cd4c233e9eb856e98ba4c0589722-refs/heads/main@{#42455}

…indows r=win-reviewers,gstoll This implements PresentSystemSettings, LocationIsPermittedHint and SystemWillPromptForPermissionHint for Windows. The Windows APIs are not always available -- some are currently only available in Windows 11 Canary builds (slated for September release). In the event that APIs are not available, this should do nothing. At present, this is detailed here: https://learn.microsoft.com/en-us/windows/win32/nativewifi/wi-fi-access-location-changes There are two issues that this is intended to handle: 1. The system will display a one-time (or so) dialog to the user when Firefox requests geolocation but doesn't have permission. For that case, we inform the user that they will be asked to grant location permission again. This system dialog is only presented in versions of Windows that support all of the relevant APIs. 2. We open system settings to the right page and post a cancelable modal dialog on the tab if the user grants geolocation to the page but geolocation permission isn't currently granted in the OS. This case will not happen if case #1 did. Unfortunately, we can't get information about the permission status without a location request on old versions of Windows, so this also does nothing unless the recent APIs are supported (in this case, AppCapability::CheckAccess). This work is necessitated not only by the new (occasional) system dialog but also by Microsoft's plans to block wifi scanning if geolocation isn't available. We have used wifi scanning as part of a fallback when system geolocation isn't available -- that approach is no longer viable here. A user would confusingly get repeated errors or very poor results (e.g. IP lookup results) without information as to why, if that happened. This is what happens in the current Windows Canary build if system geolocation is turned off. The fallback remains useful on other platforms, although Linux is in flux (but it is not in the scope of this bug). Differential Revision: https://phabricator.services.mozilla.com/D216474

We already cherry-picked this when we vendored 46b43e0072. Upstream commit: https://webrtc.googlesource.com/src/+/bef5d63112748d963af30b7ac39bf3628b6ce9ef [M128] Revert "Update support for missing HIGH profiles and 1080p" M128 merge approval: https://issues.chromium.org/issues/354143228#comment11 This reverts commit 46b43e007296737751aea10685f92ddf4df63e0d. Reason for revert: chromium:354143228 Original change's description: > Update support for missing HIGH profiles and 1080p > > The High and ConstrainedHigh profiles are missing from the decoder capabilities. Also level 3.1 doesn't allow 1080p > > Bug: webrtc:347724928 > Change-Id: I3f33468327d2aaf352fc80f69d2ee31481bafcb5 > Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/355001 > Reviewed-by: Sergey Silkin <[email protected]> > Reviewed-by: Åsa Persson <[email protected]> > Commit-Queue: Sergey Silkin <[email protected]> > Cr-Commit-Position: refs/heads/main@{#42528} (cherry picked from commit 12f9d5ce601a13cd45d56f40ed9ed94f3a90d91e) Bug: chromium:354143228, webrtc:347724928 Change-Id: I4d55b2982aca2e94ec983473336c4fa2a72d842f Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/357861 Reviewed-by: Danil Chapovalov <[email protected]> Commit-Queue: Sergey Silkin <[email protected]> Cr-Original-Commit-Position: refs/heads/main@{#42675} No-Try: True Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/358021 Bot-Commit: [email protected] <[email protected]> Reviewed-by: Åsa Persson <[email protected]> Cr-Commit-Position: refs/branch-heads/6613@{#1} Cr-Branched-From: 1ac162ee20a214bf97f6594a7effcbbc21f1effb-refs/heads/main@{#42664}

…r=m_kato This fixes four issues: 1. The test didn't provide enough movement to generate a drag session on the source before moving to the target. This meant that, when they were in different windows, Gecko wouldn't send dragleave to the source or dragenter to the target. It also never sent dragenter to the source in the first place. This remedies that. 2. dragenter and dragleave weren't properly handled because the test was sending dragleaves instead of dragexits (the latter being what Gecko expects and the former being synthesized from that -- see e.g. nsNativeDragTarget::DragLeave). This now uses dragexits and sets the proper expectations. 3. expectProtectedDataTransferAccess was needlessly complicated and, after #1, gave the wrong answers for some events like dragenter called on the source. 4. The event handler wasn't checking for exceptions and the drop handler was intentionally causing one, which was causing it to miss the rest of its execution. Differential Revision: https://phabricator.services.mozilla.com/D219550

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

…indows r=win-reviewers,gstoll a=RyanVM This implements PresentSystemSettings, LocationIsPermittedHint and SystemWillPromptForPermissionHint for Windows. The Windows APIs are not always available -- some are currently only available in Windows 11 Canary builds (slated for September release). In the event that APIs are not available, this should do nothing. At present, this is detailed here: https://learn.microsoft.com/en-us/windows/win32/nativewifi/wi-fi-access-location-changes There are two issues that this is intended to handle: 1. The system will display a one-time (or so) dialog to the user when Firefox requests geolocation but doesn't have permission. For that case, we inform the user that they will be asked to grant location permission again. This system dialog is only presented in versions of Windows that support all of the relevant APIs. 2. We open system settings to the right page and post a cancelable modal dialog on the tab if the user grants geolocation to the page but geolocation permission isn't currently granted in the OS. This case will not happen if case #1 did. Unfortunately, we can't get information about the permission status without a location request on old versions of Windows, so this also does nothing unless the recent APIs are supported (in this case, AppCapability::CheckAccess). This work is necessitated not only by the new (occasional) system dialog but also by Microsoft's plans to block wifi scanning if geolocation isn't available. We have used wifi scanning as part of a fallback when system geolocation isn't available -- that approach is no longer viable here. A user would confusingly get repeated errors or very poor results (e.g. IP lookup results) without information as to why, if that happened. This is what happens in the current Windows Canary build if system geolocation is turned off. The fallback remains useful on other platforms, although Linux is in flux (but it is not in the scope of this bug). Differential Revision: https://phabricator.services.mozilla.com/D216474

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

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

…a=dmeehan This fixes four issues: 1. The test didn't provide enough movement to generate a drag session on the source before moving to the target. This meant that, when they were in different windows, Gecko wouldn't send dragleave to the source or dragenter to the target. It also never sent dragenter to the source in the first place. This remedies that. 2. dragenter and dragleave weren't properly handled because the test was sending dragleaves instead of dragexits (the latter being what Gecko expects and the former being synthesized from that -- see e.g. nsNativeDragTarget::DragLeave). This now uses dragexits and sets the proper expectations. 3. expectProtectedDataTransferAccess was needlessly complicated and, after #1, gave the wrong answers for some events like dragenter called on the source. 4. The event handler wasn't checking for exceptions and the drop handler was intentionally causing one, which was causing it to miss the rest of its execution. Original Revision: https://phabricator.services.mozilla.com/D219550 Differential Revision: https://phabricator.services.mozilla.com/D227589

i3roly pinned this issue Jun 1, 2024

Wowfunhappy mentioned this issue Oct 3, 2024

cannot stream video or audio content #12

Closed

i3roly mentioned this issue Oct 24, 2024

10.13.6- not launching at all #11

Closed

Wowfunhappy mentioned this issue Oct 27, 2024

Scrollbars autohide even with System Preferences → General → Show Scroll Bars set to "Always" #19

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

the path forward #1

the path forward #1

i3roly commented Jun 1, 2024 •

edited

Loading

the path forward #1

the path forward #1

Comments

i3roly commented Jun 1, 2024 • edited Loading

i3roly commented Jun 1, 2024 •

edited

Loading