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

commit eb03356980c8832402533d71bcc9aa29f9692141
Author: Max Morin <maxmorin@chromium.org>
Date: Thu Aug 17 08:18:23 2017

Disable FullscreenElementInMultipleSubframes

Disables
SitePerProcessInteractiveBrowserTest.FullscreenElementInMultipleSubframes
on Chrome OS and Mac.

BUG=756338
NOTRY=true
TBR=alexmos

Change-Id: I3ca2bc9e06d32adc1cad056fe11fa07ee5545078
Reviewed-on: https://chromium-review.googlesource.com/618329
Reviewed-by: Max Morin <maxmorin@chromium.org>
Commit-Queue: Max Morin <maxmorin@chromium.org>
Cr-Commit-Position: refs/heads/master@{#495107}
[modify] https://crrev.com/eb03356980c8832402533d71bcc9aa29f9692141/chrome/browser/site_per_process_interactive_browsertest.cc

 Issue 754784  has been merged into this issue.

This is failing on the Site Isolation Windows FYI bot as well:
https://ci.chromium.org/buildbot/chromium.fyi/Site%20Isolation%20Win/22460

Alex, any chance you could take a look and/or disable?

Example output:

Still waiting for the following processes to finish:
	".\interactive_ui_tests.exe" --brave-new-test-launcher --cfi-diag=0 --gtest_also_run_disabled_tests --gtest_filter=SitePerProcessInteractiveBrowserTest.FullscreenElementInMultipleSubframes --single_process --site-per-process --snapshot-output-dir="e:\b\s\w\ioumg9ib" --test-launcher-bot-mode --test-launcher-output="C:\Users\CHROME~2\AppData\Local\Temp\scoped_dir5196_1143\results5196_5356\test_results.xml" --test-launcher-summary-output="e:\b\s\w\ioumg9ib\output.json" --user-data-dir="C:\Users\CHROME~2\AppData\Local\Temp\scoped_dir5196_1143\d5196_27126"
Still waiting for the following processes to finish:
	".\interactive_ui_tests.exe" --brave-new-test-launcher --cfi-diag=0 --gtest_also_run_disabled_tests --gtest_filter=SitePerProcessInteractiveBrowserTest.FullscreenElementInMultipleSubframes --single_process --site-per-process --snapshot-output-dir="e:\b\s\w\ioumg9ib" --test-launcher-bot-mode --test-launcher-output="C:\Users\CHROME~2\AppData\Local\Temp\scoped_dir5196_1143\results5196_5356\test_results.xml" --test-launcher-summary-output="e:\b\s\w\ioumg9ib\output.json" --user-data-dir="C:\Users\CHROME~2\AppData\Local\Temp\scoped_dir5196_1143\d5196_27126"
[0201/102230.606:FATAL:thread_task_runner_handle.cc(29)] Check failed: current. Error: This caller requires a single-threaded context (i.e. the current task needs to run from a SingleThreadTaskRunner).
Backtrace:
	base::debug::StackTrace::StackTrace [0x0345E780+32]
	base::debug::StackTrace::StackTrace [0x0342842D+13]
	logging::LogMessage::~LogMessage [0x033BD2B0+80]
	base::ThreadTaskRunnerHandle::Get [0x033D37F5+101]
	base::RunLoop::RunLoop [0x033D4FF0+80]
	SaveDesktopSnapshot [0x01351304+932]
	SaveDesktopSnapshot [0x01351037+215]
	KillAlwaysOnTopWindows [0x0134B8F7+123]
	InteractiveUITestLauncherDelegate::OnTestTimedOut [0x013507DD+13]
	base::GetTestOutputSnippet [0x033B4940+1229]
	base::TestLauncher::LaunchChildGTestProcess [0x033B2875+1273]
	base::internal::FunctorTraits<void (__cdecl*)(base::CommandLine const &,base::TimeDelta,base::TestLauncher::LaunchOptions const &,bool,base::SingleThreadTaskRunner *,std::unique_ptr<base::ProcessLifetimeObserver,std::default_delete<base::ProcessLifetimeOb [0x033B53EF+81]
	base::internal::Invoker<base::internal::BindState<void (__cdecl*)(base::CommandLine const &,base::TimeDelta,base::TestLauncher::LaunchOptions const &,bool,base::SingleThreadTaskRunner *,std::unique_ptr<base::ProcessLifetimeObserver,std::default_delete<bas [0x033B537A+74]
	base::debug::TaskAnnotator::RunTask [0x0345B127+231]
	base::internal::TaskTracker::RunOrSkipTask [0x03467A00+640]
	base::internal::TaskTracker::RunNextTask [0x0346702D+397]
	base::internal::SchedulerWorker::Thread::ThreadMain [0x0349ECDF+623]
	base::PlatformThread::GetCurrentThreadPriority [0x033F3FA5+469]
	BaseThreadInitThunk [0x76CD336A+18]
	RtlInitializeExceptionChain [0x776E9902+99]
	RtlInitializeExceptionChain [0x776E98D5+54]

fdoray: could this stack be a result of your change in r532260? I'll look at the snapshot code to see if it really needs a run loop. Maybe it doesn't.

To anyone else: the crash is in the code that runs when a test times out. The timeout itself is something else (and is a real problem that should be solved).

I have a fix to the crash up for review in https://chromium-review.googlesource.com/c/chromium/src/+/899349. This won't stop flaky tests from timing out, but it will stop the test harness from crashing when timeouts happen.

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

commit 3a004d565b29abb14b73eeecf7d056beea82cb3b
Author: Greg Thompson <grt@chromium.org>
Date: Tue Feb 06 09:00:59 2018

Fix DCHECK failure in SaveDesktopSnapshot.

This was causing a crash in interactive_ui_tests on Windows each time a
test timed out.

Based on a comment deep in WebRTC's capture code about a UI message
loop, I had previously taken pains to run a loop when capturing the
screen. Following some changes to base, this leads to a DCHECK failure
when the RunLoop is started. Looking deeper in WebRTC, I don't think
that a UI message loop is needed for the use at hand. In particular, the
comment was with regards to the use of the magnification API. Use of
this API is explicitly disabled by SaveDesktopSnapshot, so the capturer
is fully synchronous and doesn't need a message loop at all.

BUG=756338
R=sky@chromium.org

Change-Id: I92679a213e7bdf8dde03e0ab8e02c36f0fe2804b
Reviewed-on: https://chromium-review.googlesource.com/899349
Reviewed-by: Scott Violet <sky@chromium.org>
Reviewed-by: Tommi <tommi@chromium.org>
Commit-Queue: Greg Thompson <grt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534664}
[modify] https://crrev.com/3a004d565b29abb14b73eeecf7d056beea82cb3b/chrome/test/base/save_desktop_snapshot_win.cc

@alexmos any updates for this test coverage?

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

commit ec52747a5abc25a862843edca761104b3c319764
Author: Gabriel Charette <gab@chromium.org>
Date: Mon Jan 14 16:16:49 2019

[ui_controls] Unflake Send*NotifyWhenDone() on Windows

ui_controls::Send*NotifyWhenDone() can be flaky when invoked after
ui_controls::Send*() as the former can decide to notify based on
observing a yet-to-be-processed event from the latter (or even a
yet-to-be-processed event emitted by unrelated code) and thus notify too
early, resuming and testing conditions that have yet to be met.

Solution: defer the notification if the system queue has pending events
of the same type awaiting dispatch.

Note: mouse move can be repeated indefinitely during a drag, as such we
consider a mouse move complete when it hits the target regardless of
remaining mouse move messages in the queue.

@ BUG OWNERS : This might unflake many currently disabled tests. I've
CC'ed interactive_ui_tests + Windows bugs, please try to re-enable your
test after this CL if you think it might be related.

Bug:  892228 , 640996, 897801,893078,876224,875443,873110,852786,850343,848049,846695,840369,798492,756338,751031,665296,651906,499858,468660,419468,238347,131612,106489,97777,92467
Change-Id: I548856a3948ff71a145435799b4ba3e689561f14
Reviewed-on: https://chromium-review.googlesource.com/c/1392178
Reviewed-by: Sadrul Chowdhury <sadrul@chromium.org>
Reviewed-by: Greg Thompson <grt@chromium.org>
Reviewed-by: Peter Kasting <pkasting@chromium.org>
Commit-Queue: Gabriel Charette <gab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#622470}
[modify] https://crrev.com/ec52747a5abc25a862843edca761104b3c319764/chrome/browser/ui/views/bookmarks/bookmark_bar_view_test.cc
[modify] https://crrev.com/ec52747a5abc25a862843edca761104b3c319764/ui/base/test/ui_controls_internal_win.cc