Review, plan, and overhaul tab behavior

Related issues: #522, #520, #467, #434, #542, #457, #431, #529, #546, #539, #484, #450,

Before addressing these issues (some of which are closed), I think we should first agree on expected tab behavior so that we know what to test for; also including tests for all the edge cases that QA has found.

Some of these edge cases are due to unexpected webview behavior. For example, webview may trigger several did-fail-load events with a 0 error code and OK error description during the loading process, although loading hasn’t failed.

I’d like to more fully understand the differences between did-stop-loading, did-finish-load, and did-fail-load events, because although the documentation is straightforward to understand, the actual behavior is not and that is a cause for some of our unexpected tab behavior.

[joshuef]

@hunterlester I think part of tabbing issues arises from using activeTab<whatever> actions. I think we need to squash this and always pass a tab index. (Which in turn means that each tab needs its own address bar etc, (right now there’s one that’s updated).

I’d do that probably first.

So checking for things like, going back triggers back on the correct tab, and cycling tabs and updating the address triggers correct tab window.

We’ll also need to ensure that updateTab, if it changes a tabs active status, that that updates whatever tab was considered active before… (which is handled by setAsActiveTab right now, but not by updateTab…

…

Hmmm, there’s some other considerations that don’t come to me now. But I’ll come back and note down any that do 👍

[calumcraig]

Following on from my previous comment, a related issue can be seen.

1. • Open one or more new tabs as above so that they open in multiple windows.
2. • Close all but original SAFE browser instance.
3. • Continue to browse - open subsequent new tabs.
4. • Observe behaviour of tabs opened previously in multiple windows:

CTRL + TAB to cycle through tabs - this skips any tab which was opened as described.