Fix for Issue 8726 (Safari's usage of searchParams)

[ghost]

This commit addresses Issue #8726

Two fixes were required to satisfy Safari compatibility for searchParams().

1. The usage of replace() in the JURL's constructor resulted in undefined being returned from the url parameter that Safari passes. This is because Safari passes a non-String object to the JURL constructor when performing new URL(document.location).searchParams.get("x") - which lacks the replace() method. Thus when doing replace() on it, url would become undefined and result in redirecting the browser to the URL with the supplied regular expression (i.e http://localhost:8888/^[%20/t/r/n/f]+|[%20/t/r/n/f]+$/g).

The fix applied for this was to make url a String object if running on Safari browsers. This allows replace() to succeed as the method exists for the String object.

2. When the native URL object is replaced with the JURL object on the global scope, any future URL instances will result in a JURL instance. This backfires on Safari as it does not seem to fallback to the native URL object when it is unable to find a method within JURL (i.e searchParams). Other modern browsers (i.e FireFox, Chrome) seem to correctly fallback to the native URL object when attempting to look for a method not present on the JURL object.

The fix applied for this was to make a get searchParams function for the JURL object. It creates a URLSearchParams object with the appropriate search parameters and returns it to the caller.

[Snuffleupagus]

For reference: This part looks similar to PR #8727, which was closed based on #8727 (comment).
@yurydelendik What were the problems mentioned there?

---

Also, please see https://github.com/mozilla/pdf.js/wiki/Squashing-Commits.

[Snuffleupagus]

Also, given https://developer.mozilla.org/en-US/docs/Web/API/URLSearchParams/URLSearchParams#Browser_compatibility, I'm not sure how this helps in general given that it won't work in other browsers that rely on the URL polyfill (e.g. IE11).

[timvandermeij]

I'm going to close this pull request. The comment above indicate why this won't work in general. The polyfill must keep working for IE. The issue will remain open.