Issue 883706  has been merged into this issue.

 Issue 884208  has been merged into this issue.

 Issue 884079  has been merged into this issue.

 Issue 884189  has been merged into this issue.

Also seeing this on ChromeOS Asan Lsan builder:  crbug.com/884204 

Reproducible crash on linux-chromeos:

Run --enable-features=SingleProcessMash
Navigate to https://videos.pexels.com/videos/adventure-trip-852359
Click play button on video

The video area has the aw-snap sad face.

This may be related to video playback failures in telemetry memory tests, like this:
./tools/perf/run_benchmark --browser=cros-chrome --remote=100.124.8.154 --extra-browser-args="--enable-feature=SingleProcessMash" --show-stdout --results-label=SingleProcessMash --also-run-disabled-tests memory.desktop

A copy of this video is used in telemetry memory tests.

FYI - The video is an .mp4 encoded with H.264. You might need an internal source checkout and/or GN arg is_chrome_branded = true to play it.

The DCHECK/crash reproduces if you download the file then open it in the Chrome OS file manager, so I think it's just the video and not something else about the page.

Taking off sheriff queue.

 Issue 884204  has been merged into this issue.

@James: tried to repro what's described in #6 with latest Chrome (71.0.3555.0), but not seeing the crash.  Rather, the video simply doesn't play, and pressing the 'play' button does nothing.  Everything works fine with the "--enable-features=SingleProcessMash" removed, though, so it doesn't look like a missing codec issue.  Attaching captured chrome logs.

In addition, when I download the video and play it through the Files app, only the audio plays, with a black screen.  Seeing this in the logs:

[1661:1791:0918/122519.581229:WARNING:url_request_job_manager.cc(90)] Failed to map: chrome-extension://invalid/
[1661:1661:0918/122519.643781:ERROR:private_api_drive.cc(819)] Not supported file system type.

It seems something is disabled for SingleProcessMash.  

I am admittedly using a pretty old version of CrOS.  Planning to update later today, and will run through this again.

Attaching the chrome logs mentioned in #10

Deleted: chrome_log.txt 4.3 KB

chrome_log.txt 4.3 KB View Download

Issue 880067 has been merged into this issue.

Attaching full stack trace from a recent failure (https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/linux-chromeos-dbg/7785):

#0 0x7f0bf8483f3d base::debug::StackTrace::StackTrace()
#1 0x7f0bf819587c base::debug::StackTrace::StackTrace()
#2 0x7f0bf81ff8cd logging::LogMessage::~LogMessage()
#3 0x7f0bf83dd07a base::trace_event::MemoryDumpManager::UnregisterDumpProviderInternal()
#4 0x7f0bf83dc60f base::trace_event::MemoryDumpManager::UnregisterDumpProvider()
#5 0x7f0befb982b9 ws::ContextProviderCommandBuffer::~ContextProviderCommandBuffer()
#6 0x7f0befb98c69 ws::ContextProviderCommandBuffer::~ContextProviderCommandBuffer()
#7 0x7f0befba0a0b base::RefCountedThreadSafe<>::DeleteInternal<>()
#8 0x7f0befba09d5 base::DefaultRefCountedThreadSafeTraits<>::Destruct()
#9 0x7f0befba00dc base::RefCountedThreadSafe<>::Release()
#10 0x7f0befb98f49 ws::ContextProviderCommandBuffer::Release()
#11 0x7f0bef3775f6 scoped_refptr<>::Release()
#12 0x7f0bef3775da scoped_refptr<>::~scoped_refptr()
#13 0x7f0befdbed74 _ZN4base8internal13FunctorTraitsIZN12_GLOBAL__N_129PostContextProviderToCallbackE13scoped_refptrINS_22SingleThreadTaskRunnerEES3_IN3viz15ContextProviderEENS_12OnceCallbackIFvbS8_EEEE3$_0vE6InvokeISC_JS8_SB_EEEvOT_DpOT0_
#14 0x7f0befdbeced _ZN4base8internal12InvokeHelperILb0EvE8MakeItSoIZN12_GLOBAL__N_129PostContextProviderToCallbackE13scoped_refptrINS_22SingleThreadTaskRunnerEES5_IN3viz15ContextProviderEENS_12OnceCallbackIFvbSA_EEEE3$_0JSA_SD_EEEvOT_DpOT0_
#15 0x7f0befdbec9d _ZN4base8internal7InvokerINS0_9BindStateIZN12_GLOBAL__N_129PostContextProviderToCallbackE13scoped_refptrINS_22SingleThreadTaskRunnerEES4_IN3viz15ContextProviderEENS_12OnceCallbackIFvbS9_EEEE3$_0JS9_SC_EEEFvvEE7RunImplISD_NSt3__15tupleIJS9_SC_EEEJLm0ELm1EEEEvOT_OT0_NSI_16integer_sequenceImJXspT1_EEEE
#16 0x7f0befdbeba9 _ZN4base8internal7InvokerINS0_9BindStateIZN12_GLOBAL__N_129PostContextProviderToCallbackE13scoped_refptrINS_22SingleThreadTaskRunnerEES4_IN3viz15ContextProviderEENS_12OnceCallbackIFvbS9_EEEE3$_0JS9_SC_EEEFvvEE7RunOnceEPNS0_13BindStateBaseE
#17 0x7f0bf814691e _ZNO4base12OnceCallbackIFvvEE3RunEv
#18 0x7f0bf8196cfa base::debug::TaskAnnotator::RunTask()
#19 0x7f0bf836a392 base::sequence_manager::internal::ThreadControllerImpl::DoWork()
#20 0x7f0bf836cef1 _ZN4base8internal13FunctorTraitsIMNS_16sequence_manager8internal20ThreadControllerImplEFvNS4_8WorkTypeEEvE6InvokeIS7_RKNS_7WeakPtrIS4_EEJRKS5_EEEvT_OT0_DpOT1_
#21 0x7f0bf836ce55 _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMNS_16sequence_manager8internal20ThreadControllerImplEFvNS6_8WorkTypeEERKNS_7WeakPtrIS6_EEJRKS7_EEEvOT_OT0_DpOT1_
#22 0x7f0bf836cdcd _ZN4base8internal7InvokerINS0_9BindStateIMNS_16sequence_manager8internal20ThreadControllerImplEFvNS5_8WorkTypeEEJNS_7WeakPtrIS5_EES6_EEEFvvEE7RunImplIRKS8_RKNSt3__15tupleIJSA_S6_EEEJLm0ELm1EEEEvOT_OT0_NSH_16integer_sequenceImJXspT1_EEEE
#23 0x7f0bf836cccc _ZN4base8internal7InvokerINS0_9BindStateIMNS_16sequence_manager8internal20ThreadControllerImplEFvNS5_8WorkTypeEEJNS_7WeakPtrIS5_EES6_EEEFvvEE3RunEPNS0_13BindStateBaseE
#24 0x7f0bf814116d _ZNKR4base17RepeatingCallbackIFvvEE3RunEv
#25 0x7f0bf836d395 _ZN4base8internal22CancelableCallbackImplINS_17RepeatingCallbackIFvvEEEE16ForwardRepeatingIJEEEvDpT_
#26 0x7f0bf8217e9f _ZN4base8internal13FunctorTraitsIMNS_8chromeos21MemoryPressureMonitorEFvvEvE6InvokeIS5_NS_7WeakPtrIS3_EEJEEEvT_OT0_DpOT1_
#27 0x7f0bf836d56a _ZN4base8internal12InvokeHelperILb1EvE8MakeItSoIRKMNS0_22CancelableCallbackImplINS_17RepeatingCallbackIFvvEEEEEFvvERKNS_7WeakPtrIS8_EEJEEEvOT_OT0_DpOT1_
#28 0x7f0bf836d500 _ZN4base8internal7InvokerINS0_9BindStateIMNS0_22CancelableCallbackImplINS_17RepeatingCallbackIFvvEEEEEFvvEJNS_7WeakPtrIS7_EEEEES5_E7RunImplIRKS9_RKNSt3__15tupleIJSB_EEEJLm0EEEEvOT_OT0_NSH_16integer_sequenceImJXspT1_EEEE
#29 0x7f0bf836d43c _ZN4base8internal7InvokerINS0_9BindStateIMNS0_22CancelableCallbackImplINS_17RepeatingCallbackIFvvEEEEEFvvEJNS_7WeakPtrIS7_EEEEES5_E3RunEPNS0_13BindStateBaseE
#30 0x7f0bf814691e _ZNO4base12OnceCallbackIFvvEE3RunEv
#31 0x7f0bf8196cfa base::debug::TaskAnnotator::RunTask()
#32 0x7f0bf8225338 base::MessageLoop::RunTask()
#33 0x7f0bf822563b base::MessageLoop::DeferOrRunPendingTask()
#34 0x7f0bf8225d85 base::MessageLoop::DoDelayedWork()
#35 0x7f0bf822c5c8 base::MessagePumpDefault::Run()
#36 0x7f0bf8224b0e base::MessageLoop::Run()
#37 0x7f0bf82cc4f2 base::RunLoop::Run()
#38 0x7f0bf01139e5 content::RendererMain()
#39 0x7f0bf033e603 content::RunZygote()
#40 0x7f0bf0340999 content::RunOtherNamedProcessTypeMain()
#41 0x7f0bf0342d91 content::ContentMainRunnerImpl::Run()
#42 0x7f0bf0337ebc content::ContentServiceManagerMainDelegate::RunEmbedderProcess()
#43 0x7f0be5cfdb31 service_manager::Main()
#44 0x7f0bf033e035 content::ContentMain()
#45 0x0000080d89a9 content::LaunchTests()
#46 0x000006cb2e7a LaunchChromeTests()
#47 0x000006cb13ab main
#48 0x7f0bca9ebf45 __libc_start_main
#49 0x000000a80a8a _start

content::RendererMain() in the stack indicates the failure is in the renderer process.  The renderer constructs the context provider/buffer and binds it to the current thread here: https://cs.chromium.org/chromium/src/content/renderer/render_thread_impl.cc?rcl=5e4b28b18d666cb9c38cbaee8bcd3c650a4fb0b3&l=1945.  That code is behind a IsUsingWindowService() conditional, which explains why we are only seeing this failure in single_process_mash_browser_tests.

The DCHECK is hit presumably because the destruction of the command buffer and its construction and subsequent binding to the current thread are happening on different threads.

 Issue 883884  has been merged into this issue.

After some digging it looks like the regression was introduced by https://crrev.com/c/1176879.  Reverting that change, along with a dependent CL https://crrev.com/c/1090031, causes the DCHECK's to go away.

Reassigning to lethalantidote@ to help take a look.

Steps to repro:
1. Build browser_tests with these gn args:
is_debug = true
target_os = "chromeos

2. Run the MediaEngagementBrowserTest suite with --enable-features="SingleProcessMash".  Command-line:
python testing/xvfb.py out/Debug/browser_tests --brave-new-test-launcher --test-launcher-bot-mode --cfi-diag=0 --override-use-software-gl-for-tests --gtest_filter=MediaEngagementBrowserTest.* --enable-features=SingleProcessMash

From my investigation, the main thread is trying to destruct a ContextProviderCommandBuffer (after running a task posted from PostContextProviderToCallback in src/content/renderer/media/media_factory.cc) that was constructed by TaskSchedulerSingleThreadSharedForegroundBlocking0 and that is bound to that thread's task runner.  That single thread task runner looks to be the one added by https://crrev.com/c/1176879.

Thanks for the repro steps! They were very clear. Let me see if I can figure this out.

Sidenote... is the any reason why when I run these tests I heard a loud ringing beep? 

The feature is was disabled for mash, see:
https://chromium.googlesource.com/chromium/src/+blame/daf6f231d72f09a419c3cb0c18c1de4b24d0cafb/content/renderer/media/media_factory.cc#142

It was later changed to be disabled for AshInBrowserProcess by sky@:
https://chromium.googlesource.com/chromium/src/+blame/6fca131df518b7eb77eb53875e56c9c1ba55da3d/content/renderer/media/media_factory.cc#142

And jamescook@ changed it to be IsMultiProcessMash:
https://cs.chromium.org/chromium/src/content/renderer/media/media_factory.cc?rcl=2afc1abc8d3fbcf7bbc08d7f357ed4e29156cd39&l=143

Is it possible that something was lost in translation?

fsamuel/sky - Are video surface layers expected to work in single-process mash?

If not, then https://chromium.googlesource.com/chromium/src/+blame/6fca131df518b7eb77eb53875e56c9c1ba55da3d/content/renderer/media/media_factory.cc#142 was wrong and it should be !IsUsingWindowService().

The work to make single-process-mash not use window-service from renderers [1] should resolve this issue I think

[1] https://chromium-review.googlesource.com/c/chromium/src/+/1233174

OK. I'll skip the MediaEngagement browser tests on SingleProcessMash via filter file until the CL in #28 lands. I'll also put back MediaEngagementAutoplayBrowserTest.UsePreloadedData_Allowed on Linux, which was disabled on all Linux plaforms for this issue.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/47a3f38c37bc545b01c1f8eb90322ff057320fac

commit 47a3f38c37bc545b01c1f8eb90322ff057320fac
Author: James Cook <jamescook@chromium.org>
Date: Thu Sep 20 19:21:11 2018

Re-enable MediaEngagementAutoplayBrowserTest.UsePreloadedData_Allowed

It was disabled on all Linux platforms due to failures on Chrome OS
in SingleProcessMash browser_tests.

Instead, disable all MediaEngagement browser_tests via filter file
for SingleProcessMash. There's a fix in-flight for renderer
embedding in this mode, so I expect to re-enable them shortly.

Bug:  884589 ,  883706 , 881574
Change-Id: If6257ea160c7ba83c9bb322941001ce5ab1cc1b7
Reviewed-on: https://chromium-review.googlesource.com/1236836
Reviewed-by: Becca Hughes <beccahughes@chromium.org>
Commit-Queue: James Cook <jamescook@chromium.org>
Cr-Commit-Position: refs/heads/master@{#592897}
[modify] https://crrev.com/47a3f38c37bc545b01c1f8eb90322ff057320fac/chrome/browser/media/media_engagement_autoplay_browsertest.cc
[modify] https://crrev.com/47a3f38c37bc545b01c1f8eb90322ff057320fac/testing/buildbot/filters/chromeos.single_process_mash.browser_tests.filter

I have a fix I believe, so we may not need to disable the tests. 
https://chromium-review.googlesource.com/c/chromium/src/+/1237236

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fa3fba861b9ed08d48b8d704b548be20f7d21cbe

commit fa3fba861b9ed08d48b8d704b548be20f7d21cbe
Author: CJ DiMeglio <lethalantidote@chromium.org>
Date: Thu Sep 20 22:03:33 2018

Adds std::move so we don't drop the scoped_refptr on the wrong thread.

Bug:  884589 
Change-Id: Id7a1b04a2b533584637f0fee425144acb0b8d79a
Reviewed-on: https://chromium-review.googlesource.com/1237236
Reviewed-by: Dale Curtis <dalecurtis@chromium.org>
Commit-Queue: CJ DiMeglio <lethalantidote@chromium.org>
Cr-Commit-Position: refs/heads/master@{#592965}
[modify] https://crrev.com/fa3fba861b9ed08d48b8d704b548be20f7d21cbe/content/renderer/media/media_factory.cc

Thanks for taking a look!  With crrev.com/c/1237236, I am still seeing some failures when I run the tests, though they are a lot less frequent now.  I need to run it a few times to see a failure, and the retry usually passes.  It's less urgent now, since we think the renderer embedding change should address this.  Thought I'd note the occasional failures here in any case, though.

Also, this failure was seen with the EncryptedMedia tests as well, and is why they are also blacklisted for SingleProcessMash: https://cs.chromium.org/chromium/src/testing/buildbot/filters/chromeos.single_process_mash.browser_tests.filter?rcl=53f3d30ef104e4c91ab0d7eb9683305139072ef3&l=175.  Those tests can be restored as well once the issue is confirmed to be fixed.

rcui volunteered to follow up here. Thanks!

crrev.com/c/1233174 has landed, and I am no longer seeing any failures after running the tests a bunch of times.  So marking this as fixed.  Thanks all! 

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/49da3db8af5c28429b3afc7c92a31df3eb531692

commit 49da3db8af5c28429b3afc7c92a31df3eb531692
Author: Xiyuan Xia <xiyuan@chromium.org>
Date: Mon Sep 24 21:56:51 2018

Enable tests disabled for MemoryDumpManager DCHECK

sky's crrev.com/c/1233174 resolved the destruction threading
issue.

Bug:  874089 ,  884589 
Change-Id: I35b2ffee918626b6d83e497ff0a0d3dae7f27024
Reviewed-on: https://chromium-review.googlesource.com/1241315
Reviewed-by: James Cook <jamescook@chromium.org>
Commit-Queue: Xiyuan Xia <xiyuan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#593700}
[modify] https://crrev.com/49da3db8af5c28429b3afc7c92a31df3eb531692/testing/buildbot/filters/chromeos.single_process_mash.content_browsertests.filter

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/d3b31cd0baff4e80d8dcc5acbf93caaf1fbf1876

commit d3b31cd0baff4e80d8dcc5acbf93caaf1fbf1876
Author: Ryan Cui <rcui@chromium.org>
Date: Wed Sep 26 22:15:22 2018

Re-enable some previously flaky single_process_mash_browser_tests

Tests were blacklisted because of flakiness due to  crbug.com/884589 .  Now that it's fixed, renable these tests.

Bug:  884589 
Change-Id: Idc1b073c7a50636778231177488112f778d649b5
Reviewed-on: https://chromium-review.googlesource.com/1246954
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Ryan Cui <rcui@chromium.org>
Cr-Commit-Position: refs/heads/master@{#594499}
[modify] https://crrev.com/d3b31cd0baff4e80d8dcc5acbf93caaf1fbf1876/testing/buildbot/filters/chromeos.single_process_mash.browser_tests.filter

The tests still flake unfortunately, I will re-disable them.

Sample failures:
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/29200
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/29201
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/29202
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/29203
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/29203
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/29208

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8ff086cbcc47ff000230aee72a698070618c27e0

commit 8ff086cbcc47ff000230aee72a698070618c27e0
Author: Marina Ciocea <marinaciocea@chromium.org>
Date: Thu Sep 27 11:46:06 2018

Revert "Re-enable some previously flaky single_process_mash_browser_tests"

This reverts commit d3b31cd0baff4e80d8dcc5acbf93caaf1fbf1876.

Reason for revert: Tests are still flaky:

 https://crbug.com/884589#c40 
Sample failures:
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/29200
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/29201
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/29202
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/29203
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/29203
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/Linux%20Chromium%20OS%20ASan%20LSan%20Tests%20%281%29/29208

Original change's description:
> Re-enable some previously flaky single_process_mash_browser_tests
> 
> Tests were blacklisted because of flakiness due to  crbug.com/884589 .  Now that it's fixed, renable these tests.
> 
> Bug:  884589 
> Change-Id: Idc1b073c7a50636778231177488112f778d649b5
> Reviewed-on: https://chromium-review.googlesource.com/1246954
> Reviewed-by: Scott Violet <sky@chromium.org>
> Commit-Queue: Ryan Cui <rcui@chromium.org>
> Cr-Commit-Position: refs/heads/master@{#594499}

TBR=sky@chromium.org,rcui@chromium.org

Change-Id: I9d2591b7f847270af395765fd0f27b4fd67c8045
No-Presubmit: true
No-Tree-Checks: true
No-Try: true
Bug:  884589 
Reviewed-on: https://chromium-review.googlesource.com/1249263
Reviewed-by: Marina Ciocea <marinaciocea@chromium.org>
Commit-Queue: Marina Ciocea <marinaciocea@chromium.org>
Cr-Commit-Position: refs/heads/master@{#594673}
[modify] https://crrev.com/8ff086cbcc47ff000230aee72a698070618c27e0/testing/buildbot/filters/chromeos.single_process_mash.browser_tests.filter

The failures in #40 are different. It is no longer the threading DCHECK but memory leaks. IMO, we should open a new bug to track that. The test itself actually passes. 


 =================================================================
 ==18360==ERROR: LeakSanitizer: detected memory leaks
 Direct leak of 2744 byte(s) in 2 object(s) allocated from:
 #0 0xfe1a23 in __interceptor_malloc /b/swarming/w/ir/kitchen-workdir/src/third_party/llvm/compiler-rt/lib/asan/asan_malloc_linux.cc:146:3
 #1 0x1e5fec78 in PartitionAllocGenericFlags base/allocator/partition_allocator/partition_alloc.h:354:48
 #2 0x1e5fec78 in Alloc base/allocator/partition_allocator/partition_alloc.h:382
 #3 0x1e5fec78 in BufferMalloc third_party/blink/renderer/platform/wtf/allocator/partitions.h:97
 #4 0x1e5fec78 in WTF::StringImpl::CreateUninitialized(unsigned int, unsigned char*&) third_party/blink/renderer/platform/wtf/text/string_impl.cc:115
 #5 0x1e68253a in StringBuffer third_party/blink/renderer/platform/wtf/text/string_buffer.h:49:13
 #6 0x1e68253a in WTF::TextCodecUTF8::Decode(char const*, unsigned long, WTF::FlushBehavior, bool, bool&) third_party/blink/renderer/platform/wtf/text/text_codec_utf8.cc:297
 #7 0x21101860 in blink::TextResourceDecoder::Decode(char const*, unsigned long) third_party/blink/renderer/core/html/parser/text_resource_decoder.cc:453:27
 #8 0x27edeaf9 in blink::DecodedDataDocumentParser::AppendBytes(char const*, unsigned long) third_party/blink/renderer/core/dom/decoded_data_document_parser.cc:67:30
....
[ OK ] MSE_ExternalClearKey/EncryptedMediaTest.Playback_VideoClearAudio_WebM/0 (8732 ms)

Filed bug  crbug.com/889993  to track the memory leak.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/03f18beb5a0de3b7c42a5d4e0e47bf59ccc08c0a

commit 03f18beb5a0de3b7c42a5d4e0e47bf59ccc08c0a
Author: Ryan Cui <rcui@chromium.org>
Date: Fri Sep 28 14:36:42 2018

Re-enable MediaEngagementBrowserTest's

The tests were previously flaky because of  crbug.com/884589 .  Now that it's fixed, renable these tests.

The EncryptedMediaTest's used to fail for the same reason, but are now failing because of a memory leak ( crbug.com/889993 ), so keep these disabled for now.

Bug:  884589 
Change-Id: Ia394e710d47f995f64ce858a51439ad11bdc2518
Reviewed-on: https://chromium-review.googlesource.com/1249913
Reviewed-by: Scott Violet <sky@chromium.org>
Commit-Queue: Ryan Cui <rcui@chromium.org>
Cr-Commit-Position: refs/heads/master@{#595084}
[modify] https://crrev.com/03f18beb5a0de3b7c42a5d4e0e47bf59ccc08c0a/testing/buildbot/filters/chromeos.single_process_mash.browser_tests.filter

Closing out now that MediaEngagementBrowserTest's have been re-enabled, and no longer flaky[1].

[1] https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=single_process_mash_browser_tests&tests=MediaEngagementBrowserTest