0
355
VistasLa clave de manifiesto "web_accessible_resources" se ignora si los recursos respectivos se inyectan en una página de URL de archivo
Recientemente, mi extensión MV3 dejó de funcionar (aunque funcionaba antes). Después de investigar un poco, descubrí que los scripts/CSS inyectados no se cargan a pesar de que aparecen en la clave de manifiesto web_accessible_resources . Estos recursos necesarios son inyectados por mi secuencia de comandos de contenido a través de document.createElement . Vale la pena señalar que este problema solo surge si estos recursos se inyectan en una página con un archivo local ( file:// ) abierto; no hay ningún problema en las páginas http:// .
Obtengo el error net::ERR_BLOCKED_BY_CLIENT para todos los recursos inyectados: 
A continuación se muestra la clave "web_accessible_resources" en mi manifiesto:
... "web_accessible_resources": [ { "resources": [ "harviewer/*", "connection.js" ], "matches": [ "<all_urls>" ] } ], ... AFAIU es correcto, de lo contrario recibiría otro mensaje de error como este: 
La casilla de verificación "Permitir acceso a URL de archivo" está marcada para la extensión: 
No tengo extensiones tipo adblock instaladas. También he intentado borrar el caché del navegador, sin suerte.
Entonces, ¿es un error o una característica? Los documentos actuales de Chrome Dev no mencionan tal comportamiento.
Hice un MCVE que reproduce el problema.
1 Respuestas
Responde la pregunta0
Sí, confirmando este comportamiento desagradable en MV3 para el esquema file://* . Suena como un error de CSP de Chrome al acceder a los recursos de los archivos locales.
Como solución alternativa, podemos simplemente enviar todas las solicitudes global.fetch() a nuestro trabajador de servicio (también conocido como página de fondo en MV2) con chrome.runtime.sendMessage(message, callback) y luego devolver el contenido como una cadena sin formato/base64.