Closed Bug 1562547 Opened 5 years ago Closed 5 years ago

In pinned tabs, cross-origin links with no target attribute open in a new tab instead of _self

Categories

(Firefox :: Tabbed Browser, defect)

69 Branch
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox67 --- affected
firefox68 --- affected
firefox69 --- affected

People

(Reporter: me, Unassigned)

References

Details

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:69.0) Gecko/20100101 Firefox/69.0

Steps to reproduce:

Open as a pinned tab a document with links to the same and different origins, with no target and with target _self. https://temp.chrismorgan.info/links-targets-and-pinned-tabs.html is an example I’ve crafted. Click the links and observe.

Actual results:

Same origin: the link opens in the same tab.

Different origin, no target: the link opens in a new tab.

Different origin, target=_self: the link opens in the same tab.

Expected results:

According to the HTML spec, all of the links should have opened in the same tab. (Chrome also opens them all in the same tab, from pinned tabs.)

Specifically, in the spec, start at https://html.spec.whatwg.org/#following-hyperlinks-2:

  1. Let targetAttributeValue be the empty string.
  1. If subject is an a or area element, then set targetAttributeValue to the result of getting an element's target given subject.

These steps leave targetAttributeValue as the empty string when there is no target attribute, and "_self" in the other case.

  1. Let target and replace be the result of applying the rules for choosing a browsing context given targetAttributeValue, source, and noopener.

Then in the rules for choosing a browsing context:

  1. If name is the empty string or an ASCII case-insensitive match for "_self", then set chosen to current.

Thus the spec declares that a missing target should yield the same result as target=_self, which is not what Firefox implements.

This inconsistency with what I believe developers will expect (I don’t care to comment on user expectations!) has led to at least minor user experience issues at Fastmail, with download links from the email client at fastmail.com to fastmailusercontent.com opening a new blank tab for the download, rather than starting the download in the same tab. Now that we know, we can add target=_self, but it doesn’t match what I believed to be implemented or what the spec does in fact say.

If it is decided that this deviation from spec and developer expectations is in fact worthwhile, and the behaviour desirable, I think this could reasonably be turned into a spec bug to allow leeway in the interpretation of an empty target.

I managed to reproduce the bug on the latest Firefox Nightly, Firefox 68 and on Firefox 67.0.4 but on Windows 10 x64.

Status: UNCONFIRMED → NEW
Component: Untriaged → Tabbed Browser
Ever confirmed: true

(In reply to Chris Morgan from comment #0)

If it is decided that this deviation from spec and developer expectations is in fact worthwhile, and the behaviour desirable, I think this could reasonably be turned into a spec bug to allow leeway in the interpretation of an empty target.

This is indeed intentional as per bug 575561. I filed https://github.com/whatwg/html/issues/4755.

Blocks: 575561
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.