You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The URL constructor could be used as a replacement for parsing URLs using an HTMLAnchorElement now that IE support is going away.
However, there are a few difficult issues to solve since the codebase relies on invalid URL parsing by extended the intended meaning from the specification. In the case a URL resolves to a 'null' origin, AMP currently overrides the value with the following logic.
// For data URI anchorEl.origin is equal to the string 'null' which is not useful.
// We instead return the actual origin which is the full URL.
let origin;
if (anchorEl.origin && anchorEl.origin != 'null') {
origin = anchorEl.origin;
} else if (info.protocol == 'data:' || !info.host) {
origin = info.href;
} else {
origin = info.protocol + '//' + info.host;
}
info.origin = origin;
This change means for instance, data:12345 returns a value for the origin, even though this Location is invalid.
I made a series of changes to switch over to using the URL constructor as part of the initial PRs for IE Deprecation here.
Since the number of changes dedicated to URL construction and usage was greater than all other changes in the PR, this issue tracks the desire to attempt this change again in the future.
Alternatives Considered
The project could choose to only use URL constructors in the module form of the libraries. However, this means the module form would potentially use the 'null' key for uniqueness across origins in scenarios and unintentionally might use the same instance of a Service across two iframes (about:srcdoc returns a 'null' origin when using URL constructors).
Additional Context
Additionally it might be worth considering a change to the types and methods used in URLs across the project. Right now, many methods accepts {string|Location} and coerce the value into a Location multiple times in a single frame of JS time.
Moving to an interface where only Locations are used by helpers could eliminate duplicative parsing per JS frame.
The text was updated successfully, but these errors were encountered:
kristoferbaxter
changed the title
Move JS from Url Parsing via Anchor Elements to URL Constructor
Move JS from url Parsing via HTMLAnchorElements to URL Constructor
Aug 2, 2021
We could provide a temporary helper that clones the URL object and fixes the origin? We don't currently mutate the return value from the parse* methods.
We might consider instead moving to use the specified URL object, and change the other systems to expect origin to be an invalid value (and use something else instead).
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
Description
The URL constructor could be used as a replacement for parsing URLs using an
HTMLAnchorElement
now that IE support is going away.However, there are a few difficult issues to solve since the codebase relies on invalid URL parsing by extended the intended meaning from the specification. In the case a URL resolves to a
'null'
origin, AMP currently overrides the value with the following logic.This change means for instance,
data:12345
returns a value for the origin, even though this Location is invalid.I made a series of changes to switch over to using the URL constructor as part of the initial PRs for IE Deprecation here.
Since the number of changes dedicated to URL construction and usage was greater than all other changes in the PR, this issue tracks the desire to attempt this change again in the future.
Alternatives Considered
The project could choose to only use URL constructors in the
module
form of the libraries. However, this means the module form would potentially use the'null'
key for uniqueness across origins in scenarios and unintentionally might use the same instance of a Service across two iframes (about:srcdoc returns a 'null' origin when using URL constructors).Additional Context
Additionally it might be worth considering a change to the types and methods used in URLs across the project. Right now, many methods accepts
{string|Location}
and coerce the value into aLocation
multiple times in a single frame of JS time.Moving to an interface where only
Locations
are used by helpers could eliminate duplicative parsing per JS frame.The text was updated successfully, but these errors were encountered: