Use actual page URL instead of hardcoding the query string in unlock URL

We are taking up this issue in DrupalCampPune2024

Rebased to latest 2.0.x and It's ready for review.

I don't think this actually solves the problem. Here's why.

If the err.unlock_url property looks like this: /admin/modules/browse/unlock, then the current code will generate this: /admin/modules/browse/unlock&destination=my+current+url. That's an invalid URL which will lead to a 404 or worse.

What we need here is:

• If the unlock URL looks something like /admin/modules/browse/unlock?some_param=foo, then the generated URL has to look like: /admin/modules/browse/unlock?some_param=foo&destination=my+current+url. This, to be fair, is what the code in HEAD already does.
• But if the unlock URL doesn't have a query string, then we need to append it, prefixed by a question mark.

Looks fine to me!

We have native JS API's for this now, so we don't need to do our own string concat. I think something like this would make the code more readable. (Bear in mind this is GPT-generated and untested, but point being we should use URL - https://developer.mozilla.org/en-US/docs/Web/API/URL )

// Get the current page URL as a URL object for easier manipulation
const currentUrl = new URL(window.location.href);

if (err.unlock_url) {
  const unlockUrl = new URL(err.unlock_url);

  // Append the 'destination' parameter to unlockUrl
  unlockUrl.searchParams.set('destination', currentUrl.toString());

  // Update the HTML content
  div.innerHTML += `<p>${errorMessage} <a href="${unlockUrl.toString()}">${Drupal.t(
    'Unlock Install Stage'
  )}</a></p>`;
} else {
  div.innerHTML += `<p>${errorMessage}</p>`;
}

It is ready for a review.

Found something that is suspicious at best, wrong at worst, and probably needs test coverage. But I may be wrong. If I am, great - let's just add a comment to clarify and it's full steam ahead.

Reviewed. I'm still not sure we are doing this correctly, which is why I think adding some functional JS test coverage is a good idea.

@phenaproxima I added functional js tests as you suggested and i think those are taking care of sub directory issue that you were mentioning in this as tests were initially failing here because of the sub directory path was appended correctly in the code but we were not taking that into account for tests.
Marking it NR again.

Resolved all the open threads and addressed feedbacks as well.Marking it NR again.