Copied thumbnail link doesn't work outside of NTP
Reported by
pvjishn...@gmail.com,
Jun 22 2017
|
|||||||||
Issue description
<b>Chrome Version : <Copy from: 'about:version'></b>
URLs (if applicable) :
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari: PASS/FAIL (Version)
Firefox: PASS/FAIL (Version)
IE: PASS/FAIL (Version)
What steps will reproduce the problem?
(1)Open a new tab
(2)Right click on any of the previous searched thumbnails displayed
(3)Select 'Copy Image Address' from the options
(4)Open a new tab
(5)Paste the copied text in Address bar and Click Enter key/Search
What is the expected result?
The results of the thumbnail image address to be displayed.
Or the image should have been displayed.
What happens instead?
"The site can't be reached" message displayed instead of loading the result.
Please provide any additional information below. Attach a screenshot if
possible.
For graphics-related bugs, please copy/paste the contents of the about:gpu
page at the end of this report.
,
Jun 29 2017
Able to reproduce the issue on Windows-7,Windows-10,Mac-10.12.4 and Linux Ubuntu-14.04 using chrome stable version 59.0.3071.115 and canary 61.0.3143.0 with the steps mentioned in comment#0. This is Non-Regression issue, observed from M-44 and upto M-43 no such option is seen and so marking it as Untriaged to get more inputs from dev team. Thanks..!!
,
Jul 21 2017
It works for me. I get a chrome-search://thumb2/... address which I can open. Can you provide a video pls?
,
Aug 3 2017
Friendly ping! Any updates or videos available here?
,
Aug 9 2017
I can reproduce. Loading the url chrome-search://thumb/2/1 produces the screenshot in the original report. I suspect we do not really intend this to load an image. Marc, what do you think?
,
Aug 9 2017
This is a difference in TopSites vs MostLikely: MostLikely produces thumbnail URLs like "chrome-search://thumb2/https://www.url.com/" which work everywhere, while TopSites produces URLs like "chrome-search://thumb/2/1" which only work from within the NTP. (The "2" and "1" in there are "restricted IDs" which are only known to special privileged renderer processes.) I don't think there's any easy fix for this. Since it doesn't seem high impact and is not a regression, I'd say we keep it around as a low-prio feature request, to be revisited after the local NTP launch.
,
Aug 22 2017
,
Jan 11 2018
,
Aug 15
,
Sep 25
Thumbnails have been removed |
|||||||||
►
Sign in to add a comment |
|||||||||
Comment 1 by ranjitkan@chromium.org
, Jun 29 2017