Issue metadata
Sign in to add a comment
|
Bookmarks are no longer suggested while typing in bar, after update Dev 68.0.3423.2
Reported by
bced...@gmail.com,
May 9 2018
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/68.0.3423.2 Safari/537.36 Steps to reproduce the problem: 1. Update to latest Dev channel build 68.0.3423.2 2. Launch browser and type in keywords of a site you got bookmarked, expecting it to suggest results in the URL bar as usual to match your favorites 3. No results appear, rendering you unable to navigate to your bookmarks, unless you click a bookmark from the dedicated bookmarks tab What is the expected behavior? It should (used to) suggest hits based on your partial input in URL bar, as your input matches bookmarks. What went wrong? It is not coming up with your bookmarks as you type, and has always done this for me until version Dev 68.0.3423.2 Did this work before? Yes 68.0.3417.0 Chrome version: 68.0.3423.2 Channel: dev OS Version: 10.0 (17134.1) Flash Version: I have noticed this issue to this extent so far, and will re-import bookmarks html ASAP to see if it brings any chances, and perhaps re-install Chrome Dev, then I will provide an update here on whether it works or not. If something like that does resolve it here, then knowing update Dev 68.0.3423.2 has brought these issues upon the user once solely by the update process, is also worth logging.
,
May 9 2018
,
May 9 2018
Issue 841374 has been merged into this issue.
,
May 10 2018
bced991@ Thanks for the issue. Tested this issue on Windows 10 and Mac OS 10.12.6 on the reported version 68.0.3423.2 and the latest Canary 68.0.3426.0 by following the below steps. 1. Launched Chrome navigated to some site. 2. Bookmarked a webpage on that site. On a new tab entered a part of the site in omnibox and can see the suggestion of the bookmarked page and no issues are observed. Attached is the screen cast for reference. Request you to check and confirm if anything is missed from our end in triaging the issue. Also request you to retry the issue on a new chrome profile without flags/extensions and update the thread with the observations. Thanks..
,
May 10 2018
I also ran into this. See Issue 841890 .
,
May 10 2018
susan.boorgula@, Please try again, but do NOT navigate to a site to bookmark it. Bookmark an unvisited site using the bookmark manager UI. The address bar suggests sites visited from the user's history; when you tested it, you're probably see the bookmarked URL suggestion based the fact that you've visited it before, not the fact that it's bookmarked.
,
May 11 2018
Confirmed in a local build. Chromium 68.0.3427.0 (Official Build) (64-bit) Revision 59bcf50b03d8292f0155917f7908777c2dcdcdd7-refs/heads/master@{#557761} OS Windows Autocomplete works for history, but not for bookmarks.
,
May 11 2018
mpear is right Susan, the suggestion worked for you from recent URL history. I tried on a second PC with a clean chrome dev install, and the same issue appeared, also others are confirming the bug. Can you find out which commit introduced the issue next?
,
May 11 2018
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
,
May 11 2018
,
May 11 2018
Re-tried the issue on Windows 10 and Mac OS 10.12.6 on the latest Canary 68.0.3426.0 as per duped issue 841890 . 1. Freshly installed chrome and added https://open.spotify.com/browse/featured and https://www.tiingo.com/ to the bookmarks list from Bookmarks Manager. 2. Entered 'spo' in the omnibox and can see the URL suggestion 'https://open.spotify.com/browse/featured'. 3. tried with 'Tiingo' site as well and can see the Bookmarks suggestion. Attached is the screen cast of the steps followed. bced991@ Request you to provide a screen cast of the steps followed where this issue is observed. Thanks...
,
May 11 2018
,
May 11 2018
Bisect info: 555855 (good) - 555864 (bad) https://chromium.googlesource.com/chromium/src/+log/e25744d6..1f7bb9fa?pretty=fuller Suspecting r555859 = e349e963a7d1a4d8674673fdbd8d174360b9e76a = https://crrev.com/c/1041575 by sky@chromium.org "bookmarks: moves creation of various state to BookmarkLoadDetails" Landed in 68.0.3419.0 BTW in the bad builds the bookmark title keyword either produces no bookmark results in chrome://omnibox or has an extremely low "relevance" score.
,
May 11 2018
Thanks woxxom@ for the bisect, assigning to sky@ based on C#13.
,
May 13 2018
I must say that users of the Dev channel usually accept the consequences of living on the bleeding edge, instability is occasional and their own decision. However this is something that affects key interaction/GUI functionality, while they know dev may be unstable at times, it isn't often anything game-breaking and due to that, lots of people use Chrome Dev as a DAILY driver. Because this issue affects the convenience of regular use, messes with a very key part of the overall comfort of using chrome, (most people are very much used to relying on favourite suggestions when they have no such browsing history as they like to keep things clean) it is possible that this will lead to lots of usual Dev users leaving for the stable builds again, accompanied by the risk they wont ever be bothered to return to dev channel. Unfortunately, rolling back a dev build and turning off autoupdate once we hit ones we don't like, isn't that easy. I must say that for how much of a core and user-adapted feature this bug hits, that the response of the person who introduced this bug (sky@chromium.org) he clearly isn't really in a hurry to acknownledge or start working on the issue. Also I can wonder why the codereview/testing failed to detect this very basic GUI interaction issue?
,
May 13 2018
#15, chromium developers don't work on weekends for better or worse, but the reason why it wasn't detected by a test will be found eventually (not necessarily by sky@ whose changes might be unrelated) and, if possible, the automated tests will be written for this specific case.
,
May 14 2018
,
May 15 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/ae91f34a8ca86a39631da150baca0e7e78f33dd2 commit ae91f34a8ca86a39631da150baca0e7e78f33dd2 Author: Scott Violet <sky@chromium.org> Date: Tue May 15 01:09:21 2018 bookmarks: fixed populating TitledUrlIndex on load This is a regression from recent refactoring. The TitledUrlIndex was not being populated on load, resulting in the omnibox not properly surfacing bookmarks. BUG= 841375 TEST=covered by test Change-Id: I4fe924e7679f3591e5d8ad18afbfb6fdc3fdc3d4 Reviewed-on: https://chromium-review.googlesource.com/1058278 Commit-Queue: Scott Violet <sky@chromium.org> Reviewed-by: Jay Civelli <jcivelli@chromium.org> Cr-Commit-Position: refs/heads/master@{#558568} [modify] https://crrev.com/ae91f34a8ca86a39631da150baca0e7e78f33dd2/components/bookmarks/browser/bookmark_model_unittest.cc [modify] https://crrev.com/ae91f34a8ca86a39631da150baca0e7e78f33dd2/components/bookmarks/browser/bookmark_storage.cc [modify] https://crrev.com/ae91f34a8ca86a39631da150baca0e7e78f33dd2/components/bookmarks/managed/managed_bookmarks_tracker_unittest.cc
,
May 15 2018
,
May 25 2018
,
May 28 2018
Unable to reproduce the issue on win-10 using chrome reported version #68.0.3423.2 as per comment #0, #6 and #12. Observed that it suggested hits based on the partial input in URL bar, as input matches bookmarks as expected. Attached screen cast for reference. sky@ - Could you please check the attached screen cast and please help us in verifying the fix. Thanks...!! |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by susan.boorgula@chromium.org
, May 9 2018