Skip to content

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

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

victorhuangwq
Copy link

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.

@victorhuangwq victorhuangwq marked this pull request as ready for review June 10, 2025 18:19
@victorhuangwq
Copy link
Author

@aluhrs13 and @erik-anderson could you help take a look at the explainer?
I'm hoping to merge this in and use it to reach out to potential partners for feedback.


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.
Copy link
Collaborator

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.

Copy link
Member

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/)
Copy link
Member

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.

Copy link
Author

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


## 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.
Copy link
Member

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.

Copy link
Member

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.

Copy link
Member

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")
Copy link
Member

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"?

Copy link
Author

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants