The share button is disabled if a page is served with the "Cache-Control: no-store" header. This doesn't appear consistent with the intent of this header, nor with the expectations of a user. The use of this header has also slightly diverged from the RFC, in that beyond protecting sensitive information it is sometimes used just to prevent caching of timely and/or changing information. IT doesn't make sense to block sharing when this header is used as such. Even if used correctly however the RFC has the language that a user may still explicitly store the page. One would assume this intent would also be applied to explicitly sharing the page. Lacking any sort of feedback mechanism it won't be clear to a user why they can't share a particular page. It should also be noted that nothing stops the user from copying the URL and sharing it directly on a provider. Thus the limitation is one that a reasonable user should not expect as it is a new restriction on their behaviour. I would recommend lifting this restriction. If it will not be lifted then at least improve the user experience. This includes presenting a message saying why they can't share a page and providing an explicit override option (for example, clicking share on such a page shows a panel with a warning, pressing a "Continue anyways" button will then bring up the normal share panel).
"Cache-Control: no-store" is the only standard mechanism (I am aware of) that a site has to indicate that the content is sensitive in nature, I'd be very reluctant to remove this limitation. However, improving UX around this, even allowing the user to bypass, is a good improvement. Since it would involve strings, we would not be able to get this in for 23. Boriss, any thoughts on the ux around this?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Our provider allows sharing items to oneself (send by email) within a private network (like SocialCast, or LinkedIn), or simply marking it for later reading (pocket, instapaper, or our favourites). In these use cases the restriction on activating the share button doesn't make sense. It'd be like saying the no-store header also means you can't save, print, or bookmark the URL. For an improved experience it'd be nice if this "private" flag was instead passed to the share provider who could then decide how to deal with it. In our case we could gray-out the public sharing options but still allow for private sharing. There would also be a simple override mechanism to force the public sharing.
Too many pages use no-store so it isn't reasonable to rely on that. Since share requires user action, and any true sensitive data is likely behind login, thus inaccessible to the receiver of the share, we'll remove the no-store limitation.
Assignee: nobody → mixedpuppy
Attachment #766121 - Flags: review?(gavin.sharp)
Attachment #766121 - Flags: review?(gavin.sharp) → review+
Comment on attachment 766121 [details] [diff] [review] remove no-store limitation in share [Approval Request Comment] Bug caused by (feature/regressing bug #): share feature User impact if declined: users are unable to determine why share is disabled, can seem to be broken. Testing completed (on m-c, etc.): m-c Risk to taking this patch (and alternatives if risky): low String or IDL/UUID changes made by this patch: none
Attachment #766121 - Flags: approval-mozilla-aurora?
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 24
Attachment #766121 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
Comment on attachment 766121 [details] [diff] [review] remove no-store limitation in share [Approval Request Comment] Missed the Aurora train. Needs beta approval.
Attachment #766121 - Flags: approval-mozilla-aurora+ → approval-mozilla-beta?
Attachment #766121 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Shane, is there a desire for QA verification here?
(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #10) > Shane, is there a desire for QA verification here? Verification would be that the share icon is enabled/usable on any page (Facebook pages are a good test case, you couldn't click the share button on any of them).
Samvedana, can you please verify this is fixed in Firefox 23 and 24? Best try on several different Facebook pages just to be sure. Thanks.
QA Contact: samvedana.gohil
You should be able to verify the page has the no-store header via the page info dialog.
(In reply to Shane Caraveo (:mixedpuppy) from comment #13) > You should be able to verify the page has the no-store header via the page > info dialog. sorry for spam. I was wrong, but there is probably something in developer tools to do that.
To see if the no-store header is present, you need to do the following: Open the Developer Toolbox (Ctrl or Command+Shift+K) Go to the Network tab Reload the page under question After the page has finished loading, click on the entry at the top of the list A box on the right will appear Look in the Headers section Within Response headers, you should see if "Cache-Control: no-store" is present. For example, facebook.com shows http://screencast.com/t/dGdkcV9k6C9v
User Agent : Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20130711 Firefox/24.0 Build ID : 20130711004005 Tested this on latest Aurora build using Facebook pages and other websites. For all, "Share" icon was working. User Agent : Mozilla/5.0 (Windows NT 6.2; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 Build ID : 20130708202947 Tested this on Firefox 23 B4 build using Facebook pages and other websites. For all, "Share" icon was working.
Thanks Samvedana, can you also test along the lines of what Jared has suggested in comment 15?
User Agent :Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20130712 Firefox/24.0 Build ID : 20130712004003 (Latest FX Aurora) I see "Cache-Control: no-store" for first entry in the list for facebook.com User Agent :Mozilla/5.0 (Windows NT 6.2; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0 Build ID : 20130711122148 I see "Cache-Control: no-store" for first entry in the list for facebook.com
You need to log in before you can comment on or make changes to this bug.