RDKEMW-22317 : Integrate VIPA widget 1.4.4.5 with nativescript

[gurpreet319]

Reason for change: Integrate VIPA 1.4.4.5 with nativescript, updated the xhr and URLSearchParams.
Test Procedure: build should be successful
Risk: low
Priority: P2

[Copilot]

Pull request overview

This PR updates the JS runtime networking utilities to support integrating VIPA widget v1.4.4.5 with NativeScript, focusing on improving XMLHttpRequest behavior and expanding URLSearchParams compatibility.

Changes:

• Refactors XMLHttpRequest.open()/send() to reset internal state more safely, parse URLs via the WHATWG URL API, and harden request/redirect handling.
• Updates auth header creation to use Buffer.from and improves event dispatching to pass an event object to handlers/listeners.
• Extends URLSearchParams construction to accept additional init shapes and adds iteration APIs (forEach, entries, keys, values).

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
utils/xhr.js	XHR state reset, URL parsing + request option construction, redirect handling, transport validation, and event dispatch behavior updates.
src/jsc/modules/lib/URLSearchParams.js	Broader constructor input support and added iteration/utility methods (forEach/entries/keys/values).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[rdkcmf-jenkins]

b'## Blackduck scan failure details

Summary: 0 violations, 0 files pending approval, 1 file pending identification.

• Protex Server Path: /home/blackduck/github/rdkNativeScript/138/rdkcentral/rdkNativeScript

• Commit: 52de8a5

Report detail: gist'

[rdkcmf-jenkins]

b'## Blackduck scan failure details

Summary: 0 violations, 0 files pending approval, 1 file pending identification.

• Protex Server Path: /home/blackduck/github/rdkNativeScript/138/rdkcentral/rdkNativeScript

• Commit: 52de8a5

Report detail: gist'

[rdkcmf-jenkins]

b'## WARNING: A Blackduck scan failure has been waived

A prior failure has been upvoted

• Upvote reason: OK - existing id was lost

• Commit: 52de8a5
  '

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (2)

utils/xhr.js:405

• Redirect handling reuses the original request headers and always ends the redirected request without re-sending the original body. This can produce incorrect redirects for non-GET requests (e.g., POST redirects sending Content-Length/Content-Type but no body), and 303 redirects should also switch the stored method to GET for any subsequent redirects.

            var redirectOptions = {
              hostname: redirectUrl.hostname,
              host: redirectUrl.hostname,
              port: redirectPort,
              path: redirectUrl.pathname + (redirectUrl.search || ""),
              protocol: redirectSsl ? "https:" : "http:",
              ssl: redirectSsl,
              method: response.statusCode === 303 ? "GET" : settings.method,
              headers: headers,
              withCredentials: self.withCredentials
            };

src/jsc/modules/lib/URLSearchParams.js:171

• entries() currently returns the internal _list iterator, which exposes the backing tuple arrays to callers. That allows external mutation of tuples without triggering _updateSteps() and can desync URLSearchParams from its associated URL. Consider returning an iterator that yields copied [name, value] arrays instead.

  entries() {
    return this._list[Symbol.iterator]();
  }

[gurpreet319]

Hi @mhughesacn, can you please review it

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (3)

src/jsc/modules/lib/URLSearchParams.js:211

• Symbol.iterator currently returns the internal _list iterator. Delegating to entries() keeps iteration semantics consistent across APIs and avoids exposing internal pair arrays.

  [Symbol.iterator]() {
    return this._list[Symbol.iterator]();
  }

utils/xhr.js:11

• The header removed the original MIT license/attribution lines. Since this file is derived from third-party MIT-licensed code, the attribution/license notice should be retained for compliance.

 * Usage: include("XMLHttpRequest.js") and use XMLHttpRequest per W3C specs.
 * Original code by DeFelippi.
 * Some modifications by Comcast.
 *
 */

src/jsc/modules/lib/URLSearchParams.js:171

• entries() currently returns the internal _list array iterator, which exposes the mutable internal pair arrays to callers (mutating an iterated pair would mutate URLSearchParams state). Returning an iterator that yields copied [name, value] pairs better matches platform behavior and avoids unexpected side effects.

This issue also appears on line 209 of the same file.

  entries() {
    return this._list[Symbol.iterator]();
  }

[mhughesacn]

Hi @gurpreet319 : Blackduck is now happy with the identifications in the tool and scans clean but the original credit was better (original authors emails). See comment below.
The fossid findings are valid too, but the original code is properly credited in NOTICE so nothing else to do and fossid findings here cannot be cleared, so you can just ignore.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.

Suppressed comments (2)

utils/xhr.js:461

• request.on("error", ...) is called unconditionally, but the code only checks request.on later for the abort handler. If the transport returns a request object without an .on method, this will throw and bypass handleError. Guard both listener registrations consistently.

      request.on("error", errorHandler);
      if (typeof request.on === "function") {
        request.on("abort", function() {
          self.handleError(new Error("XMLHttpRequest: request aborted by transport"));
        });
      }

utils/xhr.js:407

• Redirect handling chains .on("error", ...) directly off redirectTransport.request(...). If request() returns a request object without .on, this will throw inside the redirect path. Create the request first, then conditionally attach the error handler (similar to the main request path).

            request = redirectTransport.request(redirectOptions, responseHandler).on("error", errorHandler);
            request.end();