Issue metadata
Sign in to add a comment
|
Omnibox contents flicker as you type |
||||||||||||||||||||||
Issue descriptionVersion: 56.0.2909.0 OS: masOS 10.11 What steps will reproduce the problem? (1) Launch Chrome with an empty user data dir (2) Create a new window (3) Start typing https:// What is the expected output? The omnibox content should smoothly update. What do you see instead? The content flickers as you type each character. When you type the magnifying glass changes to a document icon, but as you type each character the icon briefly changes back to the magnifying glass before going back to the document icon. The text also flickers between black and gray. Finally the "Press tab to search Google" text briefly disappears and then reappears. It seems like when you type a character the omnibox shows what you've typed so far, and then an update comes in with the omnibox's autocomplete suggestion and the omnibox content gets updated. We should avoid drawing the intermediate state. I tried this back as far as M54 stable and still see it there.
,
Nov 4 2016
,
Nov 4 2016
,
Nov 10 2016
Able to reproduce the issue on Mac 10.11.6 using latest canary 56.0.2915.0. This is a regression issue broken in M 53. Bisect info: ============ Good: 53.0.2782.0 Bad : 53.0.2784.0 Unable to run the tool bisect due to chromium is not invoking, below is the suspect from omahaproxy UI CL. CL : https://chromium.googlesource.com/chromium/src/+log/53.0.2782.0..53.0.2784.0?pretty=fuller&n=10000 Suspect : Review-Url: https://codereview.chromium.org/2082723002 spqchan@ : Could you please take a look into it. Note: Unable to reproduce the issue on Windows and Linux.
,
Nov 11 2016
That CL doesn't have anything to do with the flicker. This is being caused by multiple parts of the location, autocomplete cell, etc updating the UI. This is going to take a while to investigate.
,
Nov 11 2016
Looks like it's flickering between "Edit without any suggestions" and "Edit with suggestions"
,
Nov 18 2016
Friendly ping to get an update on this.
,
Nov 30 2016
,
Dec 6 2016
spqchan@ Friendly ping to get an update on this issue.
,
Dec 6 2016
Working on it
,
Dec 13 2016
I've been looking at this and it looks like we're doing something weird with the match results with this edge case. For some reason as we type "http", we're getting match results on the omnibox. Based on what I'm seeing on Windows and other cases on Mac, this should not happen. We shouldn't get any match results until we finished typing "https://" I'm not really sure why this is happening, this is something I'll have to dig into.
,
Dec 13 2016
It's not necessarily true that you shouldn't get match results while typing a scheme. It would depend on the profile data, I'd think.
,
Dec 13 2016
Ah, never mind. Disregard what I said on #11. I got mixed up with something else. Anyway, I'm currently investigating why the results are weird
,
Jan 10 2017
Just to Update, Still able to reproduce the issue on Mac 10.12.2 using latest chrome version 57.0.2977.0. spqchan@: Could you please look in to this issue. Thanks!
,
Jan 10 2017
Talked to shrike@ about this issue and we decided that it's not a blocker
,
Jan 10 2017
This has been broken for awhile (since M53) and only occurs with an empty user data dir, so given how many other regressions we have right now and the fact that this so far has not been easy to track down I said we should remove it as a release blocker. I haven't had a chance to review all of the regressions - once I do I'll have a better idea of how much time we have to try to fix it.
,
Jan 10 2017
,
Jan 10 2017
,
Jan 25 2017
,
Feb 12 2017
Issue 691367 has been merged into this issue.
,
Mar 4 2017
,
Jun 22 2017
This certainly would be an issue if it's widespread. I don't see it on a Mac with my various profiles. Can anyone still reproduce this?
,
Jun 22 2017
I just tried and can no longer reproduce. I'm going to mark it WontFix. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by shrike@chromium.org
, Nov 4 20164.0 MB
4.0 MB Download