New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 866781 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Jul 27
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Regression : Omnibox border disappears after using "Enter passphrase" button of signin popup.

Reported by pranjali...@etouch.net, Jul 24

Issue description

Chrome version : 70.0.3500.0 (Official Build)  19fb8c745affb4c0f621296e66bac6094e692076-refs/branch-heads/3500@{#1}(32/64-bit) 

OS: Windows (7,8,8.1,10) ,Mac(10.12.6,10.13.1,10.13.6,10.14) and Linux(14.04  LTS)OS

What steps will reproduce the problem?
1.Launch chrome , sign into chrome with valid credentials and set passphrase.
2. Sign out from account and again click on sign into chrome button and sign in with valid credentials.(please refer attached screencast)
3. Click on avatar icon(showing error for passphrase ) and click on 'enter passphrase' button.
4. Now enter wrong passphrase and switch to NTP.
5. Observe.

Actual  : Omnibox border disappears after entering wrong passphrase.
Expected: Omnibox border should not disappears after entering wrong passphrase.

This is a regression issue broken in ‘M-69’ and below is bisect info.
Good build: 69.0.3496.0
Bad build: 69.0.3497.0

You are probably looking for a change made after 576751 (known good), but no later than 576752 (first known bad).

CHANGELOG URL:

The script might not always return single CL as suspect as some perf builds might get missing due to failure.
 https://chromium.googlesource.com/chromium/src/+log/43dcce8bc1451019ca9e00f89d7098f6617f72cd..26c6253c48d5cccca00276cd42c812500130fe20

Suspecting : https://chromium.googlesource.com/chromium/src/+/26c6253c48d5cccca00276cd42c812500130fe20

@tommycli: Could you please check whether this is caused with respect to your change, if not please help to reassigning it to the right owner.

Note: For Mac OS  ,enable 'Use Views browser windows instead of Cocoa' flag from 'chrome://flags' to reproduce issue.

Thank You!
 
Actual_result.mp4
1.0 MB View Download
Expected_result.mp4
946 KB View Download
Status: Started (was: Assigned)
Summary: Regression : Omnibox border disappears after using "Enter passphrase" button of signin popup. (was: Regression : Omnibox border disappears after entering wrong passphrase.)
This bug occurs whenever the user clicks the "Enter passphrase" button and is switched to the Settings tab.

There's no need to actually enter a passphrase at all. Switching back to the original tab will reproduce the bug.
tommycli: When you switch back and the focus state is incorrect, typing will fix things up, I assume? If so, it's a relatively rare action producing a mostly cosmetic issue, yes?

If so, this seems to me like a P2 and not worth merging.
Labels: -OS-Linux -Pri-1 Pri-2
Indeed typing fixes things up.

I'm okay with not merging.
Labels: OS-Linux
Project Member

Comment 5 by bugdroid1@chromium.org, Jul 25

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

commit 19422be2e791e3a33e9e6b8644499f3f4273dc71
Author: Tommy C. Li <tommycli@chromium.org>
Date: Wed Jul 25 23:47:13 2018

Omnibox UI Refresh: Prevent restoring incorrect edit model focus state

The tab management system saves and restores the last-focused control
for each tab.

However, if the last-focused control is destroyed, the browser focuses
the Omnibox by default. In those cases, the edit model's saved focus
state will be incorrect.

This CL prevents that weird state from occurring by cross-checking the
edit model's saved focus state with the actual focus state restored by
the tab management system.

This state de-syncing was always there, but has been recently made
visibly apparent because of:
https://chromium-review.googlesource.com/c/chromium/src/+/1144211

Bug:  866781 
Change-Id: I0e85be9f650ae896021096e6c546b9f085d528d6
Reviewed-on: https://chromium-review.googlesource.com/1149191
Commit-Queue: Tommy Li <tommycli@chromium.org>
Reviewed-by: Justin Donnelly <jdonnelly@chromium.org>
Cr-Commit-Position: refs/heads/master@{#578131}
[modify] https://crrev.com/19422be2e791e3a33e9e6b8644499f3f4273dc71/components/omnibox/browser/omnibox_edit_model.cc
[modify] https://crrev.com/19422be2e791e3a33e9e6b8644499f3f4273dc71/components/omnibox/browser/omnibox_edit_model_unittest.cc

Cc: tnijssen@google.com tommycli@chromium.org
 Issue 866995  has been merged into this issue.
Cc: jdonnelly@chromium.org
Labels: Merge-Request-69
I just confirmed in Canary that it fixes both the above symptom as well as the tab-dragging misbehavior in 866995.

Justin - Since the tab-dragging misbehavior seems to be a more frequent occurrence, does a merge make more sense now?
Project Member

Comment 8 by sheriffbot@chromium.org, Jul 27

Labels: -Merge-Request-69 Hotlist-Merge-Approved Merge-Approved-69
Your change meets the bar and is auto-approved for M69. Please go ahead and merge the CL to branch 3497 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
Project Member

Comment 9 by bugdroid1@chromium.org, Jul 27

Labels: -merge-approved-69 merge-merged-3497
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/9e541135d0b0f9654208c3bbc05421930e256c93

commit 9e541135d0b0f9654208c3bbc05421930e256c93
Author: Tommy C. Li <tommycli@chromium.org>
Date: Fri Jul 27 16:45:04 2018

Omnibox UI Refresh: Prevent restoring incorrect edit model focus state

The tab management system saves and restores the last-focused control
for each tab.

However, if the last-focused control is destroyed, the browser focuses
the Omnibox by default. In those cases, the edit model's saved focus
state will be incorrect.

This CL prevents that weird state from occurring by cross-checking the
edit model's saved focus state with the actual focus state restored by
the tab management system.

This state de-syncing was always there, but has been recently made
visibly apparent because of:
https://chromium-review.googlesource.com/c/chromium/src/+/1144211

Bug:  866781 
Change-Id: I0e85be9f650ae896021096e6c546b9f085d528d6
Reviewed-on: https://chromium-review.googlesource.com/1149191
Commit-Queue: Tommy Li <tommycli@chromium.org>
Reviewed-by: Justin Donnelly <jdonnelly@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#578131}(cherry picked from commit 19422be2e791e3a33e9e6b8644499f3f4273dc71)
Reviewed-on: https://chromium-review.googlesource.com/1153307
Reviewed-by: Tommy Li <tommycli@chromium.org>
Cr-Commit-Position: refs/branch-heads/3497@{#157}
Cr-Branched-From: 271eaf50594eb818c9295dc78d364aea18c82ea8-refs/heads/master@{#576753}
[modify] https://crrev.com/9e541135d0b0f9654208c3bbc05421930e256c93/components/omnibox/browser/omnibox_edit_model.cc
[modify] https://crrev.com/9e541135d0b0f9654208c3bbc05421930e256c93/components/omnibox/browser/omnibox_edit_model_unittest.cc

Status: Fixed (was: Started)

Sign in to add a comment