[p5.js 2.0 Bug Report]:

[MASTERsj01]

Most appropriate sub-area of p5.js?

• Accessibility
• Color
• Core/Environment/Rendering
• Data
• DOM
• Events
• Image
• IO
• Math
• Typography
• Utilities
• WebGL
• Build process
• Unit testing
• Internationalization
• Friendly errors
• Other (specify if possible)

p5.js version

dev-2.0

Web browser and version

Any

Operating system

Any

Steps to reproduce this

Several modules in the dev-2.0 branch use raw console.log() for validation/warning messages instead of the Friendly Error System. These messages are not suppressed by p5.disableFriendlyErrors = true and cannot be translated via i18n.

This issue consolidates #8608, #8609, #8610, #8611 as discussed with @davepagurek and @ksen0 on Discord.

Affected locations (all confirmed on dev-2.0 branch):

1. src/data/local_storage.js — 5 raw console.log() calls

• storeItem() line 117: non-string key warning
• storeItem() line 122: key ending with 'p5TypeID' warning
• storeItem() line 128: undefined value warning
• getItem() line 266: unable to determine type
• removeItem() line 421: non-string key warning

2. src/dom/p5.MediaElement.js — 1 leftover debug console.log(id)

• removeCue() line 1173: logs internal cue ID to user console (debug leftover, should be removed)

3. src/image/p5.Image.js — 1 raw console.log()

• setFrame() line 1608: invalid GIF frame index warning

4. src/events/pointer.js — 1 raw console.log()

• requestPointerLock() line 1864: browser capability warning

5. src/dom/dom.js — 1 raw console.log()

• createFileInput() line 1836: File APIs not supported warning

Steps to reproduce (example):

1. Set p5.disableFriendlyErrors = true
2. Call storeItem(123, 'value') (non-string key)
3. Observe: warning still appears in console despite FES being disabled

Expected behavior:

All validation/warning messages should use p5._friendlyError() so they respect p5.disableFriendlyErrors and can be translated. The debug console.log(id) in removeCue() should simply be removed.

I have confirmed all locations exist on the dev-2.0 branch and would be happy to open a PR targeting dev-2.0.