More affected tests are:

GalleryBrowserTest.SelectAllImagesAfterImageDeletionOnDownloads
                  .TraverseSlideImagesOnDownloads
                  .StopStartSlideshowOnDownloads
                  .SlideshowTraversalOnDownloads
                  .OpenSingleImageOnDownloads
                  .SlideshowTraversalOnDrive
                  .TraverseSlideThumbnailsOnDownloads

AudioPlayerBrowserTest.TogglePlayState
AudioPlayerBrowserTest.ChangeVolumeLevel
VideoPlayerBrowserTest.OpenSingleVideoOnDownloads
QuickView/FileManagerBrowserTest.Test

Add this week's sheriffs. I could not identify the culprit CL. I could see the browser test failure as early as Nov 2017 (I didn't check more of them).

I am not sure what is the strategy here as there are multiple failures here, and not reliably failed on every test. We could wait on file app people working on this as this root cause only fails on dbg builders, which I think will not block CQ...

Looks like this error is already marked flaky: https://cs.chromium.org/chromium/src/testing/buildbot/filters/mojo.fyi.mash.browser_tests.filter?rcl=ad1c30462ddce13bc57a66d448381cce7563c0f6&l=103

Yes, but that filter is for browser_tests --mash. There are non-trivial flakiness on recent builds. We need to fix that : /

Still live: <https://uberchromegw.corp.google.com/i/chromium.chromiumos/builders/linux-chromeos-dbg/builds/3902>

Adding to the sheriff tracking list.  We should consider disabling these tests if we don't get traction (and we continue to see flaky test results).  This is the first time I've seen this error during my rotation so perhaps it is infrequent enough that we can leave then enabled.

I'm disabling the two tests in https://chromium-review.googlesource.com/c/chromium/src/+/886702

Thanks for handling.
I quickly looked at some tests and got that the cause is not obvious. I could not reproduce all of those locally.
By this reason I think it is reasonable to disable the tests until we do careful investigation.

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

commit cdb51726002968dfa4f0e88e44b6b69488275f25
Author: Vasilii Sukhanov <vasilii@chromium.org>
Date: Thu Jan 25 16:17:07 2018

Disable flaky GalleryBrowserTests.

GalleryBrowserTest.StopStartSlideshowOnDrive
GalleryBrowserTest.OpenSingleImageOnDownloads

TBR=yamaguchi@chromium.org

Bug:  804413 
Change-Id: I2c9e7874b8858bc9786f48fff2f3685871abae3f
Reviewed-on: https://chromium-review.googlesource.com/886702
Commit-Queue: Vasilii Sukhanov <vasilii@chromium.org>
Reviewed-by: Vasilii Sukhanov <vasilii@chromium.org>
Cr-Commit-Position: refs/heads/master@{#531911}
[modify] https://crrev.com/cdb51726002968dfa4f0e88e44b6b69488275f25/chrome/browser/chromeos/file_manager/gallery_browsertest.cc

https://ci.chromium.org/buildbot/chromium.chromiumos/linux-chromeos-rel/4627

release build is also flaky. We might want to disable it on non-debug build too.

Looks like https://chromium-review.googlesource.com/886702 broke GalleryBrowserTestInGuestMode.OpenSingleImageOnDownloads.

Fix here: https://crrev.com/c/887374

Hi, GalleryBrowserTestInGuestMode.OpenSingleImageOnDownloads is also failing on linux-chromeos-rel/: https://ci.chromium.org/buildbot/chromium.chromiumos/linux-chromeos-rel/

Could we just disable it for all builders?
I created a CL here: https://chromium-review.googlesource.com/c/chromium/src/+/887618

Let's land https://chromium-review.googlesource.com/c/chromium/src/+/887618 and the failure will be disabled.

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

commit 61912e82b004e6f2ca46647ce7c58e4cf9fefcc8
Author: Qiang Xu <warx@chromium.org>
Date: Fri Jan 26 20:28:58 2018

disable GalleryBrowserTestInGuestMode.OpenSingleImageOnDownloads

Disabling as this test is failing on linux-chromeos-rel builder.
See:
https://ci.chromium.org/buildbot/chromium.chromiumos/linux-chromeos-rel/4627

TBR=yamaguchi@chromium.org
TBR=yoshiki@chromium.org

Bug:  804413 
Change-Id: I9591ee8652fc7965b1261a8cf2f1666b6ae7d3ea
Reviewed-on: https://chromium-review.googlesource.com/887618
Reviewed-by: Vasilii Sukhanov <vasilii@chromium.org>
Reviewed-by: Qiang(Joe) Xu <warx@chromium.org>
Commit-Queue: Qiang(Joe) Xu <warx@chromium.org>
Cr-Commit-Position: refs/heads/master@{#532053}
[modify] https://crrev.com/61912e82b004e6f2ca46647ce7c58e4cf9fefcc8/chrome/browser/chromeos/file_manager/gallery_browsertest.cc

@yamaguchi Can you please review these disabled tests? Test coverage has been reduced with these disables.

QuickView/FileManagerBrowserTest.Test/1 is failing as well

https://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=QuickView%2FFileManagerBrowserTest.Test%2F1&testType=browser_tests

#17 example: https://logs.chromium.org/v/?s=chromium%2Fbb%2Fchromium.chromiumos%2Flinux-chromeos-dbg%2F4150%2F%2B%2Frecipes%2Fsteps%2Fbrowser_tests%2F0%2Flogs%2FQuickView__x2f_FileManagerBrowserTest.Test__x2f_1%2F0

 Issue 810743  has been merged into this issue.

Flakes keep coming

AudioPlayerBrowserTest.OpenAudioOnDownloads
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=AudioPlayerBrowserTest.OpenAudioOnDownloads&testType=browser_tests

AudioPlayerBrowserTest.ChangeVolumeLevel
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=AudioPlayerBrowserTest.ChangeVolumeLevel&testType=browser_tests

AudioPlayerBrowserTest.OpenAudioOnDrive
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=AudioPlayerBrowserTest.OpenAudioOnDrive&testType=browser_tests

Also VideoPlayerBrowserTest.CheckInitialElements
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=VideoPlayerBrowserTest.CheckInitialElements

 Issue 810969  has been merged into this issue.

Adding remaining file_manager owners. Can somebody please prioritize looking into this issue? This has been broken since at least November, and it affects so many tests that it's impractical to disable them all.

 Issue 811184  has been merged into this issue.

 Issue 803505  has been merged into this issue.

I could not get this in the business hours today. Let me release this bug once, just in case someone can handle in a different timezone.
I will continue to investigate this issue tomorrow with the top priority.

I tried to reproduce on buildbot but still have not got effective result. https://chromium-review.googlesource.com/c/chromium/src/+/904222

Re: assertion with FileSystemBackend::CanHandleType, TestFileSystemBackend only supports kFileSystem and some tests may pass a wrong type URL. However I cannot explain flakiness by this. I'd examine around this tomorrow.

Sheriff here. I can reproduce this locally by just running the Gallery* browser tests in a debug chromeos build. file_system_url.type() is becoming kFileSystemTypeUnknown (which is unsurprisingly not handled). The URLs look reasonable, though (e.g. "filesystem:chrome-extension://hhaomjibdihmijegdhdafkllkbggdgoj/isolated/F2E300172F2D4C9EB35C9C3646259F4F/fs/"), and do appear registered in an isolated context.

In the crashing case, we start with a URL of type 2 (kFileSystemTypeIsolated). Using the instance found by its filesystem ID, we get a URL of type 109 (kFileSystemTypeNativeForPlatformApp), which is cracked using the crackers and indices 0 and 1, the latter of which produces an invalid URL (type -1).

In successful cases, this results in a URL of type 101 (kFileSystemTypeNativeLocal) or 106 (kFileSystemTypeDrive).

The failing cracker in at least one instance is ExternalMountPoints, which is failing to turn

NativeForPlatformApp@69F21C4C1041F92831AA966AF2167FCA:/usr/local/google/home/jbroman/Downloads)
into
NativeLocal@Downloads-user:/usr/local/google/home/jbroman/Downloads

because the mount /usr/local/google/home/jbroman/Downloads is not present in ExternalMountPoints::path_to_name_map_ (but in other cases it is). Perhaps there is a race on the logic which populates this?

Diagnosis: the problem appears to be that file_manager::VolumeManager::RegisterDownloadsDirectoryForTesting (on the test main thread) is removing the mount before the browser main thread accesses it, but either doesn't add it back due to a validation issue or loses the race (N.B. storage::ExternalMountPoints::lock_ is not held between revoking and re-registering the downloads mount).

In progress. https://chromium-review.googlesource.com/c/chromium/src/+/919121

I think we can consider the cause is some race condition rather than failing to add a mount back.

The invocation of mount_points->RegisterFileSystem would have been success in the failure cases, because if it were returning false, it would have hit the DCHECK condition in SetupInMainThread.

https://cs.chromium.org/chromium/src/chrome/browser/chromeos/file_manager/volume_manager.cc?sq=package:chromium&l=69
> return mount_points->RegisterFileSystem(mount_point_name,
>                                          storage::kFileSystemTypeNativeLocal,
>                                          storage::FileSystemMountOption(),
>                                          path);

https://cs.chromium.org/chromium/src/chrome/browser/chromeos/file_manager/file_manager_browsertest_base.cc?sq=package:chromium&l=529
>  ASSERT_TRUE(local_volume_->Mount(profile()));

 Issue 811937  has been merged into this issue.

I could double check the analysis noted in Comment 33.
The map is first initialized normally and then overwritten for test. Incoming data is always normal ones (i.e. not /tmp/*), but the map is in either way sometimes. It causes mismatch leading to error.


I could have repro on my local environment by adding a 3 second delay in VolumeManager::Initialize(), before the line invoking RegisterDownloadsMountPoint.

A string like [/usr/local/google/home/yamaguchi/Downloads]
is passed as |path_in| to ExternalMountPoints::GetVirtualPath.

In the failure cases, the |path_to_name_map_| is like:

/special/drive-user/ | drive-user
/tmp/.org.chromium.Chromium.Y4oek2/do88ueS/user/Downloads/ | Downloads-user
/tmp/chromeos/media/archive/ | archive
/tmp/chromeos/media/removable/ | removable

whereas it's like

/special/drive-user/ | drive-user
/tmp/chromeos/media/archive/ | archive
/tmp/chromeos/media/removable/ | removable
/usr/local/google/home/yamaguchi/Downloads/ | Downloads-user
/usr/share/oem/ | oem

When it cannot find the exact match, it falls until this line in the function:
https://cs.chromium.org/chromium/src/storage/browser/fileapi/external_mount_points.cc?q=ExternalMountPoints::GetVirtualPath&sq=package:chromium&l=227
> return iter->first.AppendRelativePath(path, virtual_path);
since virtual_path is not a strict child of |path|, AppendRelativePath refuses to join and returns false, then produce empty URL in the caller.

I have just a beginner with this part, but I got a hypothesis that existing logic was written unintentionally inconsistent but was passing due to another unintentional asynchronous execution.
This is still an incomplete hypothesis not yet fully verified.

- There are 3 url_crackers_. These must be consistent to relay the transformation.
https://cs.chromium.org/chromium/src/storage/browser/fileapi/file_system_context.cc?q=FileSystemContext::CrackFileSystemURL&sq=package:chromium&l=551

- The first one (external_mount_points) is not relevant to this issue.
- The second one is made based on the mounted point in the test. (i.e. the Downloads location was /tmp/.org.* )
- The third one is based on Isolated Context. Generated based on the real profile (this is NOT verified) rather than the test filesystem. (i.e. the Downloads location was /usr/local/... )
- So the second and the third is inconsistent.
- However, due to unintentional asynchronous execution, the second one had also been generated based on the real profile.

I am thinking of revising it to make it emit the Isolated Context coupled with the test filesystem, but I need to consult someone who originally wrote these parts to make sure that's legit and not affect other parts badly.
+kinaba

 Issue 618198  has been merged into this issue.

We've decided to disable all the affected test cases as a tentative solution before fixing the root cause, because I got to work on a release blocker bug for the upcoming milestone right now.

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

commit b62afbeebd9a48eac6b7665d58133caa5ca2c611
Author: Tatsuhisa Yamaguchi <yamaguchi@chromium.org>
Date: Tue Feb 20 09:57:27 2018

Disable flaky tests affected by  crbug.com/804413 .

This is a tentative care to silence all flaky tests.
We have found all the tests using the test mount point info are flaky
affecting the trybot runs every time. So we'll disable all the affected
test before fixing the root cause.

Bug:  804413 
Change-Id: I6e97504db495e5cd9c06d7e2d43de6a9611a083d
Reviewed-on: https://chromium-review.googlesource.com/925878
Commit-Queue: Tatsuhisa Yamaguchi <yamaguchi@chromium.org>
Reviewed-by: Naoki Fukino <fukino@chromium.org>
Cr-Commit-Position: refs/heads/master@{#537747}
[modify] https://crrev.com/b62afbeebd9a48eac6b7665d58133caa5ca2c611/chrome/browser/chromeos/file_manager/audio_player_browsertest.cc
[modify] https://crrev.com/b62afbeebd9a48eac6b7665d58133caa5ca2c611/chrome/browser/chromeos/file_manager/file_manager_browsertest.cc
[modify] https://crrev.com/b62afbeebd9a48eac6b7665d58133caa5ca2c611/chrome/browser/chromeos/file_manager/gallery_browsertest.cc
[modify] https://crrev.com/b62afbeebd9a48eac6b7665d58133caa5ca2c611/chrome/browser/chromeos/file_manager/video_player_browsertest.cc

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

commit 94f8117c386b375b74aa6da33846fb83ade00d0a
Author: Greg Thompson <grt@chromium.org>
Date: Mon Mar 05 12:17:31 2018

Disable more flaky tests affected by  crbug.com/804413 .

This is a tentative care to silence all flaky tests.
We have found all the tests using the test mount point info are flaky
affecting the trybot runs every time. So we'll disable all the affected
test before fixing the root cause.

TBR=yamaguchi@chromium.org

Bug:  804413 
Change-Id: I7f711446accc61a8bedf00f52c328a1037a11791
Reviewed-on: https://chromium-review.googlesource.com/948483
Reviewed-by: Greg Thompson <grt@chromium.org>
Commit-Queue: Greg Thompson <grt@chromium.org>
Cr-Commit-Position: refs/heads/master@{#540806}
[modify] https://crrev.com/94f8117c386b375b74aa6da33846fb83ade00d0a/chrome/browser/chromeos/file_manager/gallery_browsertest.cc
[modify] https://crrev.com/94f8117c386b375b74aa6da33846fb83ade00d0a/chrome/browser/chromeos/file_manager/video_player_browsertest.cc

We lose a lot of coverage by leaving these tests disabled. Marking as P1 for M67, since we want to prioritise fixing our testing coverage.

Yamaguchi - I'm assuming you're no longer working on this? If so, please unassign yourself as owner and we'll find someone else to take this on.

@yamaguchi can you ptal at comment 46?

I am currently handling Zip Archiver issues. So it would be nice if someone else could handle this.

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

commit 29351787276873f7aed2e6e979721c596bc3bbfd
Author: Noel Gordon <noel@chromium.org>
Date: Tue Mar 27 05:44:27 2018

Enable GalleryBrowserTestInGuestMode::OpenSingleImageOnDownloads

Test was disabled in  issue 804413  due to the linux-chromeos-release bot
flakiness. Re-enable to determine if the test flakes on the CQ.

Tbr: fukino-san
Bug:  804413 
Change-Id: I14b1f3dfcb78123a3deadd227960cdb3db91a874
Reviewed-on: https://chromium-review.googlesource.com/981812
Reviewed-by: Sasha Morrissey <sashab@chromium.org>
Cr-Commit-Position: refs/heads/master@{#546029}
[modify] https://crrev.com/29351787276873f7aed2e6e979721c596bc3bbfd/chrome/browser/chromeos/file_manager/gallery_browsertest.cc

Tests are still disabled:
https://cs.chromium.org/search/?q= http://crbug.com/804413 &sq=package:chromium&type=cs

The issue (see comments #37, #33) is still here.

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

commit b123aca0757cac1de32d01819fdfcf35e77712a9
Author: Dominic Battre <battre@chromium.org>
Date: Tue Mar 27 09:09:32 2018

Add debug information on failing CanHandleType

TBR=fukino@chromium.org
notry=true

Bug:  804413 
Change-Id: I6fd7c66036d38bf23c6b77e16f214eff06c7d903
Reviewed-on: https://chromium-review.googlesource.com/980939
Reviewed-by: Dominic Battré <battre@chromium.org>
Commit-Queue: Dominic Battré <battre@chromium.org>
Cr-Commit-Position: refs/heads/master@{#546069}
[modify] https://crrev.com/b123aca0757cac1de32d01819fdfcf35e77712a9/chrome/browser/chromeos/extensions/file_manager/private_api_file_system.cc

#55 More logging would be good.  #53 yeah I get that the bug symptom described in this issue maybe still there, but my change was about the code revision landed in #15 which disabled test

GalleryBrowserTestInGuestMode::OpenSingleImageOnDownloads

on the current bug. Looking at the failing browser_test shard log provided in #15,

https://ci.chromium.org/buildbot/chromium.chromiumos/linux-chromeos-rel/4627

I see the following:

[ RUN      ] GalleryBrowserTestInGuestMode.MAYBE_OpenSingleImageOnDownloads
../../base/test/test_suite.cc:73: Failure
Value of: TestSuite::IsMarkedMaybe(test_info)
  Actual: true
Expected: false
Probably the OS #ifdefs don't include all of the necessary platforms.
Please ensure that no tests have the MAYBE_ prefix after the code is preprocessed.
[15847:15847:0125/085931.972160:3158493590:FATAL:browser_test_base.cc(147)] Check failed: set_up_called_. SetUp was not called. This probably means that the developer has overridden the method and not called the superclass version. In this case, the test does not run and reports a false positive result.

Seems entirely unrelated to the current bug (hence my change #52 to re-enable).

This result makes me wonder: how many of the other browser tests disabled in this bug actually have the symptom that is the subject of this bug?  Or has this bug become some kind of a dumping ground for flakes related to the CrOS FilesApp or its sub-components (QuickView, GalleryView, MediaView [video || audio] ...).

#20 disabled AudioPlayerBrowserTest.OpenAudioOnDownloads, but provided no logs. Tried looking it up via chromium flakiness dashboard:
https://test-results.appspot.com/dashboards/flakiness_dashboard.html#tests=AudioPlayerBrowserTest.OpenAudioOnDownloads&testType=browser_tests
Test is disabled of course, so I selected "show all available runs" to look back in time.  Waited, waited and boom, my browser crashed :?

Filed  issue 826959  about the Flakiness Dashboard "show all available runs" crash.

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

commit b5da1d7664754928b08997b8f39160529e7adb44
Author: Noel Gordon <noel@chromium.org>
Date: Tue Apr 03 00:23:15 2018

Re-enable two GalleryBrowserTestInGuestMode browser tests

Re-enable two GalleryBrowserTestInGuestMode tests, listed below, which
were disabled in  issue 804413  due to linux-chromeos-release bot flakes
on the CQ.

  GalleryBrowserTestInGuestMode.SlideshowTraversalOnDownloads
  GalleryBrowserTestInGuestMode.StopStartSlideshowOnDownloads

Tbr: yamaguchi-san
Bug:  804413 
Change-Id: I2928ba5a849b47a911bbd89382ef5c32d76edec2
Reviewed-on: https://chromium-review.googlesource.com/991212
Reviewed-by: Noel Gordon <noel@chromium.org>
Commit-Queue: Noel Gordon <noel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#547577}
[modify] https://crrev.com/b5da1d7664754928b08997b8f39160529e7adb44/chrome/browser/chromeos/file_manager/gallery_browsertest.cc

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

commit bf88d549e5364269921f0f04bf113a1943d37bab
Author: Noel Gordon <noel@chromium.org>
Date: Tue Apr 03 10:12:45 2018

Remove GalleryBrowserTestBase member scripts_

Per http:crrev.com/336357 the variable existed when the old file
manager browser test was split up after growing too large. It is
not used in GalleryBrowserTestBase today: remove scripts_.

Test: browser_tests --gtest_filter=GalleryBrowserTest*
Bug:  804413 
Change-Id: Iada83b00c5644d8ea8d9d3a334affe103a59d1db
Reviewed-on: https://chromium-review.googlesource.com/991772
Commit-Queue: Noel Gordon <noel@chromium.org>
Reviewed-by: Tatsuhisa Yamaguchi <yamaguchi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#547660}
[modify] https://crrev.com/bf88d549e5364269921f0f04bf113a1943d37bab/chrome/browser/chromeos/file_manager/gallery_browsertest.cc

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

commit 5d8129e513f1cffb5797693e3762262324c0d8d4
Author: Noel Gordon <noel@chromium.org>
Date: Wed Apr 04 03:59:32 2018

Re-enable all GalleryBrowserTestInGuestMode browser tests

Re-enable all GalleryBrowserTestInGuestMode tests, listed below, which
were disabled in  issue 804413  due to linux-chromeos-release bot flakes
on the CQ. (Guest mode RenameImageOnDownloads disabled on issue 508949
before  issue 804413 ).

  GalleryBrowserTestInGuestMode.RenameImageOnDownloads
  GalleryBrowserTestInGuestMode.
      CheckAvailabilityOfShareButtonOnDownloads
  GalleryBrowserTestInGuestMode.ResizeImageOnDownloads

Bug:  804413 , 508949
Change-Id: I254a9597c7fdd727cfb888db4c552cc3ad67b0a6
Reviewed-on: https://chromium-review.googlesource.com/992592
Reviewed-by: Sasha Morrissey <sashab@chromium.org>
Commit-Queue: Noel Gordon <noel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#547972}
[modify] https://crrev.com/5d8129e513f1cffb5797693e3762262324c0d8d4/chrome/browser/chromeos/file_manager/gallery_browsertest.cc

Results for #60, #61, #62 [1] GalleryBrowserTestInGuestMode.* in browser_tests(with patch), green on these try runs, no evidence of flakes. Zero evidence they ever had the "external_backend->CanHandleType(file_system_url.type())" signature that is the subject of this bug.

[1] https://test-results.appspot.com/dashboards/flakiness_dashboard.html#testType=browser_tests%20(with%20patch)&tests=GalleryBrowserTestInGuestMode.*

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

commit 038d0bb1c744460122e07651eaf0f9ee670f7682
Author: Noel Gordon <noel@chromium.org>
Date: Mon Apr 09 04:15:18 2018

Re-enable VideoPlayerBrowserTestInGuestMode browser tests

Run VideoPlayerBrowserTestInGuestMode tests (there is only one, listed
below) on all bots.

  VideoPlayerBrowserTestInGuestMode.OpenSingleVideoOnDownloads

Bug:  804413 ,508949
Change-Id: I1f355725775bb104101e108b3872a4b25549a074
Reviewed-on: https://chromium-review.googlesource.com/1002334
Reviewed-by: Tatsuhisa Yamaguchi <yamaguchi@chromium.org>
Commit-Queue: Noel Gordon <noel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549105}
[modify] https://crrev.com/038d0bb1c744460122e07651eaf0f9ee670f7682/chrome/browser/chromeos/file_manager/video_player_browsertest.cc

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

commit 0a450c32017755bb629c14062cd32f4e1aa2e0db
Author: Noel Gordon <noel@chromium.org>
Date: Mon Apr 09 09:58:21 2018

Re-enable GalleryBrowserTest.TraverseSlideThumbnailsOnDrive in debug

According to the flakiness dashboard, this test works in release mode,
and on the much slower ASAN and MSAN bots. Re-enable on the debug bots
to gather new data about  issue 804364  and related.

Bug:  804413 ,  804364 
Change-Id: Ifc3f1f383ca8b4b385ec65412e070748047683da
Reviewed-on: https://chromium-review.googlesource.com/1002345
Reviewed-by: Tatsuhisa Yamaguchi <yamaguchi@chromium.org>
Commit-Queue: Noel Gordon <noel@chromium.org>
Cr-Commit-Position: refs/heads/master@{#549139}
[modify] https://crrev.com/0a450c32017755bb629c14062cd32f4e1aa2e0db/chrome/browser/chromeos/file_manager/gallery_browsertest.cc

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

commit ce92ada91522695758a70d18e960194e5f071895
Author: Noel Gordon <noel@chromium.org>
Date: Tue Apr 17 08:30:34 2018

Rid our system of persistent FileManagerBrowserTest flakiness

Postpone the creation of the FilesApp component extensions AudioPlayer
FileManager, Gallery, and VideoPlayer in browser testing. Not doing so
leads to systemic browser test failures (flakiness) per the bugs.

Fix: prepare test resources first, load the component extensions, then
start testing. Failure was the component extensions were active before
the file resources needed by the tests were ready, causing flake-fails
when the component extensions tried to access those resources.

Bug:  831074 ,  804413 ,  829310 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: Ie794bac638f48c3855e0c1f1609e59aa615c31dd
Reviewed-on: https://chromium-review.googlesource.com/1013823
Commit-Queue: Noel Gordon <noel@chromium.org>
Reviewed-by: Naoki Fukino <fukino@chromium.org>
Reviewed-by: Tomasz Mikolajewski <mtomasz@chromium.org>
Reviewed-by: Tatsuhisa Yamaguchi <yamaguchi@chromium.org>
Cr-Commit-Position: refs/heads/master@{#551279}
[modify] https://crrev.com/ce92ada91522695758a70d18e960194e5f071895/chrome/browser/chromeos/file_manager/file_manager_browsertest_base.cc

For that last 48 hours after #69, no evidence of the bug symptom

[23667:23667:0122/042713.995569:FATAL:private_api_file_system.cc(810)] Check failed: external_backend->CanHandleType(file_system_url.type()).

anymore on the linux-chromeos-* bots.

 Issue 477360  has been merged into this issue.