-
Notifications
You must be signed in to change notification settings - Fork 243
Add Back to Opener Explainer #1057
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Add Back to Opener Explainer #1057
Conversation
@aluhrs13 and @erik-anderson could you help take a look at the explainer? |
BackToOpener/explainer.md
Outdated
|
||
Developers can signal their intent via `window.open()` and `<a>` elements. The browser will then handle the navigation logic, ensuring that when the user navigates back in the new tab, it automatically returns focus to the originating tab and closes the new tab if the opener is still active. | ||
|
||
- For `window.open()`, we propose introducing a new `windowFeatures` parameter called `addOpenerToHistory`. When this feature is specified, the browser will add the opener to the new tab's history. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should think more about the name here-- e.g. should it actually be a history entry or not?
Is there some other name that conveys more about the behavior? I can't immediately think of a better name, however.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 on the naming comment. I don't necessarily think we need to bikeshed/block on that though.
This document is intended as a starting point for engaging the community and standards bodies in developing collaborative solutions fit for standardization. As the solutions to problems described in this document progress along the standards-track, we will retain this document as an archive and use this section to keep the community up-to-date with the most current standards venue and content location of future work and discussions. | ||
|
||
This document status: Active | ||
Expected venue: [WHAT WG](https://whatwg.org/) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we intend for discussion to happen in whatwg? Via issues on the EdgeExplainers site? We should pick one and provide a link to that location.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think WHATWG is where we will eventually bring this explainer to discuss. Should I just directly open an issue there then? Or should I begin within EdgeExplainers? Any best practices here
BackToOpener/explainer.md
Outdated
|
||
## User-Facing Problem | ||
|
||
The new-tab default of chat interfaces and search engines can frustrate users by causing tab proliferation and making it difficult to return to the original conversation or context. Traditional [guidance](https://www.nngroup.com/articles/new-browser-windows-and-tabs/) warns against breaking the user's flow by opening new tabs. At the same time, modern chat interfaces prioritize multitasking and context preservation, which thus prefers opening in new tab. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we have any external signals that we can link that show this is a real user problem?
|
||
- Inconsistency Risks: This behavior might vary across browsers and UA versions, leading to unpredictable user experiences. | ||
- In quickly evolving markets like chat interfaces, a manual override is important—developers should be able to opt into the behavior when needed rather than rely solely on UA heuristics. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there any prior art, previous discussions, or people that should be mentioned in a ''References and Acknowledgements' section?
|
||
- Inconsistency Risks: This behavior might vary across browsers and UA versions, leading to unpredictable user experiences. | ||
- In quickly evolving markets like chat interfaces, a manual override is important—developers should be able to opt into the behavior when needed rather than rely solely on UA heuristics. | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any Stakeholder Feedback / Opposition content that should be added? Something that would list early feedback or known concerns?
- For `window.open()`, we propose introducing a new `windowFeatures` parameter called `addOpenerToHistory`. When this feature is specified, the browser will add the opener to the new tab's history. | ||
|
||
```javascript | ||
window.open("https://www.destination.com", "_blank", "addOpenerToHistory") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are these new windowFeatures only viable if target="_blank"?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It should only be viable for target="_blank". Added a comment
This PR introduces an explainer for Back to the Opener, a proposed feature to improve navigation when links open in new tabs.
It allows developers to opt-in (via
window.open()
or<a>
tag attributes) to have the opener tab added to the new tab's history. This enables a seamless "back" navigation to the opener, closing the new tab and reducing tab clutter, especially useful for search and chat interfaces.