Add separate plumbing for subresources with certificate errors

Add separate plumbing for subresources with certificate errors

Previously, when subresources were loaded over connections with
certificate errors, WebContents treated them the same as mixed content
(subresources loaded over HTTP). While this sort of approximately worked
for a while, it was messy and is starting to create problems. For
example, once WebContents is notified that insecure resources have been
loaded, it notifies DevTools to update the security panel -- but by that
point, we had lost information about whether the insecure resource was
mixed content or broken HTTPS, so DevTools can't distinguish them in the
UI.

There was also an ugly hack in place to stop the renderer from notifying
the browser about same-origin broken HTTPS subresources, to stop the
browser from marking a page as mixed content after clicking through an
interstitial. That hack was removed in https://codereview.chromium.org/2191113002
which means that all pages with certificate errors get marked as having
mixed content now if they load subresources.

This CL creates plumbing for certificate error subresources that is
parallel to the mixed content plumbing, and uses that now instead of
reusing the mixed content plumbing.

At the moment, cert error subresources only affect the lock icon, but
follow-up CLs will adapt WebsiteSettings and DevTools to describe when
the page has loaded content with certificate errors.

BUG=634171

[estark, 2016-08-06 22:13:13]

The CQ bit was checked by estark@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-06 22:13:26]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-06 22:34:31]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-06 22:34:32]

Dry run: Try jobs failed on following builders:
  cast_shell_linux on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/cast_shell_linu...)

[estark, 2016-08-06 22:55:05]

The CQ bit was checked by estark@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-06 22:55:09]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-06 23:21:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-06 23:21:12]

Dry run: Try jobs failed on following builders:
  android_arm64_dbg_recipe on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/android_arm6...)

[estark, 2016-08-07 00:00:44]

The CQ bit was checked by estark@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-07 00:00:54]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-07 00:44:05]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-07 00:44:06]

Dry run: This issue passed the CQ dry run.

[estark, 2016-08-08 18:25:32]

The CQ bit was checked by estark@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-08-08 18:25:56]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-08-08 19:39:50]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-08-08 19:39:51]

Dry run: This issue passed the CQ dry run.

[estark, 2016-08-09 00:04:21]

estark@chromium.org changed reviewers:
+ jam@chromium.org

[estark, 2016-08-09 00:04:22]

jam: this CL should start to address the ssl_browser_test.cc TODOs you added for
me in https://codereview.chromium.org/2191113002. In this CL 'm creating a
separate set of plumbing so that browser UI can distinguish subresources loaded
with certificate errors from mixed content (subresources loaded over plain
HTTP). Unfortunately this is kind of tedious as the distinction has to be
maintained through many various layers, so there are lots of classes that need
parallel DidRunInsecureContent/DidRunContentWithCertificateErrors and
DidDisplayInsecureContent/DidDisplayContentWithCertificateErrors methods.

(I haven't actually rebased on top of your CL yet and done the TODOs; I'm
waiting for https://codereview.chromium.org/2224693002/ to land which introduces
a few more TODOs of the same nature. Once that lands I'll rebase.)

[estark, 2016-08-09 00:05:45]

Description was changed from

==========
Add separate plumbing for subresources with certificate errors

Previously, when subresources were loaded over connections with
certificate errors, WebContents treated them the same as mixed content
(subresources loaded over HTTP). While this sort of approximately worked
for a while, it was messy and is starting to create problems. For
example, once WebContents is notified that insecure resources have been
loaded, it notifies DevTools to update the security panel -- but by that
point, we had lost information about whether the insecure resource was
mixed content or broken HTTPS, so DevTools can't distinguish them in the
UI.

There was also an ugly hack in place to stop the renderer from notifying
the browser about same-origin broken HTTPS subresources, to stop the
browser from marking a page as mixed content after clicking through an
interstitial.

This CL creates plumbing for certificate error subresources that is
parallel to the mixed content plumbing, and uses that now instead of
reusing the mixed content plumbing.

At the moment, cert error subresources only affect the lock icon, but
follow-up CLs will adapt WebsiteSettings and DevTools to describe when
the page has loaded content with certificate errors.

BUG=634171
==========

to

==========
Add separate plumbing for subresources with certificate errors

Previously, when subresources were loaded over connections with
certificate errors, WebContents treated them the same as mixed content
(subresources loaded over HTTP). While this sort of approximately worked
for a while, it was messy and is starting to create problems. For
example, once WebContents is notified that insecure resources have been
loaded, it notifies DevTools to update the security panel -- but by that
point, we had lost information about whether the insecure resource was
mixed content or broken HTTPS, so DevTools can't distinguish them in the
UI.

There was also an ugly hack in place to stop the renderer from notifying
the browser about same-origin broken HTTPS subresources, to stop the
browser from marking a page as mixed content after clicking through an
interstitial. That hack was removed in
https://codereview.chromium.org/2191113002
which means that all pages with certificate errors get marked as having
mixed content now if they load subresources.

This CL creates plumbing for certificate error subresources that is
parallel to the mixed content plumbing, and uses that now instead of
reusing the mixed content plumbing.

At the moment, cert error subresources only affect the lock icon, but
follow-up CLs will adapt WebsiteSettings and DevTools to describe when
the page has loaded content with certificate errors.

BUG=634171
==========

[estark, 2016-08-09 00:49:47]

Actually, sorry, this CL is too huge and disgusting and under-tested. I'm going
to close it out and break it up into a few separate ones, so need to review this
yet.