Closed Bug 1665942 Opened 4 years ago Closed 3 years ago

Container tabs with twitter.com open with the default container after session restore

Categories

(Firefox :: Session Restore, defect)

Product:
Firefox
Component:
Session Restore
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
88 Branch
Tracking Flags:
Tracking Status
firefox-esr78 --- wontfix
firefox86 --- wontfix
firefox87 --- wontfix
firefox88 --- fixed

People

(Reporter: saschanaz, Assigned: tt)

References

(Regression)

Details

(Keywords: regression)

Attachments

(3 files)

Bug 1665942 - A test to verify COOP+COEP site should have the same userContextId after restoring;
47 bytes, text/x-phabricator-request
Details | Review
Bug 1665942 - Collect userContextId from tab in _collectBaseTabData and stop collecting it in the session history collection;
47 bytes, text/x-phabricator-request
Details | Review
Bug 1665942 - Remove the code for updating remoteness logic in addMultipleTabs since we have already handled fixing remoteness when restoring tabs;
48 bytes, text/x-phabricator-request
Details | Review

From https://github.com/mozilla/multi-account-containers/issues/1867, but the extension itself is probably not the culprit as its last update was two months ago.

  1. Prepare an empty Firefox profile, on Windows 10 64bit
  2. Install this Container extension
  3. Open twitter.com and sign in
  4. "Reopen in Container", and sign in too
  5. Open wikipedia.org
  6. Duplicate the wikipedia tab with a container
  7. Close the browser
  8. Open the browser and restore the session
  9. See the results

Expected: Two Twitter tabs with different containers and two wikipedia tabs also with different containers
Actual: Two Twitter tabs with the same default containers and two wikipedia tabs with different containers

This started happening on this week.

mozregression says it's a regression from Bug 1575095, specifically https://phabricator.services.mozilla.com/D76841. I'm pretty sure my specific issue is not that old but Twitter might did some change on their side.

Regressed by: 1575095
Has Regression Range: --- → yes

Simplified repro steps without closing browser:

  1. After step 4, close the duplicated tab
  2. Undo Close Tab by Control+Shift+T
  3. See the tab opens with the correct container.

This is independent of Twitter. In my case, which appears to be related to this, containers are simply discarded and the tabs appear as normal tabs. In my case the update started happening with Firefox 80.

(In reply to riccardo.robecchi from comment #3)

This is independent of Twitter. In my case, which appears to be related to this, containers are simply discarded and the tabs appear as normal tabs. In my case the update started happening with Firefox 80.

What websites did you try? For me it's only reproducible with Twitter while tabs with Wikipedia and Ebay are unaffected.

Flags: needinfo?(riccardo.robecchi)

I can reporduce this with mac and 82.0a1

(In reply to Kagami :saschanaz from comment #4)

(In reply to riccardo.robecchi from comment #3)

This is independent of Twitter. In my case, which appears to be related to this, containers are simply discarded and the tabs appear as normal tabs. In my case the update started happening with Firefox 80.

What websites did you try? For me it's only reproducible with Twitter while tabs with Wikipedia and Ebay are unaffected.

Feedly, Gmail and Reddit among others. I updated to FF 81 right after I posted and the problem seems to have disappeared, though. I will keep the situation monitored and will let you know if it happens again or if it was fixed. For the record, it had been happening for two weeks so I have seen it a few times.

Flags: needinfo?(riccardo.robecchi)

I check the data that FF writes into the disk and I got:

   {
      "host": "twitter.com",
      "value": "en",
      "path": "/",
      "name": "lang",
      "originAttributes": {
        "firstPartyDomain": "",
        "geckoViewSessionContextId": "",
        "inIsolatedMozBrowser": false,
        "partitionKey": "",
        "privateBrowsingId": 0,
        "userContextId": 1
      },
      "sameSite": 1,
      "schemeMap": 2
    },
    {
      "host": "twitter.com",
      "value": "en",
      "path": "/",
      "name": "lang",
      "originAttributes": {
        "firstPartyDomain": "",
        "geckoViewSessionContextId": "",
        "inIsolatedMozBrowser": false,
        "partitionKey": "",
        "privateBrowsingId": 0,
        "userContextId": 0
      },
      "sameSite": 1,
      "schemeMap": 2
    },
    {
      "host": ".wikipedia.org",
      "value": "DE:BE:Berlin:52.54:13.42:v4",
      "path": "/",
      "name": "GeoIP",
      "secure": true,
      "originAttributes": {
        "firstPartyDomain": "",
        "geckoViewSessionContextId": "",
        "inIsolatedMozBrowser": false,
        "partitionKey": "",
        "privateBrowsingId": 0,
        "userContextId": 2
      },
      "sameSite": 1,
      "schemeMap": 2
    },

    {
      "host": ".wikipedia.org",
      "value": "DE:BE:Berlin:52.54:13.42:v4",
      "path": "/",
      "name": "GeoIP",
      "secure": true,
      "originAttributes": {
        "firstPartyDomain": "",
        "geckoViewSessionContextId": "",
        "inIsolatedMozBrowser": false,
        "partitionKey": "",
        "privateBrowsingId": 0,
        "userContextId": 0
      },
      "sameSite": 1,
      "schemeMap": 2
    },

So, it seems that the userContextId is propagated correctly and maybe the issue happens when we restore pages from these data?

(In reply to Tom Tung [:tt, :ttung] from comment #8)

So, it seems that the userContextId is propagated correctly and maybe the issue happens when we restore pages from these data?

Hmm, that's probably not true.

So, I added log at the place for restoring a tab
And I saw:

[TT] restoreTab {"entries":[{"url":"https://twitter.com/home","triggeringPrincipal_base64":"eyIzIjp7fX0="}]}
[TT] restoreTab {"entries":[{"url":"https://twitter.com/home","triggeringPrincipal_base64":"eyIzIjp7fX0="}]}
[TT] restoreTab {"entries":[{"url":"https://www.wikipedia.org/","title":"Wikipedia","cacheKey":0,"ID":0,"docshellUUID":"{a020e774-e986-7f48-99e0-83ed16aec04d}","originalURI":"https://www.wikipedia.org/","resultPrincipalURI":"https://www.wikipedia.org/","loadReplace":false,"loadReplace2":true,"principalToInherit_base64":"eyIwIjp7IjAiOiJtb3otbnVsbHByaW5jaXBhbDp7YTZmYWJiMDktNWRlZS00OGM1LWFmNTctNDc5MDZjZGQ4YTg3fSJ9fQ==","partitionedPrincipalToInherit_base64":"eyIwIjp7IjAiOiJtb3otbnVsbHByaW5jaXBhbDp7YTZmYWJiMDktNWRlZS00OGM1LWFmNTctNDc5MDZjZGQ4YTg3fSJ9fQ==","hasUserInteraction":false,"triggeringPrincipal_base64":"eyIxIjp7IjAiOiJodHRwczovL3d3dy53aWtpcGVkaWEub3JnLyIsIjIiOiJedXNlckNvbnRleHRJZD0yIn19","docIdentifier":15032385537,"persist":true}],"lastAccessed":1600701969601,"hidden":false,"attributes":{},"userContextId":2,"index":1,"requestedIndex":0,"image":"data:image/x-icon;base64,AAABAAMAMDAQAAEABABoBgAANgAAACAgEAABAAQA6AIAAJ4GAAAQEBAAAQAEACgBAACGCQAAKAAAADAAAABgAAAAAQAEAAAAAAAABgAAAAAAAAAAAAAQAAAAAAAAAAEBAQAXFxcAMDAwAEdHRwBYWFgAZ2dnAHZ2dgCHh4cAlZWVAKmpqQC3t7cAx8fHANfX1wDo6OgA/v7+AAAAAAD////+7u7u7u7u7u7u7u7u7u7u7u///////+7u7u7u7u7u7u7u7u7u7u7u7u7u/////u7u7u7u7u7u7u7u7u7u7u7u7u7u7///7u7u7u7u7u7u7u7u7u7u7u7u7u7u7v/+7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u/+7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u/+7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u/u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7sa+7u7u7u1b7u7u7u7u7u7u7u7u7u7u7p9u7u7u7ugG7u7u7u7u7u7u7u7u7u7u7TAa7u7u7tQBzu7u7u7u7u7u7u7u7u7u6wAF7u7u7pAAju7u7u7u7u7u7u7u7u7u1AAAru7u7U//Le7u7u7u7u7u7u7u7u7uz/8RPe7u6gAB+e7u7u7u7u7u7u7u7u7ubw94Ce7u1QAIIu7u7u7u7u7u7u7u7u7tH/G+Mt7usAAtcL7u7u7u7u7u7u7u7u7n8ATun47uQACO0T7u7u7u7u7u7u7u7u7hDxnu4x3sAPLO5Qzu7u7u7u7u7u7u7u6P/z7u6wXk/wfu7ATu7u7u7u7u7u7u7u4QAY7u7kCQADzu7kDO7u7u7u7u7u7u7uoA8u7u7sAAAG7u7r9e7u7u7u7u7u7u7uIPB+7u7uUAAs7u7uMd7u7u7u7u7u7u7rEAHe7u7uQABu7u7un37u7u7u7u7u7u7kAAXu7u7sAPHe7u7u4S3u7u7u7u7u7u7BAA3u7u7k8AHO7u7u6Aju7u7u7u7u7u5g/07u7u7B8BBe7u7u7RLu7u7u7u7u7u0v/87u7u5QAGQa7u7u7nCe7u7u7u7u7ugAA+7u7uwQ8dsE7u7u7rBO7u7u7u7u7tP/++7u7uYAB+5Qnu7u7tQa7u7u7u7u7pH/Lu7u7sLwHe6xPe7u7ur27u7u7u7u7V//ru7u7mAAju7n+e7u7u0yvu7u7u7u6h8C3u7u6yAB3u7rEs7u7u6Pfu7u7u7u1AAE7u7u5g/27u7tQG3u7u6QHO7u7u7tbwAB3u7ukfAH7u7sIAju7u5wA97u7utiAAAAF76lAA/wWeyDAA84zqUAABfO7uMiNERDIm4iNERDIrkiNEQybiI0RDJO7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7+7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u/+7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u/+7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u//7u7u7u7u7u7u7u7u7u7u7u7u7u7u7v///u7u7u7u7u7u7u7u7u7u7u7u7u7u7////+7u7u7u7u7u7u7u7u7u7u7u7u7u///////+7u7u7u7u7u7u7u7u7u7u7u/////+AAAAAH8AAPAAAAAADwAA4AAAAAAHAADAAAAAAAMAAIAAAAAAAQAAgAAAAAABAACAAAAAAAEAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAABAACAAAAAAAEAAIAAAAAAAQAAwAAAAAADAADgAAAAAAcAAPAAAAAADwAA/gAAAAB/AAAoAAAAIAAAAEAAAAABAAQAAAAAAIACAAAAAAAAAAAAABAAAAAAAAAAAQEBABYWFgAnJycANTU1AEdHRwBZWVkAZWVlAHh4eACIiIgAmZmZAK6urgDMzMwA19fXAOnp6QD+/v4AAAAAAP//7u7u7u7u7u7u7u7u////7u7u7u7u7u7u7u7u7u7//u7u7u7u7u7u7u7u7u7u7/7u7u7u7u7u7u7u7u7u7u/u7u7u7u7u7u7u7u7u7u7u7u7u7u7X3u7u7I7u7u7u7u7u7u7uYF7u7uIK7u7u7u7u7u7u7QAM7u6vBO7u7u7u7u7u7ucABe7uMA/O7u7u7u7u7u7R8q/O6gCEbu7u7u7u7u7ukAnibuTx6g3u7u7u7u7u7hAe6gzP+O4Y7u7u7u7u7urwju4mXx7uge7u7u7u7u7jAd7uoACO7tCe7u7u7u7uoPfu7uEB3u7mPu7u7u7u7k8N7u7QBu7u6wru7u7u7uwAXu7ufwbu7u407u7u7u7lAM7u7RBQzu7ur87u7u7u0ATu7ucA0l7u7uFu7u7u7n/67u7RB+oL7u7nHe7u7u0fPu7ucA3uJO7u7Qju7u7o/67u7Q9u7q+u7u5R3u7u0Q/e7ub/vu7PLO7uX13u4w//Be4v/xnoH/+ekv//Xu7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7u7+7u7u7u7u7u7u7u7u7u7v/u7u7u7u7u7u7u7u7u7u7//u7u7u7u7u7u7u7u7u7v///+7u7u7u7u7u7u7u7v//8AAAD8AAAAOAAAABgAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAAGAAAABwAAAA/AAAA8oAAAAEAAAACAAAAABAAQAAAAAAMAAAAAAAAAAAAAAABAAAAAAAAAAAQEBABcXFwAnJycAOzs7AElJSQBpaWkAeXl5AIaGhgCVlZUApqamALOzswDMzMwA2dnZAObm5gD+/v4AAAAAAP/u7u7u7u7//u7u7u7u7u/u7uzu7t7u7u7u4Y7lTu7u7u6QTtA77u7u7iaoctXu7u7qDOQZ5d7u7uRO5R7rbu7uv77iLu5O7u5D7pGn7pju7QrtKOTe4+6z+OT40z2RTO7u7u7u7u7u7u7u7u7u7u7+7u7u7u7u7//u7u7u7u7/wAMAD4ABAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA8AAAAPAAAADwAAAA+AAQAPwAMADw=="}
[TT] restoreTab {"entries":[{"url":"https://twitter.com/home","title":"https://twitter.com/home","cacheKey":0,"ID":0,"docshellUUID":"{ce671e27-4551-4a46-b9a3-f35a7769a1a5}","originalURI":"https://twitter.com/home","resultPrincipalURI":"https://twitter.com/home","loadReplace":false,"scrollRestorationIsManual":true,"principalToInherit_base64":"eyIwIjp7IjAiOiJtb3otbnVsbHByaW5jaXBhbDp7YjkzY2VkMWUtYWJjNC00YTljLWIyZDEtZmE1NjEyZGEzMjI3fSJ9fQ==","partitionedPrincipalToInherit_base64":"eyIwIjp7IjAiOiJtb3otbnVsbHByaW5jaXBhbDp7YjkzY2VkMWUtYWJjNC00YTljLWIyZDEtZmE1NjEyZGEzMjI3fSJ9fQ==","hasUserInteraction":false,"triggeringPrincipal_base64":"eyIxIjp7IjAiOiJodHRwczovL3R3aXR0ZXIuY29tL2hvbWUiLCIyIjoiXnVzZXJDb250ZXh0SWQ9MSJ9fQ==","docIdentifier":19327352833,"persist":true}],"lastAccessed":1600701958625,"hidden":false,"attributes":{},"userContextId":0,"index":1,"requestedIndex":0,"userTypedValue":"","userTypedClear":0,"image":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAAXNSR0IArs4c6QAAA0pJREFUWAntVk1oE1EQnnlJbFK3KUq9VJPYWgQVD/5QD0qpfweL1YJQoZAULBRPggp6kB78PQn14kHx0jRB0UO9REVFb1YqVBEsbZW2SbVS0B6apEnbbMbZ6qbZdTempqCHPAjvzcw3P5mdmfcAiquYgX+cAVwu/+5AdDMQnSPCHUhQA0hf+Rxy2OjicIvzm+qnKhito0qpb2wvJhWeJgCPP7oPELeHvdJ1VSGf3eOPnSWga0S0Qo9HxEkEusDBuNjbEca8G291nlBxmgDc/ukuIvAJxI6wr+yKCsq1ewLxQ2lZfpQLo8oQ4ZXdCkfnACrGWpyDCl+oQmVn5xuVPU102e2P3qoJkFOhzVb9S7KSnL5jJs/mI+As01PJFPSlZeFSZZoAGBRXBZyq9lk5NrC+e7pJ5en30c+JWk59pZ5vRDOuhAD381c/H/FKz1SMNgCE16rg505r5TT0uLqme93d0fbq+1SeLSeU83Ke0RHYFPGVPcjQfNDUwIa7M665+dQAEEjZoMwZMcEF9RxIDAgBQ2mCcqJ0Z0b+h4MNbZ4RnyOSDbNmE2iRk5jCNgIIckFoZAs4IgfLGrlKGjkzS16iwj6pV9I4mUvCPf73JVytH9nRJj24QHrqU8NCIWrMaGqAC+Ut/3ZzAS63cx4v2K/x/IvQBOCwWzu5KmJGwEJ5PIgeG9nQBDDcXPpFoDjJ7ThvBC6EZxXWkJG+JgAFwGM4KBAOcibeGCn8FQ/hyajXPmSk+1sACogn4hYk7OdiHDFSWipPkPWSmY6mCzIghEEuxJvcEYUvxIdhX2mvmSHDDPBF9AJRnDZTyp+P40671JYLbxiAohDxSTfQIg4oNxgPzCWPHaWQBViOf2jGqVwBaEaxGbAqOFMrp+SefC8eNhoFIY5lXzpmtnMGUB2IbU3JdIqVW9m5zcxINn/hAYKiIexdaTh4srHKORMAP0b28PNgJyGt5gvHzQVYx91QpVcwpRFl/p63HSR1DLbid1OcTpAJQOG7u+KH+aI5Qwj13IsamU5vkUSIc8uGLDa8OtoivV8U5HcydFLtT7hlSDVy2nfxI2Ibg9awuVU8IeJAOMF5m2B6jFs1tM5R9rS3GRP5uSuiihn4DzPwA7z7GDH+43gqAAAAAElFTkSuQmCC"}
[TT] restoreTab {"entries":[{"url":"https://twitter.com/home","title":"https://twitter.com/home","cacheKey":0,"ID":0,"docshellUUID":"{c1436792-699a-d240-b6a3-b239b13d4a2f}","originalURI":"https://twitter.com/home","resultPrincipalURI":"https://twitter.com/home","loadReplace":false,"principalToInherit_base64":"eyIwIjp7IjAiOiJtb3otbnVsbHByaW5jaXBhbDp7M2E3ZmE0ZTYtZjkyNS00YTc2LWExY2MtZmM0Zjc4MDZmZmRmfSJ9fQ==","partitionedPrincipalToInherit_base64":"eyIwIjp7IjAiOiJtb3otbnVsbHByaW5jaXBhbDp7M2E3ZmE0ZTYtZjkyNS00YTc2LWExY2MtZmM0Zjc4MDZmZmRmfSJ9fQ==","hasUserInteraction":false,"triggeringPrincipal_base64":"eyIxIjp7IjAiOiJodHRwczovL3R3aXR0ZXIuY29tL2hvbWUiLCIyIjoiXnVzZXJDb250ZXh0SWQ9MSJ9fQ==","docIdentifier":21474836481,"persist":true}],"lastAccessed":1600701964759,"hidden":false,"attributes":{},"userContextId":0,"index":1,"requestedIndex":0,"userTypedValue":"","userTypedClear":0,"image":"data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAAXNSR0IArs4c6QAAA0pJREFUWAntVk1oE1EQnnlJbFK3KUq9VJPYWgQVD/5QD0qpfweL1YJQoZAULBRPggp6kB78PQn14kHx0jRB0UO9REVFb1YqVBEsbZW2SbVS0B6apEnbbMbZ6qbZdTempqCHPAjvzcw3P5mdmfcAiquYgX+cAVwu/+5AdDMQnSPCHUhQA0hf+Rxy2OjicIvzm+qnKhito0qpb2wvJhWeJgCPP7oPELeHvdJ1VSGf3eOPnSWga0S0Qo9HxEkEusDBuNjbEca8G291nlBxmgDc/ukuIvAJxI6wr+yKCsq1ewLxQ2lZfpQLo8oQ4ZXdCkfnACrGWpyDCl+oQmVn5xuVPU102e2P3qoJkFOhzVb9S7KSnL5jJs/mI+As01PJFPSlZeFSZZoAGBRXBZyq9lk5NrC+e7pJ5en30c+JWk59pZ5vRDOuhAD381c/H/FKz1SMNgCE16rg505r5TT0uLqme93d0fbq+1SeLSeU83Ke0RHYFPGVPcjQfNDUwIa7M665+dQAEEjZoMwZMcEF9RxIDAgBQ2mCcqJ0Z0b+h4MNbZ4RnyOSDbNmE2iRk5jCNgIIckFoZAs4IgfLGrlKGjkzS16iwj6pV9I4mUvCPf73JVytH9nRJj24QHrqU8NCIWrMaGqAC+Ut/3ZzAS63cx4v2K/x/IvQBOCwWzu5KmJGwEJ5PIgeG9nQBDDcXPpFoDjJ7ThvBC6EZxXWkJG+JgAFwGM4KBAOcibeGCn8FQ/hyajXPmSk+1sACogn4hYk7OdiHDFSWipPkPWSmY6mCzIghEEuxJvcEYUvxIdhX2mvmSHDDPBF9AJRnDZTyp+P40671JYLbxiAohDxSTfQIg4oNxgPzCWPHaWQBViOf2jGqVwBaEaxGbAqOFMrp+SefC8eNhoFIY5lXzpmtnMGUB2IbU3JdIqVW9m5zcxINn/hAYKiIexdaTh4srHKORMAP0b28PNgJyGt5gvHzQVYx91QpVcwpRFl/p63HSR1DLbid1OcTpAJQOG7u+KH+aI5Qwj13IsamU5vkUSIc8uGLDa8OtoivV8U5HcydFLtT7hlSDVy2nfxI2Ibg9awuVU8IeJAOMF5m2B6jFs1tM5R9rS3GRP5uSuiihn4DzPwA7z7GDH+43gqAAAAAElFTkSuQmCC"}

So, the userContextId is not set for "twitter.com" in the personal tab in storage for the session store.

When we are restoring twitter.com that living userContextId = 1, I found:

{
  "entries": [
    {
      "url": "https://twitter.com/home?lang=en",
      "title": "Home / Twitter",
      "cacheKey": 0,
      "ID": 0,
      "docshellUUID": "{db149b97-eb1e-0148-a742-6844f6c0a284}",
      "originalURI": "https://twitter.com/home?lang=en",
      "resultPrincipalURI": "https://twitter.com/home?lang=en",
      "loadReplace": false,
      "scrollRestorationIsManual": true,
      "principalToInherit_base64": "eyIwIjp7IjAiOiJtb3otbnVsbHByaW5jaXBhbDp7MjU2MjQwYjItYTBmYS00OGExLWEyNjktZmJhNmQ5NmY4MTk4fSJ9fQ==",
      "partitionedPrincipalToInherit_base64": "eyIwIjp7IjAiOiJtb3otbnVsbHByaW5jaXBhbDp7MjU2MjQwYjItYTBmYS00OGExLWEyNjktZmJhNmQ5NmY4MTk4fSJ9fQ==",
      "hasUserInteraction": false,
      "triggeringPrincipal_base64": "eyIxIjp7IjAiOiJodHRwczovL3R3aXR0ZXIuY29tL2hvbWU/bGFuZz1lbiIsIjIiOiJedXNlckNvbnRleHRJZD0xIn19",
      "docIdentifier": 15032385537,
      "persist": true
    }
  ],
  "lastAccessed": 1600766488623,
  "hidden": false,
  "attributes": {
    
  },
  "userContextId": 0,
  "index": 1,
  "requestedIndex": 0,
  "userTypedValue": "",
  "userTypedClear": 0,
  "storage": {
    "https://twitter.com^userContextId=1": {
      "branch_session": "{\"session_id\":\"836882360259255656\",\"identity_id\":\"836882360250870045\",\"link\":\"https://twitter.app.link?%24identity_id=836882360250870045\",\"data\":\"{\\\"+clicked_branch_link\\\":false,\\\"+is_first_session\\\":true}\",\"browser_fingerprint_id\":\"836482814738707346\",\"has_app\":false}"
    }
  },
  "image": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAACAAAAAgCAYAAABzenr0AAAAAXNSR0IArs4c6QAAA0pJREFUWAntVk1oE1EQnnlJbFK3KUq9VJPYWgQVD/5QD0qpfweL1YJQoZAULBRPggp6kB78PQn14kHx0jRB0UO9REVFb1YqVBEsbZW2SbVS0B6apEnbbMbZ6qbZdTempqCHPAjvzcw3P5mdmfcAiquYgX+cAVwu/+5AdDMQnSPCHUhQA0hf+Rxy2OjicIvzm+qnKhito0qpb2wvJhWeJgCPP7oPELeHvdJ1VSGf3eOPnSWga0S0Qo9HxEkEusDBuNjbEca8G291nlBxmgDc/ukuIvAJxI6wr+yKCsq1ewLxQ2lZfpQLo8oQ4ZXdCkfnACrGWpyDCl+oQmVn5xuVPU102e2P3qoJkFOhzVb9S7KSnL5jJs/mI+As01PJFPSlZeFSZZoAGBRXBZyq9lk5NrC+e7pJ5en30c+JWk59pZ5vRDOuhAD381c/H/FKz1SMNgCE16rg505r5TT0uLqme93d0fbq+1SeLSeU83Ke0RHYFPGVPcjQfNDUwIa7M665+dQAEEjZoMwZMcEF9RxIDAgBQ2mCcqJ0Z0b+h4MNbZ4RnyOSDbNmE2iRk5jCNgIIckFoZAs4IgfLGrlKGjkzS16iwj6pV9I4mUvCPf73JVytH9nRJj24QHrqU8NCIWrMaGqAC+Ut/3ZzAS63cx4v2K/x/IvQBOCwWzu5KmJGwEJ5PIgeG9nQBDDcXPpFoDjJ7ThvBC6EZxXWkJG+JgAFwGM4KBAOcibeGCn8FQ/hyajXPmSk+1sACogn4hYk7OdiHDFSWipPkPWSmY6mCzIghEEuxJvcEYUvxIdhX2mvmSHDDPBF9AJRnDZTyp+P40671JYLbxiAohDxSTfQIg4oNxgPzCWPHaWQBViOf2jGqVwBaEaxGbAqOFMrp+SefC8eNhoFIY5lXzpmtnMGUB2IbU3JdIqVW9m5zcxINn/hAYKiIexdaTh4srHKORMAP0b28PNgJyGt5gvHzQVYx91QpVcwpRFl/p63HSR1DLbid1OcTpAJQOG7u+KH+aI5Qwj13IsamU5vkUSIc8uGLDa8OtoivV8U5HcydFLtT7hlSDVy2nfxI2Ibg9awuVU8IeJAOMF5m2B6jFs1tM5R9rS3GRP5uSuiihn4DzPwA7z7GDH+43gqAAAAAElFTkSuQmCC"
}

So, the "storage" is set to "https://twitter.com^userContextId=1" but "userContextId" is set to "0"

I cannot reproduce this with patches in Bug 1662925.

See Also: → 1662925

I can reproduce a certain behavior on all websites, 100% of the time:

GOOD case:

  1. Open a random website in a tab with default container
  2. Right click that tab -> Reopen in container -> Chose any non-default container
  3. Close Firefox and start it again or just close the non-default container tab and press Ctrl+Shift+T
  4. Result: The restored non-default container tab still has the correct container
    (works for any website I've tried so far)

BAD case

  1. Click the plus icon to open a new tab in a non-default container (I have set privacy.userContext.newTabContainerOnLeftClick.enabled to true)
  2. navigate to a random website in that tab
  3. Close Firefox and start it again or just close the non-default container tab and press Ctrl+Shift+T
  4. Result: The restored (previously non-default container) tab switched back to the default container

I mixed up some GOOD case tabs with some BAD case tabs again and again and this behavior was 100% consistent during all my tests.

Thanks for working on this, containers are really one of the main reasons for me personally to use Firefox since I have multiple Google and other accounts and I have a lot of pinned tabs with different container so I can quickly access stuff like Gmail or Drive (and other stuff) on any of my accounts.

A lot of people probably won't notice, but for people like me who use containers quite heavily it's a real showstopper right now.

Anyway, let me know if you need more debug info or anything. :)

Firefox 83.0 (release)
Build ID 20201112153044
OS Windows_NT 10.0 19042

(In reply to Paul from comment #12)
Hi Paul,

Thanks for the reply and for letting us know the issue might still exist! However, I tried this a few more times and I couldn't reproduce this (with setting privacy.userContext.newTabContainerOnLeftClick.enabled to true and false) on the latest Nightly (which is 85.0a1).

I have two questions and I put them below:

  • Which site did you use for reproducing this issue? Is that Twitter? If so, would you mind checking if you can still reproduce it after removing its service worker in "about:serviceworkers"?
  • Can you also help me to check if you can reproduce this with a clean profile? (You can create one in "about:profiles")
Flags: needinfo?(bugzilla)

I can still reproduce this issue on today's nightly with a clean profile. Here are the precise steps I followed to do that:

  1. Install "Firefox Multi-Account Containers".
  2. Go to https://en.wikipedia.org/wiki/Jack_Dorsey#External_links (you can do that from a "No Container" tab, it doesn't matter).
  3. Right click on the link to Dorsey's twitter profile and select "Open Link in New Container Tab -> Personal".
  4. The twitter page tab now runs in the "Personal" container. Close that tab.
  5. Press Ctrl+Shift+T to reopen the last closed tab.
  6. Notice that the reopened tab runs in "No Container" mode.

I have encountered this issue with sites other than twitter, but with twitter it occurs 100% of the time.

(In reply to Marios Titas from comment #14)

I have encountered this issue with sites other than twitter, but with twitter it occurs 100% of the time.

Thanks! Now, I can reproduce the issue with these steps when I set fission.autostart to false. If I set fission.autostart to true, then this issue disappears.

So, this issue only happens in non-Fission mode.

Flags: needinfo?(bugzilla)

(In reply to Tom Tung [:tt, :ttung] from comment #13)

(In reply to Paul from comment #12)
Hi Paul,

Thanks for the reply and for letting us know the issue might still exist! However, I tried this a few more times and I couldn't reproduce this (with setting privacy.userContext.newTabContainerOnLeftClick.enabled to true and false) on the latest Nightly (which is 85.0a1).

I have two questions and I put them below:

  • Which site did you use for reproducing this issue? Is that Twitter? If so, would you mind checking if you can still reproduce it after removing its service worker in "about:serviceworkers"?
  • Can you also help me to check if you can reproduce this with a clean profile? (You can create one in "about:profiles")

I did not use Twitter. I used random websites that i found by googling a random string and then opening a random result.

I was not able to produce this with a clean profile but after a bit of testing I found the following:

  1. I use the Tabliss addon: https://addons.mozilla.org/en-US/firefox/addon/tabliss

BAD
2. With the addon enabled: press the "plus" and select a non-default container
3. Type a URL and press enter
4. restart firefox -> the tab will be the default container

GOOD
2. With the addon disabled: press the "plus" and select a non-default container
3. Type a URL and press enter
4. restart firefox -> the tab will be in the non-default container that you selected in step 2

Maybe that helps for tackling down the underlying issue.

Test that succeeds with --enable-fission but fails with the COOP+COEP case in
without enbling fission.

D98296 fixes the issue on my mac book pro. Will send review requests once the try completes and its result look good.

Attachment #9190489 - Attachment description: Bug 1665942 - test; → Bug 1665942 - A test to verify COOP+COEP site should have the same userContextId after restoring;

(In reply to Tom Tung [:tt, :ttung] from comment #20)

D98296 fixes the issue on my mac book pro. Will send review requests once the try completes and its result look good.

I tested this patch and it seems to address the issue when tested against a clean new profile. However, the issue is still there when testing against an existing old profile. Is there anyway to fix this for the old profile? Or did the old code produce a "corrupt" say sessionstore.jsonlz4 (or whatever other file) in that profile?

Assignee: nobody → ttung
Status: NEW → ASSIGNED

(In reply to Marios Titas from comment #21)

(In reply to Tom Tung [:tt, :ttung] from comment #20)

D98296 fixes the issue on my mac book pro. Will send review requests once the try completes and its result look good.

I tested this patch and it seems to address the issue when tested against a clean new profile. However, the issue is still there when testing against an existing old profile. Is there anyway to fix this for the old profile? Or did the old code produce a "corrupt" say sessionstore.jsonlz4 (or whatever other file) in that profile?

Thanks for testing and letting me know it seems to fix the issue on your machine as well!

Unfortunately, I don't think there is an easy way to recover back once SessionStore persists its data into the disk (sessionstore.jsonlz4). The problem is how to determine whether the userContextId for a tab in SessionStore needs to be updated.

We might be able to tell if the data in sessionstore.jsonlz4 is needed to be updated by comparing the userContextId in different entries (e.g. in comment #10, we have "storage": { "https://twitter.com^userContextId=1" ...} ), but not all the sites is using SessionStorage and it can be overwrite after the further restore.

To elaborate more on recovering from a "corrupt" sessionstore.jsonlz4, my concern is that if there are no other entries that store the correct userContextId, then we won't be able to recover the tab to the right userContextId.

(In reply to Tom Tung [:tt, :ttung] from comment #22)

Unfortunately, I don't think there is an easy way to recover back once SessionStore persists its data into the disk (sessionstore.jsonlz4). The problem is how to determine whether the userContextId for a tab in SessionStore needs to be updated.

I understand that and it makes sense. What confuses me is that the problem persists in old profiles, even for newly created tabs, even in newly created containers. In fact, I tried the following:

  1. In an existing profile, delete all containers
  2. Close firefox.
  3. Delete sessionstore.jsonlz4 and sessionstore-backups from the profile.
  4. Apply the patch from D98296.
  5. Run firefox, create some new containers and try to reproduce the bug (e.g. by following the steps from comment #14).
    You will notice that the bug is still there.
Attachment #9190812 - Attachment description: Bug 1665942 - Use userContextId from tab for the new TabStateCache; → Bug 1665942 - Collect userContextId from tab in _collectBaseTabData and stop collecting it in the session history collection;
Depends on: 1681250
Attachment #9190812 - Attachment description: Bug 1665942 - Collect userContextId from tab in _collectBaseTabData and stop collecting it in the session history collection; → Bug 1665942 - Use userContextId from tab for the new TabStateCache;
Attachment #9190812 - Attachment description: Bug 1665942 - Use userContextId from tab for the new TabStateCache; → Bug 1665942 - Collect userContextId from tab in _collectBaseTabData and stop collecting it in the session history collection;
Pushed by ttung@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e67e319c6e1b
A test to verify COOP+COEP site should have the same userContextId after restoring; r=nika
Keywords: leave-open

When SessionStore restores a window, it calls tabbrowser.addMultipleTabs to add tabs and then calls ssi.restoreTabs to retores tabs. Inside the ssi.restoreTab, it checks whether the tab has been removed from TAB_STATE_FOR_BROWSER. However, inside tabbrowser.addMultipleTabs, it's possible to reuse the selected tab without resetting the tabState for a tab from a lined browser.

This code wasn't tested in browser_637020.js because the this.selectedTab.userContextId was undefined which is corrected to 0 by D98468.

Anyway I will file a ticket for that.

Depends on: 1683713
Blocks: 1666584
Pushed by ttung@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/d2f4a6c7e9ca
Collect userContextId from tab in _collectBaseTabData and stop collecting it in the session history collection; r=nika,geckoview-reviewers,agi

Backed out with Bug 1683713 for failures on browser_cookies_legacy.js

backout: https://hg.mozilla.org/integration/autoland/rev/2149651d7eb759e867b44d115298480399be1f1b

push: https://treeherder.mozilla.org/jobs?repo=autoland&group_state=expanded&revision=d2f4a6c7e9ca100494c68870457a56c2da1187b4

failure log: https://treeherder.mozilla.org/logviewer?job_id=330222914&repo=autoland&lineNumber=24423

[task 2021-02-17T11:02:24.051Z] 11:02:24 INFO - TEST-PASS | browser/components/sessionstore/test/browser_cookies_legacy.js | cookie added by the cookie service -
[task 2021-02-17T11:02:24.051Z] 11:02:24 INFO - Buffered messages logged at 11:00:55
[task 2021-02-17T11:02:24.058Z] 11:02:24 INFO - Leaving test bound test_window
[task 2021-02-17T11:02:24.058Z] 11:02:24 INFO - Entering test bound test_browser
[task 2021-02-17T11:02:24.059Z] 11:02:24 INFO - waiting for cookie name58626=value58626 from http://example.com...
[task 2021-02-17T11:02:24.059Z] 11:02:24 INFO - TEST-PASS | browser/components/sessionstore/test/browser_cookies_legacy.js | cookie added by the cookie service -
[task 2021-02-17T11:02:24.060Z] 11:02:24 INFO - running
[task 2021-02-17T11:02:24.061Z] 11:02:24 INFO - Buffered messages finished
[task 2021-02-17T11:02:24.061Z] 11:02:24 INFO - TEST-UNEXPECTED-FAIL | browser/components/sessionstore/test/browser_cookies_legacy.js | Test timed out -
[task 2021-02-17T11:02:24.061Z] 11:02:24 INFO - GECKO(8918) | MEMORY STAT | vsize 3410MB | residentFast 416MB | heapAllocated 105MB
[task 2021-02-17T11:02:24.063Z] 11:02:24 INFO - TEST-OK | browser/components/sessionstore/test/browser_cookies_legacy.js | took 90044ms

Flags: needinfo?(ttung)

(In reply to Natalia Csoregi [:nataliaCs] from comment #28)

Backed out with Bug 1683713 for failures on browser_cookies_legacy.js

So, this code expects that it can get back to the backup browser state after restoring from the legacy browser state.
it sets the browser state and thus restore windows and then waits for the "SSTabRestored" event. Restoring windows causes to restore the tab content. During restoring the tab content, it firstly registers onStopRequest listener from the web progress event and then makes the browsing content load to the uri. If the callback(this._restoreTabContentComplete) is called, it would send out the "SSTabRestored" event. So that the promise will be resolved.

Before my patches, it doesn't reuse the selected tab because this.selectedTab.userContextId is 0 and userContextId is undefined. The reason for userContextId being undefined is that the userContextId hasn't been updated when we are getting the backup browser state.

After my patches, it would reuse the selected tab because this.selectedTab.userContextId is 0, userContextId is also 0, and the selected tab is not restoring. However, it updates remoteness of the tab. And updating the remoteness of the tab makes the frame loader unload and thus unregisters the listener from listening to the web progress event. Such that, the callback in onStopRequest won't be executed and thus the promise will never be resolved.

Flags: needinfo?(ttung)

Updating tab's remoteness will cause all web progress listeners to be removed
from the tab browser. However, since we are going to reuse that tab and register
new web progress listener on that tab browser. We need to wait until the final
message is received before reusing.

Attachment #9204516 - Attachment description: Bug 1665942 - Ensure the the final message for the remoteness updating tab browser is received before restoring tabs; → Bug 1665942 - Remove the code for updating remoteness logic in addMultipleTabs since we have already handled fixing remoteness when restoring tabs;
Pushed by ttung@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/51013501829a
Collect userContextId from tab in _collectBaseTabData and stop collecting it in the session history collection; r=nika,geckoview-reviewers,agi
https://hg.mozilla.org/integration/autoland/rev/20c676649a86
Remove the code for updating remoteness logic in addMultipleTabs since we have already handled fixing remoteness when restoring tabs; r=nika
Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Keywords: leave-open
Resolution: --- → FIXED
status-firefox86: --- → wontfix
status-firefox87: --- → wontfix
status-firefox88: --- → fixed
status-firefox-esr78: --- → wontfix
Target Milestone: --- → 88 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: