Return XMLHttpRequest in PLYLoader

[JohnKis]

Description

In a similar fashion to PR 6649, return the XMLHttpRequest on the PLYLoader's load method.

[Mugen87]

STLLoader does not return the XMLHttpRequest object. The mentioned PR was reverted with 70e4206.

I do not vote to just change a single loader. If anything, all loaders should be changed. However, I believe this won't work with loaders which use fetch. Besides, loaders like GLTFLoader which load resources like buffers also produce multiple XMLHttpRequest objects. So how should this use case be handled?

The benefits of this change are not clear to me. Do you mind explain in more detail why you need the raw XMLHttpRequest object? Do you only need it for abort operations?

[JohnKis]

Sorry, I wasn't aware that it was reverted.

The use case is being able to cancel an ongoing request. In the app where I'm using three.js users can navigate between multiple items (each having a 3D model). If they navigate while the model is loading they'll end up with a lot of ongoing requests (downloading large files) that should be canceled.

I agree that it would be better to have a uniform solution for all loaders however unfortunately I don't have the time or resources to contribute to that. I made the same change locally and I thought I'd raise a PR in case it's useful for others.

[Mugen87]

Notice that FileLoader does not always return an instance of XMLHttpRequest: #10712

[JohnKis]

Fair point, I wasn't aware of that either.

I'm happy to close the PR and use my local version of PLY loader, however I still think that having a built-in way to abort HTTP requests would be beneficial to many users.

[Mugen87]

however I still think that having a built-in way to abort HTTP requests would be beneficial to many user.

This is a fair feature request. We've talked about this in the past multiple times but I'm not aware of a respective issue.

Another related PR: #9600

[JohnKis]

I shall close this then and open a feature request just so it's tracked.