Set up CI with Azure Pipelines #2

azure-pipelines · 2018-10-17T18:55:19Z

experiment with Azure Pipelines

MozReview-Commit-ID: 6qNBdx6Tbss

MozReview-Commit-ID: B375OSnZ5fK

MozReview-Commit-ID: AMFN3PhJ3HN

MozReview-Commit-ID: H28R5x5woxs

MozReview-Commit-ID: ZFcEEwFIWr

MozReview-Commit-ID: FUI0Dx1J23w

MozReview-Commit-ID: HwNxsB89q1e

MozReview-Commit-ID: IY4E4JbqRfI

MozReview-Commit-ID: 9qeJlz44FIU

MozReview-Commit-ID: GudHKRopDn8

MozReview-Commit-ID: DF0AIxDm7Dt

MozReview-Commit-ID: 3qkifoEpLBk

Automatic update from web-platform-tests Squashed 'css/tools/apiclient/' changes from 9d80ee4507..f0e1aa75a7 f0e1aa75a7 Merge pull request #2 from cclauss/modernize-Python-2-codes 08bedeaf9d Use print() function in both Python 2 and Python 3 git-subtree-dir: css/tools/apiclient git-subtree-split: f0e1aa75a7113c2df87ab76cdf6734e77dfbaeb7 -- Merge commit '77ff57a73af15f3ac3743a3eedf59d4acf6d0a41' into update-apiclient -- Merge pull request #15248 from gsnedders/update-apiclient Update apiclient -- wpt-commits: 77ff57a73af15f3ac3743a3eedf59d4acf6d0a41, 83364c672a2c3857fd8fa522327c103f1490155b, edc48a7c1238f7cf8216746cd287a51cce6f0ced wpt-pr: 15248

…o clean up Object.prototype, a=testonly Automatic update from web-platform-tests IndexedDB: Fix WPT bindings-inject-key to clean up Object.prototype chromedriver doesn't allow changing Object.prototype to add enumerable properties, but this test requires setting some values on Object.prototype. When Object.prototype.a is set to: {b: {c: 'on proto'}} chromedriver fails with: JavascriptErrorException: javascript error (500): Maximum call stack size exceeded (Session info: chrome=72.0.3626.121) Remote-end stacktrace: #0 0x563ff3a32a59 <unknown> #1 0x563ff39cb7f3 <unknown> #2 0x563ff38fcd7c <unknown> #3 0x563ff38ff78c <unknown> #4 0x563ff38ff5f7 <unknown> #5 0x563ff38ffbe7 <unknown> #6 0x563ff38fff1b <unknown> #7 0x563ff38a3f7a <unknown> #8 0x563ff3899bf2 <unknown> #9 0x563ff38a37b7 <unknown> #10 0x563ff3899ac3 <unknown> #11 0x563ff38782d2 <unknown> #12 0x563ff3879112 <unknown> #13 0x563ff39fe865 <unknown> #14 0x563ff39ff32b <unknown> #15 0x563ff39ff70c <unknown> #16 0x563ff39d940a <unknown> #17 0x563ff39ff997 <unknown> #18 0x563ff39e9947 <unknown> #19 0x563ff3a1a800 <unknown> #20 0x563ff3a3c8be <unknown> #21 0x7f3bf4545494 start_thread #22 0x7f3bf2d58a8f clone Ran 1 tests finished in 2.0 seconds. • 0 ran as expected. 0 tests skipped. • 1 tests had errors unexpectedly Work around this problem by cleaning up the test environment so Object.prototype no longer has the override by the time chromedriver tries to inspect the test result. While here, fix the other tests to use the t.add_cleanup() function so they'll cleanup their test environment in case they exit in some other way besides reaching t.done(). The underlying chromedriver issue is tracked upstream at https://crbug.com/chromedriver/2555. Bug: 934844 Change-Id: Id1b4ab2a908bfbc001e2a2d045eeec3ef01c24d9 -- wpt-commits: 1be74ca2738a05f6e8d98d55ba44c50e3a332554 wpt-pr: 15637

…onously. Attempt #2, a=testonly Automatic update from web-platform-tests DocumentLoader: commit navigation synchronously. Attempt #2 We used to commit navigation after receiving the first byte of document response. This CL moves commit earlier, synchronously done from CommitNavigation call. The change should not be web-observable, but some internal assumptions may have been affected. Test changes: - ReplacingDocumentLoaderFiresLoadEvent was testing the old behavior, which is not applicable anymore. - MultiChunkWithReentrancy now uses a different method to trigger reentrancy (pdf plugin), since we no longer commit after first byte. - backdrop-object.html and anchor-change-href.svg relied on test finishing late enough, now they wait for onload to eliminate a race. - use-property-synchronization-crash.html now reports an error message synchronously and therefore has JS stack and a line number. - setting-allowpaymentrequest-timing.https.sub.html has a race as explained here [1], and now fails even without site isolation. This corresponds to the step 8.b from the doc linked to the bug. Difference from attempt #1 (https://chromium-review.googlesource.com/c/1399447): - PluginDocumentParser and MediaDocumentParser early return if not parsing before accessing GetDocument. This is because DocumentLoader calls Finish() even after parser was stopped/detached. For example in Document::Abort we cancel parsing, but committed DocumentLoader might be still receiving data. We should ideally clean up all calls into parser, there are numerous TODOs for that. - pageload-image-in-popup.html relies on small image being parsed in the same task as navigation commit. Using onload seems to fix the issue. - touch-handler-iframe-plugin-assert.js hopes that onload for about:blank happens after test has finished, which is racy now. [1] https://bugs.chromium.org/p/chromium/issues/detail?id=819800#c6 Bug: 855189, 937639, 836242, 937358 Change-Id: I65048a27e6d249a608d4eb61e5c882292386026e Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1506663 Commit-Queue: Dmitry Gozman <dgozman@chromium.org> Reviewed-by: Daniel Cheng <dcheng@chromium.org> Reviewed-by: Arthur Sonzogni <arthursonzogni@chromium.org> Cr-Commit-Position: refs/heads/master@{#639992} -- wpt-commits: 8f3d4f59182a1df4d7ca548bdae37e56a0ad263e wpt-pr: 15770

…or fixed, a=testonly Automatic update from web-platform-tests [LayoutNG] Fix for DCHECK(NeedsLayout) for fixed All tests pass, and crashes no longer happen. I believe that code will not longer crash, but there might be futher instances of incorrect positioning. Fix #1 LayoutDescendantCandidates did not sweep newly discovered candidates. This was done manually once inside NGOutOfFlowLayoutPart::Run, and sweep was not performed for LayoutDescendantCandidates found in Legacy. Fix is to make LayoutDescendantCandidates perform sweep instead. Fix #2 fix #1 exposed a bug where duplicate fragments were generated for a single layout object. This happened when NG was generating fragments not inside ContainingBlock. Fix one instance of this inside NGOutOfFlowLayoutPart::IsContainingBlockForDescendant by making sure that OOF with inline containers are only positioned inside its ContainingBlock() Fix #3 NGOutOfFlowLayoutPart::LayoutDescendant offset adjustment. Bug: 935805 Change-Id: I9f7ebbc7223f40fbbf6ba3739d9385bfd59e3641 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1517093 Commit-Queue: Aleks Totic <atotic@chromium.org> Reviewed-by: Morten Stenshorne <mstensho@chromium.org> Reviewed-by: Koji Ishii <kojii@chromium.org> Cr-Commit-Position: refs/heads/master@{#641628} -- wpt-commits: c748846db4d54c5b1c93659d9458698871a98eea wpt-pr: 15794

… it's for <textarea> element r=m_kato As far as I've tested, `TextEditor` has the following structure patterns: 1. If it's for a non-empty `<input>` element, it has only one text node. 2. If it's for an empty `<input>` element, it has only bogus node. 3. If it's for a non-empty `<textarea>` element, it has a text node and `moz-<br>` element. Additionally they are followed by `<scrollbar>` and `<resizer>` elements. 4. If it's for an empty `<textarea>` element, it has a `moz-<br>` element followed by `<scrollbar>` and `<resizer>` elements. Additionally, `TextEditRules::WillInsert()` always removes bogus node if there is. So, in the case #2, there is no children. Fortunately, we don't support XUL addons anymore on Firefox. However, in other products like Thunderbird, the tree may be changed as unexpected. Therefore, we still need to keep checking the tree, but we can use the fast path for `<textarea>` element too. Differential Revision: https://phabricator.services.mozilla.com/D30012

…e changes to 'none'", a=testonly Automatic update from web-platform-tests Revert "Correctly handle scroll-snap-type changes to 'none'" This reverts commit 712c3cf3ed8201420acf23f760eaa34be20781cd. Reason for revert: This patch causes webkit-layout-tests failure on WebKit_Linux_Trusty_ASAN bot: https://ci.chromium.org/p/chromium/builders/ci/WebKit%20Linux%20Trusty%20ASAN/25720 Unexpected Failures: * external/wpt/css/css-scroll-snap/scroll-snap-type.html * virtual/threaded/external/wpt/css/css-scroll-snap/scroll-snap-type.html STDERR: ==1==ERROR: AddressSanitizer: heap-use-after-free on address 0x61200023f8d8 at pc 0x5620c924e56d bp 0x7ffde3c56830 sp 0x7ffde3c56828 STDERR: READ of size 8 at 0x61200023f8d8 thread T0 (content_shell) STDERR: #0 0x5620c924e56c in get ./../../base/memory/scoped_refptr.h:212:27 STDERR: #1 0x5620c924e56c in Style ./../../third_party/blink/renderer/core/layout/layout_object.h:1615:0 STDERR: #2 0x5620c924e56c in GetPhysicalSnapType ./../../third_party/blink/renderer/core/page/scrolling/snap_coordinator.cc:88:0 STDERR: #3 0x5620c924e56c in blink::SnapCoordinator::UpdateSnapContainerData(blink::LayoutBox&) ./../../third_party/blink/renderer/core/page/scrolling/snap_coordinator.cc:107:0 STDERR: #4 0x5620c924e74b in blink::SnapCoordinator::UpdateAllSnapContainerData() ./../../third_party/blink/renderer/core/page/scrolling/snap_coordinator.cc:76:5 Original change's description: > Correctly handle scroll-snap-type changes to 'none' > > > Previously when a scroll container's snap type is changed to 'none' its > data was discarded including all of its snap areas. However this is > incorrect. Because while the snap type is 'none', the element is still > a scroll container which per spec [1] means that is should continue to > captures the snap areas in its subtree for whom it is the nearest > ancestor scroll container . The only difference is that it no longer > snaps. > > The fix is that we no longer remove the snap container data just > because is has a 'none' snap type and instead keep it and its snap > areas. But we check the snap type before performing any snap. > > To ensure this does not introduce any performance regression, this CL > also includes an optimization where we avoid re-calculating > snap_container_data when the snap type is 'none'. So keeping these snap > data should not be cheap. > > Note that there is another problem where if the current snap container > is no longer a scroll container (e.g., overflow: scroll => overflow: > visible) we release its snap areas and they become "orphan". But if we > are to do this correctly, we should re-assign these areas to the next > stroller in the chain. Similarly when an element becomes a scroll > container, it can potentially take over snap areas from its parent snap > container. > > > This patch does not address that situation yet but fixes the easier > problem. > > [1] https://drafts.csswg.org/css-scroll-snap/#overview > > Bug: 953575 > Test: > - wpt/css/css-scroll-snap/scroll-snap-type-change.html => Changing snap-type should work correctly > - wpt/css/css-scroll-snap/scroll-snap-type.html => Add a specific test for type 'none' to ensure it does not snap > > Change-Id: Ie493ad68ecba818ed41c0ee103ccf44725ff6e3f > Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1589899 > Reviewed-by: Majid Valipour <majidvp@chromium.org> > Reviewed-by: David Bokan <bokan@chromium.org> > Commit-Queue: Majid Valipour <majidvp@chromium.org> > Cr-Commit-Position: refs/heads/master@{#657460} TBR=bokan@chromium.org,majidvp@chromium.org Change-Id: I3a327f6e342e95d045194d24ceaf49de52b2b921 No-Presubmit: true No-Tree-Checks: true No-Try: true Bug: 953575 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/1600437 Reviewed-by: Takashi Sakamoto <tasak@google.com> Commit-Queue: Takashi Sakamoto <tasak@google.com> Cr-Commit-Position: refs/heads/master@{#657571} -- wpt-commits: 59ffeb608fd8491995002d5c1dce17d4e49c5291 wpt-pr: 16724

…directly as far as possible r=smaug Most commands are dispatched only when the `document` has `contenteditable` or in `designMode`. In such case, command context is considered with the following order: 1. `HTMLEditor` for the document. 2. `TextEditor` if the document has focus and it has `TextEditor`. 3. Other command controller table associated with window or DocShell. In the case of #1 and #2, `ExecCommand()` can use `EditorCommand` directly and we only need to send subject principal to the editor only in these cases. In the case of #3, we need to fall back to traditional path. There are 2 paths: 1. If it's "paste" command, handle it with `nsCommandManager` to dispatch "paste" event. 2. If it's "cur" or "copy", handle it with `DocShell` to dispatch "cut" or "copy" event in the window or focused sub-document. Note that clipboard "cut" and "copy" commands are special cases. Only them were handled by `DocShell` instead of `nsCommandManager` This difference caused making active element's `TextEditor` is preferred rather than `HTMLEditor`. Although this behavior is better than our traditional behavior because Chromium works as so. But for now, we should keep our behavior. Finally, this patch makes `ExecCommand()` creates `nsCommandParams` instance since now, `EditorCommand` class can take only necessary parameter without it. Differential Revision: https://phabricator.services.mozilla.com/D29632

StartGamepadMonitoring() can end up in AddGamepad, and acquire the lock again on the same thread, effectively dead-locking. This is a regression from bug 1657404. Relevant stack: (gdb) bt #0 0x00007fd19bace801 in clock_nanosleep@GLIBC_2.2.5 () at /lib64/libc.so.6 mykmelez#1 0x00007fd19bad4157 in nanosleep () at /lib64/libc.so.6 mykmelez#2 0x00007fd19bad408e in sleep () at /lib64/libc.so.6 mykmelez#3 0x00007fd195233e87 in ah_crap_handler(int) (signum=11) at /home/emilio/src/moz/gecko-4/toolkit/xre/nsSigHandlers.cpp:95 #4 0x00007fd1952165c4 in nsProfileLock::FatalSignalHandler(int, siginfo_t*, void*) (signo=11, info=0x7fd14abb9db0, context=0x7fd14abb9c80) at /home/emilio/src/moz/gecko-4/toolkit/profile/nsProfileLock.cpp:177 #5 0x00007fd1964973b2 in WasmTrapHandler(int, siginfo_t*, void*) (signum=11, info=<optimized out>, context=<optimized out>) at /home/emilio/src/moz/gecko-4/js/src/wasm/WasmSignalHandlers.cpp:978 #6 0x00007fd19bf3ca90 in <signal handler called> () at /lib64/libpthread.so.0 #7 mozilla::detail::MutexImpl::mutexLock() (this=<optimized out>) at /home/emilio/src/moz/gecko-4/mozglue/misc/Mutex_posix.cpp:118 #8 mozilla::detail::MutexImpl::lock() (this=<optimized out>) at /home/emilio/src/moz/gecko-4/mozglue/misc/Mutex_posix.cpp:142 #9 0x00007fd190cc795a in mozilla::OffTheBooksMutex::Lock() (this=0x7fd136649398) at /home/emilio/src/moz/gecko-4/xpcom/threads/BlockingResourceBase.cpp:318 #10 0x00007fd19326e65e in mozilla::detail::BaseAutoLock<mozilla::Mutex&>::BaseAutoLock(mozilla::Mutex&) (this=<optimized out>, aLock=...) at /home/emilio/src/moz/gecko-4/obj-debug-no-sccache/dist/include/mozilla/Mutex.h:159 #11 mozilla::dom::GamepadPlatformService::NotifyGamepadChange<mozilla::dom::GamepadAdded>(unsigned int, mozilla::dom::GamepadAdded const&) (this=0x7fd136649380, aIndex=1, aInfo=...) at /home/emilio/src/moz/gecko-4/dom/gamepad/GamepadPlatformService.cpp:65 #12 0x00007fd193269178 in mozilla::dom::GamepadPlatformService::AddGamepad(char const*, mozilla::dom::GamepadMappingType, mozilla::dom::GamepadHand, unsigned int, unsigned int, unsigned int, unsigned int, unsigned int) (this=0x7fd136649380, aID=<optimized out>, aMapping=mozilla::dom::GamepadMappingType::_empty, aHand=mozilla::dom::GamepadHand::_empty, aNumButtons=11, aNumAxes=8, aHaptics=0, aNumLightIndicator=0, aNumTouchEvents=0) at /home/emilio/src/moz/gecko-4/dom/gamepad/GamepadPlatformService.cpp:96 #13 0x00007fd19326de4a in (anonymous namespace)::LinuxGamepadService::AddDevice(mozilla::udev_device*) (this=<optimized out>, dev=<optimized out>) at /home/emilio/src/moz/gecko-4/dom/gamepad/linux/LinuxGamepad.cpp:139 #14 0x00007fd19326a156 in (anonymous namespace)::LinuxGamepadService::ScanForDevices() (this=<optimized out>) at /home/emilio/src/moz/gecko-4/dom/gamepad/linux/LinuxGamepad.cpp:188 #15 (anonymous namespace)::LinuxGamepadService::Startup() (this=<optimized out>) at /home/emilio/src/moz/gecko-4/dom/gamepad/linux/LinuxGamepad.cpp:233 #16 mozilla::dom::StartGamepadMonitoring() () at /home/emilio/src/moz/gecko-4/dom/gamepad/linux/LinuxGamepad.cpp:334 #17 0x00007fd193269c6b in mozilla::dom::GamepadPlatformService::AddChannelParent(mozilla::dom::GamepadEventChannelParent*) (this=<optimized out>, aParent=<optimized out>) at /home/emilio/src/moz/gecko-4/dom/gamepad/GamepadPlatformService.cpp:225 #18 0x00007fd19326d175 in mozilla::dom::GamepadEventChannelParent::Init() (this=0x7fd136e76a00) at /home/emilio/src/moz/gecko-4/dom/gamepad/ipc/GamepadEventChannelParent.cpp:50 #19 0x00007fd1913ba3a6 in mozilla::ipc::BackgroundParentImpl::RecvPGamepadEventChannelConstructor(mozilla::dom::PGamepadEventChannelParent*) (this=0x7fd13f888000, aActor=0x0) at /home/emilio/src/moz/gecko-4/ipc/glue/BackgroundParentImpl.cpp:1109 #20 0x00007fd1917c7da1 in mozilla::ipc::PBackgroundParent::OnMessageReceived(IPC::Message const&) (this=0x7fd13f888000, msg__=...) at PBackgroundParent.cpp:4967 #21 0x00007fd1913ea71d in mozilla::ipc::MessageChannel::DispatchAsyncMessage(mozilla::ipc::ActorLifecycleProxy*, IPC::Message const&) (this=0x7fd13f8880f8, aProxy=0x7fd13ff48140, aMsg=...) Differential Revision: https://phabricator.services.mozilla.com/D87967

1. Ship the Sanitization (currently on in Nightly but without crashing) to the trains 2. Enabling crashing in Nightly mykmelez#1 will start omitting the preference values in Content Processes. An affected user will have their browser behave differently - it will be as if the preference has no value. So for e.g. the font preferences, their font customizations will be gone. If they file a bug about this happening and an engineer connects the problem to pref sanitization we could debug the issue and maybe understand it. mykmelez#2 will mean that an affected user (of which there are currently none we think) will have a content process crash when they access a forbidden preference. The crash reason will contain the name of the preference, and the stack which would help us better understand why we crashed. Differential Revision: https://phabricator.services.mozilla.com/D167287

…brtc-reviewers,pehrsons, a=dmeehan Make the new API available to everyone and just return an empty capturer in case when building without PipeWire. It will not make any difference because using X11 based capturers on Wayland is useless anyway so if we fail for missing PipeWire on Wayland, it will have the same outcome. Differential Revision: https://phabricator.services.mozilla.com/D171192

…ding error in page.py test, a=testonly Automatic update from web-platform-tests [wdspec] browsingContext.print: fix rounding error in page.py test (#40504) * [wdspec] browsingContext.print: fix rounding error in page.py test [pytest](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/webdriver/tests/support/image.py) uses: def cm_to_px(cm): return round(cm * 96 / 2.54) [js](https://github.com/web-platform-tests/wpt/blob/7a087d54be8b6c0ca0181a86dc1ff0b28461c383/tools/wptrunner/wptrunner/print_pdf_runner.html) uses: const viewport = page.getViewport({ scale: 96. / 72. }); ... canvas.height = viewport.height; canvas.width = viewport.width; This produces a rounding error, even though the dimension is correct: > assert cm_to_px(expected_dimensions["height"]) == height E assert 454 == 453 E +454 E -453 The inconsistency of rounding in both ends becomes clear when we eliminate "round" in the pytest side: > assert cm_to_px(expected_dimensions["height"]) == height E assert 453.54330708661416 == 453 E +453.54330708661416 E -453 There are multiple ways to fix this issue. Option mykmelez#1: Use "floor" instead of "round" in pytest. Option mykmelez#2: Use a range in the assertion comparison, allowing a difference of up to +-1.0. This is what this PR does. The comparison is performed in [`assert_pdf_dimensions`](https://github.com/web-platform-tests/wpt/blob/b6107cc1ac8b9c2800b4c8e58af719b8e4d9b8db/webdriver/tests/support/fixtures_bidi.py#L210). The problematic part is .96 / .72 which evaluates to 4/3 = 1.333333.... * use floor in cm_to_px instead of round * compare to floor and to round instead of a range * Revert "compare to floor and to round instead of a range" This reverts commit 63f894e6d1881616e0f13b7a40ddcb30b772eba8. * Revert "use floor in cm_to_px instead of round" This reverts commit 7e65d918b25575060ca50009d261d1e76dca6cae. -- wpt-commits: fb57353809aa19c0659ece5563d05ed20706d1fc wpt-pr: 40504

We already cherry-picked this when we vendored e46e37b6f8. Upstream commit: https://webrtc.googlesource.com/src/+/ba943f71e64a93558a51e75d18917f363b8672e9 [M115] 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) 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/+/308000 Reviewed-by: Mirko Bonadei <mbonadei@webrtc.org> Cr-Commit-Position: refs/branch-heads/5790@{mykmelez#2} Cr-Branched-From: 2eacbbc03a4a41ea658661225eb1c8fc07884c33-refs/heads/main@{#40122}

We already cherry-picked this when we vendored 402f60c2ea. Upstream commit: https://webrtc.googlesource.com/src/+/70aa7e99e4af06e9a2273793179dfcfddad11898 [Merge to 117] CHECK against overwrites in send_modules_map_ (cherry picked from commit 9d8fb97b3ca56ec9920271d8e545ae2ac76b143c) No-try: true Bug: chromium:1477075 Change-Id: Ia05a868bfab9e99ef66704e8d6bce516a7a43b0a Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/318440 Reviewed-by: Sergey Silkin <ssilkin@webrtc.org> Commit-Queue: Harald Alvestrand <hta@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40673} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/319100 Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org> Cr-Commit-Position: refs/branch-heads/5938@{mykmelez#2} Cr-Branched-From: 82e5f91a2bdf955aa870142008fbdc9ac12f6acd-refs/heads/main@{#40524}

Upstream commit: https://webrtc.googlesource.com/src/+/52bc9f7c1205f4b731ea0289b059f7d240c1e228 [Merge M119] Return error when requested codec is preferred but not negotiated Because of our asymmetrical codec situation, it's possible to have send only codecs that we cannot negotiate even with ourselves. This means that we should not have a DCHECK, but just a plain error. (cherry picked from commit 1adea9806d7aec9b5f91181231ccc31fef3b115f) Bug: chromium:1442194, webrtc:15064 Change-Id: I0c170e5c7f356197bcb04bcecb8259c344423ccb Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/323183 Reviewed-by: Harald Alvestrand <hta@webrtc.org> Commit-Queue: Florent Castelli <orphis@webrtc.org> Cr-Original-Commit-Position: refs/heads/main@{#40939} No-Try: True Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/324044 Reviewed-by: Guido Urdaneta <guidou@webrtc.org> Cr-Commit-Position: refs/branch-heads/6045@{mykmelez#2} Cr-Branched-From: bce7ce7ba054ac0e79fed49b84ef52fb24c31778-refs/heads/main@{#40854}

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 mykmelez#1 0x5591400a52ef in webrtc::DecisionLogic::ExpectedPacketAvailable(webrtc::NetEqController::NetEqStatus) ./../../modules/audio_coding/neteq/decision_logic.cc:311:36 mykmelez#2 0x5591400a39e9 in webrtc::DecisionLogic::GetDecision(webrtc::NetEqController::NetEqStatus const&, bool*) ./../../modules/audio_coding/neteq/decision_logic.cc:0:0 mykmelez#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/+/e7686023a186ac233ed1284da45cc166c0df4e1a [M128] PipeWire camera: Annotate functions with PipeWire calls to avoid CFI Similar to PipeWire implementation of desktop capture, we have to avoid CFI check for calls of dlopened PipeWire library. This avoid crashing PipeWire camera backend when "is_official_build=true" option is used as this turns on "is_cfi=true" enabling control flow integrity. iOS bots are broken due to xcode version mismatch. But the change is linux-only, so they are irrelevant. Disabling presubmit checks. (cherry picked from commit 9e755f0e19a9f3fdd5015283b5328fc65a7bfe1c) No-Try: true Bug: chromium:354776214 Change-Id: I7a9fc1c2d77c4ee0e8fe0586369b7246e0bb9180 Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/358103 Commit-Queue: Jan Grulich <grulja@gmail.com> Reviewed-by: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Alexander Cooper <alcooper@chromium.org> Cr-Original-Commit-Position: refs/heads/main@{#42706} Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/359162 Commit-Queue: Ilya Nikolaevskiy <ilnik@webrtc.org> Reviewed-by: Jan Grulich <grulja@gmail.com> Cr-Commit-Position: refs/branch-heads/6613@{mykmelez#2} Cr-Branched-From: 1ac162ee20a214bf97f6594a7effcbbc21f1effb-refs/heads/main@{#42664}

azure-pipelines bot and others added 13 commits October 17, 2018 18:55

Set up CI with Azure Pipelines

a7b7d3e

explicitly invoke bash when building

9c393c3

MozReview-Commit-ID: 6qNBdx6Tbss

move to job-based config; ensure SHELL defined

3b3b3d4

MozReview-Commit-ID: B375OSnZ5fK

make script name valid

8f541e6

MozReview-Commit-ID: AMFN3PhJ3HN

set shell for build command

714f90c

MozReview-Commit-ID: H28R5x5woxs

export SHELL via multi-line script

4aedd3b

MozReview-Commit-ID: ZFcEEwFIWr

maximize job run time

d9e6c42

MozReview-Commit-ID: FUI0Dx1J23w

add cbindgen executable path to PATH

88e6804

MozReview-Commit-ID: HwNxsB89q1e

try bootstrapping without explicit sudo

4cb325e

MozReview-Commit-ID: IY4E4JbqRfI

set SHELL when bootstrapping too

2dad3f4

MozReview-Commit-ID: 9qeJlz44FIU

arrange keys for steps in the order that Azure expects

9362516

MozReview-Commit-ID: GudHKRopDn8

log environment variables before and after sourcing cargo env file

4feb647

MozReview-Commit-ID: DF0AIxDm7Dt

don't source cargo env file unnecessarily

f209af2

MozReview-Commit-ID: 3qkifoEpLBk

mykmelez closed this in 3675297 Apr 25, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Set up CI with Azure Pipelines #2

Set up CI with Azure Pipelines #2

azure-pipelines bot commented Oct 17, 2018

Set up CI with Azure Pipelines #2

Set up CI with Azure Pipelines #2

Conversation

azure-pipelines bot commented Oct 17, 2018