style.loadURL prints an error when the request is aborted

[madoci]

maplibre-gl-js version: 4.5.0

browser: Chrome

Steps to Trigger Behavior

1. Create a map with a style URL
2. Use map.setStyle immediately after (to make sure the first style request is aborted)
3. An error log appears in the browser console

map.setStyle is one way to trigger this error, but other methods can too, as long as it calls style._remove.

Link to Demonstration

https://jsbin.com/garasukubu/edit?html,output

Expected Behavior

No error should be printed in the console.

Actual Behavior

A DOMException: signal is aborted without reason error is printed in the console.

[HarelM]

Can you check if this ever worked? I would try version 2.x and 3.x
In version 4 I have moved all callback hell to use abort controller and promises.
This might explain this error I guess, althought I'm not sure.

[HarelM]

Also note that you have not registered the map error event listener, so all errors are printed to the console.
Not that I'm sure if in this particular case there should or shouldn't be an error, but still...

[madoci]

It worked with version 3.6.2 for example (https://jsbin.com/retetelayo/edit?html,output). I believe the cancel() used before did not raise an error, but the AbortController.abort() does.

It's worth noting that the Style.loadJSON ignores the abort error (style.ts#L312) but the Style.loadURL doesn't. I would argue that this abort error should be ignored as well – just like aborted vector tile requests – as it is caused by the style being removed so there should be no side effects, but I might be wrong.

Regarding the map error event listener, in this case it doesn't catch this error (see https://jsbin.com/biciviqoto/edit?html,output), because eventedParent is set to null before catching the abort error (I believe it is set to null here but I'm not sure : style.ts#L1562). And even if we do catch it, we would not have access to the signal (and therefore to signal.aborted), so the only way to test if it's an abort error would be to check the DOMException name but I don't know how reliable it is to do it this way.

I would personally prefer if this abort error was completely ignored, but if not, I think we should ensure that the error can be caught by the map error event listener and that we can easily tell it's an abort error (for example, adding an aborted attribute to the ErrorEvent, or using a different event type like aborterror).

[HarelM]

Feel free to submit a PR.
I would recommend reproducing the behavior that existed in 3.6 - i.e. ignore this error.
Thanks for taking the time to report this issue!