Closed Bug 1046430 Opened 5 years ago Closed 5 years ago

Revert aurora/nightly default cookie behavior to match release/beta

Categories

(Core :: Networking: Cookies, defect)

34 Branch
x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla36
Tracking Status
firefox34 --- unaffected
firefox35 + fixed
firefox36 + fixed

People

(Reporter: nmalkin, Assigned: mmc)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 3 obsolete files)

User agent:

This bug appears in the latest Nightly (Firefox 34). It behaves correctly in the current stable version (Firefox 31).


Steps to reproduce:

1. Start with a page that sets a cookie and redirects (HTTP 302) in the same request
2. Load that page in an iframe
3. Make sure the page that serves the iframe is on a different host/origin from the page in the iframe


Expected behavior:

- The cookie is set


Actual behavior:

- The cookie is *not* set


Test case: https://gist.github.com/nmalkin/cb50a41698ed99f84a6f
(clone this gist to try it yourself)

This defines a simple server that sets a cookie before redirecting the page to a new destination.
The destination checks to see if the cookie was set.

(To run the server, install Flask [pip install -r requirements.txt] and run server.py)

To see the bug in action: open iframe.html in your browser, as a local file. 
As you'll see, the iframe is redirected to the new page, but the cookie is not set.

If you now open the root of the server, which serves the exact same content, you'll see that, this time, the cookie is set successfully.

(Note that the page with the iframe doesn't have to be served over file://; the bug also appears if it's served over http or https, as long as the host/origin is different from that of the iframe.)


Extra:

- I reproduced this on a fresh profile, with no extensions.
- I cannot reproduce in Firefox 31, the current stable version.
I suspect this is because Nightly has different default cookie permissions than stable, regardless of version.

Can you go to Preferences > Privacy > Use Custom Settings for History and make sure "Accept third party cookies" is set to Always, and try to reproduce?
Flags: needinfo?(nmalkin)
You're right: enabling "Accept third party cookies" in Nightly fixes the issue.
Thanks for confirming, nmalkin. I'm planning to revert the default in Nightly to "accept all cookies" to avoid developer confusion, but it is taking a while to coordinate with non-engineering teams.
Status: UNCONFIRMED → RESOLVED
Closed: 5 years ago
Resolution: --- → INVALID
Flags: needinfo?(nmalkin)
On second thought, leaving this open.
Blocks: 818340
Status: RESOLVED → UNCONFIRMED
Resolution: INVALID → ---
Summary: Regression: cookies not set on redirect inside iframe → cookies not set on redirect inside iframe on non-release builds
QA Contact: lhenry
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee: nobody → mmc
Status: NEW → ASSIGNED
Attachment #8499223 - Attachment is obsolete: true
Summary: cookies not set on redirect inside iframe on non-release builds → Make aurora/nightly cookie behavior match release/beta
Comment on attachment 8500780 [details] [diff] [review]
Make cookie behavior the same on beta/release as on aurora/nightly

Review of attachment 8500780 [details] [diff] [review]:
-----------------------------------------------------------------

This pref change never rode the trains and never will in its current state. We are working on something better in https://bugzilla.mozilla.org/show_bug.cgi?id=1029886 that solves a lot of problems with this approach. This patch also fixes bug 1066613.
Attachment #8500780 - Flags: review?(josh)
Attachment #8500780 - Flags: review?(jduell.mcbugs)
Comment on attachment 8500780 [details] [diff] [review]
Make cookie behavior the same on beta/release as on aurora/nightly

Review of attachment 8500780 [details] [diff] [review]:
-----------------------------------------------------------------

::: testing/web-platform/tests/html/dom/documents/resource-metadata-management/document-cookie.html
@@ +15,5 @@
>    var doc = document.implementation.createHTMLDocument("doc");
>    assert_equals(doc.cookie, "");
>    doc.cookie = "test=foobar";
> +  assert_equals(doc.cookie, "test=foobar");
> +}, "Setting cookie for document should work.");

We can't modify these tests. We need to add an expected failure to an ini file in http://mxr.mozilla.org/mozilla-central/source/testing/web-platform/meta/html/dom/documents/resource-metadata-management/.
Attachment #8500780 - Flags: review?(josh) → review+
Attachment #8500780 - Attachment is obsolete: true
Attachment #8500780 - Flags: review?(jduell.mcbugs)
Comment on attachment 8501202 [details] [diff] [review]
Make cookie behavior the same on beta/release as on aurora/nightly (

Address jdm's feedback, waiting on try before checking in.
Attachment #8501202 - Flags: review+
Summary: Make aurora/nightly cookie behavior match release/beta → Revert aurora/nightly default cookie behavior to match release/beta
I'd like to see a comms plan before we land this please.
I'll add you to the thread with Erica.
[Tracking Requested - why for this release]: This has to make it in before 35 hits beta, otherwise we break the tree because of https://bugzilla.mozilla.org/show_bug.cgi?id=1066613.
Attachment #8501202 - Attachment is obsolete: true
https://hg.mozilla.org/mozilla-central/rev/53027edc3bde
Status: ASSIGNED → RESOLVED
Closed: 5 years ago5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla36
Comment on attachment 8521887 [details] [diff] [review]
Make cookie behavior the same on beta/release as on aurora/nightly (

Approval Request Comment
[Feature/regressing bug #]: 818340 (the part of that bug that set the default cookie preference)
[User impact if declined]: We need an alternative solution to bug 1066613
[Describe test coverage new/current, TBPL]: m-c
[Risks and why]: Pretty low risk. This pref change affects only Nightly and Aurora, the original default pref change from bug 818340 never progressed to beta.
[String/UUID change made/needed]: none.
Attachment #8521887 - Flags: approval-mozilla-aurora?
Attachment #8521887 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.