I didn’t investigate this one specifically but it looks consistent with my findings on https://mozilla-hub.atlassian.net/browse/FXIOS-5951 ( https://mozilla-hub.atlassian.net/browse/FXIOS-5951|smart-link ) , from the actual behavior description it looks like only the selected restoring tab is failing to keep the cookies, we hoped the Tab refactoring will fix this issue for good but the Webkit restore process has not started yet so we should take another look with fresh eyes.
I talked with Orla Mitchell last week about the ticket above so whoever takes this one can sync with us so we don’t double efforts
The issue is only reproducible in the selected tab being restored. Ex if we have 3 tabs with bbc.com ( http://bbc.com ) open. We accept the cookies and restore the app only for the selected tab the cookie banner will show again and if the user reload the banner disappear. If we switch to the other 2 previously tabs the banner doesn’t show.
So the issue is related to the tab restore process only for the selected tab the cookie store is empty (probably a race condition).
This part of the code is very flaky and is being refactored already, after a sync with Orla Mitchell we think it makes more sense to wait for the refactoring to fix this issue for good that to find a partial patch that could cause side effects
Not an iOS user, but this questions poped up in my head ... maybe someone here know the answer.
Since firefox on iOS uses the underlying safari core, how much of the cookie managment/handling is actually even done by firefox itself?