Bitstream downloads fail when script blockers are active on sites with Matomo integration

[bauermeisterdifu]

Describe the bug

When using a script blocker extension like uBlock Origin in Firefox, bitstream downloads do not work on DSpace sites with enabled Matomo integration. Instead of initiating the file download, the page eventually runs into a timeout.
Disabling the script blocker or whitelisting the DSpace domain resolves the issue and downloads work as expected.

To Reproduce

Steps to reproduce the behavior:

1. Setup Matomo Tracking for the Dspace Site
2. Install uBlock Origin (or similar script blocker) in Firefox
3. Navigate to an item with a bitstream
4. Click the download link

Ecpected behavior

The bitstream download should complete successfully, even if the Matomo tracking request is blocked.

Question

Is this behavior intentional, perhaps due to how the download mechanism is implemented? I'm raising this because some users may have script blockers enabled by default and might not immediately realize they need to whitelist the DSpace site to download files.
Ideally, the download should not depend on the Matomo tracking URL being reachable – the tracking could either fail silently or be handled asynchronously without blocking the actual file transfer. I am wondering whether this could be a deliberate design choice?

[tdonohue]

This sounds like a possible bug to me, so I'm pulling this over to the maintenance board in search of a volunteer. I don't believe this is a design choice, but I'm not as familiar with this area of the code...so, if a volunteer finds it's purposeful behavior then we can minimally document this better.

[pzlakowski]

I will attempt to try fix it.

[pzlakowski]

The issue happens here:

src/app/statistics/matomo.service.ts

/**
 * Appends the Matomo visitor ID to the given URL.
 * @param url - The original URL to which the visitor ID will be added.
 * @returns An Observable that emits the URL with the visitor ID appended.
 */
appendVisitorId(url: string): Observable<string> {
  return fromPromise(this.matomoTracker?.getVisitorId())
    .pipe(
      map(visitorId => this.appendTrackerId(url, visitorId)),
      take(1),
    );
}

When we call this.matomoTracker?.getVisitorId() we have no ability to fallback to passed url. Ublock origin blocks matomo script to be loaded. When we execute this function, we queue to Matomo instance to handle task for us but it will never be processed.

Dirty solution would be to use rxjs operator timeout for X time and then fallback to original download link. Unfortunately ngx-matomo-client library does not have any observable event which would show that script cannot be loaded. We should check whenever scripts get loaded but other than timeout would be desireable as guard anyway.

I will try to think about the other solution but expect the dirty one I do not have anything in mind yet.