Repository navigation
v2.11 Search Fix: arregla tres bugs de la búsqueda y amplía los límites (112/112 tests) - #12
Merged
Merged
Conversation
La busqueda operaba nodo de texto por nodo de texto sobre el DOM ya coloreado, lo que causaba tres fallos encadenados: 1. Degradacion progresiva (critico): clearSearchMarks reemplazaba cada <mark> por un nodo de texto sin fusionar los adyacentes (faltaba normalize()). Cada busqueda fragmentaba el DOM de forma permanente. Reproducido: buscar 'Rayuela' -> 1 resultado; buscar 'y'; buscar 'Rayuela' otra vez -> 0 resultados. 2. Terminos que cruzan colores: '<libro', 'libro id' o 'id="1"' daban 0 coincidencias aunque estuvieran visibles, porque el texto esta partido en spans por color. 3. Contadores inconsistentes: '<libro' daba 0 en vista Resaltada y 2 en vista Texto. Solucion: applySearch aplana el DOM guardando el offset de cada nodo, busca sobre el texto completo con findRanges() (misma logica que las vistas Texto/Arbol, asi los contadores coinciden por construccion) y marca cada coincidencia por trozos, uno por nodo que toque. Los trozos comparten indice para la navegacion. Ademas normalize() al limpiar y el outline de la coincidencia activa pasa a box-shadow inset, porque un borde por trozo la partia con lineas verticales. Limites ampliados por decision del mantenedor: ~3000 lineas / 120KB (antes ~2500 / 100KB, que bloqueaban este arreglo). Se levanta el modo solo-bugfixes de v2.10. De paso se corrigieron referencias obsoletas a '~1500 lineas' en README, SECURITY y GUIA. Tests: 6 nuevos (uno por bug, navegacion y findRanges) — 112/112. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Resumen
El mantenedor reportó que la búsqueda "a veces dejaba de encontrar" cosas. La auditoría encontró tres bugs encadenados, todos con la misma raíz:
applySearch()buscaba nodo de texto por nodo de texto sobre el DOM ya coloreado.🔴 Bug 1 — La búsqueda se degradaba sola (crítico)
clearSearchMarks()quitaba las marcas reemplazándolas por nodos de texto, pero nunca volvía a fusionar los nodos adyacentes (faltabanormalize()). Cada búsqueda fragmentaba el DOM de forma permanente y las siguientes dejaban de encontrar términos que cruzaran esos cortes.Reproducción en la app (antes del fix):
Rayuelay— parte el nodo enRa|y|uelaRayuelaotra vezEl texto seguía visible en pantalla; la única forma de recuperarlo era volver a pulsar Formatear.
🟠 Bug 2 — Imposible buscar términos que cruzan colores
En la vista Resaltada el texto está partido en
<span>por color. Como la búsqueda solo miraba dentro de cada nodo, cualquier término que abarcara dos colores daba cero aunque estuviera a la vista:<libro→ 0,libro id→ 0,id="1"→ 0 (mientras quelibrosolo → 4 ✅).🟡 Bug 3 — Contadores inconsistentes entre vistas
Consecuencia del anterior:
<librodaba 0 en vista Resaltada y 2 en vista Texto. Mismo documento, mismo término, dos respuestas.✅ Solución
applySearch()ahora busca sobre el texto completo de la salida y mapea las posiciones al DOM resaltado:findRanges()— la misma lógica que usan las vistas Texto/Árbol, así que los contadores coinciden por construcción (bug 3 desaparece estructuralmente, no por parche)<mark>por nodo tocado, y todos los trozos comparten índice de coincidencia para la navegación ▲▼Extras:
normalize()al limpiar las marcas (raíz del bug 1)outlinede la coincidencia activa pasa abox-shadowinset: un borde por trozo la partía con líneas verticales. Verificado que los 5 trozos de<libro id=quedan contiguos (0px de hueco) con un subrayado continuo.Resultado tras el fix, mismos casos:
Rayuelatras 5 búsquedas intermedias<librolibro idid="1"<titulo>Rayuela<libroen Resaltada vs Texto📏 Ampliación de límites
El arreglo no cabía en el presupuesto de v2.10 (~2474 de ~2500 líneas, ~97KB de 100KB). Decisión del mantenedor: techo a ~3000 líneas y 120KB duros. Se levanta el modo solo-bugfixes declarado en v2.10, documentado en SCOPE.md, ROADMAP.md, README.md y CLAUDE.md.
De paso corregí referencias obsoletas a "~1500 líneas" que habían quedado desde v2.4 en README, SECURITY y la guía de documentación.
Tests
6 nuevos, uno por bug más navegación y la función pura:
findRanges: sin solapamiento, insensible a mayúsculas, respeta el tope112/112 pasando.
Métricas
index.html: ~2510 líneas / ~99KB (nuevos límites: ~3000 / 120KB).🤖 Generated with Claude Code