Fix Microsoft/TypeScript#19277

[Kingwl]

1. remove readonly
2. type to Location | string

Fix microsoft/TypeScript#19277

[saschanaz]

While the setter allows string the getter always returns Location not string. I think forcing location.href is reasonable enough.

[Kingwl]

@saschanaz

1. 'get' and 'set' accessor must have the same type
2. but that is strange

[saschanaz]

'get' and 'set' accessor must have the same type

In TypeScript. Not in raw JavaScript world, sadly.

[mhegazy]

i am not sure this is the right fix here... we may need to make this any instead..

we have favored reading over writing before, favoring writing over reading seems to just change the problem instead of fixing it.. seems like any is the only "fix" for both cases..

[amoshydra]

Wanted to highlight that this PR is reverted in this commit 9e88bfd

As of today [email protected] it is not possible to assign type string to Location

window.location = '/'

Error:

Type 'string' is not assignable to type 'Location'.ts(2322)

[saschanaz]

Is there any reason to not use window.location.href?

[amoshydra]

Is there any reason to not use window.location.href?

Apparently yes. There seems to be some differences between setting location.href vs location.

Quoting

I note that in browsers today, setting window.location = "some string" has special behaviour, see here: stackoverflow.com/questions/2383401/… - see the comments regarding same-site, same-origin and XHR behaviour. – Dai Dec 16 '19 at 5:54

Was trying to create an issue about this in this repo, however, I am not able to setup an environment to proof those differences mention in the discussion.

[saschanaz]

Have you seen that behavior yourself? The mentioned web page doesn't say the href setter will throw (only the getter will), and AFAIK setting window.location simply forwards its value to window.location.href. (See PutForwards=href in the IDL.)

[amoshydra]

@saschanaz I now understood what you meant by "doesn't say the href setter will throw". I wasn't reading the mentioned web page in detail earlier.

Upon testing, it is possible to redirect an iframe by setting both location and location.href in context where same-origin policy is enforced.

I have tested this behaviour in different browsers.

Chrome 79 Firefox 68.3 IE 11 (Also emulated IE 5, 7, 8, 9, 10) Edge 44.18362,449 (it crashed for both case, seems to be a separate bug with Edge itself) Test: https://codepen.io/amoshydra/full/YzPeyYb All browsers are able to redirect an iframe of different origin by setting its location.href

It seems like all those claims about the special behaviour of setting location made are invalid / unfounded.

---

I agree with you. Right now I see no reason to not use window.location.href