Tab: Focus upon activation should be optional

[mathiasschopmans]

There was a refactoring in July where the active tab would always gain focus once activated.

In my recent project I'm (mis)using tabs as a navigation element in a fixed header to jump between sections on a long onepage website. In addition to this if a user scrolls the page, I highlight the current section once a new section becomes visible in the viewport by using navigation.activateTab(sectionIndex)

This is causing an issue, because when you try to navigate the page via the tab-key and you reach an element in the next section, the viewport scrolls, the event-listener will activate the next tab and focus is back in the header. 😢

Back then @kfranqueiro also raised a question related to this:

Are we sure we want to do this in all cases? Couldn't this be really confusing if you're focused e.g. on a part of the page unaffected by tabs, then a tab is activated programmatically and grabs the user's focus?

In my case it would be awesome to be able to configure/disable this behaviour when creating the instance or add a second parameter to .activateTab(sectionIndex, false) to not set the focus when programmatically activating a tab.

Related PR: #3164 "feat(tab): Give focus to tab when activated" by @patrickrodee

[kfranqueiro]

This seems like potentially a popular use case so I agree, this should probably at least be available as a flag. I'm going to see if I can get input from one of our interaction designers and maybe also check with our engineers.

Also I appreciate that you even dug up that comment :)

[kfranqueiro]

Checked with interaction designer and engineers and we all seem to be agreeable on adding a flag for this, with the default being the current behavior.

[kfranqueiro]

After looking at this a bit, the most likely way forward would seem to be to add a setter to the Tab component forwarding to a foundation method to set a flag used to conditionalize the focus call in activate. MDC Tab Bar can then have an equivalent setter which would forward to all of its child tab components, since the most common use case will be to apply this behavior across an entire Tab Bar.

On the MDC Tab level, we could alternately consider adding an optional argument to the activate API or to the Tab component/foundation constructors, but that seems potentially more confusing.