New issue
Advanced search Search tips

Issue 664674 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Nov 2016
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 1
Type: Bug
Team-Security-UX



Sign in to add a comment

HTTP-bad warning sometimes disappears shortly after navigation

Project Member Reported by est...@chromium.org, Nov 12 2016

Issue description

Version: 56.0.2917.0
OS: Linux

What steps will reproduce the problem?
(1) Open Chrome and open DevTools.
(2) Navigate to http://nytimes.com.
(3) Navigate to http://http-password.badssl.com

What is the expected result?
"Not secure" warning appears in omnibox and stays there.

What happens instead?
"Not secure" warning flickers into view and then disappears.
 

Comment 1 by est...@chromium.org, Nov 12 2016

Labels: -OS-Linux -Pri-2 OS-All Pri-1
Summary: HTTP-bad warning sometimes disappears shortly after navigation (was: With DevTools open, HTTP-bad warning disappears shortly after navigation)
Reproduced on Mac too without DevTools open. Must be something timing-related that DevTools happens to trigger.
Project Member

Comment 2 by bugdroid1@chromium.org, Nov 15 2016

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/31558028cf555b5ff9a29917b206c52ac8faee20

commit 31558028cf555b5ff9a29917b206c52ac8faee20
Author: estark <estark@chromium.org>
Date: Tue Nov 15 12:33:00 2016

Track visible password fields by RenderFrameHost, not frame tree node

Previously, VisiblePasswordObserver was tracking each frame tree node
that shows or removes password fields. However, the same frame tree node
can be associated with different RenderFrameHosts over time: see the
comment on RenderFrameHost::GetFrameTreeNodeId. This means that we could
receive a message that a RenderFrameHost corresponding to frame tree
node X was deleted, and we'd treat that as if frame tree node X no
longer has visible password fields. But frame tree node X could have
been transferred to a different process during a navigation, meaning
that there might be a different RenderFrameHost for frame tree node X
that does have a visible password field. In this case we would
incorrectly remove the "Not secure" warning when the original
RenderFrameHost is deleted.

This CL tracks password fields by RenderFrameHost instead of by frame
tree node id, so that we don't confuse messages from different RFHs
corresponding to the same frame tree node during cross-process
navigations.

BUG= 664674 
TEST=With the #mark-non-secure-as flag set to "Display a verbose state
when password or credit card fields are detected on an HTTP page",
navigate to http://nytimes.com, then to
http://http-password.badssl.com. Ensure that a "Not secure" warning
shows up in the omnibox on the latter page and does not
disappear. Repeat several times since the reproduction is flaky.

Review-Url: https://codereview.chromium.org/2500213002
Cr-Commit-Position: refs/heads/master@{#432167}

[modify] https://crrev.com/31558028cf555b5ff9a29917b206c52ac8faee20/components/password_manager/content/browser/content_password_manager_driver_unittest.cc
[modify] https://crrev.com/31558028cf555b5ff9a29917b206c52ac8faee20/components/password_manager/content/browser/visible_password_observer.cc
[modify] https://crrev.com/31558028cf555b5ff9a29917b206c52ac8faee20/components/password_manager/content/browser/visible_password_observer.h

Comment 3 by est...@chromium.org, Nov 16 2016

Status: Fixed (was: Assigned)

Sign in to add a comment