v153 · navigation · feature removal
Which frame actually moved
Blink treated target="_current" as a fifth keyword meaning "this frame", and no other engine did. The removal makes it an ordinary name again. One experiment separates the two behaviours: put a frame that is genuinely named _current next to the frame doing the linking, click, and see which one ends up somewhere new.
Run it
The harness below holds three frames: one named _current, one named sidecar, and a source frame with real links in it. Nothing is simulated — the button clicks the link and the browser decides where the navigation lands.
Where each frame is
Read straight out of the live frame tree after the click, by same-origin DOM access. The moved row is the one the navigation chose.
| frame | name | document title | moved? |
|---|---|---|---|
| Run the experiment. | |||
what the two outcomes mean
The source frame is the one that contains the link. The frame named _current is a sibling of it.
| frame that moved | what the browser did | Chrome |
|---|---|---|
| source | _current was treated as a keyword meaning "this frame" — the same as _self — and the sibling that is actually named _current was ignored. | before the removal |
| named _current | _current was looked up as an ordinary frame name, found the sibling, and navigated it. This is what the HTML standard has always specified for any name that is not one of the four keywords. | after the removal |
The control button targets sidecar, a name with nothing special about it in any engine. It navigates the frame named sidecar in both versions of Chrome, which is what makes the _current result a difference in kind rather than a broken harness.
the markup under test
<!-- harness -->
<iframe name="_current" src="nav-frame.html?label=NAMED%20_current"></iframe>
<iframe name="sidecar" src="nav-frame.html?label=NAMED%20sidecar"></iframe>
<iframe id="source" src="nav-source.html"></iframe>
<!-- inside the source frame -->
<a href="nav-frame.html?label=LANDED" target="_current">target="_current"</a>