Dead links to be given lower preference
Reported by
anuprai1...@gmail.com,
Oct 3 2017
|
|||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/61.0.3163.100 Safari/537.36 Steps to reproduce the problem: 1. use some link which breaks after some time 2. let's say the link changed in the last some characters like git repo moved happened with me 3. in the search bar type the content the search result comes in order of number of times used What is the expected behavior? I feel if broken links somehow could be given lover preference. that maybe calculated using the current preview or maybe based on the last event What went wrong? I feel if broken links somehow could be given lover preference. that maybe calculated using the current preview or maybe based on the last event Did this work before? No Chrome version: 61.0.3163.100 Channel: stable OS Version: OS X 10.12.6 Flash Version: Haven't gone through the code don't know if this is feasible or maybe it is not required so just let me know if this is no good
,
Oct 4 2017
This seems to be a feature request. Hence, marking it as untriaged to get more inputs from the dev team. Thanks...!!
,
Oct 4 2017
Good idea. A valid, reasonable request. Might be hard to do. (For other people reading this bug, we don't want to suppress dead links entirely in case the error was transient. But for links with recent errors, it might make sense to make them less prominent so they'll fade faster from the dropdown.)
,
Oct 4 2017
Hey I am new here but can I pick this up. Would ask a few questions though and I am trying to get into chromium project development.
,
Oct 4 2017
Welcome to chromium! I'm glad you want to contribute. This, however, is not a good first bug. I suggest you pick another bug first. I've contributed to the omnibox and history systems for ~5 years, and I'm having trouble thinking about a good way to solve this one. There are two main components to the omnibox that make suggestions of URLs from the user's history: 1. HistoryURL provider 2. HistoryQuick provider. The first doesn't know anything about visits; it only gets summary statistics like total number of visits. The second knows something about recent visits (the times of them), but doesn't actually know anything about what happened during that attempted visit (e.g., did it have an error?). It wouldn't be hard in principle to pipe that status information in *if we had it*. But the history system doesn't keep track of errors or anything like that. So to improve this issue, we may have to expand the history database, in particular change the schema of the Visits table. And anytime you have to touch table schemas, you need to write migration code. The whole thing gets complicated fast. For bug 755735, I think I want to also add supplemental information to the history system in some form. (That bug is also about tracking pages that result in errors.) I'm planning sometime in the next month or so to sit down with some of the engineers who originally designed the history system about possible approaches. Overall though, I'd have to say this is a complicated problem and not a good first bug.
,
Oct 5
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 8
|
|||||
►
Sign in to add a comment |
|||||
Comment 1 by nyerramilli@chromium.org
, Oct 4 2017