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

Issue 848683 link

Starred by 1 user

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: Jul 21
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression: Imported bookmarks content appear missing after reloading the page in chrome://bookmarks/

Reported by vku...@etouch.net, Jun 1 2018

Issue description

Chrome Version: 69.0.3447.0 (Official Build)Revision ec57e30ccad35465163bffcc3860ac8b30a6fb33-refs/branch-heads/3447@{#1} 32/64-bit.
OS:Windows (7,8,8.1,10),Mac OS X(10.12.6,10.13.1,10.13.6) & Linux (14.04 LTS)

Precondition: Make sure Long list of bookmark file is present on system to import (file attached for reference)

What steps will reproduce the problem?
(1)Launch chrome and navigate chrome://bookmarks/
(2)Click on 'Organize' > Import bookmarks > Upload html file from system.
(3)Reload the page and click on 'long history' folder,observe the content of bookmarks

Actual: Imported bookmarks content appear missing after reloading the page in chrome://bookmarks/

Expected: Imported bookmarks content should appear completely even after reloading the page.

This is a regression issue broken in 'M69' and below is the manual bisect info:
Good Build: 69.0.3442.0 (Revision:562139)
Bad Build:  69.0.3443.0 (Revision:562160)

(Unable to narrow down the range using per-revision bisect,hence providing bisect using old script)
Narrow Bisect info: 
You are probably looking for a change made after 562149 (known good), but no later than 562150 (first known bad).
CHANGELOG URL:
https://chromium.googlesource.com/chromium/src/+log/883c397ddd952ca243d37f7ce68dc3b4235f2f20..21154794b8ae44ef571979016fd64b1de23a7cb7?pretty=fuller&n=10

Suspect: https://chromium.googlesource.com/chromium/src/+/21154794b8ae44ef571979016fd64b1de23a7cb7

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





 
long_bookmarks.html
113 KB View Download
ActualBookmark.mp4
343 KB View Download
ExpectedBookmark.mp4
559 KB View Download
Cc: pbomm...@chromium.org
Labels: ReleaseBlock-Stable
Adding release blocker label for this issue.Please reduce priority or remove if not the case.

Thank You!
Status: Started (was: Assigned)
Confirmed that the issue goes away when I flip the flag back.  Investigating now.
Cc: calamity@chromium.org
It looks like the parser change changed the timing of some activities and exposed an issue with the iron-list implementation.  Specifically around iron-resize: https://www.webcomponents.org/element/PolymerElements/iron-list#resizing

I don't know the bookmarks code well enough to know the sequencing for how they are loaded and when things are displayed/hidden (working on figuring it out but also +others who know it better).

Scattering this.$.list.fire('iron-resize'); in a couple of places in list.js fixes the issue but I want to make sure it is fixed correctly.
Project Member

Comment 4 by bugdroid1@chromium.org, Jun 7 2018

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

commit 6bea985101e8377d30f671f83c573ce565085053
Author: Patrick Meenan <pmeenan@chromium.org>
Date: Thu Jun 07 14:00:20 2018

Notify the iron list to resize based on the new list of elements.

This fixes an issue where long bookmark lists do not display the full
content when scrolled.

Bug:  848683 
Cq-Include-Trybots: master.tryserver.chromium.linux:closure_compilation
Change-Id: Ie4c273f952a2348bc332d43e2c8193ca20e0f33f
Reviewed-on: https://chromium-review.googlesource.com/1085227
Reviewed-by: calamity <calamity@chromium.org>
Commit-Queue: Patrick Meenan <pmeenan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#565252}
[modify] https://crrev.com/6bea985101e8377d30f671f83c573ce565085053/chrome/browser/resources/md_bookmarks/list.js

Comment 5 by vku...@etouch.net, Jun 8 2018

Labels: TE-Verified-M69 TE-Verified-69.0.3453.0
Update : 

Rechecked this issue on Windows (7,8,8.1,10), Mac OS X(10.12.6,10.13.1,10.13.6) and Linux (14.04 LTS) OS with latest Canary Chrome version: 69.0.3453.0 and the issue is fixed.Kindly refer attached screen cast for your reference.
Actual_Canary.mp4
785 KB View Download
Can we tag this as fixed?
Status: Verified (was: Started)
Yes, sorry, I thought it had been flipped to fixed when the verified tags had been added.
Labels: Merge-TBD
[Auto-generated comment by a script] We noticed that this issue is targeted for M-69; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-69 label, otherwise remove Merge-TBD label. Thanks.
Labels: -Merge-TBD
No merge.  Fix landed long before branch point.

Sign in to add a comment