Closed Bug 756881 Opened 8 years ago Closed 6 years ago
New tab thumbnails not displayed (or old images displayed) for Facebook, Twitter (sites using Cache-Control no-store)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:15.0) Gecko/15.0 Firefox/15.0a1 Build ID: 20120519030527 Steps to reproduce: Click on "open new tab" icon on tab bar. Actual results: 9 frequently viewed pages are displayed, but the thumbnails for some of them do not refresh properly. In particular, the thumbnails for Facebook pages never refresh when accessed through the appropriate thumbnail. Thumbnails for other pages appear to refresh properly. Previously, the correct page thumbnails for Facebook were displayed. Expected results: The thumbnail updates to display the most recent page viewed, including for Facebook.
That's because of the fix for bug 754608 - if the page uses the "Cache-Control: no-store" header (Facebook does), the thumbnail isn't updated. That means that you keep using the old one. Note that currently we're not deleting thumbnails (bug 754671), the old thumbnail will stay around unless you destroy the thumbnails folder in your profile. I noticed that if you delete the thumbnails folder, you will get a grey rectangle instead of the thumbnail. Facebook will never have a thumbnail if it uses no-store on all its pages. That's even worse than showing the old content.
Status: UNCONFIRMED → NEW
Component: Untriaged → Tabbed Browser
Ever confirmed: true
OS: Mac OS X → All
QA Contact: untriaged → tabbed.browser
Hardware: x86 → All
Version: 15 Branch → Trunk
Is there a way to force thumbnail regeneration? I had tried deleting the tabs in question, along with subsequent ones, in order to try to force it to regenerate, but now no new thumbnails show up for any site that I removed from the thumbnail list.
I realise it's probably too late to do anything, but the fix for bug 754608 went into the last beta, so this is an issue for 14 as well.
Summary: New tab thumbnails display old or incorrect images for Facebook pages → New tab thumbnails not displayed (or old images displayed) for Facebook, Twitter (sites using Cache-Control no-store)
No need to track for FF14, we won't be taking a forward fix here for an intermittent screenshotting issue. Tim - are you the right person to look at this for FF15? It'll be on Beta as of today, so it's really important that we move on a fix here asap.
(In reply to Alex Keybl [:akeybl] from comment #9) > Tim - are you the right person to look at this for FF15? It'll be on Beta as > of today, so it's really important that we move on a fix here asap. Fixing this is really hard. Starting with Fx 14, we'll not capture pages that send a 'Cache-Control: no-store' header because of privacy implications - bug 754608. Now, there are lots of sites that use it to disable caching because they probably want no stale content and want to keep control over the displayed content. OTOH there are banking sites that send it for security reasons. There is no way to distinguish between those two. There was thread on dev.planning about this with no real conclusion either: https://groups.google.com/forum/#!searchin/mozilla.dev.planning/thumbnail/mozilla.dev.planning/enlr8-0CfXw/lf0P_3n5sYwJ
(In reply to Tim Taubert [:ttaubert] from comment #10) > (In reply to Alex Keybl [:akeybl] from comment #9) > > Tim - are you the right person to look at this for FF15? It'll be on Beta as > > of today, so it's really important that we move on a fix here asap. > > Fixing this is really hard. Starting with Fx 14, we'll not capture pages > that send a 'Cache-Control: no-store' header because of privacy implications > - bug 754608. > > Now, there are lots of sites that use it to disable caching because they > probably want no stale content and want to keep control over the displayed > content. OTOH there are banking sites that send it for security reasons. > There is no way to distinguish between those two. > > There was thread on dev.planning about this with no real conclusion either: > > https://groups.google.com/forum/#!searchin/mozilla.dev.planning/thumbnail/ > mozilla.dev.planning/enlr8-0CfXw/lf0P_3n5sYwJ Are we still exploring options? Or are you suggesting we wontfix and let the product team know so that they can try deal with the implications?
(In reply to Alex Keybl [:akeybl] from comment #11) > Are we still exploring options? Or are you suggesting we wontfix and let the > product team know so that they can try deal with the implications? We're not actively exploring options but I think we should. Other browsers just don't seem to care about what screenshots they take so there's no behavior to adopt for us and we need to come up with *something*. There's also bug 725189 which covers a similar problem. I'm sure a lot of people don't care about screenshots being taken while logged into facebook or similar, but some do.
It is true that some websites do not generate thumbnails because they can reveal private information or this is a issue? (if it is a issue I have it on facebook, thepiratebay and abovetopsecret websites) However what kind of private information you can see in that small thumbnails? :)
Possible Solution: All user to select images to be shown in the Thumbnail Space. Maybe use the favicon, or allow storing of user-created images. Why must the image displayed on the "New Tab" page be a screenshot of the site, specially when that screenshot shows old content. At least with the option for user to use their own image, no "privacy" issues will arise and there will be no "blank" thumbnails.
Allow user to set their own images for the thumbnail on the New Tab Page.
The new tab thumbnails need some serious work: -I have over 800mb of useless thumbnails from useless links. *fix - store thumbnails only for pined websites and automatically delete thumbnails older than 24h -no thumbnails for sites using Cache-Control no-store *fix - add pref to override the "security" feature, personally I don't see any privacy issue in a 427x341p thumbnail.
(In reply to Oz from comment #16) > -I have over 800mb of useless thumbnails from useless links. > *fix - store thumbnails only for pined websites and automatically delete > thumbnails older than 24h bug 754671
Problem: Not all thumbnails are displayed More: Its quite random and I'm not really able to pinpoint which pages don't display the thumbnails, Since I can't manually pin a website. But of the few websites that I have pinned, I think the ones using https don't show up a thumbnails. I cannot confirm this because there aren't enough test pages and again I don't know how to manually set a page in there. Troubleshooting done: I have cleared the cache. Restarted firefox multiple times. Firefox is up to date To sum it up : I think HTTPS pages don't get their thumbnails.
(In reply to prasanaik from comment #18) > Problem: Not all thumbnails are displayed > > More: Its quite random and I'm not really able to pinpoint which pages don't > display the thumbnails, Since I can't manually pin a website. > But of the few websites that I have pinned, I think the ones using https > don't show up a thumbnails. > I cannot confirm this because there aren't enough test pages and again I > don't know how to manually set a page in there. > > Troubleshooting done: > I have cleared the cache. > Restarted firefox multiple times. > Firefox is up to date > > > To sum it up : I think HTTPS pages don't get their thumbnails. A bit of an update. I don't think this has to do https. On the other hand, it might have to do with AJAX. I'm basing this on what I noticed: Pages like twitter and Google Reader fail to load. I think its those pages that keep updating without an actual refresh using AJAX which leads to the thumbnail failing.
We're investigating what to do here in the longterm, but it's not a critical issue for shipping the feature in upcoming releases, so no need to track for 15. If a low-risk fix is found, we would consider uplift however.
Suggestion: Cache thumbnails for Cache-Control: no-store if (1) The user entered the URL explicitly into the browser (2) The URL has a path of '/'.
This seems like a serious issue from the standpoint of just looking respectable. My new tabs have looked like this for a few weeks: http://gyazo.com/6af13f20394299d19fef5f110fac1d61 [ You can track the timing pretty accurately since it clearly last took a snapshot of the famous Twitter downtime that happened on July 26th. :) ] As pretty as Koolaid.Junkie's mockup is, I don't think wasting users' time asking them to specify thumbnails is viable. If we can't find a reasonably attractive (and privacy-respecting) thumbnail automatically, I'm afraid we need to reconsider the whole design of a thumbnails page. The screenshot I linked to is pretty embarrassing aesthetically. Dave
I can confirm comment 22. I rather turned the whole new page off instead of looking at a set of grey rectangles. This should be resolved somehow.
The grey rectangles are more likely to be issues with losing thumbnails in the file cache, which is fixed by bug 744388. That patch is currently scheduled to ship in Firefox 16.
I'm running Aurora and, just like :dherman, I have mostly grey rectangles on my new tab page, so I don't think the issue is related to the file cache. I've made sure all my cache settings are set to default.
The other major cause of blank thumbnails appearing on about:newtab is bug 756881.
Er, which is this bug. But the point stands - this bug is not fixed :)
Please note the comments I entered in bug 830770 after it was mmarked as a duplicate of this one. Another example of a site which fails to result in a placeholder or thumbnail containing an image is http://casperflights.com/.
Can we just take a screenshot of the un-logged-in front page of sites that set this and use that? I think other browsers may do this.
No longer depends on: 841495
(In reply to Madhava Enros [:madhava] from comment #32) > Can we just take a screenshot of the un-logged-in front page of sites that > set this and use that? I think other browsers may do this. You just pretty much described the goal of bug 841495 :)
any news on this?
Bug 841495 is the proposed solution, work is progressing in that bug.
Consider showing favicon like Chrome.
Is it supposed to be fixed now that patches in bug 841495 landed? My Nightly still doesn't capture thumbs for "no-store" websites.
(In reply to Sid from comment #39) > Is it supposed to be fixed now that patches in bug 841495 landed? My Nightly > still doesn't capture thumbs for "no-store" websites. No, bug 841495 just implemented the mechanism. We still need to fix a couple of follow-ups and implement a policy for when to use the new service (see bug 870100).
Looking forward for this bug to be fixed. I see the screenshot as a possible solution but only temporarily like Opera does, I think a better PNG creation system must be done, not depending on Cache headers.
For those of you who are tired of waiting for a fix, a good workaround is this addon: https://addons.mozilla.org/en-US/firefox/addon/new-tab-tools
I can confirm that this has been fixed for the latest Nightly version. :D
Fixed by bug 870100.
Assignee: ttaubert → mhammond
Target Milestone: --- → Firefox 25
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
I'm using Nightly 30, and this bug is not fixed. Thumbnails are not updated for days, even if i click them regularly.
This bug has indeed been fixed. The page thumbnails now source the login pages for websites like twitter etc. People commenting about the feature being a issue in Nightlies should try stable releases as they work perfectly well.
This bug is not fixed and stable releases do not 'work perfectly well'. We are using standard/stable release 30: thumbnails are not updated as described.
For privacy reasons, Firefox does not save screenshots while you are logged in to sites like Facebook. Instead, it shows a thumbnail of what a logged-out user sees instead. This is the fix that was chosen for this bug. It's a compromise between aesthetics and user privacy. (Before this fix, there was no image displayed at all for Facebook, Twitter, etc.) If you are seeing something other than the intended behavior, please file a new bug with a detailed description/screenshots of the issue you are seeing, so we can work on fixing it. Thanks!
Status: RESOLVED → VERIFIED
FYI there are several continuations of this bug - 949655, 1126487 at least.
You need to log in before you can comment on or make changes to this bug.