Per the HTML spec, browsers should ignore target names that don't start with an alphabetic character and aren't one of the reserved identifiers. <http://www.w3.org/TR/html4/types.html#type-frame-target> Mozilla isn't doing this.

Bulk reassigning Eric Pollmann's remaining form submission bugs to Alex.

->Frames

I suspect that this is here for a reason. Is there any compelling <B>technical</B> reason to deny these anchors from working?

As I understand it, Mozilla aspires to HTML 4 conformance. If there is a reason that non-reserved target names starting with "_" *should* be allowed, that behavior should be reserved for quirks mode.

OK, I'll give you that. But so far I think the spec sounds pretty arbitrary in this regard. I'm very curious whether there is any user- or developer-level justification for this restriction.

The "developer-level" justification is future-proofing: effectively reserving all identifiers that start with "_" means that identifiers in this namespace can be given special meaning without impacting existing pages. However, I'll grant that the obsolescence of frames and resulting improbability that they will be extended make this argument pretty theoretical.

*** Bug 202167 has been marked as a duplicate of this bug. ***

>Is there any compelling <B>technical</B> reason to deny these anchors from working? _new might be one for backward compatibility... although even here I'm all for removing support for _new. You can expect that some people will complain if support for _new is suddenly removed. It was first introduced in NS 4 because _new was more intuitive, self-explanatory than _blank. Mozilla still supports _new; see line 1406 at this url (url broken to avoid horizontal scrolling): http://lxr.mozilla.org/seamonkey/source/embedding/components/windowwatcher/﷒0﷓ Note that Composer only offers _blank and does not offer _new in its drop down list of choices for target. _content is one for sure. Internally, Mozilla supports _content so that scripts can access the sidebar content. http://www.mozilla.org/docs/dom/domref/dom_window_ref3.html#1016797

The current [admittedly DRAFT] HTML 4 test suite at the W3C http://www.w3.org/MarkUp/Test/HTML401/current/tests/6_16-BF-01.html (that page is loaded into http://www.w3.org/MarkUp/Test/HTML401/current/tests/sec6_16-BF-01.html ) clearly indicates that Mozilla also fails at ignoring target name starting with a digit. E.g.: Load the W3C HTML 4 test suite, then click on the link <a href="6_16-BF-01f.html" target="4four">this link</a> in the bottom-left-lime-colored frame (...c.html). Despite the fact that a frame was named "4four", the link should load into the same frame, not into the bottom-right-pink-colored frame (...d.html)

I completely agree with the W3C's recommendation but it was five years tardy. Names beginning with underscores other than the reserved ones are in use in the wild. Implementing this recommendation would "break" those sites. ("Break" in quotes because the consequences of ignoring a frame name generally don't lead to a serious malfunction.) I've happened to have noticed a few examples. One is www.scriptsearch.html, which uses the not uncommon "_new" target. I believe the malfunction at this site caused by implementing the W3C's recommendation would be limited to opening advertising in the same window rather than a new one, which seems quite benign. A second example I've run across is HSBC's, a bank in the UK. Its login process (at http://www.ukpersonal.hsbc.co.uk/public/ukpersonal/internet_banking/en/logon.jhtml) involves submitting a form targeted to a window named "_pib", for whatever reason. When you log in to this bank the main window is supposed to remain at the login screen, which contains other useful links as well. A secondary window should open to handle the details of your account. If we were to implement the W3C recommendation, Mozilla would handle this bank's login quite incorrectly. We've considered disallowing non-reserved names beginning with an underscore more than once, and always decided not to. It would have been nice had that namespace been reserved. Following the W3C spec now will cause problems perceived to be a bug in Mozilla, and it's not to be done lightly. I'm changing this bug's summary to reflect its questionable status.

*** Bug 248396 has been marked as a duplicate of this bug. ***

Whiteboard [WONTFIX?]

A WONTFIX seems good to me... 5 years later...

HTML5 requires supporting all target values, even ones that don't start with a-zA-Z. Marking invalid.