From 5ba8a7437a34c758c6c0b2c2ea3bb7552e43a413 Mon Sep 17 00:00:00 2001 From: Carlos Narro Date: Thu, 4 Jun 2026 15:47:03 +0200 Subject: [PATCH] Defensa en createWeeklyTracker: normalizar Date in situ MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit El error TypeError: estimatedEndDate.toLocaleDateString seguía ocurriendo a pesar de rehydrateDates al cargar caché. Sin entender todavía por qué la rehidratación no convierte el valor (posible que el campo en storage no sea ISO-string sino algo no contemplado), añado defense in depth: createWeeklyTracker normaliza los tres campos Date (sessionStart, sessionEnd, estimatedEndDate) en su primera línea. Es no-op cuando rehydrateDates funciona (instanceof Date → as-is) y rescata el render cuando falla por cualquier motivo. Una llamada a toLocaleDateString sobre un string ya no rompe la extensión. Co-Authored-By: Claude Opus 4.7 (1M context) --- content.js | 16 ++++++++++++++++ 1 file changed, 16 insertions(+) diff --git a/content.js b/content.js index eb686a1..02f862c 100644 --- a/content.js +++ b/content.js @@ -492,6 +492,22 @@ } function createWeeklyTracker(pageData, dailyData) { + // Defense in depth: si pageData/dailyData vienen del caché de chrome.storage, + // los Date pueden seguir siendo string/number aunque rehydrateDates haya pasado. + // Normalizar aquí mismo evita TypeError al llamar .toLocaleDateString/Time. + const ensureDate = (v) => { + if (v == null) return null; + if (v instanceof Date) return isNaN(v.getTime()) ? null : v; + if (typeof v === 'string' || typeof v === 'number') { + const d = new Date(v); + return isNaN(d.getTime()) ? null : d; + } + return null; + }; + pageData.sessionStartTime = ensureDate(pageData.sessionStartTime); + pageData.sessionEndTime = ensureDate(pageData.sessionEndTime); + dailyData.estimatedEndDate = ensureDate(dailyData.estimatedEndDate); + const container = document.createElement('div'); container.className = 'claude-usage-tracker-container'; container.id = 'claude-usage-tracker';