Test code line: https://cs.chromium.org/chromium/src/chrome/browser/password_manager/password_manager_browsertest.cc?rcl=0&l=2763

In test "IN_PROC_BROWSER_TEST_F(PasswordManagerBrowserTestBase, InternalsPage)"

Error:
[ RUN      ] PasswordManagerBrowserTestBase.InternalsPage
[70319:48143:0823/053028:WARNING:mac_util.mm(255)] Failed to set backup exclusion for file '/private/var/folders/9x/6c6sv3cj4j53wzpzthbp4ksm0000gm/T/.org.chromium.Chromium.FgXpTu/dJ0wEBh/Default/History': Error Domain=NSOSStatusErrorDomain Code=-50 "The operation couldn?t be completed. (OSStatus error -50.)" (paramErr: error in user parameter list) (-50)
[70319:48143:0823/053028:WARNING:mac_util.mm(255)] Failed to set backup exclusion for file '/private/var/folders/9x/6c6sv3cj4j53wzpzthbp4ksm0000gm/T/.org.chromium.Chromium.FgXpTu/dJ0wEBh/Default/Favicons': Error Domain=NSOSStatusErrorDomain Code=-50 "The operation couldn?t be completed. (OSStatus error -50.)" (paramErr: error in user parameter list) (-50)
[70322:1287:0823/053028:WARNING:vt_video_decode_accelerator_mac.cc(162)] Failed to create VTDecompressionSession: Error Domain=NSOSStatusErrorDomain Code=-8973 "The operation couldn?t be completed. (OSStatus error -8973.)" (codecOpenErr) (-8973)
[70322:1287:0823/053028:WARNING:vt_video_decode_accelerator_mac.cc(197)] Failed to create hardware VideoToolbox session
[70322:1287:0823/053028:ERROR:vt_video_encode_accelerator_mac.cc(540)]  VTCompressionSessionCreate failed: -12908
[70319:82951:0823/053029:WARNING:simple_synchronous_entry.cc(1054)] Could not open platform files for entry.
[70319:54279:0823/053029:WARNING:embedded_test_server.cc(202)] Request not handled. Returning 404: /favicon.ico
../../chrome/browser/password_manager/password_manager_browsertest.cc:2763: Failure
Value of: renderer_logs_found
  Actual: false
Expected: true
[70319:1287:0823/053029:WARNING:url_request_context_getter.cc(43)] URLRequestContextGetter leaking due to no owning thread.
[  FAILED  ] PasswordManagerBrowserTestBase.InternalsPage, where TypeParam =  and GetParam() =  (1606 ms)

Vaclav: you added this test and I know it has not changed in a long time, but can you please investigate to see why it is now failing consistently?  First started failing at "2016-08-23 13:13:37 UTC", but I didn't see any commits obviously related.  Thanks.

Thanks for routing this to me! I'll have a look today.

The test failure is Mac only, and seems to be amplified to a 100% failing once switched to Mojo in https://codereview.chromium.org/2270333002/ (not landed). If I cannot fix today, I will disable the test on Mac and carry on fixing.

The test has an issue of not waiting for the right event to be sure that all internals logs are in. I will change that, but in the meantime, https://codereview.chromium.org/2287143003/ disables it on Mac, to relieve the CQ a bit.

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

commit 2683579867440a6ead8e06329f00bd7d0b3a1ce2
Author: vabr <vabr@chromium.org>
Date: Mon Aug 29 11:14:45 2016

Disable PasswordManagerBrowserTestBase.InternalsPage on Mac

The test flakes on Mac.

BUG= 640737 
TBR=vasilii@chromium.org

Review-Url: https://codereview.chromium.org/2287143003
Cr-Commit-Position: refs/heads/master@{#414996}

[modify] https://crrev.com/2683579867440a6ead8e06329f00bd7d0b3a1ce2/chrome/browser/password_manager/password_manager_browsertest.cc

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

commit 201fbb175db0902e4d9041eee0c4bdfb5c304aba
Author: vabr <vabr@chromium.org>
Date: Tue Aug 30 08:52:35 2016

Revert of Disable PasswordManagerBrowserTestBase.InternalsPage on Mac (patchset #1 id:1 of https://codereview.chromium.org/2287143003/ )

Reason for revert:
As leonhsl@ noted on https://codereview.chromium.org/2270333002/, the test failures only happened when the Mojo change https://codereview.chromium.org/2216463002 was on the trunk. Looking at the list of flakes [1], the revision numbers speak clearly:
413708 = Mojo change went in
413716 = first flake recorded
413923 = last flake recorded
413934 = Mojo change reverted

Therefore the revert is not needed, the Mojo change needs to be fixed before relanding.

[1] https://chromium-try-flakes.appspot.com/all_flake_occurrences?key=ahVzfmNocm9taXVtLXRyeS1mbGFrZXNyNwsSBUZsYWtlIixQYXNzd29yZE1hbmFnZXJCcm93c2VyVGVzdEJhc2UuSW50ZXJuYWxzUGFnZQw

Original issue's description:
> Disable PasswordManagerBrowserTestBase.InternalsPage on Mac
>
> The test flakes on Mac.
>
> BUG= 640737 
> TBR=vasilii@chromium.org
>
> Committed: https://crrev.com/2683579867440a6ead8e06329f00bd7d0b3a1ce2
> Cr-Commit-Position: refs/heads/master@{#414996}

TBR=vasilii@chromium.org
# Skipping CQ checks because original CL landed less than 1 days ago.
NOPRESUBMIT=true
NOTREECHECKS=true
NOTRY=true
BUG= 640737 

Review-Url: https://codereview.chromium.org/2292893002
Cr-Commit-Position: refs/heads/master@{#415248}

[modify] https://crrev.com/201fbb175db0902e4d9041eee0c4bdfb5c304aba/chrome/browser/password_manager/password_manager_browsertest.cc

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

commit e78084414756fa83c67cb9a50f5693fb3bcef68d
Author: vabr <vabr@chromium.org>
Date: Mon Sep 05 13:58:55 2016

Redo PasswordManagerBrowserTestBase.InternalsPage

The old version of the test was flaky after
https://codereview.chromium.org/2270333002/ switched some messages to Mojo,
because the signal that "internals page is ready for logging" propagated into
the renderer after the renderer tried to log.

The issue is likely Mojo-specific. It did not occur without the switch to
Mojo. After the switch to Mojo, signals about navigation events no longer go
through the same channel as the autofill messages (including the
logging-related). Therefore the test code could have observed the internals
page finish loading and consequently start loading the page with forms
without all Mojo messages being properly transferred.

The issue was test-specific, because the test was opening the page with forms
much quicker after opening the internals page, than a human trying to capture
the logs could do.

The issue was Mac-specific, but not sure why. It does not seem important,
though.

Therefore, this CL fixes the test in adding an additional reload of the form
page. That is, instead of:

1. Loading the internals page
2. Loading the page with forms

the test now does

1'. Loading the internals page
2'. Loading the page with forms
3'. Reloading the page with forms

The reloading increases the chance of the Mojo messages about logging
activation to arrive to the renderer, simply because reloading takes longer.
IIUC, there is no good event to wait for to be sure that the Mojo messages
were received (without modifying the production code).

The CL also splits the test into two, because it checked for two different\
things in the logs (browser vs. renderer messages).

BUG= 640737 
R=vasilii@chromium.org

Review-Url: https://codereview.chromium.org/2288203002
Cr-Commit-Position: refs/heads/master@{#416540}

[modify] https://crrev.com/e78084414756fa83c67cb9a50f5693fb3bcef68d/chrome/browser/password_manager/password_manager_browsertest.cc

The test should be now prepared for the switch to Mojo, which comes in https://codereview.chromium.org/2270333002/. If it starts flaking after https://codereview.chromium.org/2270333002/ lands, there is one more approach to try described in https://codereview.chromium.org/2288203002#msg29 (repeated reloading until timeout).