Remove the allow-displaying-mixed-content setting from Blink.

Remove the allow-displaying-mixed-content setting from Blink.

As the ability for the user to avoid the displaying of mixed content
was recently removed the respective Blink setting didn't need to exist
anymore. This change removes it and also updates tests and other
dependencies.

BUG=631525
Committed: https://crrev.com/5f1c51795e03c929c36eb05960d5ff4fbcb16c37
Cr-Commit-Position: refs/heads/master@{#417354}

[carlosk, 2016-08-25 22:25:16]

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

[commit-bot: I haz the power, 2016-08-25 22:25:51]

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-26 00:09:16]

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

[commit-bot: I haz the power, 2016-08-26 00:09:17]

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

[carlosk, 2016-08-27 03:40:47]

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

[commit-bot: I haz the power, 2016-08-27 03:41:30]

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-27 07:01:24]

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

[commit-bot: I haz the power, 2016-08-27 07:01:25]

Dry run: Try jobs failed on following builders:
  win_chromium_rel_ng on master.tryserver.chromium.win (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.win/builders/win_chromium_rel_...)

[carlosk, 2016-08-30 23:43:36]

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

[commit-bot: I haz the power, 2016-08-30 23:44:14]

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

[carlosk, 2016-08-31 00:27:10]

carlosk@chromium.org changed reviewers:
+ mkwst@chromium.org

[carlosk, 2016-08-31 00:27:11]

Adding initial reviewers.

mkwst@: PTAL at how I adapted mixed content checking, layout test harness and
Blink code. Also PTAL at how I adapted the Android WebView to work with this
change (more on this below).

estade@, horo@: FYI.


Android WebView:

I'm not really sure my adaptation of Android WebView for the removal of the
mixed content display control is the correct way to go. What I did was to create
a mapping of the "legacy" Java displaying/running configurations to the
running/strict-checking ones in C++. Given how this code works there's only 3
possible states:
- Java: displaying true, running true -> C++: running true, strict-checking
false
- Java: displaying true, running false -> C++: running false, strict-checking
false
- Java: displaying false, running false -> C++: running false, strict-checking
true

Layout tests:

For some layout tests I just removed the usage of the "allow displaying" setting
as the now regular behavior of allowing it was good enough. For others I
replaced it with the "strict mixed content checking" one to block displaying.

But a few require more input:

* Mixed content tests insecure-formSubmission-in-main-frame-allowed.html and its
counterpart insecure-formSubmission-in-main-frame-blocked.html are not testing
opposite outcomes as their names imply. They succeed with the "display" option
being either true or false. It seems the form submission is never blocked as I
couldn't find any code that uses mixed content restriction settings to block 
mixed content forms.
So do we want to actually block mixed content forms submission depending on
settings? If so we need to change MixedContentChecker and possibly related code.
Otherwise I think we should remove the *-blocked* version of the test.

- For ServiceWorker's fetch-mixed-content-to-inscope.html it didn't matter even
before my this change if displaying of mixed content was authorized or not and
it succeeded nonetheless. horo@, the test author, has already confirmed removing
the setting was the right thing to do so I consider this one solved.

[commit-bot: I haz the power, 2016-08-31 01:21:43]

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

[commit-bot: I haz the power, 2016-08-31 01:21:44]

Dry run: This issue passed the CQ dry run.

[Mike West, 2016-08-31 09:46:52]

https://codereview.chromium.org/2278303002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/loader/MixedContentChecker.cpp (right):

https://codereview.chromium.org/2278303002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/loader/MixedContentChecker.cpp:220:
client->passiveInsecureContentFound(url);
It looks like `ContentSettingsObserver::passiveInsecureContentFound` would end
up changing the UI. I think this changes the behavior in ways we don't want.
That is, strict mode should block the content without degrading the omnibox
display.

The current code doesn't call up to the client at all if we're in strict mode.
Would it be reasonable to move this call into the `if (allowed)` block? (Perhaps
simplifying that to `if (!strictMode)`?

[Torne, 2016-08-31 12:49:58]

torne@chromium.org changed reviewers:
+ torne@chromium.org

[Torne, 2016-08-31 12:49:59]

https://codereview.chromium.org/2278303002/diff/40001/android_webview/native/...
File android_webview/native/aw_settings.cc (right):

https://codereview.chromium.org/2278303002/diff/40001/android_webview/native/...
android_webview/native/aw_settings.cc:434:
Java_AwSettings_getAllowDisplayingInsecureContentLocked(env, obj));
These two DCHECKs are identical? Also, it'd be clearer to use DCHECK_IMPLIES,
since what you have here is an implies relation.

https://codereview.chromium.org/2278303002/diff/40001/android_webview/native/...
android_webview/native/aw_settings.cc:439: if
(Java_AwSettings_getAllowDisplayingInsecureContentLocked(env, obj)) {
The actual Java side value stored is an enum:
WebSettings.MIXED_CONTENT_ALWAYS_ALLOW, MIXED_CONTENT_NEVER_ALLOW,
MIXED_CONTENT_COMPATIBILITY_MODE. Currently the Java code in AwContents converts
this into two bools because that's the form web_prefs used to want.

I think it would be clearer here to either:
1) Change the Java code to just return the actual enum value to native, and let
the native code map that to strict_mixed_content_checking and
allow_running_insecure_content
or 2) Change the Java code to map the enum value to those actual two bools (and
rename the functions), and have the native code continue to be trivial
assignments to web_prefs.

rather than trying to keep the JNI the same.

[Torne, 2016-08-31 13:05:20]

Apparently DCHECK_IMPLIES was removed, but in any case if you change the JNI
here it won't really be necessary to have a dcheck.

[carlosk, 2016-09-02 23:47:10]

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

[carlosk, 2016-09-02 23:47:43]

Thanks.

https://codereview.chromium.org/2278303002/diff/40001/android_webview/native/...
File android_webview/native/aw_settings.cc (right):

https://codereview.chromium.org/2278303002/diff/40001/android_webview/native/...
android_webview/native/aw_settings.cc:434:
Java_AwSettings_getAllowDisplayingInsecureContentLocked(env, obj));
On 2016/08/31 12:49:59, Torne wrote:
> These two DCHECKs are identical? Also, it'd be clearer to use DCHECK_IMPLIES,
> since what you have here is an implies relation.

Indeed. But as you also realized, DCHECK_IMPLIES is sadly no more.

https://codereview.chromium.org/2278303002/diff/40001/android_webview/native/...
android_webview/native/aw_settings.cc:439: if
(Java_AwSettings_getAllowDisplayingInsecureContentLocked(env, obj)) {
On 2016/08/31 12:49:59, Torne wrote:
> The actual Java side value stored is an enum:
> WebSettings.MIXED_CONTENT_ALWAYS_ALLOW, MIXED_CONTENT_NEVER_ALLOW,
> MIXED_CONTENT_COMPATIBILITY_MODE. Currently the Java code in AwContents
converts
> this into two bools because that's the form web_prefs used to want.
> 
> I think it would be clearer here to either:
> 1) Change the Java code to just return the actual enum value to native, and
let
> the native code map that to strict_mixed_content_checking and
> allow_running_insecure_content
> or 2) Change the Java code to map the enum value to those actual two bools
(and
> rename the functions), and have the native code continue to be trivial
> assignments to web_prefs.
> 
> rather than trying to keep the JNI the same.

Agreed. I didn't realize those getters were used only here.

As I don't see a C++ version of those enum values I'll go with 2) as the logic
will be in Java where the enum is defined.

https://codereview.chromium.org/2278303002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/loader/MixedContentChecker.cpp (right):

https://codereview.chromium.org/2278303002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/loader/MixedContentChecker.cpp:220:
client->passiveInsecureContentFound(url);
On 2016/08/31 09:46:51, Mike West (OOO until 29th) wrote:
> It looks like `ContentSettingsObserver::passiveInsecureContentFound` would end
> up changing the UI. I think this changes the behavior in ways we don't want.
> That is, strict mode should block the content without degrading the omnibox
> display.

ContentSettingsObserver::passiveInsecureContentFound (previously known as
allowDisplayingInsecureContent) is currently only reporting histograms so I
don't see any UI change as a consequence of that call. Did I miss something?

> The current code doesn't call up to the client at all if we're in strict mode.
> Would it be reasonable to move this call into the `if (allowed)` block?
(Perhaps
> simplifying that to `if (!strictMode)`?

Moving that call inside the if-block would change the current behavior: the
histograms reporting I mentioned above would only happen if mixed content was
allowed here, whereas right now they would be recorded even if not.

Also the `allowed` variable must be set because it is accessed further down this
method hence why I didn't do that simplification.

[commit-bot: I haz the power, 2016-09-02 23:47:47]

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-09-03 03:05:53]

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

[commit-bot: I haz the power, 2016-09-03 03:05:54]

Dry run: This issue passed the CQ dry run.

[Mike West, 2016-09-05 10:01:51]

https://codereview.chromium.org/2278303002/diff/40001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/loader/MixedContentChecker.cpp (right):

https://codereview.chromium.org/2278303002/diff/40001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/loader/MixedContentChecker.cpp:220:
client->passiveInsecureContentFound(url);
On 2016/09/02 at 23:47:42, carlosk wrote:
> On 2016/08/31 09:46:51, Mike West (OOO until 29th) wrote:
> > It looks like `ContentSettingsObserver::passiveInsecureContentFound` would
end
> > up changing the UI. I think this changes the behavior in ways we don't want.
> > That is, strict mode should block the content without degrading the omnibox
> > display.
> 
> ContentSettingsObserver::passiveInsecureContentFound (previously known as
allowDisplayingInsecureContent) is currently only reporting histograms so I
don't see any UI change as a consequence of that call. Did I miss something?
> 
> > The current code doesn't call up to the client at all if we're in strict
mode.
> > Would it be reasonable to move this call into the `if (allowed)` block?
(Perhaps
> > simplifying that to `if (!strictMode)`?
> 
> Moving that call inside the if-block would change the current behavior: the
histograms reporting I mentioned above would only happen if mixed content was
allowed here, whereas right now they would be recorded even if not.
> 
> Also the `allowed` variable must be set because it is accessed further down
this method hence why I didn't do that simplification.

Got it, thanks for the explanation. Blink LGTM.

[Torne, 2016-09-05 11:01:22]

android_webview LGTM, thanks!

[carlosk, 2016-09-06 17:08:15]

carlosk@chromium.org changed reviewers:
+ nasko@chromium.org, thestig@chromium.org

[carlosk, 2016-09-06 17:08:16]

nasko@chromium.org: PTAL content/public/** and content/renderer/**.

thestig@chromium.org: PTAL chrome/browser/ui/** and chrome/renderer/**.

[Lei Zhang, 2016-09-06 19:03:19]

https://codereview.chromium.org/2278303002/diff/60001/chrome/common/pref_names.h
File chrome/common/pref_names.h (left):

https://codereview.chromium.org/2278303002/diff/60001/chrome/common/pref_name...
chrome/common/pref_names.h:145: extern const char
kWebKitAllowDisplayingInsecureContent[];
Do we need to do PrefService::ClearPref() like another CL did in
https://codereview.chromium.org/2254273003/ ?

[carlosk, 2016-09-07 01:24:26]

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

[commit-bot: I haz the power, 2016-09-07 01:24:41]

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

[carlosk, 2016-09-07 01:25:01]

Thanks.

https://codereview.chromium.org/2278303002/diff/60001/chrome/common/pref_names.h
File chrome/common/pref_names.h (left):

https://codereview.chromium.org/2278303002/diff/60001/chrome/common/pref_name...
chrome/common/pref_names.h:145: extern const char
kWebKitAllowDisplayingInsecureContent[];
On 2016/09/06 19:03:18, Lei Zhang wrote:
> Do we need to do PrefService::ClearPref() like another CL did in
> https://codereview.chromium.org/2254273003/ ?

Assuming that CL is doing the right thing (I have no idea) I'd say that yes, I
need to also do the same cleanup as this setting was similarly registered in
PrefsTabHelper::RegisterProfilePrefs.

Done.

[commit-bot: I haz the power, 2016-09-07 01:27:20]

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

[commit-bot: I haz the power, 2016-09-07 01:27:21]

Dry run: Try jobs failed on following builders:
  mac_chromium_rel_ng on master.tryserver.chromium.mac (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.mac/builders/mac_chromium_rel_...)

[Lei Zhang, 2016-09-07 01:33:19]

lgtm, though:

a) Your patch does not apply at the moment.
b) This CL is racing against https://codereview.chromium.org/2293373002/ .

[Lei Zhang, 2016-09-07 06:46:03]

On 2016/09/07 01:33:19, Lei Zhang wrote:
> lgtm, though:
> 
> a) Your patch does not apply at the moment.
> b) This CL is racing against https://codereview.chromium.org/2293373002/ .

(b) landed, and now...

c) I've put up https://codereview.chromium.org/2312263003/ to clean up after
(b).

[carlosk, 2016-09-07 17:40:53]

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

[commit-bot: I haz the power, 2016-09-07 17:41:26]

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

[carlosk, 2016-09-07 17:45:03]

On 2016/09/07 06:46:03, Lei Zhang wrote:
> On 2016/09/07 01:33:19, Lei Zhang wrote:
> > lgtm, though:
> > 
> > a) Your patch does not apply at the moment.
> > b) This CL is racing against https://codereview.chromium.org/2293373002/ .
> 
> (b) landed, and now...
> 
> c) I've put up https://codereview.chromium.org/2312263003/ to clean up after
> (b).

Thanks. I rebased this morning with all of those changes already in, including
c).

[commit-bot: I haz the power, 2016-09-07 18:12:28]

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

[commit-bot: I haz the power, 2016-09-07 18:12:29]

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

[nasko, 2016-09-07 20:52:29]

content/ LGTM. It does looks like a bunch of tests are failing though.

[carlosk, 2016-09-07 20:58:57]

On 2016/09/07 20:52:29, nasko (slow) wrote:
> content/ LGTM. It does looks like a bunch of tests are failing though.

Thanks. But just confirming: your LGTM is also covering
content/public/common/common_param_traits_macros.h, correct?

Failures seem to be due to some unrelated issue. Most of them were invalidated
due to them happening with and without my patch applied.

[nasko, 2016-09-07 21:00:10]

On 2016/09/07 20:58:57, carlosk wrote:
> On 2016/09/07 20:52:29, nasko (slow) wrote:
> > content/ LGTM. It does looks like a bunch of tests are failing though.
> 
> Thanks. But just confirming: your LGTM is also covering
> content/public/common/common_param_traits_macros.h, correct?
> 
> Failures seem to be due to some unrelated issue. Most of them were invalidated
> due to them happening with and without my patch applied.

content/public/common/common_param_traits_macros.h is under content/, right? :)
Yes, it covers all of content, including the IPC parts.

[carlosk, 2016-09-07 21:35:14]

The CQ bit was checked by carlosk@chromium.org

[carlosk, 2016-09-07 21:35:15]

The patchset sent to the CQ was uploaded after l-g-t-m from mkwst@chromium.org,
torne@chromium.org, thestig@chromium.org
Link to the patchset: https://codereview.chromium.org/2278303002/#ps100001
(title: "Rebase.")

[commit-bot: I haz the power, 2016-09-07 21:35:44]

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-09-07 22:33:43]

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

[commit-bot: I haz the power, 2016-09-07 22:33:45]

Exceeded global retry quota

[carlosk, 2016-09-07 23:15:21]

On 2016/09/07 22:33:45, commit-bot: I haz the power wrote:
> Exceeded global retry quota

This is the 1st time I ever got this message and I'm guessing the CQ is having
some issues. I'll wait some time before trying again.

[carlosk, 2016-09-07 23:23:15]

The CQ bit was checked by carlosk@chromium.org

[commit-bot: I haz the power, 2016-09-07 23:23:48]

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

[boliu, 2016-09-07 23:32:49]

On 2016/09/07 23:15:21, carlosk wrote:
> On 2016/09/07 22:33:45, commit-bot: I haz the power wrote:
> > Exceeded global retry quota
> 
> This is the 1st time I ever got this message and I'm guessing the CQ is having
> some issues. I'll wait some time before trying again.

I think this means something broke for real, and a whole bunch of different bots
failed. The assumption here is probably something like: if CL is ok but there
are flakes, only a few bots are retried by cq; but if enough bots needs to
retried, then it's probably the CL's problem, thus cq gives up and produces this
message.

Does this stack look suspicious?
[837:837:0907/111710:FATAL:pref_service.cc(377)] Check failed: false. Trying to
clear an unregistered pref: webkit.webprefs.allow_displaying_insecure_content
#0 0x000002a2199e base::debug::StackTrace::StackTrace()
#1 0x000002a3852b logging::LogMessage::~LogMessage()
#2 0x000003ac143c PrefService::ClearPref()
#3 0x000002bac23d chrome::MigrateObsoleteProfilePrefs()
#4 0x000002bd0254 ProfileImpl::OnLocaleReady()
#5 0x000002bcdf26 ProfileImpl::OnPrefsLoaded()
#6 0x000002bcdd81 ProfileImpl::ProfileImpl()
#7 0x000002bcc3c8 Profile::CreateProfile()
#8 0x000002beab99 ProfileManager::CreateProfileHelper()
#9 0x000002be47de ProfileManager::CreateAndInitializeProfile()
#10 0x000002be44c9 ProfileManager::GetProfile()
#11 0x000004cb3af2 GetStartupProfile()
#12 0x000002ec3f78 ChromeBrowserMainParts::PreMainMessageLoopRunImpl()
#13 0x000002ec3625 ChromeBrowserMainParts::PreMainMessageLoopRun()
#14 0x000002003c45 content::BrowserMainLoop::PreMainMessageLoopRun()
#15 0x00000236c177 content::StartupTaskRunner::RunAllTasksNow()
#16 0x000002002066 content::BrowserMainLoop::CreateStartupTasks()
#17 0x0000020070fa content::BrowserMainRunnerImpl::Initialize()
#18 0x000001fff0d8 content::BrowserMain()
#19 0x000002a0531e content::RunNamedProcessTypeMain()
#20 0x000002a05dd3 content::ContentMainRunnerImpl::Run()
#21 0x000002a04630 content::ContentMain()
#22 0x000003077c65 content::BrowserTestBase::SetUp()
#23 0x000002ad7181 InProcessBrowserTest::SetUp()
#24 0x0000036e77e8 testing::Test::Run()
#25 0x0000036e8553 testing::TestInfo::Run()
#26 0x0000036e89e7 testing::TestCase::Run()
#27 0x0000036efa27 testing::internal::UnitTestImpl::RunAllTests()
#28 0x0000036ef67a testing::UnitTest::Run()
#29 0x000002ae3f13 base::TestSuite::Run()
#30 0x000002a14959 ChromeTestSuiteRunner::RunTestSuite()
#31 0x00000309f162 content::LaunchTests()
#32 0x000002a148e7 main

From here:
https://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium...

[commit-bot: I haz the power, 2016-09-07 23:33:26]

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

[commit-bot: I haz the power, 2016-09-07 23:33:28]

Try jobs failed on following builders:
  linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED,
https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)

[carlosk, 2016-09-07 23:41:21]

You're right. This is my change. Sorry about the noise.

On Wed, Sep 7, 2016 at 4:32 PM, <boliu@chromium.org> wrote:

> On 2016/09/07 23:15:21, carlosk wrote:
> > On 2016/09/07 22:33:45, commit-bot: I haz the power wrote:
> > > Exceeded global retry quota
> >
> > This is the 1st time I ever got this message and I'm guessing the CQ is
> having
> > some issues. I'll wait some time before trying again.
>
> I think this means something broke for real, and a whole bunch of
> different bots
> failed. The assumption here is probably something like: if CL is ok but
> there
> are flakes, only a few bots are retried by cq; but if enough bots needs to
> retried, then it's probably the CL's problem, thus cq gives up and
> produces this
> message.
>
> Does this stack look suspicious?
> [837:837:0907/111710:FATAL:pref_service.cc(377)] Check failed: false.
> Trying to
> clear an unregistered pref: webkit.webprefs.allow_
> displaying_insecure_content
> #0 0x000002a2199e base::debug::StackTrace::StackTrace()
> #1 0x000002a3852b logging::LogMessage::~LogMessage()
> #2 0x000003ac143c PrefService::ClearPref()
> #3 0x000002bac23d chrome::MigrateObsoleteProfilePrefs()
> #4 0x000002bd0254 ProfileImpl::OnLocaleReady()
> #5 0x000002bcdf26 ProfileImpl::OnPrefsLoaded()
> #6 0x000002bcdd81 ProfileImpl::ProfileImpl()
> #7 0x000002bcc3c8 Profile::CreateProfile()
> #8 0x000002beab99 ProfileManager::CreateProfileHelper()
> #9 0x000002be47de ProfileManager::CreateAndInitializeProfile()
> #10 0x000002be44c9 ProfileManager::GetProfile()
> #11 0x000004cb3af2 GetStartupProfile()
> #12 0x000002ec3f78 ChromeBrowserMainParts::PreMainMessageLoopRunImpl()
> #13 0x000002ec3625 ChromeBrowserMainParts::PreMainMessageLoopRun()
> #14 0x000002003c45 content::BrowserMainLoop::PreMainMessageLoopRun()
> #15 0x00000236c177 content::StartupTaskRunner::RunAllTasksNow()
> #16 0x000002002066 content::BrowserMainLoop::CreateStartupTasks()
> #17 0x0000020070fa content::BrowserMainRunnerImpl::Initialize()
> #18 0x000001fff0d8 content::BrowserMain()
> #19 0x000002a0531e content::RunNamedProcessTypeMain()
> #20 0x000002a05dd3 content::ContentMainRunnerImpl::Run()
> #21 0x000002a04630 content::ContentMain()
> #22 0x000003077c65 content::BrowserTestBase::SetUp()
> #23 0x000002ad7181 InProcessBrowserTest::SetUp()
> #24 0x0000036e77e8 testing::Test::Run()
> #25 0x0000036e8553 testing::TestInfo::Run()
> #26 0x0000036e89e7 testing::TestCase::Run()
> #27 0x0000036efa27 testing::internal::UnitTestImpl::RunAllTests()
> #28 0x0000036ef67a testing::UnitTest::Run()
> #29 0x000002ae3f13 base::TestSuite::Run()
> #30 0x000002a14959 ChromeTestSuiteRunner::RunTestSuite()
> #31 0x00000309f162 content::LaunchTests()
> #32 0x000002a148e7 main
>
> From here:
> https://build.chromium.org/p/tryserver.chromium.linux/
> builders/linux_chromium_rel_ng/builds/293561/steps/
> browser_tests%20%28with%20patch%29%20on%20Ubuntu-12.04/logs/AllForms_
> FormStructureBrowserTest.DataDrivenHeuristics_116
>
> https://codereview.chromium.org/2278303002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[Lei Zhang, 2016-09-07 23:41:37]

On 2016/09/07 23:32:49, boliu wrote:
> On 2016/09/07 23:15:21, carlosk wrote:
> > On 2016/09/07 22:33:45, commit-bot: I haz the power wrote:
> > > Exceeded global retry quota
> > 
> > This is the 1st time I ever got this message and I'm guessing the CQ is
having
> > some issues. I'll wait some time before trying again.
> 
> I think this means something broke for real, and a whole bunch of different
bots
> failed. The assumption here is probably something like: if CL is ok but there
> are flakes, only a few bots are retried by cq; but if enough bots needs to
> retried, then it's probably the CL's problem, thus cq gives up and produces
this
> message.
> 
> Does this stack look suspicious?
> [837:837:0907/111710:FATAL:pref_service.cc(377)] Check failed: false. Trying
to
> clear an unregistered pref: webkit.webprefs.allow_displaying_insecure_content

Oh yes, we do need to register the pref to clear it. See the other obsolete
prefs for examples.

[carlosk, 2016-09-07 23:48:10]

You're right. This is my change. Sorry about the noise.

On Wed, Sep 7, 2016 at 4:32 PM, <boliu@chromium.org> wrote:

> On 2016/09/07 23:15:21, carlosk wrote:
> > On 2016/09/07 22:33:45, commit-bot: I haz the power wrote:
> > > Exceeded global retry quota
> >
> > This is the 1st time I ever got this message and I'm guessing the CQ is
> having
> > some issues. I'll wait some time before trying again.
>
> I think this means something broke for real, and a whole bunch of
> different bots
> failed. The assumption here is probably something like: if CL is ok but
> there
> are flakes, only a few bots are retried by cq; but if enough bots needs to
> retried, then it's probably the CL's problem, thus cq gives up and
> produces this
> message.
>
> Does this stack look suspicious?
> [837:837:0907/111710:FATAL:pref_service.cc(377)] Check failed: false.
> Trying to
> clear an unregistered pref: webkit.webprefs.allow_
> displaying_insecure_content
> #0 0x000002a2199e base::debug::StackTrace::StackTrace()
> #1 0x000002a3852b logging::LogMessage::~LogMessage()
> #2 0x000003ac143c PrefService::ClearPref()
> #3 0x000002bac23d chrome::MigrateObsoleteProfilePrefs()
> #4 0x000002bd0254 ProfileImpl::OnLocaleReady()
> #5 0x000002bcdf26 ProfileImpl::OnPrefsLoaded()
> #6 0x000002bcdd81 ProfileImpl::ProfileImpl()
> #7 0x000002bcc3c8 Profile::CreateProfile()
> #8 0x000002beab99 ProfileManager::CreateProfileHelper()
> #9 0x000002be47de ProfileManager::CreateAndInitializeProfile()
> #10 0x000002be44c9 ProfileManager::GetProfile()
> #11 0x000004cb3af2 GetStartupProfile()
> #12 0x000002ec3f78 ChromeBrowserMainParts::PreMainMessageLoopRunImpl()
> #13 0x000002ec3625 ChromeBrowserMainParts::PreMainMessageLoopRun()
> #14 0x000002003c45 content::BrowserMainLoop::PreMainMessageLoopRun()
> #15 0x00000236c177 content::StartupTaskRunner::RunAllTasksNow()
> #16 0x000002002066 content::BrowserMainLoop::CreateStartupTasks()
> #17 0x0000020070fa content::BrowserMainRunnerImpl::Initialize()
> #18 0x000001fff0d8 content::BrowserMain()
> #19 0x000002a0531e content::RunNamedProcessTypeMain()
> #20 0x000002a05dd3 content::ContentMainRunnerImpl::Run()
> #21 0x000002a04630 content::ContentMain()
> #22 0x000003077c65 content::BrowserTestBase::SetUp()
> #23 0x000002ad7181 InProcessBrowserTest::SetUp()
> #24 0x0000036e77e8 testing::Test::Run()
> #25 0x0000036e8553 testing::TestInfo::Run()
> #26 0x0000036e89e7 testing::TestCase::Run()
> #27 0x0000036efa27 testing::internal::UnitTestImpl::RunAllTests()
> #28 0x0000036ef67a testing::UnitTest::Run()
> #29 0x000002ae3f13 base::TestSuite::Run()
> #30 0x000002a14959 ChromeTestSuiteRunner::RunTestSuite()
> #31 0x00000309f162 content::LaunchTests()
> #32 0x000002a148e7 main
>
> From here:
> https://build.chromium.org/p/tryserver.chromium.linux/
> builders/linux_chromium_rel_ng/builds/293561/steps/
> browser_tests%20%28with%20patch%29%20on%20Ubuntu-12.04/logs/AllForms_
> FormStructureBrowserTest.DataDrivenHeuristics_116
>
> https://codereview.chromium.org/2278303002/
>

-- 
You received this message because you are subscribed to the Google Groups "Blink
Reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to blink-reviews+unsubscribe@chromium.org.

[carlosk, 2016-09-08 16:52:04]

The CQ bit was checked by carlosk@chromium.org

[carlosk, 2016-09-08 16:52:05]

The patchset sent to the CQ was uploaded after l-g-t-m from
thestig@chromium.org, mkwst@chromium.org, torne@chromium.org, nasko@chromium.org
Link to the patchset: https://codereview.chromium.org/2278303002/#ps120001
(title: "Fixed missign deprecated preference registration.")

[commit-bot: I haz the power, 2016-09-08 16:52:28]

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-09-08 18:59:59]

Committed patchset #7 (id:120001)

[commit-bot: I haz the power, 2016-09-08 19:01:35]

Description was changed from

==========
Remove the allow-displaying-mixed-content setting from Blink.

As the ability for the user to avoid the displaying of mixed content
was recently removed the respective Blink setting didn't need to exist
anymore. This change removes it and also updates tests and other
dependencies.

BUG=631525
==========

to

==========
Remove the allow-displaying-mixed-content setting from Blink.

As the ability for the user to avoid the displaying of mixed content
was recently removed the respective Blink setting didn't need to exist
anymore. This change removes it and also updates tests and other
dependencies.

BUG=631525

Committed: https://crrev.com/5f1c51795e03c929c36eb05960d5ff4fbcb16c37
Cr-Commit-Position: refs/heads/master@{#417354}
==========

[commit-bot: I haz the power, 2016-09-08 19:01:37]

Patchset 7 (id:??) landed as
https://crrev.com/5f1c51795e03c929c36eb05960d5ff4fbcb16c37
Cr-Commit-Position: refs/heads/master@{#417354}