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

<a> and <area> popup blocker exception is broken #2616

Closed
annevk opened this issue May 3, 2017 · 2 comments
Closed

<a> and <area> popup blocker exception is broken #2616

annevk opened this issue May 3, 2017 · 2 comments
Labels
topic: hyperlink

Comments

@annevk
Copy link
Member

annevk commented May 3, 2017

Both <a> and <area> have this copypasta:

If the user has not indicated a specific browsing context for following the link, and the element's target attribute is present, and applying the rules for choosing a browsing context given a browsing context name, using the value of the target attribute as the browsing context name, would result in there not being a chosen browsing context, then:

  1. If there is an entry settings object, throw an "InvalidAccessError" DOMException.
  2. Abort these steps without following the hyperlink.

This however doesn't consider target attributes on the base element and it also ends up duplicating text from "following hyperlinks".

I think it should be deduplicated with "following hyperlinks" (and we should maybe be more clearer about where that exception ends up) though I need to test what actually happens and also test what happens for "download the hyperlink" since that doesn't concern itself with browsing contexts at all. It's unclear if that should just ignore the target attribute (normative change) or still have this kind of check first, but also accounting for base elements.
@annevk annevk mentioned this issue May 3, 2017
Open
@annevk
Copy link
Member Author

annevk commented May 3, 2017

http://software.hixie.ch/utilities/js/live-dom-viewer/saved/5120 shows that this doesn't end up throwing an exception at all so that requirement seems wrong as well.

@annevk
Copy link
Member Author

annevk commented May 3, 2017

When I add a download attribute Chrome downloads and Firefox shows a download dialog. Safari doesn't do anything different. So it seems like you would branch first on the download attribute and then if there's no such attribute maybe return (no exception) if the targeting hits the popup blocker.

That should further simplify the algorithms we have today.

annevk added a commit 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.
This was referenced May 3, 2017
Merged
Closed
@annevk annevk closed this as completed in 5578a04 May 9, 2017
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.
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
topic: hyperlink
Milestone
No milestone
Development

No branches or pull requests
1 participant
@annevk