de.serlo.org doesn't work on iOS

[serlo]

de.serlo.org doesn't work on iOS

[aeneasr]

could be caused by cloudflare

[aeneasr]

this is reproducible when using the ios simulator and the latest iphone

[aeneasr]

It looks like this was caused by webcomponents.js, which has been solve here: 17484c9

[nazar-pc]

CloudFlare passes window.location object to window.URL constructor while constructor accepts only strings, which is why https://github.com/webcomponents/webcomponentsjs/blob/c9bceeedb4077b5658d95f5755883592be92fcaf/src/URL/URL.js#L473 works very differently and causes this error, meaning redirect to another page instead of string replace.

CloudFlare already notified about this, hope they'll fix it soon.

[aeneasr]

Thanks for tracking this down!!

[terinjokes]

@nazar-pc this still doesn't make sense, just a few lines beforehand the base property is stringified and converted to a jURL instance.

https://github.com/webcomponents/webcomponentsjs/blob/c9bceeedb4077b5658d95f5755883592be92fcaf/src/URL/URL.js#L468

[nazar-pc]

@terinjokes, regexp works with url variable, base is not relevant there.

[terinjokes]

@nazar-pc I fixed this a while ago, but just came across this thread, I forgot what I was doing. Sorry, carry along. :)

---

The code that was failing on CloudFlare was a feature detection check to see if the URL constructor exists and works. It does this by passing in window.location (and now window.location.href) as the first parameter to the URL constructor, and checking the output.

If the URL constructor exists and works, then throughout the codebase, the URL constructor is passed two arguments, url and base, and I'm accustom to base often being window.location (now window.location.href).

For a moment after reading this thread, I thought the issue was in this latter case, rather than the former, thus the confusion.