Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2515373003:
Post tasks for sensitive input visibility notifications (Closed)
DescriptionPost tasks for sensitive input visibility notifications
If password inputs are hidden and shown multiple times in the same task
(as apparently happens when processing a stylesheet), we don't want to
the omnibox warning to flicker in and out. Thus, this CL posts sensitive
input visibility notifications to the end of the task queue, so that the
omnibox warning updates get coalesced.
BUG=664194
TEST=Visit http://http-password.badssl.com and observe that the omnibox
warning does not flicker in and out twice.
Committed: https://crrev.com/7bdbe352cdbd7cc1dec2b71653e60b47688bd9e1
Cr-Commit-Position: refs/heads/master@{#434340}
Patch Set 1 #
Total comments: 7
Patch Set 2 : dcheng, haraken comments #Patch Set 3 : move cancellable task to PasswordInputType, not Document #
Total comments: 1
Patch Set 4 : revert back to patchset 2 #
Total comments: 7
Patch Set 5 : dcheng, haraken comments round 2 #
Messages
Total messages: 49 (26 generated)
The CQ bit was checked by estark@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
estark@chromium.org changed reviewers: + dcheng@chromium.org
dcheng does this look remotely reasonable to you? Thanks!
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
Currently, this will post a task for every change, but we can do better by deduping the tasks. Traditionally, we've done this with a Timer... But we've been deprecating one shot timers in favor of postCancellableTask [1]: would you be willing to guinea pig this? =) https://cs.chromium.org/chromium/src/third_party/WebKit/Source/platform/WebTa... https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp (right): https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp:52: if (!document || !document->frame()) Nit: weak persistents should be automatically cancelled, so it's not necessary to null check document. (Not sure if we can make this clearer by forcing it to bind as a mutable ref: maybe +esprehn/+haraken/+tzik will have thoughts on this... that being said, it's completely orthogonal to this CL and resolving the larger question is out of scope of this CL. Just something to consider.)
haraken@chromium.org changed reviewers: + haraken@chromium.org
https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp (right): https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp:51: void SendSensitiveInputVisibility(Document* document) { sendSensitiveInputVisibility https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp:56: mojo::GetProxy(&sensitiveInputServicePtr)); Isn't it expensive to get an InterfacePtr at every callback? Is there any option to cache it on the first time access?
https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp (right): https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp:56: mojo::GetProxy(&sensitiveInputServicePtr)); On 2016/11/22 01:57:34, haraken wrote: > > Isn't it expensive to get an InterfacePtr at every callback? Is there any option > to cache it on the first time access? It's suppose to be pretty cheap, but it's not free either. I don't think we have good guidance on when we should cache vs re-request; we have a mix of both styles throughout the codebase currently.
The CQ bit was checked by estark@chromium.org to run a CQ dry run
> But we've been deprecating one shot timers in favor of postCancellableTask [1]: > would you be willing to guinea pig this? =) Sure, PTAL. https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... File third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp (right): https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp:51: void SendSensitiveInputVisibility(Document* document) { On 2016/11/22 01:57:34, haraken wrote: > > sendSensitiveInputVisibility n/a now (moved to Document) https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp:52: if (!document || !document->frame()) On 2016/11/22 01:53:25, dcheng wrote: > Nit: weak persistents should be automatically cancelled, so it's not necessary > to null check document. > > (Not sure if we can make this clearer by forcing it to bind as a mutable ref: > maybe +esprehn/+haraken/+tzik will have thoughts on this... that being said, > it's completely orthogonal to this CL and resolving the larger question is out > of scope of this CL. Just something to consider.) Done. https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp:56: mojo::GetProxy(&sensitiveInputServicePtr)); On 2016/11/22 02:00:30, dcheng wrote: > On 2016/11/22 01:57:34, haraken wrote: > > > > Isn't it expensive to get an InterfacePtr at every callback? Is there any > option > > to cache it on the first time access? > > It's suppose to be pretty cheap, but it's not free either. > > I don't think we have good guidance on when we should cache vs re-request; we > have a mix of both styles throughout the codebase currently. Acknowledged. Left it as is, though it would be easy enough to cache it on Document the first time we access it.
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
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_...)
On 2016/11/23 08:14:29, estark wrote: > > But we've been deprecating one shot timers in favor of postCancellableTask > [1]: > > would you be willing to guinea pig this? =) > > Sure, PTAL. > > https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... > File third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp (right): > > https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... > third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp:51: void > SendSensitiveInputVisibility(Document* document) { > On 2016/11/22 01:57:34, haraken wrote: > > > > sendSensitiveInputVisibility > > n/a now (moved to Document) > > https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... > third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp:52: if > (!document || !document->frame()) > On 2016/11/22 01:53:25, dcheng wrote: > > Nit: weak persistents should be automatically cancelled, so it's not necessary > > to null check document. > > > > (Not sure if we can make this clearer by forcing it to bind as a mutable ref: > > maybe +esprehn/+haraken/+tzik will have thoughts on this... that being said, > > it's completely orthogonal to this CL and resolving the larger question is out > > of scope of this CL. Just something to consider.) > > Done. > > https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... > third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp:56: > mojo::GetProxy(&sensitiveInputServicePtr)); > On 2016/11/22 02:00:30, dcheng wrote: > > On 2016/11/22 01:57:34, haraken wrote: > > > > > > Isn't it expensive to get an InterfacePtr at every callback? Is there any > > option > > > to cache it on the first time access? > > > > It's suppose to be pretty cheap, but it's not free either. > > > > I don't think we have good guidance on when we should cache vs re-request; we > > have a mix of both styles throughout the codebase currently. > > Acknowledged. Left it as is, though it would be easy enough to cache it on > Document the first time we access it. Hmm. I'm not really happy about making Document a place to put random things :) Can we encapsulate the InterfacePtr in PasswordInputType.cpp?
On 2016/11/23 13:51:48, haraken wrote: > On 2016/11/23 08:14:29, estark wrote: > > > But we've been deprecating one shot timers in favor of postCancellableTask > > [1]: > > > would you be willing to guinea pig this? =) > > > > Sure, PTAL. > > > > > https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... > > File third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp (right): > > > > > https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... > > third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp:51: void > > SendSensitiveInputVisibility(Document* document) { > > On 2016/11/22 01:57:34, haraken wrote: > > > > > > sendSensitiveInputVisibility > > > > n/a now (moved to Document) > > > > > https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... > > third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp:52: if > > (!document || !document->frame()) > > On 2016/11/22 01:53:25, dcheng wrote: > > > Nit: weak persistents should be automatically cancelled, so it's not > necessary > > > to null check document. > > > > > > (Not sure if we can make this clearer by forcing it to bind as a mutable > ref: > > > maybe +esprehn/+haraken/+tzik will have thoughts on this... that being said, > > > it's completely orthogonal to this CL and resolving the larger question is > out > > > of scope of this CL. Just something to consider.) > > > > Done. > > > > > https://codereview.chromium.org/2515373003/diff/1/third_party/WebKit/Source/c... > > third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp:56: > > mojo::GetProxy(&sensitiveInputServicePtr)); > > On 2016/11/22 02:00:30, dcheng wrote: > > > On 2016/11/22 01:57:34, haraken wrote: > > > > > > > > Isn't it expensive to get an InterfacePtr at every callback? Is there any > > > option > > > > to cache it on the first time access? > > > > > > It's suppose to be pretty cheap, but it's not free either. > > > > > > I don't think we have good guidance on when we should cache vs re-request; > we > > > have a mix of both styles throughout the codebase currently. > > > > Acknowledged. Left it as is, though it would be easy enough to cache it on > > Document the first time we access it. > > Hmm. I'm not really happy about making Document a place to put random things :) > Can we encapsulate the InterfacePtr in PasswordInputType.cpp? Yes, but then the callback will get called more often (once per password field per task instead of once per task for the whole Document). Is that okay? Also, I just want to make sure that will solve the original bug: if a stylesheet is being processed, an input element will get detached and attached but it'll stay the same PasswordInputType, correct?
The CQ bit was checked by estark@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Moved the cancellable task to PasswordInputType, not Document.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: This issue passed the CQ dry run.
I think it would be nice to dedupe on a Document level though... I guess one option is a Document supplement, so it wouldn't be embedded directly in Document. haraken@, would that be OK with you? https://codereview.chromium.org/2515373003/diff/40001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp (right): https://codereview.chromium.org/2515373003/diff/40001/third_party/WebKit/Sour... third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp:148: m_sensitiveInputVisibilityTask = Nit: I think we only want to post if !m_sensitiveInputVisibilityTask.isActive() is true (otherwise, I suppose this could get deferred for awhile)
On 2016/11/24 00:43:36, dcheng wrote: > I think it would be nice to dedupe on a Document level though... I guess one > option is a Document supplement, so it wouldn't be embedded directly in > Document. Does this really matter that much? The tasks only get posted when the document counter changes from 0->1 or 1->0 so I would be surprised if deduping at the Document level makes much of a difference. > > haraken@, would that be OK with you? > > https://codereview.chromium.org/2515373003/diff/40001/third_party/WebKit/Sour... > File third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp (right): > > https://codereview.chromium.org/2515373003/diff/40001/third_party/WebKit/Sour... > third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp:148: > m_sensitiveInputVisibilityTask = > Nit: I think we only want to post if !m_sensitiveInputVisibilityTask.isActive() > is true (otherwise, I suppose this could get deferred for awhile)
On 2016/11/24 00:46:24, estark wrote: > On 2016/11/24 00:43:36, dcheng wrote: > > I think it would be nice to dedupe on a Document level though... I guess one > > option is a Document supplement, so it wouldn't be embedded directly in > > Document. > > Does this really matter that much? The tasks only get posted when the document > counter changes from 0->1 or 1->0 so I would be surprised if deduping at the > Document level makes much of a difference. It's not 100% clear to me what's going on with the style recalc here: it's not clear to me if the transients during style recalc with multiple password inputs would look like: 0-> 1 -> 2-> 1 -> 0 -> 1 -> 2 Or 0 -> 1 -> 0 -> 1 -> 0 -> 1 -> 0 -> 1 -> 2 etc > > > > > haraken@, would that be OK with you? > > > > > https://codereview.chromium.org/2515373003/diff/40001/third_party/WebKit/Sour... > > File third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp (right): > > > > > https://codereview.chromium.org/2515373003/diff/40001/third_party/WebKit/Sour... > > third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp:148: > > m_sensitiveInputVisibilityTask = > > Nit: I think we only want to post if > !m_sensitiveInputVisibilityTask.isActive() > > is true (otherwise, I suppose this could get deferred for awhile)
On 2016/11/24 00:49:15, dcheng wrote: > On 2016/11/24 00:46:24, estark wrote: > > On 2016/11/24 00:43:36, dcheng wrote: > > > I think it would be nice to dedupe on a Document level though... I guess one > > > option is a Document supplement, so it wouldn't be embedded directly in > > > Document. > > > > Does this really matter that much? The tasks only get posted when the document > > counter changes from 0->1 or 1->0 so I would be surprised if deduping at the > > Document level makes much of a difference. > > It's not 100% clear to me what's going on with the style recalc here: it's not > clear to me if the transients during style recalc with multiple password inputs > would look like: > > 0-> 1 -> 2-> 1 -> 0 -> 1 -> 2 > > Or > > 0 -> 1 -> 0 -> 1 -> 0 -> 1 -> 0 -> 1 -> 2 > > etc > > > > > > > > > haraken@, would that be OK with you? > > > > > > > > > https://codereview.chromium.org/2515373003/diff/40001/third_party/WebKit/Sour... > > > File third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp > (right): > > > > > > > > > https://codereview.chromium.org/2515373003/diff/40001/third_party/WebKit/Sour... > > > third_party/WebKit/Source/core/html/forms/PasswordInputType.cpp:148: > > > m_sensitiveInputVisibilityTask = > > > Nit: I think we only want to post if > > !m_sensitiveInputVisibilityTask.isActive() > > > is true (otherwise, I suppose this could get deferred for awhile) If it matters to do the dedupe at the Document level, I'm fine with putting the code in Document.
The CQ bit was checked by estark@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Ok, I reverted back to patchset 2 that does it on Document. I'll have to investigate a bit to see whether it makes any difference to dedupe on Document, but it's a little hard for me to do that remotely, so I'll take a look next week when I'm back in the office.
LGTM You don't need to try hard to prove that the Document-level dedupe makes some difference. I just didn't want to add code that can be done in PasswordInput to Document. If doing that in Document is considered to have some benefit, I'm totally fine with it :)] https://codereview.chromium.org/2515373003/diff/60001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/dom/Document.cpp (right): https://codereview.chromium.org/2515373003/diff/60001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/Document.cpp:4343: void Document::sendSensitiveInputVisibilityImpl() { sendSensitiveInputVisibilityImpl => sendSensitiveInputVisibilityInternal
LGTM with comments addressed https://codereview.chromium.org/2515373003/diff/60001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/dom/Document.cpp (right): https://codereview.chromium.org/2515373003/diff/60001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/Document.cpp:4335: m_sensitiveInputVisibilityTask = Let's guard this with an isActive() so we only queue a new task if it's not already pending. https://codereview.chromium.org/2515373003/diff/60001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/Document.cpp:4344: if (!frame()) DCHECK(frame()), since I think it should be non-null in all the contexts where we use this.
https://codereview.chromium.org/2515373003/diff/60001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/dom/Document.cpp (right): https://codereview.chromium.org/2515373003/diff/60001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/Document.cpp:4335: m_sensitiveInputVisibilityTask = On 2016/11/24 01:54:08, dcheng wrote: > Let's guard this with an isActive() so we only queue a new task if it's not > already pending. Done. (Sorry I missed that suggestion earlier.) https://codereview.chromium.org/2515373003/diff/60001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/Document.cpp:4343: void Document::sendSensitiveInputVisibilityImpl() { On 2016/11/24 01:52:40, haraken wrote: > > sendSensitiveInputVisibilityImpl => sendSensitiveInputVisibilityInternal Done. https://codereview.chromium.org/2515373003/diff/60001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/Document.cpp:4344: if (!frame()) On 2016/11/24 01:54:08, dcheng wrote: > DCHECK(frame()), since I think it should be non-null in all the contexts where > we use this. I couldn't convince myself of this. Is it not possible that the Document would detach from the frame before the queued task runs?
The CQ bit was checked by estark@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
https://codereview.chromium.org/2515373003/diff/60001/third_party/WebKit/Sour... File third_party/WebKit/Source/core/dom/Document.cpp (right): https://codereview.chromium.org/2515373003/diff/60001/third_party/WebKit/Sour... third_party/WebKit/Source/core/dom/Document.cpp:4344: if (!frame()) On 2016/11/24 03:24:48, estark wrote: > On 2016/11/24 01:54:08, dcheng wrote: > > DCHECK(frame()), since I think it should be non-null in all the contexts where > > we use this. > > I couldn't convince myself of this. Is it not possible that the Document would > detach from the frame before the queued task runs? Ah-ha. You got me. You're totally right. I'm a bit torn on whether or not we should null check frame() here or just cancel the task proactively in Document::shutdown()... but either way is fine. Originally, I was thinking it was better to be explicit about it and explicitly cancel it in Document::shutdown()... but I guess we're going to queue this task *in* Document::shutdown() when we detach the layout tree. In conclusion: this is fine. Maybe in some hypothetical future we can change this, but this is safer for now. *sigh*
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: blimp_linux_dbg on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL) cast_shell_linux on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL) chromeos_x86-generic_chromium_compile_only_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL) linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL) linux_chromium_chromeos_compile_dbg_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL) linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL) linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL) linux_chromium_clobber_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL) linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL)
The CQ bit was checked by estark@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from haraken@chromium.org, dcheng@chromium.org Link to the patchset: https://codereview.chromium.org/2515373003/#ps80001 (title: "dcheng, haraken comments round 2")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Exceeded global retry quota
The CQ bit was checked by estark@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 80001, "attempt_start_ts": 1480001381834440,
"parent_rev": "0a863f923bc80fd3be63124ef3b7183edd8ee542", "commit_rev":
"cb1823858d296960b232b1ae23512aa703ebdb38"}
Message was sent while issue was closed.
Committed patchset #5 (id:80001)
Message was sent while issue was closed.
Description was changed from ========== Post tasks for sensitive input visibility notifications If password inputs are hidden and shown multiple times in the same task (as apparently happens when processing a stylesheet), we don't want to the omnibox warning to flicker in and out. Thus, this CL posts sensitive input visibility notifications to the end of the task queue, so that the omnibox warning updates get coalesced. BUG=664194 TEST=Visit http://http-password.badssl.com and observe that the omnibox warning does not flicker in and out twice. ========== to ========== Post tasks for sensitive input visibility notifications If password inputs are hidden and shown multiple times in the same task (as apparently happens when processing a stylesheet), we don't want to the omnibox warning to flicker in and out. Thus, this CL posts sensitive input visibility notifications to the end of the task queue, so that the omnibox warning updates get coalesced. BUG=664194 TEST=Visit http://http-password.badssl.com and observe that the omnibox warning does not flicker in and out twice. Committed: https://crrev.com/7bdbe352cdbd7cc1dec2b71653e60b47688bd9e1 Cr-Commit-Position: refs/heads/master@{#434340} ==========
Message was sent while issue was closed.
Patchset 5 (id:??) landed as https://crrev.com/7bdbe352cdbd7cc1dec2b71653e60b47688bd9e1 Cr-Commit-Position: refs/heads/master@{#434340}
Message was sent while issue was closed.
A revert of this CL (patchset #5 id:80001) has been created in https://codereview.chromium.org/2531683002/ by tapted@chromium.org. The reason for reverting is: Suspected for flaky failures on browser_tests for Mac 10.9 asan, Mac 10.10 E.g. SecurityStateTabHelperTestWithPasswordCcSwitch/SecurityStateTabHelperTestWithPasswordCcSwitch.PasswordSecurityLevelDowngradedFromIframe/0 SecurityStateTabHelperTest.PasswordSecurityLevelNotDowngradedWithoutSwitch https://uberchromegw.corp.google.com/i/chromium.memory/builders/Mac%20ASan%20... https://uberchromegw.corp.google.com/i/chromium.mac/builders/Mac10.10%20Tests... Errors like ../../chrome/browser/ssl/security_state_tab_helper_browser_tests.cc:966: Failure Value of: security_info.security_level Actual: 0 Expected: security_state::HTTP_SHOW_WARNING Which is: 1 ../../chrome/browser/ssl/security_state_tab_helper_browser_tests.cc:971: Failure Value of: entry->GetSSL().content_status & content::SSLStatus::DISPLAYED_PASSWORD_FIELD_ON_HTTP Actual: false Expected: true. |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
