Feature Request
Description
Our team wanted to create an ApplicationNavigation utility item which opens a URL in a new tab/window, for the purpose of linking to an external help page, e.g. when selecting the specified item below:
Attempting to invoke window.open() in either the onSelectHelp or onSelectUtilityItem callbacks results in popup-blocking behaviors in the latest versions of Firefox and Safari (as of June 2022), and a no-op in iOS 14.4. Notably however, Chrome seems to natively understand that the request originated as a result of a user click and allows for the window to open.
I wasn't sure whether to classify this as a bug, as it's not clear to me whether this type of usage was ever intended. That said, either altering the code to allow for the above behavior to work across all major browsers or adding first-class support for this feature would be desirable.
As an example of the latter proposal, the utilityItems object could potentially expose a configuration option that would support this feature (similar to the external variant in the Hyperlink component), such that upon selecting the item, the externalLink URL would open in a new window, without the need to define a callback method:
{
key: 'utility_1',
icon: <Icon1 >,
text: 'Utility 1',
metaData: { myValue: value1 },
externalLink: <some URL>
}
Additional Context / Screenshots
Note: Prior to creating this issue, I searched the repo history and found a similar request. However, I believe that request was specific to the navigationItems as opposed to the utilityItems. Additionally, we don't have a desire/need for the utility items to behave like standard browser hyperlinks (ie. such that a user may right-click and select 'open in a new tab').
Feature Request
Description
Our team wanted to create an
ApplicationNavigationutility item which opens a URL in a new tab/window, for the purpose of linking to an external help page, e.g. when selecting the specified item below:Attempting to invoke
window.open()in either theonSelectHelporonSelectUtilityItemcallbacks results in popup-blocking behaviors in the latest versions of Firefox and Safari (as of June 2022), and a no-op in iOS 14.4. Notably however, Chrome seems to natively understand that the request originated as a result of a user click and allows for the window to open.I wasn't sure whether to classify this as a bug, as it's not clear to me whether this type of usage was ever intended. That said, either altering the code to allow for the above behavior to work across all major browsers or adding first-class support for this feature would be desirable.
As an example of the latter proposal, the
utilityItemsobject could potentially expose a configuration option that would support this feature (similar to theexternalvariant in the Hyperlink component), such that upon selecting the item, theexternalLinkURL would open in a new window, without the need to define a callback method:Additional Context / Screenshots
Note: Prior to creating this issue, I searched the repo history and found a similar request. However, I believe that request was specific to the
navigationItemsas opposed to theutilityItems. Additionally, we don't have a desire/need for the utility items to behave like standard browser hyperlinks (ie. such that a user may right-click and select 'open in a new tab').