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

Issue 671960 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Not on Chrome
Closed: Dec 2016
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression : History entries are missing in duplicate tab.

Reported by yfulgaon...@etouch.net, Dec 7 2016

Issue description

Chrome Version : 57.0.2944.0 (Official Build) bb1ac197d94d071514695c0f23854881db26f012-refs/heads/master@{#436816} 32/64 bit
OS : Mac(10.11.6, 10.12.1, 10.12), Windows(7,8,8.1,10), Linux (14.04 LTS)

Precondition : Navigate to some web pages and generate history entries.

What steps will reproduce the problem?
1. Launch chrome and navigate to chrome://history.
2. Middle click on ‘Reload’ button (duplicate tab opens) and observe the contents in duplicate tab.

Actual : History entries are missing in duplicate tab.
Expected : History entries should be seen in duplicate tab as well.

This is a regression issue broken in ‘M-57’, below is the Manual Regression range and will soon update other info.
Good build : 57.0.2943.0
Bad build : 57.0.2944.0
 
Actual_history.mov
4.1 MB Download
Expected_history.mov
3.5 MB Download
Labels: hasbisect-per-revision
Owner: tsergeant@chromium.org
Status: Assigned (was: Unconfirmed)
Using the per-revision bisect providing the bisect results,
Good build: 57.0.2943.0 (Revision: 436483).
Bad build: 57.0.2944.0 (Revision: 436816).

You are probably looking for a change made after 436540 (known good), but no later than 436541 (first known bad).
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/6ee456f20d1987d8dfa75f1c431722111eb4ca2a..de3f7c638407ff97118047ff6519c3f84055dd25

@tsergeant -- Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.

Thank You.
Status: Started (was: Assigned)
Seems to be a timing issue where results become available before the <iron-pages> elements knows what it is showing.
Project Member

Comment 3 by bugdroid1@chromium.org, Dec 8 2016

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

commit 546b09b2e48f471fd08f991d477c952689ad8b99
Author: tsergeant <tsergeant@chromium.org>
Date: Thu Dec 08 06:37:40 2016

MD History: Fix loading of history results in background tabs

When reloading the history page in a background tab, it was possible for
results to arrive before the page was fully initialized and the
<iron-pages> element knew which type of history list should be used.

This replaces the list selection code with a direct selector, removing
the dependency on <iron-pages> startup from page initialization.

BUG= 671960 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

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

[modify] https://crrev.com/546b09b2e48f471fd08f991d477c952689ad8b99/chrome/browser/resources/md_history/app.crisper.js
[modify] https://crrev.com/546b09b2e48f471fd08f991d477c952689ad8b99/chrome/browser/resources/md_history/app.vulcanized.html
[modify] https://crrev.com/546b09b2e48f471fd08f991d477c952689ad8b99/chrome/browser/resources/md_history/list_container.js

Status: Fixed (was: Started)

Sign in to add a comment