To explain some background to this: Currently, the tab state is stored persistent in localStorage (a data store in the browser useable by JS).
That means if you today open an article and navigate to the permission tab, that tab will be stored as active tab. Next time you open an article again it will still be the active tab.
That is nice when you just close and edit the same article or another one.
However it will also activate that tab when you open the article form in a week or month as the data will never be deleted, just updated once you change the active tab.
This leads to quite unexpected behavior of the tabs.

Now if you play the same game with templates, plugins, module and component options there is an additional strange thing because the last active tab (eg an custom tab in a module) may not be available in the module you edit next (a week later or just a few minutes). You then get a form where no tab is active at all.

Why do we even store tabs

On 6 December 2016 at 14:47, Thomas Hunziker notifications@github.com
wrote:

To explain some background to this: Currently, the tab state is stored
persistent in localStorage (a data store in the browser useable by JS).
That means if you today open an article and navigate to the permission
tab, that tab will be stored as active tab. Next time you open an article
again it will still be the active tab.
That is nice when you just close and edit the same article or another one.
However it will also activate that tab when you open the article form in a
week or month as the data will never be deleted, just updated once you
change the active tab.
This leads to quite unexpected behavior of the tabs.

Now if you play the same game with templates, plugins, module and
component options there is an additional strange thing because the last
active tab (eg an custom tab in a module) may not be available in the
module you edit next (a week later or just a few minutes). You then get a
form where no tab is active at all.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#13105 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8TnI9PSZB3cCrm_9_4Zh1OysHLBMks5rFXWDgaJpZM4LFYEM
.

--
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

Why do we even store tabs

Because of #1458 ?

I think it is useful if you want to edit the same option in multiple instances of the same item.
But imho it has to reset once the browser is closed.

We could use sessionStorage instead of localStorage and then it would only be saved in the current tab. Once you close the tab or navigate away from the page, it will reset. It also has no effect on other open tabs.

The issues with tab storage you described above are just as annoying in the same session.

I think within the same session, it doesn't confuse as you (hopefully) still remember what you have opened a few minutes ago. So you at least will understand why it opens that tab ?

Not for the issue with modules of course. That one needs a fall back to the first tab if the stored tab doesn't exist.

It might not confuse but it doesnt serve any benefit.
The stored tab also usually doesnt exist in component options.

On 6 December 2016 at 15:03, Thomas Hunziker notifications@github.com
wrote:

I think within the same session, it doesn't confuse as you (hopefully)
still remember what you have opened a few minutes ago. So you at least will
understand why it opens that tab ?

Not for the issue with modules of course. That one needs a fall back to
the first tab if the stored tab doesn't exist.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#13105 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8WU8xDsp_Li9CBA7sGXq-LEVQc94ks5rFXkxgaJpZM4LFYEM
.

--
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

If it's unneeded functionality, then I shouldn't try to fix the behaviour...

I think it is very useful especially for when you hit the save (apply) button where the form is reloaded right away. Without it, it would reload with the first tab active.
The other cases it is less usefull.

My thought is maybe it is better to just store it in the sessionStorage instead. Then we don't need any additional logic to simulate a time to life behavior. If you move away from the site or close the tab, the state is reset.

It's driving me nuts right now when I switch between articles and it goes
directly to the last tab I used on the old article and not the first tab on
the new article

On 9 Dec 2016 9:29 a.m., "Thomas Hunziker" notifications@github.com wrote:

I think it is very useful especially for when you hit the save (apply)
button where the form is reloaded right away. Without it, it would reload
with the first tab active.
The other cases it is less usefull.

My thought is maybe it is better to just store it in the sessionStorage
instead. Then we don't need any additional logic to simulate a time to life
behavior. If you move away from the site or close the tab, the state is
reset.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#13105 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8a4ONsFY5GFgeyT7Qs0a0JAn5Dk2ks5rGR-TgaJpZM4LFYEM
.

But do you agree that for the "Apply" task or a page reload it makes sense to be on the same tab?
If so we may take into account the item ID when storing the active tab to make it reset on first tab for other articles.

Yes I agree on that

On 9 December 2016 at 10:00, Thomas Hunziker notifications@github.com
wrote:

But do you agree that for the "Apply" task or a page reload it makes sense
to be on the same tab?
If so we may take into account the item ID when storing the active tab to
make it reset on first tab for other articles.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
#13105 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPH8W1cx4QMNLwhg959lgr9FumTTPPQks5rGSangaJpZM4LFYEM
.

--
Brian Teeman
Co-founder Joomla! and OpenSourceMatters Inc.
https://brian.teeman.net/ http://brian.teeman.net/

@dgt41 What do you think of #13572?

I'm closing this as #13572 seems a better solution