On a sidenote: This doesn't solve the issue that the tab is stored across all items of the same type (eg all modules, or all articles) which can cause some issues as well.
For that we would need to take into account the ID of the item as well.

I have tested this item ? unsuccessfully on 53ee212

Tested on article works like testing instructions said, with module in new browser-tab also last used tab is shown.

@franz-wohlkoenig Did you really mean to add an unsuccessful test?

@Bakual Yes, because for Module in new browser-tab not the first tab is shown, the last used tab is shown (ie. the 2nd). In Article it works as written in instructions (in new browser-tab the first tab is shown).

@franz-wohlkoenig what was the browser?

@dgt41: Firefox 50.1.0 (Joomla! 3.7.0-alpha2-nightly, macOS Sierra, 10.12.2, PHP 7.0.4, MySQLi 5.5.53-0)

Hmm, may it be that the browser had an already cached version of the JavaScript code and thus did it the old way? I don't see a reason why modules would behave different than articles otherwise.
I just tried with Firefox and it also behaves as expected.

I have tested this item ✅ successfully on 25f7685

Tested on articles and modules. FF cache OFF.
Settings is preserved per tab. Reset by new/close browser tab.

1. Edit an article (or module, plugin, whatever) and change the tab.
2. Click "Save" (not "Save & Close"), the form should reload with the same tab active.
3. Click "Save & Close" and then re-edit the item. The form should open with the same tab active again.
4. Edit an article in another browser tab. The first tab should be active.

Tested again: 1-3 works. 4: Other Article in new Browsertab shows same active Tab as in 3.

Test on:

Joomla! 3.7.0-staging
macOS Sierra, 10.12.3
Firefox 50.1.0 (private Modus)
PHP 7.0.4
MySQLi 5.5.53-0

4: Other Article in new Browsertab shows same active Tab as in 3.

According to caniuse.com

In private browsing mode, Safari, iOS Safari and the Android browser (not include Chrome for Android) do not support setting sessionStorage or localStorage.

This may play a role here. Different browsers may also have a different behavior for new tabs - I don't know that personally.

@csthomas got successfully test on Firefox, maybe other Version and/or different OS.

I have FF 51.0.1 on linux (private mode also tested and OK).
I did, edit article, change tab in article, close article, edit article again, close article, edit article in next browser tab (and get first active article tab).

I got your result if I do not applied current PR.

@Bakual I have tested this and yes it works from a new browser view.

But Save and new opens the same tab again and again, it's stuck on the current browser/session.

Shouldn't we be storing the id, component and type i.e. edit or new ?Then we can decide with JS to pre-select the tab or not?

Shouldn't we be storing the id, component and type i.e. edit or new ?Then we can decide with JS to pre-select the tab or not?

Component and view are stored currently (most of the URL actually), but the ID may be useful as well. However as long as it is stored in localStorage I wouldn't add the ID as that would blow up that list a lot more. It's already ridiculous long as it is. When we switch to sessionStorage, we can add the ID fine if still needed.

But you don't want me to mess with JS to add that. It would be something for another PR from another contributor ?

@Bakual what I am struggling to understand is why we are making tabs so complicated? Why are we storing the tab selection at all? Is it for the few people who edit and save so the tab they saved on is loaded? If that's the only case, in my eyes this is causing more of an issue that it was without it.

It was added so when you use the "Save" and not "Save & Close" button (or reload the page) you stay on the same tab and don't jump back to the first tab. Which imho makes sense in that specific case.
PR which introduced it: #1458.

@Bakual And for that specific case it does make sense I agree, but in doing so it applies to save, save & close and all other menu items. And it only seems to be affecting browsers recently.

To me, if would make more sense to do this on the php level i.e. save and close includes a post variable on save / apply which has the last tab selected. Then when the user goes to the list view and create a new article for instance it's not remembering the selected tab from the session.

Honestly I don't care. I just want to fix the use of localStorage because it is very disturbing to have an article open on the permission tab just because you closed it with that tab open the last time you edited an article (which may be a half year ago).

I have tested this item ✅ successfully on 25f7685

Resolves the issue @Bakual describes. Tested on Chrome and then Safari.

I have tested this item ✅ successfully on 25f7685

RTC