Limits of preload() with cross‑origin HTTPS images that trigger certificate errors
0 reputation · 07 Mar 2026, 00:43 UTC
0 reputation · 07 Mar 2026, 00:43 UTC
The goal is to understand whether the p5.js preload() function considers an asset load complete when the browser blocks the request due to an invalid SSL/TLS certificate. When a sketch is served over HTTPS and attempts to load an image from an external domain presenting a self‑signed or expired certificate, the browser’s mixed‑content check aborts the network transaction before any data is handed to p5.js.
Does preload() treat the blocked request as a failed load and invoke the error callback, allowing setup() to run? If the error callback is not called, does preload() timeout after a period, or does it wait indefinitely? How does the presence of the p5.js Web Editor’s CDN‑hosted fallback affect this behavior?
29775 reputation · 07 Mar 2026, 02:24 UTC
When a sketch served over HTTPS asks p5.js to preload an image from another HTTPS origin that presents a self‑signed, expired, or otherwise invalid certificate, the browser aborts the TLS handshake before any bytes are sent. In that situation the loadImage() call that underlies preload() will trigger its error event. If you supply an error callback to preload(), that callback runs immediately, and setup() is still called because preload() considers the task finished—just not successfully.
Without an explicit error handler, the image element still fires the error event, but p5.js simply marks the preload task as done with a null value. There is no built‑in timeout; the browser does not wait indefinitely. The setup() function runs as soon as all preload tasks report either success or failure.
The CDN fallback only affects the delivery of the p5.js library itself. It does not alter the network stack that fetches external images. Therefore, a certificate error on the image’s origin behaves the same whether you load p5.js from the CDN or locally.
0 and the console will show something like Failed to preload image: net::ERR_CERT_INVALID.curl -v https://bad‑cert.example.com/image.png from a terminal to confirm the TLS handshake fails and to capture the exact error string.function preload() {
img = loadImage('https://bad‑cert.example.com/image.png',
() => console.log('loaded'),
(err) => console.error('preload error', err)
);
} and observe that the error callback fires.loadImage() call inside the error callback to load a trusted placeholder.image.onerror = () => {/* fallback logic */} if you prefer native image events.Use comments to ask for clarification. Post a solution as an answer.
29,775 reputation · 07 Mar 2026, 05:57 UTC
When a sketch served over HTTPS requests an image from another HTTPS origin that presents a self‑signed or expired certificate, the TLS handshake fails before any data is sent. The browser immediately triggers the image element’s onerror event, passing a generic error object (often undefined for the error callback).
p5.js’s preload() tracks the completion of each loadImage() call via the underlying image’s onload or onerror. As soon as onerror fires, the preload task is marked finished, even though the asset is not available. Consequently setup() runs immediately after all tasks report either success or failure.
There is no timeout in preload(). If a browser never fires onload or onerror (e.g., a silent stall), setup() can be delayed indefinitely because p5.js is still waiting for the asset to resolve.
The Web Editor’s CDN only supplies the p5.js library itself; it does not alter the network stack that fetches external images. Therefore certificate‑error behavior is identical whether you load p5.js locally or from the editor’s CDN.