Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

[p5.js 2.0+ Bug Report]: getURLParams() mis-parses valueless parameters and never percent-decodes values

Abierto Apto para principiantes
  • ¿Algo no está bien?
#9,241 1 comentario 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

@mayanksingh-7974 ya está trabajando en esto.

Desde el 11/10/2026.

  • #9274 de @mayanksingh-7974 — abierto

Evaluación

Dificultad
2/5
Tiempo estimado
1-3 horas
Aptitud para principiantes
88/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
javascript
Área
frontend

Línea de trabajo

Empieza en getURLParams en src/core/environment.js:1058 y ejecuta los cuatro casos independientes del issue (el fragmento de regex inline) para ver el parseo incorrecto antes de tocar nada. La sustitución sugerida es Object.fromEntries(new URLSearchParams(location.search)), que maneja claves sin valor, decodificación porcentual y + como espacio; elimina el workaround de lastIndex junto con ello. Añade tests de regresión para ?debug&x=1, ?a=1&b, ?name=Hello%20World y ?q=a+b en las pruebas unitarias de environment, y revisa la documentación de referencia de getURLParams para la nota de doble decodificación.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Most appropriate sub-area of p5.js?
  • Core/Environment/Rendering
p5.js version

2.3.2 (verified on main @ 94fb07d)

Web browser and version

All — the parser is a hand-rolled regex, not a browser API.

Operating system

All

Steps to reproduce this
Steps:
  1. Open any sketch with ?debug&x=1 appended to the URL.
  2. Log getURLParams().
  3. It returns { debug: "x" } — a pair that does not exist in the query string — and x=1 is gone entirely.
  4. Try ?name=Hello%20World: the value comes back still percent-encoded.
Snippet:
function setup() {
  print(getURLParams());
}

The parser can be run standalone to see all the cases:

const re = /[?&]([^&=]+)(?:[&=])([^&=]+)/gim;
function current(search) {
  let m; const v = {};
  while ((m = re.exec(search)) != null) {
    if (m.index === re.lastIndex) re.lastIndex++;
    v[m[1]] = m[2];
  }
  return v;
}

current('?debug&x=1');           // { debug: "x" }           expected { debug: "", x: "1" }
current('?a=1&b');               // { a: "1" }               expected { a: "1", b: "" }
current('?name=Hello%20World');  // { name: "Hello%20World" } expected { name: "Hello World" }
current('?q=a+b');               // { q: "a+b" }             expected { q: "a b" }

Cause

// src/core/environment.js:1058
fn.getURLParams = function () {
  const re = /[?&]([^&=]+)(?:[&=])([^&=]+)/gim;
  let m;
  const v = {};
  while ((m = re.exec(location.search)) != null) {
    if (m.index === re.lastIndex) {
      re.lastIndex++;
    }
    v[m[1]] = m[2];
  }
  return v;
};

Three problems:

  1. The separator group accepts & as well as =. (?:[&=]) means a parameter with no value matches &debug&x as key debug, separator &, value x — it absorbs the next parameter's name as its own value, and consumes the real x=1 pair along with it. A valueless parameter does not just get skipped; it corrupts its neighbour.
  2. Nothing is decoded. No decodeURIComponent, and + is not translated to a space, so any value containing a space, &, / or a non-ASCII character arrives in its encoded form.
  3. A repeated key keeps only the last occurrence, and the returned object is a {} literal, so it inherits toString, constructor, hasOwnProperty and friends. Code that tests if (params.constructor) gets a surprising truthy value.

Expected behaviour

Query strings should be parsed per the URL standard: values decoded, + treated as a space, and a parameter with no value reported as an empty string rather than absorbing the parameter after it.

Suggested fix

The platform already does all of this correctly, and URLSearchParams has been available in every browser p5 2.x supports for years:

fn.getURLParams = function () {
  return Object.fromEntries(new URLSearchParams(location.search));
};

That also removes the lastIndex workaround (needed only because of the zero-length-match hazard in the hand-rolled loop) and the prototype-inherited keys.

Two notes on compatibility, since this is a behaviour change and not purely a fix:

  • Valueless parameters start appearing as '' instead of being mis-parsed. Any sketch relying on the current output for ?flag was getting wrong data, but it is still a change worth a line in the release notes.
  • Values arrive decoded. A sketch that was calling decodeURIComponent() on the result itself would now double-decode. Worth mentioning in the reference docs for getURLParams().

If you'd prefer to preserve repeated keys as arrays while you're in there, that is easy to add on top — but it is a separate decision, so I've left it out of the suggestion.

I'd be glad to open a PR with the replacement and tests covering all four cases above.

Lenguaje dominante
JavaScript
Estrellas
24.1k
Forks
3.9k
Merge medio
3 d 4 h
PR fusionados (30 d)
29

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de processing/p5.js

Todos los issues de processing/p5.js

Issues similares

Más issues de JavaScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.