User-Agent: Opera/9.25 (Macintosh; Intel Mac OS X; U; en) Build Identifier: FF3 beta3 Most iframe facebook apps (as opposed to fbml-based fb apps, which always go through fb servers) need to set cookies to remember which facebook user is logged in. The discussion in https://bugzilla.mozilla.org/show_bug.cgi?id=417286 shows at least one developer being surprised by this. "we do, indeed, block cookies in iframes with third-party URLs. this means our third-party blocking is good, perhaps too good, as it already stands." Asking users to manually change security settings is a bar most won't bother jumping over. That's not really an acceptable workaround. A dialog along the lines of "this page is setting a third party cookie. add to whitelist?" might be okay. The original https://bugzilla.mozilla.org/show_bug.cgi?id=324397 issue where cookie-blocking policy was changed asks for examples of sites this would break. Facebook is a fairly major example, even though iframe-based apps are a minority. Reproducible: Always Steps to Reproduce: 1. 2. 3. For comparison, the latest versions of IE, FF2, and Opera allow such cookies in iframes. (In IE's case this requires setting a p3p header but this is a well-known and trivial workaround that can be implemented on the server.)
it's a useful datapoint to know that facebook apps can break with third party cookie blocking. as you say, this highlights the need for a good solution for sites that do break - but we shouldn't cripple this feature and compromise privacy as a result. (note that we've already reverted making this pref the default, exactly because of the fallout - bug 417800.) see also bug 419596.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 417800
Ah, thanks for clarifying that. I didn't notice from bug 417800 that the pref had been reverted since the summary was proposing something else.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.