fix: revoke Blob URLs created by p5.File

[slash-init]

Resolves #9134

Changes:

• Track media p5.File objects with Blob URLs on their owning p5 instance.
• Automatically revoke tracked Blob URLs through the remove lifecycle hook.
• Add p5.File.revoke() for explicitly releasing a file’s Blob URL.
• Make p5.File.revoke() idempotent.
• Track media files from both createFileInput() and Element.drop() without passing pInst through File._load().
• Register the p5.File addon through p5.registerAddon().
• Add behavior-focused unit tests covering automatic cleanup, manual revocation, duplicate cleanup prevention, instance isolation, and both file-loading entry points.
• Preserve existing behavior for non-media files.

PR Checklist

• npm run lint passes
• Inline reference is included / updated
• Unit tests are included / updated

[rk-3001]

Hi, I'd like to take this on.
Cause: p5.File._load() creates blob URLs for audio/video files via URL.createObjectURL() but never revokes them, so they leak for the page's lifetime instead of the sketch's.
Fix: track created URLs in a _blobUrls Set on the p5 instance (passed through from createFileInput/drop), revoke + clear them in p5.remove(), and add a file.revoke() method for early manual cleanup. I'll include unit tests.
I can work on this...

[slash-init]

@rk-3001 i think you should read contributor guidelines first.

[Vaivaswat2244]

Thanks for the pr @slash-init . Matches what we discussed on the issue, left a few comments.

[limzykenneth]

Does this need to be on the p5 instance? Can it not be fully handled by p5.File itself? For cleaning up when the sketch is removed, use the remove lifecycle hook which is designed for this kind of use.

[slash-init]

@limzykenneth Thanks for the feedback! I looked through the lifecycle code and I think I understand the direction now: move the Blob URL cleanup into p5.File and use the existing remove lifecycle hook, rather than keeping _blobUrls on the p5 instance.
The one thing I'm still unsure about is how you'd like the File to keep track of which p5 instance it belongs to. Right now _load() gets pInst explicitly for that, but from your comment on dom.js, it sounds like you'd prefer not to pass it through like this.
I could move the cleanup into a single remove hook, but I don't want to introduce another registry or ownership mechanism if there's already a pattern in p5.js that I'm missing.
Is there a particular approach you had in mind for handling the per-instance cleanup here?

[limzykenneth]

It is a bit abstract for me to think about without actually writing the code so the explanation here may be a bit abstract as well. Passing pInst to File._load in this case could possibly work since it is a static function with no side effect. Another option if at all possible is to handle the object URL somewhere where this points to the p5 instance, that can be in lifecycle hooks or more likely a p5 function call such as createFileInput, eg.

const handleFileSelect = function (event) {
  for (const file of event.target.files) {
    File._load(file, trackObjectURL);
  }
};

// Deliberate arrow function to keep reference to `this`
const trackObjectURL = (callback) => (blob) => {
  if(blob instanceof Blob){
    this._blobURLs.push(blob);
  }
  callback(blob);
};

Hopefully that made sense, let me know if not and I can try to flesh out the idea more.

[slash-init]

@limzykenneth
Made the changes based on your feedback.
Moved the Blob URL cleanup into the remove lifecycle hook, removed the pInst plumbing from File._load(), and used the callback approach to track Blob-backed files per p5 instance. Also switched p5.File to p5.registerAddon().
Would love a feedback.

[p5-bot]

Continuous Release

CDN link

• https://raw.esm.sh/pr/p5@5de459c/lib/p5.min.js

Published Packages

• https://pkg.pr.new/p5@5de459c

Commit hash: 5de459c

Previous deployments

cd057c7

• https://raw.esm.sh/pr/p5@cd057c7/lib/p5.min.js
• https://pkg.pr.new/p5@cd057c7

---

This is an automated message.

[limzykenneth]

Looks good. Thanks!