Skip to content
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

Form with target=_blank and opener relationship #7256

Closed
cdumez opened this issue Oct 22, 2021 · 6 comments
Closed

Form with target=_blank and opener relationship #7256

cdumez opened this issue Oct 22, 2021 · 6 comments

Comments

@cdumez
Copy link

cdumez commented Oct 22, 2021

I was investigating the following WPT test:
html/semantics/forms/form-submission-target/rel-input-target.html

In particular, the first subtest uses <form rel=""> and a button that looks like <input type=submit formtarget=_blank>.

I would have expected the new window to NOT have an opener since target is _blank and rel does not include opener.
However, the test seems the expect an opener here. Is this a bug in the test or am I misunderstanding the specification?

The relevant specification text seems to be:

which is called from:

@cdumez
Copy link
Author

cdumez commented Oct 22, 2021

cc @annevk @domenic

@cdumez
Copy link
Author

cdumez commented Oct 22, 2021

Similarly, the following tests use a

with target="_blank" and do not have rel="opener", yet they expect the popup to have an opener:

  • content-security-policy/form-action/form-action-self-allowed-target-blank.html
  • content-security-policy/form-action/form-action-src-allowed-target-blank.sub.html
  • content-security-policy/form-action/form-action-src-redirect-allowed-target-blank.sub.html

Kaiido added a commit to Kaiido/html that referenced this issue Oct 25, 2021
Spotted while reading whatwg#7256
`targetAttributeValue` was never defined in this algorithm.
@annevk
Copy link
Member

annevk commented Oct 25, 2021

I suspect the problem is that this hasn't been implemented yet.

Firefox still has https://bugzilla.mozilla.org/show_bug.cgi?id=1509346.

That pointed to web-platform-tests/wpt#15356 for tests I wrote so I suspect we're in an inconsistent state on WPT.

@Kaiido
Copy link
Member

Kaiido commented Oct 25, 2021

Note that there seems to be a typo in https://html.spec.whatwg.org/multipage/form-control-infrastructure.html#form-submission-algorithm:get-an-element's-noopener targetAttributeValue is undefined, I guess this should read target.

@annevk
Copy link
Member

annevk commented Oct 25, 2021

Created web-platform-tests/wpt#31368 and #7258 to address these. Review appreciated.

annevk added a commit that referenced this issue Oct 25, 2021
annevk added a commit to web-platform-tests/wpt that referenced this issue Oct 25, 2021
@annevk annevk closed this as completed Oct 25, 2021
@cdumez
Copy link
Author

cdumez commented Oct 25, 2021

Thank you for updating the tests. I am updating WebKit's behavior accordingly via https://bugs.webkit.org/show_bug.cgi?id=232243.

moz-v2v-gh pushed a commit to mozilla/gecko-dev that referenced this issue Oct 29, 2021
…oopener defaulting, a=testonly

Automatic update from web-platform-tests
Correct <form target=_blank> tests for noopener defaulting

See whatwg/html#7256 for context.

--

wpt-commits: 2c3823e4038375bc18b17eece9cdbae0a270147a
wpt-pr: 31368
jamienicol pushed a commit to jamienicol/gecko that referenced this issue Nov 1, 2021
…oopener defaulting, a=testonly

Automatic update from web-platform-tests
Correct <form target=_blank> tests for noopener defaulting

See whatwg/html#7256 for context.

--

wpt-commits: 2c3823e4038375bc18b17eece9cdbae0a270147a
wpt-pr: 31368
Gabisampaio pushed a commit to Gabisampaio/wpt that referenced this issue Nov 18, 2021
dandclark pushed a commit to dandclark/html that referenced this issue Dec 4, 2021
mfreed7 pushed a commit to mfreed7/html that referenced this issue Jun 3, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants