Fix AutofillDialogCocoaBrowserTest.DisplayUI.

Fix AutofillDialogCocoaBrowserTest.DisplayUI.

This re-lands a fixed version of r196005, which was reverted.

BUG=234008
TEST=AutofillDialogCocoaBrowserTest.DisplayUI works everywhere

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=202185

[Avi (use Gerrit), 2013-05-24 16:21:24]

https://codereview.chromium.org/16025002/diff/1/chrome/browser/ui/cocoa/autof...
File chrome/browser/ui/cocoa/autofill/autofill_dialog_cocoa_browsertest.mm
(right):

https://codereview.chromium.org/16025002/diff/1/chrome/browser/ui/cocoa/autof...
chrome/browser/ui/cocoa/autofill/autofill_dialog_cocoa_browsertest.mm:85:
autofill::test::DisableSystemServices(browser()->profile());
Passing a real profile here, rather than NULL as you did in
https://chromiumcodereview.appspot.com/13996022 , is key here. If we look at
DisableSystemServices, it only properly disables auxiliary profiles if you pass
the profile. If you pass NULL, as the previous version of this patch did,
nothing happens.

[groby-ooo-7-16, 2013-05-24 17:57:50]

LGTM - thanks for fixing this! I erroneously assumed using a Mock keychain would
be enough. (And since the bug didn't repro locally, couldn't verify)

For my future self: Reproing AB asking for permissions might require deleting
the permissions database, which lives in ~/Library/Application
Support/com.apple.TCC/TCC.db

On 2013/05/24 16:21:24, Avi wrote:
>
https://codereview.chromium.org/16025002/diff/1/chrome/browser/ui/cocoa/autof...
> File chrome/browser/ui/cocoa/autofill/autofill_dialog_cocoa_browsertest.mm
> (right):
> 
>
https://codereview.chromium.org/16025002/diff/1/chrome/browser/ui/cocoa/autof...
> chrome/browser/ui/cocoa/autofill/autofill_dialog_cocoa_browsertest.mm:85:
> autofill::test::DisableSystemServices(browser()->profile());
> Passing a real profile here, rather than NULL as you did in
> https://chromiumcodereview.appspot.com/13996022 , is key here. If we look at
> DisableSystemServices, it only properly disables auxiliary profiles if you
pass
> the profile. If you pass NULL, as the previous version of this patch did,
> nothing happens.

[commit-bot: I haz the power, 2013-05-24 17:58:09]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/avi@chromium.org/16025002/1

[Avi (use Gerrit), 2013-05-24 18:00:24]

On 2013/05/24 17:57:50, groby wrote:
> For my future self: Reproing AB asking for permissions might require deleting
> the permissions database, which lives in ~/Library/Application
> Support/com.apple.TCC/TCC.db

I didn't know where that lived; good to know. For me, I went into the UI and
unchecked the permission checkbox, and then when I ran the test from the
commandline it puked up a stack trace when it didn't get the permission it
expected.

[groby-ooo-7-16, 2013-05-24 18:41:00]

Ah, but that stack trace is not what you're looking for :)

It ends with  __ABIsAccessGranted_block_invoke_0. You'll see the test is still
marked as passed. That's normal behavior - we get the AddressBook using
RunBlockIgnoringExceptions, and denying permissions throws an exception. (No
comment. It's not documented, so yay)

What happened on the ASAN bots was a timeout, which is the OS throwing up a
dialog asking if you'd grant permission and waiting for user action. That, at
least in local tests, requires deleting the permission DB.

[groby-ooo-7-16, 2013-05-24 19:00:13]

Sigh. I take that back. It's not an exception, it just spews to the log that it
couldn't open.

Still, reproing the ASAN issue requires deleting the TCC.db. (Or modifying it.
It's sqlite3, and user-writeable. So technically, the bots could just force
access... ;)

[Avi (use Gerrit), 2013-05-24 19:43:43]

On 2013/05/24 18:41:00, groby wrote:
> Ah, but that stack trace is not what you're looking for :)

That stack trace is exactly what I was looking for :). Even seeing a denied
permission request meant that we were making the call that we didn't want to be
making.

[commit-bot: I haz the power, 2013-05-24 21:51:28]

Change committed as 202185