<STR/explanation coming> This repros both with and without the new collection code from bug 1572084. A quick solution could be to replace the `null` placeholders with some special placeholder object (`{isplaceholder: true}`?), which the restore code will know how to deal with. This is causing the test added in [D108989](https://phabricator.services.mozilla.com/D108989) to fail.
Bug 1700190 Comment 0 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
STR 1. Visit https://kashav.ca/bugs/1700190/top.html 2. Type something into the second frame (and only the second frame) 3. Close the tab 4. Restore that closed tab (Ctrl-Shift-T) Expected: the second frame restores its form data correctly. Actual: the typed data either ends up in the first frame or sometimes is lost completely. This repros both with and without the new collection code from bug 1572084. What's happening is that: - we've only typed data into the second frame, we're only collecting data from that frame - we use a placeholder `null` in the collected data children list for the first frame. For the above STR, the collected data looks something like: `{ ..., children: [null, { url: "form.html", ... }] }`. - in the final flush, we copy all data from the cache [here](https://searchfox.org/mozilla-central/rev/fd8b90d571797a1601b95fa58c08621baa071fe0/browser/components/sessionstore/SessionStore.jsm#1384-1386). As part of that process, we run our form data through PrivacyFilter.filterFormData [here](https://searchfox.org/mozilla-central/rev/fd8b90d571797a1601b95fa58c08621baa071fe0/browser/components/sessionstore/TabState.jsm#185), and that function [explicitly filters out `null` children objects](https://searchfox.org/mozilla-central/source/toolkit/modules/sessionstore/PrivacyFilter.jsm#52-54,60-61). A quick solution could be to replace the `null` placeholders with some special placeholder object (`{isplaceholder: true}`?), which the restore code will know how to deal with. This is causing the test added in [D108989](https://phabricator.services.mozilla.com/D108989) to fail.
STR 1. Visit https://kashav.ca/bugs/1700190/top.html 2. Type something into the second frame (and only the second frame) 3. Close the tab 4. Restore that closed tab (Ctrl-Shift-T) Expected: the second frame restores its form data correctly. Actual: the typed data either ends up in the first frame or sometimes is lost completely. This repros both with and without the new collection code from bug 1572084. What's happening is that: - we've only typed data into the second frame, so we're only collecting data from that frame - we use a placeholder `null` in the collected data children list for the first frame. For the above STR, the collected data looks something like: `{ ..., children: [null, { url: "form.html", ... }] }`. - in the final flush, we copy all data from the cache [here](https://searchfox.org/mozilla-central/rev/fd8b90d571797a1601b95fa58c08621baa071fe0/browser/components/sessionstore/SessionStore.jsm#1384-1386). As part of that process, we run our form data through PrivacyFilter.filterFormData [here](https://searchfox.org/mozilla-central/rev/fd8b90d571797a1601b95fa58c08621baa071fe0/browser/components/sessionstore/TabState.jsm#185), and that function [explicitly filters out `null` children objects](https://searchfox.org/mozilla-central/source/toolkit/modules/sessionstore/PrivacyFilter.jsm#52-54,60-61). A quick solution could be to replace the `null` placeholders with some special placeholder object (`{isplaceholder: true}`?), which the restore code will know how to deal with. This is causing the test added in [D108989](https://phabricator.services.mozilla.com/D108989) to fail.
STR 1. Visit https://kashav.ca/bugs/1700190/top.html 2. Type something into the second frame (and only the second frame) 3. Close the tab 4. Restore that closed tab (Ctrl-Shift-T) Expected: the second frame restores its form data correctly. Actual: the typed data either ends up in the first frame or sometimes is lost completely. This repros both with and without the new collection code from bug 1572084. What's happening is that: - we've only typed data into the second frame, so we're only collecting data from that frame - we use a placeholder `null` in the collected data children list for the first frame. For the above STR, the collected data looks something like: `{ ..., children: [null, { url: ".../form.html", ... }] }`. - in the final flush, we copy all data from the cache [here](https://searchfox.org/mozilla-central/rev/fd8b90d571797a1601b95fa58c08621baa071fe0/browser/components/sessionstore/SessionStore.jsm#1384-1386). As part of that process, we run our form data through PrivacyFilter.filterFormData [here](https://searchfox.org/mozilla-central/rev/fd8b90d571797a1601b95fa58c08621baa071fe0/browser/components/sessionstore/TabState.jsm#185), and that function [explicitly filters out `null` children objects](https://searchfox.org/mozilla-central/source/toolkit/modules/sessionstore/PrivacyFilter.jsm#52-54,60-61). A quick solution could be to replace the `null` placeholders with some special placeholder object (`{isplaceholder: true}`?), which the restore code will know how to deal with. This is causing the test added in [D108989](https://phabricator.services.mozilla.com/D108989) to fail.