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

Issue 803011 link

Starred by 2 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

Regreesion: Unwanted blink of previous URL is seen in omnibox while clicking on back navigation button.

Reported by db...@etouch.net, Jan 17 2018

Issue description

Chrome Version: 65.0.3323.0 Revision 470d3a6be2f380affa8de3dc0dd1508f3eeba9f7-refs/heads/master@{#529554}(32/64 bit)
OS: Windows(7,8,8.1,10),Linux(14.04 LTS)

What steps will reproduce the problem?
(1) Launch chrome, open NTP and navigate to chrome://version.
(2) Type chrome://kill in omnibox and then observe in omnibox while clicking on back navigation button 

Actual: Unwanted blink of previous URL (i.e. chrome://version) is seen in omnibox while clicking on back navigation button.

Expected: No such a blink of URL should seen in omnibox while clicking on back navigation button.

This is a regression issue, broken in 'M65', Using the per-revision bisect providing the bisect results:

Good Build: 65.0.3317.0(528120)
Bad Build: 65.0.3318.0(528541)

You are probably looking for a change made after 528476 (known good), but no later than 528477 (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/2140d23a8add3f894fd9c94f5916e92974feb435..966d29e791e4811124037ae509754c4277391fd1

Suspect: https://chromium.googlesource.com/chromium/src/+/966d29e791e4811124037ae509754c4277391fd1

Note: Issue is not seen on Mac(10.12.6,10.13.1,10.13.3) OS.
 
Actual_URL.mp4
715 KB View Download
Expected_URL.mp4
451 KB View Download
Labels: RegressedIn-65 Target-65 FoundIn-65
Cc: fsam...@chromium.org
Owner: pkasting@chromium.org
I tried --disable-features="SurfaceSynchronization" to disable surface synchronization and I am still able to repro this bug. I suspect surface synchronization perturbed the timing a bit making it more obvious, but this is an existing issue. Passing along to pkasting@ for triage.
Cc: pkasting@chromium.org
Owner: ----
Status: Untriaged (was: Assigned)
Marking as Untriaged so the omnibox triage process picks it up.
Labels: ET-MUM-Reported
Labels: -Pri-1 Pri-2
Status: Available (was: Untriaged)
Hey, I was able to reproduce this.

I can also say that the root cause is likely an Omnibox bug rather than a graphical artifact. 

I added some trace statements, and for the steps listed in comment#0, chrome://version is indeed restored into the OmniboxEditModel when the user presses back.

I also added a printf statement in OmniboxEditModel::ResetDisplayUrls. Here are the logs:

url for editing: chrome://version
[1:1:0220/095652.388464:ERROR:render_frame_impl.cc(878)] Intentionally terminating current process because user navigated to chrome://kill/
url for editing: chrome://kill
url for editing: chrome://version

Sign in to add a comment