Closed Bug 1474235 Opened 7 years ago Closed 7 years ago

Possible issue with containers (or a test site issue)

Categories

(Core :: DOM: Security, defect)

Product:
Core
Component:
DOM: Security
Version:
62 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 906448
Tracking Flags:
Tracking Status
firefox62 --- affected
firefox63 --- affected

People

(Reporter: quality+bugzilla, Unassigned)

Details

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0 Build ID: 20180705151535 Steps to reproduce: Steps to reproduce: 1. Install Firefox with a new profile 2. Install Firefox Multi-Account Containers extension 3. Open a tab in the 'Personal' container by long-clicking on the new tab button 4. Open http://lucb1e.com/rp/cookielesscookies/ 5. Type "Hello World" in the "Want to store some text here?" text entry field 6. Press the "Store" button 7. Open a tab in the 'Work' container by long-clicking on the new tab button 8. Repeat step 4 9. Notice that the counter has incremented, and that the "Hello World" text is present Is this a bug in Firefox's containers mechanism (not keeping discrete caches), or a bug in the test in step 4? If it's a bug in the test, and containers in Firefox are working correctly, does anyone have a better test site for HTTP ETAG that Firefox will pass?
I managed to get the same behavior on Nightly 63.0a1 (2018-07-11) [Windows 7], but I am not sure if this is the intended behavior or it is a Firefox bug. I will set Core::DOM:Security component so it can be reviewed by someone.
status-firefox63: --- → affected
Component: Untriaged → DOM: Security
Product: Firefox → Core
This doesn't appear to be eTag tracking
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → DUPLICATE
(In reply to Daniel Veditz [:dveditz] from comment #2) > This doesn't appear to be eTag tracking Why is the string persistent across different containers? Shouldn't each new container be independent of other containers? Also, why does the counter increment? Shouldn't container independence prevent this?
Flags: needinfo?(dveditz)
Yes this is a problem. Private Browsing, which doesn't use the cache at all, shows the same bleed-over in bug 906448. Since containers and private browsing are both built on "origin attributes" and bug 906448 is about the exact same test page it's the same underlying bug whatever the cause.
Flags: needinfo?(dveditz)
(In reply to Daniel Veditz [:dveditz] from comment #4) > Yes this is a problem. Private Browsing, which doesn't use the cache at all, > shows the same bleed-over in bug 906448. Since containers and private > browsing are both built on "origin attributes" and bug 906448 is about the > exact same test page it's the same underlying bug whatever the cause. Thank you, Daniel, for your reply.
You need to log in before you can comment on or make changes to this bug.