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.

Sign up for GitHub

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

Jump to bottom

Add ability to test with popup blocker enabled #3867

Open
zcorpan opened this issue Oct 4, 2016 · 10 comments
Open

Add ability to test with popup blocker enabled #3867

zcorpan opened this issue Oct 4, 2016 · 10 comments
Labels
infra priority:backlog type:missing-coverage type:untestable

Comments

@zcorpan
Copy link
Member

zcorpan commented Oct 4, 2016

See whatwg/html#1854

It would be good to be able to somehow test the behavior of window.open with the popup blocker enabled (not just for the return value, but also to test when the popup is being blocked, for cases that don't need to be manual).
@zcorpan zcorpan mentioned this issue Oct 4, 2016
Merged
@cvrebert cvrebert added the infra label Oct 8, 2016
@zcorpan zcorpan mentioned this issue Dec 7, 2016
Open
@annevk
Copy link
Member

annevk commented May 3, 2017

This is also a problem for whatwg/html#2616.

cc @jugglinmike

annevk added a commit to whatwg/html that referenced this issue May 3, 2017
@annevk
Revamp the rules for choosing a browsing context
c5b0508 
This makes several changes:

* Stop throwing an exception in <a> and <area> activation behavior as a
result of popup blocking as it doesn’t match implementations. Fixes
#2616. Formal testing is not possible and tracked by
web-platform-tests/wpt#3867.
* Make matching for special names ASCII case-insensitive. Fixes #2443.
* Centralize all user-configurable behavior instead of having it
duplicated in various ways in all the caller algorithms.
* Call out a known issue with browsing context name matching: #2126.

It also modernizes the writing style and makes variables and what is
returned much more explicit, including no longer relying on some
out-of-band channel for communicating whether a new browsing context
got created.
@annevk annevk mentioned this issue May 3, 2017
Merged
annevk added a commit to whatwg/html that referenced this issue May 3, 2017
@annevk
Revamp the rules for choosing a browsing context
58aaf16 
This makes several changes:

* Stop throwing an exception in <a> and <area> activation behavior as a
result of popup blocking as it doesn’t match implementations. Fixes
web-platform-tests/wpt#3867.
* Make matching for special names ASCII case-insensitive. Fixes #2443.
* Centralize all user-configurable behavior instead of having it
duplicated in various ways in all the caller algorithms.
* Call out a known issue with browsing context name matching: #2126.

It also modernizes the writing style and makes variables and what is
returned much more explicit, including no longer relying on some
out-of-band channel for communicating whether a new browsing context
got created.
annevk added a commit to whatwg/html that referenced this issue May 8, 2017
@annevk
Revamp the rules for choosing a browsing context
0bdbb7c 
This makes several changes:

* Stop throwing an exception in <a> and <area> activation behavior as a
result of popup blocking as it doesn’t match implementations. Fixes
web-platform-tests/wpt#3867.
* Make matching for special names ASCII case-insensitive. Fixes #2443.
* Centralize all user-configurable behavior instead of having it
duplicated in various ways in all the caller algorithms.
* Call out a known issue with browsing context name matching: #2126.

It also modernizes the writing style and makes variables and what is
returned much more explicit, including no longer relying on some
out-of-band channel for communicating whether a new browsing context
got created.
annevk added a commit to whatwg/html that referenced this issue May 9, 2017
@annevk
Revamp the rules for choosing a browsing context
5578a04 
This makes several changes:

* Stop throwing an exception in `<a>` and `<area>` activation behavior as a
  result of popup blocking as it doesn’t match implementations. Fixes #2616. 
  Formal testing is not possible and tracked by
  web-platform-tests/wpt#3867.
* Make matching for special names ASCII case-insensitive. Fixes #2443.
* Centralize all user-configurable behavior instead of having it
  duplicated in various ways in all the caller algorithms.
* Call out a known issue with browsing context name matching: #1440.

It also modernizes the writing style and makes variables and what is
returned much more explicit, including no longer relying on some
out-of-band channel for communicating whether a new browsing context
got created.
inikulin pushed a commit to HTMLParseErrorWG/html that referenced this issue May 9, 2017
@annevk @inikulin
Revamp the rules for choosing a browsing context
1ef5cce 
This makes several changes:

* Stop throwing an exception in `<a>` and `<area>` activation behavior as a
  result of popup blocking as it doesn’t match implementations. Fixes whatwg#2616. 
  Formal testing is not possible and tracked by
  web-platform-tests/wpt#3867.
* Make matching for special names ASCII case-insensitive. Fixes whatwg#2443.
* Centralize all user-configurable behavior instead of having it
  duplicated in various ways in all the caller algorithms.
* Call out a known issue with browsing context name matching: whatwg#1440.

It also modernizes the writing style and makes variables and what is
returned much more explicit, including no longer relying on some
out-of-band channel for communicating whether a new browsing context
got created.
inikulin pushed a commit to HTMLParseErrorWG/html that referenced this issue May 9, 2017
@annevk @inikulin
Revamp the rules for choosing a browsing context
aa6c8c7 
This makes several changes:

* Stop throwing an exception in `<a>` and `<area>` activation behavior as a
  result of popup blocking as it doesn’t match implementations. Fixes whatwg#2616. 
  Formal testing is not possible and tracked by
  web-platform-tests/wpt#3867.
* Make matching for special names ASCII case-insensitive. Fixes whatwg#2443.
* Centralize all user-configurable behavior instead of having it
  duplicated in various ways in all the caller algorithms.
* Call out a known issue with browsing context name matching: whatwg#1440.

It also modernizes the writing style and makes variables and what is
returned much more explicit, including no longer relying on some
out-of-band channel for communicating whether a new browsing context
got created.
@foolip
Copy link
Member

foolip commented Oct 4, 2017

I'm labeling this as backlog (the lowest priority) because it seems like this will not affect any whole features, but rather a handful of cases spread around the platform. @JKereliuk, this might require some WebDriver APIs. If you're tracking feature requests somewhere, can you add this there?

@kereliuk
Copy link
Contributor

kereliuk commented Oct 4, 2017

@foolip +1 :)

@kereliuk
Copy link
Contributor

Are there any existing manual tests that need this?

@annevk
Copy link
Member

annevk commented Nov 21, 2017

There's examples linked in the issues above that could easily be turned into tests.

@foolip
Copy link
Member

foolip commented Jan 11, 2018

@jstenback ran into this with https://wpt.fyi/html/browsers/the-window-object/apis-for-creating-and-navigating-browsing-contexts-by-name/open-features-non-integer-width.html, which fails on Edge and Safari because of the popup blocker, at least it seems like that in my manual testing.

@kereliuk, do you know if ChromeDriver implicitly disables the popup blocker, or why this passes in Chrome?

@annevk
Copy link
Member

annevk commented Jan 11, 2018

You need to disable the popup blocker to use web-platform-tests. That's why this issue is asking for the opposite.

@mustaqahmed
Copy link
Member

This is blocking tests for User Activation v2 consumption behavior: disabled popup blocker means activation consumption is invisible to the page.

@foolip
Copy link
Member

foolip commented Aug 8, 2018

Thanks for reporting @mustaqahmed. Multiple teams are now using https://web-platform-tests.org/writing-tests/testdriver-tutorial.html to add their own testing APIs end-to-end, with help from @kereliuk. As you're implementing User Activation v2, is this an issue you'd consider owning? I believe the WebDriver extension API, if that makes sense, would have to go in either HTML or a standalone extension spec.

How are you testing this internally, in LayoutTests? Is there an internals.something() API that you use?

alice pushed a commit to alice/html that referenced this issue Jan 8, 2019
@annevk
Revamp the rules for choosing a browsing context
ae8d59f 
This makes several changes:

* Stop throwing an exception in `<a>` and `<area>` activation behavior as a
  result of popup blocking as it doesn’t match implementations. Fixes whatwg#2616. 
  Formal testing is not possible and tracked by
  web-platform-tests/wpt#3867.
* Make matching for special names ASCII case-insensitive. Fixes whatwg#2443.
* Centralize all user-configurable behavior instead of having it
  duplicated in various ways in all the caller algorithms.
* Call out a known issue with browsing context name matching: whatwg#1440.

It also modernizes the writing style and makes variables and what is
returned much more explicit, including no longer relying on some
out-of-band channel for communicating whether a new browsing context
got created.
@davidben davidben mentioned this issue Sep 18, 2023
Closed
@zcorpan
Copy link
Member Author

zcorpan commented Aug 5, 2024

This is also a problem for full test coverage for whatwg/html#10547

@domenic domenic mentioned this issue Nov 15, 2024
Merged
5 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
infra priority:backlog type:missing-coverage type:untestable
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
6 participants
@zcorpan @cvrebert @foolip @annevk @mustaqahmed @kereliuk