Issue metadata
Sign in to add a comment
|
Bookmark Manager only displays the first 60 bookmarks in a folder that contains roughly 100 bookmarks
Reported by
mtolle.m...@gmail.com,
Jul 31
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.75 Safari/537.36 Steps to reproduce the problem: 1. Open a folder in bookmark manger and scroll down 2. 3. What is the expected behavior? All bookmarks should appear What went wrong? Bookmark Manager doesn't display all of the bookmarks. Did this work before? Yes M67 Chrome version: 68.0.3440.75 Channel: stable OS Version: Ubuntu 14 and Mint 17 Flash Version: Google Chrome Stable 68.0.3440.75 removed the flag to disable Material Design in the Bookmark Manager - thus forcing Material Design of the Bookmark Manager. The initial reason I preferred the prior Bookmark Manager is because I was able to copy bookmarks, and paste them in a different folder - which I am unable to do in the Material Design interface. Now that the flag to disable Material Design in the Bookmark Manager has been removed, I notice that the Bookmark Manager only displays the first 60 bookmarks in a folder that contains roughly 100 bookmarks. Another folder that contains over 400 bookmarks also displays only the first 60.
,
Jul 31
https://bugs.chromium.org/p/chromium/issues/detail?id=834205 tracks work to remove the non-MD bookmark manager. The first and only comment there WAS April 30 - until I found it today.
,
Jul 31
Note - -- disable-md-bookmarks when appended to the command line when launching Chrome doesn't work either
,
Jul 31
,
Jul 31
Same problems in Windows 10 - Folders that contains hundreds of bookmarks only display a fraction of the bookmarks in the folder. Unable to copy/paste bookmarks among folders.
,
Jul 31
Loaded Chrome with hardware acceleration enabled and all bookmarks in a large collection displayed properly ... But ... I have had hardware acceleration disabled since Sept 2017 when Chrome M61 started crashing hard [complete system freezes] Neither condition is acceptable. What do you suggest?
,
Aug 1
Unable to reproduce the issue on reported version #68.0.3440.75 using Ubuntu 17.10 by following below steps Steps: ===== 1.Launched chrome. 2.Opened bookmark manager and able to see all the bookmarks. 3.Copied bookmark from one folder to other and was able to copy and no issues are observed. Attached is the screen-cast for reference. @reporter : Could you please review the screen-cast and let us know if anything is being missed from our end.Requesting to test this issue by creating new profile with no apps and extensions in it and let us know if the issue still persists. Thanks!
,
Aug 1
Chrome with hardware acceleration enabled displayed all bookmarks in a large collection properly. However, I had to disable hardware acceleration mid Sept 2017 when Chrome M61 started crashing hard [system frozen completely]. The Chromium team never provided a fix to whatever causes those crashes - my system still crashes with hardware acceleration enabled. Attached screenshot shows whitespace in a folder that should display 1304 bookmarks. The only extensions in this install of Chrome are Google Docs - and they are curently disabled. Perhaps you could provide instructions to me so that I could bisect Chrome 68.0.3440.84 Stable (64-bit) targeting the interaction of the Material Design Bookmark Manager and GPU Hardware Acceleration?
,
Aug 1
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 2
I did some further testing - Ubuntu 14.04.05 LTS Linux 4.4.0-130-generic x86_64 Dell Dimension-C521 desktop w/AMD Athlon 64 Processor 3200+ Gallium 0.4 on NV4E Able to display all bookmarks but Chrome 68.0.3440.84 crashes with hardware acceleration enabled. Mint 17.3 Cinnamon Ubuntu 14.04.03 LTS Linux 4.4.0-130-generic x86_64 Acer NV51B laptop w/AMD Dual Core C50 AMD Radeon HD 6250 Unable to display all bookmarks in Chrome 68.0.3440.84 with or without hardware acceleration enabled.
,
Aug 2
Unable to repro the issue on chrome version #68.0.3440.84 as per comment#17 using Ubuntu 14.04 and Ubuntu 17.10, by following below steps. Steps: ===== 1.Launched chrome. 2.Disabled hardware acceleration. 3.Opened bookmark manager and able to see all the bookmarks. 4.Copied bookmark from one folder to other and was able to copy and no issues are observed. Note : Tried with both enabling and disabling the hardware acceleration. Attached screen cast for reference. @reporter : Could you please review the attached screen cast and let us know if any thing is being missed from our end.As per comment#12 requesting you to provide the crash id by navigating to chrome://crashes. Thanks.!
,
Aug 2
Uploaded Crash Report ID fcba4a2beff0f7b0 (Local Crash ID: Chrome) Crash report uploaded on Thursday, August 2, 2018 at 9:47:47 AM Uploaded Crash Report ID 00602a2202b949a1 (Local Crash ID: Chrome) Crash report uploaded on Thursday, August 2, 2018 at 9:48:38 AM Uploaded Crash Report ID a9ede6cef4580a5a (Local Crash ID: Chrome) Crash report uploaded on Thursday, August 2, 2018 at 9:49:21 AM Uploaded Crash Report ID 65c69b89c3046c86 (Local Crash ID: Chrome) Crash report uploaded on Thursday, August 2, 2018 at 9:51:15 AM
,
Aug 2
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Aug 3
FWIW, the crashes provided seem to be related to graphics issues (nouveau_dri.so).
,
Aug 3
The [old] bookmark manager worked just fine without hardware acceleration. Only when the code to support the prior bookmark manager was removed in M68 did I consider testing the Material Design Bookmark Manager with hardware acceleration enabled. As I stated in comment #12 - I had to disable hardware acceleration mid Sept 2017 when Chrome M61 started crashing [sometimes freezing the system completely]. I have the most up to date drivers and my system functions perfectly. Unfortunately, Chrome still crashes with hardware acceleration enabled - the Chromium team never properly re-mediated whatever causes those crashes. I have been perfectly happy to run Chrome without hardware acceleration enabled, as I have observed no appreciable improvement in performance. Since your team is apparently deeply committed to migrating to a common code base across all your products on all platforms, the obvious question going forward is this: Shouldn't the Material Design Bookmark Manager properly display all the bookmarks in a folder - without hardware acceleration enabled? Will your team work to achieve that? If not, then my choices become: Replace my laptop? Upgrade the video card in my desktop? Or, more simply and less expensively, just get used to Firefox again?
,
Aug 3
As per comment#10 and #comment18, unable to reproduce the issue on reported version #68.0.3440.75 and on latest stable #68.0.3440.84 using Ubuntu 14.04 and Ubuntu 17.10. Hence removing Needs-Bisect label as it is not getting reproduced from TE end.Requesting anyone from UI>Browser>Bookmarks team to look into the issue. Thanks.!
,
Aug 3
I think I figured out the command to bisect 67.0.3396.99..68.0.3440.84 python bisect-builds.py -a linux64 -g 550428 -b 561733 Downloading list of known revisions... (use --use-local-cache to cache and re-use the list of revisions) Downloading revision 555754...inux_x64/98946// Received 103060169 of 103060169 bytes, 100.00% Bisecting range [550430 (good), 561732 (bad)], roughly 12 steps left. Trying revision 555754... Revision 555754 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 558484... Bisecting range [555754 (good), 561732 (bad)], roughly 11 steps left. Trying revision 558484... Revision 558484 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 560184... Bisecting range [558484 (good), 561732 (bad)], roughly 10 steps left. Trying revision 560184... Revision 560184 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 560818... Bisecting range [560184 (good), 561732 (bad)], roughly 9 steps left. Trying revision 560818... Revision 560818 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 561309... Bisecting range [560818 (good), 561732 (bad)], roughly 8 steps left. Trying revision 561309... Revision 561309 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 561468... Bisecting range [561309 (good), 561732 (bad)], roughly 7 steps left. Trying revision 561468... Revision 561468 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 561580... Bisecting range [561468 (good), 561732 (bad)], roughly 6 steps left. Trying revision 561580... Revision 561580 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 561515... Bisecting range [561468 (good), 561580 (bad)], roughly 5 steps left. Trying revision 561515... Revision 561515 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 561541... Bisecting range [561515 (good), 561580 (bad)], roughly 4 steps left. Trying revision 561541... Revision 561541 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 561551... Bisecting range [561541 (good), 561580 (bad)], roughly 3 steps left. Trying revision 561551... Revision 561551 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 561562... Bisecting range [561551 (good), 561580 (bad)], roughly 2 steps left. Trying revision 561562... Revision 561562 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 561577... Bisecting range [561562 (good), 561580 (bad)], roughly 2 steps left. Trying revision 561577... Revision 561577 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g You are probably looking for a change made after 561577 (known good), but no later than 561580 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/ed65b2457027ad2dc357bb8ccb8632a2a7637644..f85585b37189469ba6c9b53dfea57d88f1a9fe0f-builds.py -a linux64 -g 550428 -b 561733 Hope this helps identify the problem and provides a basis to remediate it
,
Aug 3
None of the three commits in the bisected range is related to bookmarks. See if you can reproduce using --verify-range -g 561577 -b 561580 Otherwise try bisecting again.
,
Aug 3
$ python bisect-builds.py -a linux64 -g 550428 -b 561733 Downloading list of known revisions... (use --use-local-cache to cache and re-use the list of revisions) Downloading revision 555754...inux_x64/98946// Received 103060169 of 103060169 bytes, 100.00% Bisecting range [550430 (good), 561732 (bad)], roughly 12 steps left. Trying revision 555754... Revision 555754 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 558484... Bisecting range [555754 (good), 561732 (bad)], roughly 11 steps left. Trying revision 558484... Revision 558484 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 560184... Bisecting range [558484 (good), 561732 (bad)], roughly 10 steps left. Trying revision 560184... Revision 560184 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 559416... Bisecting range [558484 (good), 560184 (bad)], roughly 9 steps left. Trying revision 559416... Revision 559416 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 558884... Bisecting range [558484 (good), 559416 (bad)], roughly 8 steps left. Trying revision 558884... Revision 558884 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 558660... Bisecting range [558484 (good), 558884 (bad)], roughly 7 steps left. Trying revision 558660... Revision 558660 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 558611... Bisecting range [558484 (good), 558660 (bad)], roughly 6 steps left. Trying revision 558611... Revision 558611 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 558561... Bisecting range [558484 (good), 558611 (bad)], roughly 5 steps left. Trying revision 558561... Revision 558561 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 558524... Bisecting range [558484 (good), 558561 (bad)], roughly 4 steps left. Trying revision 558524... Revision 558524 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 558500... Bisecting range [558484 (good), 558524 (bad)], roughly 3 steps left. Trying revision 558500... Revision 558500 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 558493... Bisecting range [558484 (good), 558500 (bad)], roughly 2 steps left. Trying revision 558493... Revision 558493 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b You are probably looking for a change made after 558484 (known good), but no later than 558493 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/cb526bb53f0399662a2c9d5bd3889257b52907f9..b013458806a073a78d15d153763f2655daea91df
,
Aug 4
$ python bisect-builds.py -a linux64 -g 550428 -b 561733 Downloading list of known revisions... (use --use-local-cache to cache and re-use the list of revisions) Downloading revision 555754...inux_x64/98946// Received 103060169 of 103060169 bytes, 100.00% Bisecting range [550430 (good), 561732 (bad)], roughly 12 steps left. Trying revision 555754... Revision 555754 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 552936... Bisecting range [550430 (good), 555754 (bad)], roughly 11 steps left. Trying revision 552936... Revision 552936 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 551793... Bisecting range [550430 (good), 552936 (bad)], roughly 10 steps left. Trying revision 551793... Revision 551793 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 552364... Bisecting range [551793 (good), 552936 (bad)], roughly 9 steps left. Trying revision 552364... Revision 552364 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 552616... Bisecting range [552364 (good), 552936 (bad)], roughly 8 steps left. Trying revision 552616... Revision 552616 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 552572... Bisecting range [552364 (good), 552616 (bad)], roughly 7 steps left. Trying revision 552572... Revision 552572 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b Downloading revision 552492... Bisecting range [552364 (good), 552572 (bad)], roughly 6 steps left. Trying revision 552492... Revision 552492 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 552537... Bisecting range [552492 (good), 552572 (bad)], roughly 5 steps left. Trying revision 552537... Revision 552537 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 552556... Bisecting range [552537 (good), 552572 (bad)], roughly 4 steps left. Trying revision 552556... Revision 552556 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 552561... Bisecting range [552556 (good), 552572 (bad)], roughly 3 steps left. Trying revision 552561... Revision 552561 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 552567... Bisecting range [552561 (good), 552572 (bad)], roughly 2 steps left. Trying revision 552567... Revision 552567 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: g Downloading revision 552571... Bisecting range [552567 (good), 552572 (bad)], roughly 2 steps left. Trying revision 552571... Revision 552571 is [(g)ood/(b)ad/(r)etry/(u)nknown/(s)tdout/(q)uit]: b You are probably looking for a change made after 552567 (known good), but no later than 552571 (first known bad). CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/45f3a814c40d7108d72178dd9038808ce06de76b..24332003a4f4d6324d6b694222e7a2507353ca40
,
Aug 4
I am baffled - three bisects using the same parameters - three different results. As far as I can tell, only the results in comment #31 lead to a commit that relates to bookmarks : https://crrev.com/558484 What do you make of this?
,
Aug 4
FWIW The bisects in comments #29, #31, & #33 were done on the Dell desktop running Ubuntu 14.04.05 referenced in comment #17. I had to first disable hardware acceleration [to prevent crashing/system freeze], then import a bookmark file to test the bookmark manager. Though I have no idea why three bisects using the same parameters yielded three different results on the desktop ... I was able to duplicate the result in comment #33 on the Asus laptop running Mint 17.3 Cinnamon [14.04.3], [without disabling hardware acceleration -as it hasn't been subject to system freezes with hardware acceleration enabled]. [Though the laptop doesn't show all the bookmarks in a large collection with or without hardware acceleration enabled in 68.0.3440.84] Any thoughts?
,
Aug 7
Could the problem have been introduced here? https://chromium.googlesource.com/chromium/src/+/3d8828e68c6faf98403190a0c0096c70ad1a3772%5E%21/
,
Aug 9
The refresh: 68.0.3440.106 (Official Build) (64-bit) Revision: 1c32c539ce0065a41cb79da7bfcd2c71af1afe62-refs/branch-heads/3440@{#794} OS: Linux JavaScript: V8 6.8.275.26 Flash: 30.0.0.134 ~google-chrome/PepperFlash/30.0.0.134/libpepflashplayer.so User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3440.106 Safari/537.36 released Aug 8, does not fix the problem.
,
Aug 28
As the issue is not reproducible from our end (...comment#10, #18 & #27) hence adding label "TE-NeedsTriageHelp" and requesting someone from "UI>Browser>Bookmarks" team to have a look into it and help in further triaging it. Thanks!
,
Sep 6
I can't repro this on Win10 w/ hardware acceleration off either. Press F12 on the page and copy any errors that you see in the Console tab. WRT copy/paste, Ctrl + C and Ctrl + V still work, you can also use the copy/paste options in Chrome's main 3-dot menu which has copy/paste. I'm deleting comments not related to this bug since most are duplicated in Issue 834205 .
,
Sep 6
#34: That's an iOS-only change. Nothing to do with MD Bookmarks. #38: Unlikely, basically nothing from MD Bookmarks is touched there. You may also want to try running a bisect with tools/bisect-builds.py --times=3 so that it runs each build a couple of times. Your issue sounds like it occurs randomly.
,
Sep 6
@calamity I am uncertain how you came to think that the 'issue sounds like it occurs randomly' - M68 Stable consistently failed to display all the bookmarks in a large collection [folder]. However - the release of M69 Stable cured that issue! [I had observed that issue was resolved in M69 Beta and had hoped for a refresh of M68 Stable that included the 'fix' rather than wait till Sept 4] Nonetheless - thanks for taking an interest in this issue.
,
Sep 6
@calamity Re c#43 - While Ctrl + C and Ctrl + V still work to copy/paste a bookmark ... I think you would find that many users agree - a right click context menu item to copy/paste a bookmark would be superior to using the copy/paste options in Chrome's main 3-dot menu.
,
Sep 7
#45: Random because the bisect isn't reliably reproducible. Just because it's consistent in M68, doesn't mean it's not random before that. Since it seems fixed on your end in Beta, I'll mark this as WontFix. #46: Addressed in Issue 805738 . I've bugged someone about this before, the response is that it wasn't used often enough in the old bookmark manager to warrant a UI affordance. This relegates it to being a 'power user' feature, for which a keyboard shortcut is sufficient. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by swarnasree.mukkala@chromium.org
, Jul 31