Disable history delete directives when sessions are encrypted.

Disable history delete directives when sessions are encrypted.

Full history sync is based on server-side process of session data, so
if session data is encrypted, it can't be read on the server. In this
case, delete directives are also unnecessary, so they can be disabled
whenever the session data type is encrypted.

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

[Patrick Dubroy, 2013-04-11 16:37:12]

Hey Nicolas,

This was an attempt to ensure that the delete directives datatype is disabled
whenever encryption is enabled, so that the history page can just check for the
existence of the delete directives datatype to know which message to show.

Problem is, this doesn't work :-) Any idea what the right way to do this would
be? And does it make sense to behave this way?

[Nicolas Zea, 2013-04-15 18:35:25]

On 2013/04/11 16:37:12, dubroy wrote:
> Hey Nicolas,
> 
> This was an attempt to ensure that the delete directives datatype is disabled
> whenever encryption is enabled, so that the history page can just check for
the
> existence of the delete directives datatype to know which message to show.
> 
> Problem is, this doesn't work :-) Any idea what the right way to do this would
> be? And does it make sense to behave this way?

Hmm, originally I had thought that it would be better to have the history code
just check for whether encryption was enabled or not, but auto-disabling the
type might work too, and since the history ui already listens to reconfigures,
it might be cleaner.

DeactivateDataType isn't the right method though. I think DisableBrokenDatatype
should work. And the ProfileSyncComponentsFactory shouldn't need to be touched,
that's all called before the PSS even knows about the account's encryption
state.

[Patrick Dubroy, 2013-04-16 15:29:02]

Nicolas, please take another look.

[dubroy1, 2013-04-18 21:52:00]

Ping.
On Apr 16, 2013 5:29 PM, <dubroy@chromium.org> wrote:

> Nicolas, please take another look.
>
>
https://codereview.chromium.**org/14139010/<https://codereview.chromium.org/1...
>

[Nicolas Zea, 2013-04-18 21:55:14]

LGTM!

[commit-bot: I haz the power, 2013-04-19 12:01:46]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/dubroy@chromium.org/14139010/4001

[Patrick Dubroy, 2013-04-19 13:14:28]

Committed patchset #2 manually as r195154 (presubmit successful).