Here is a video from TED-Ed that explains why. TLDR: phones looking for a signal broadcast on high power, but planes move so fast that you can end up right next to a cell tower so the high power signal can interfere with other phones trying to communicate.
I disagree with how he phrases a few things, but I think it’s mostly accurate.
The first Star Trek game I played was a shareware version of EGA Trek for DOS, which was also one of the first computer games I ever played.
I remember it would tell you a starbase was under attack and you would have to go there to defend it. One of my torpedoes missed and hit a star which made it go supernova, destroying the enemy ship. Fun times.
It seems like this is a bug.
https://github.com/mozilla-mobile/firefox-ios/issues/11994
Yoana Rios Diaz commented:
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
https://github.com/mozilla-mobile/firefox-ios/issues/13520
Yoana Rios Diaz commented:
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
In the second paragraph, it states that the group that makes the open source Chrome OS also collaborated in making the board. That is probably why they highlight it in the title.