Greasemonkey: WebExt: Suporta todas as APIs GM

bug1323433 e bug1332273 podem ser interessantes aqui.

Obrigado pelas dicas, concordo que ambos são super úteis.

Oh, talvez alguma quantidade de passagem de mensagens síncrona seja possível!

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/onMessage#Sending_a_synchronous_response

Teste isso. Isso possibilita o uso de uma implementação síncrona simples (suportada por APIs somente em segundo plano) para os métodos mencionados acima?

Isso retorna uma promessa no lado do conteúdo, portanto, é efetivamente assíncrono. acho que "síncrono" é um nome impróprio aqui, é mais como emparelhar uma mensagem de filho para pai com uma resposta para que não seja necessário acompanhar manualmente as respostas pendentes.

Afaik, a única API síncrona disponível são os XHRs de sincronização que podem ser interceptados com webrequest ou algo parecido.

Sincronizar XHR não funciona corretamente no script de conteúdo: https://bugzilla.mozilla.org/show_bug.cgi?id=1360968, então no momento não temos nenhum canal de sincronização de conteúdo > plano de fundo.

Parece que GM_setValue e GM_getValue foram projetados como operação de sincronização e no navegador de processo único eles funcionam bem quando operamos em várias guias, mas no e10s não (https://github.com/greasemonkey /greasemonkey/issues/2427). Com a API de extensão antiga, ela pode ser facilmente reparada, mas na WebExt não. Sem mensagem de sincronização (mesmo para dados pequenos, apenas emitimos valores curtos), não podemos sincronizar corretamente o valor entre mais guias. em algum momento, isso sempre será uma condição de corrida.

Independentemente de como você resolve os problemas acima na versão WebExt, devemos obter o novo método set/get projetado de maneira assíncrona, portanto, onde é importante, podemos escrever o script de maneira assíncrona. As documentações devem conter algumas informações sobre a falta de comportamento GM_setValue e GM_getValue ao operar em múltiplas abas.

imo, são raros os casos de uso que usam GM_setValue / GM_getValue em várias guias e a ordem deve ser seguida. como resultado, armazenar uma cópia (cache) de _GM_values_ no script de conteúdo, ler sempre do cache, escrever de volta assíncrono e atualizar o cache com eventos acionados pelo script em segundo plano deve ser uma solução aceitável.

btw, se sim, adicionar uma API equivalente a GM_addValueChangeListener é ótimo se possível. (e eu não gosto do nome addValueChangeListener outra coisa deveria ser melhor talvez

Na minha ramo dev não há suporte para:

• GM.getResourceURL
• GM.deleteValue , GM.getValue , GM.listValues , GM.setValue

Eu pretendo nunca adicionar :

• GM_log
• GM_addStyle

Ainda precisamos :

• GM_xmlhttpRequest

Pretendo adiar (ou talvez desistir):

• GM_registerMenuCommand (este sempre foi um custo de suporte enorme)
• GM_getResourceText

O que significa que o progresso aqui está bem próximo.

Bom feedback no commit acima, não se esqueça.

Acabei de experimentar o novo add-on. Parece que a solicitação xhr de domínio cruzado já havia sido habilitada sem os recursos GM_xhr. Isso é realmente um comportamento?

Apenas tente um userscript grant none com os seguintes códigos:

fetch(prompt()).then(resp => resp.text()).then(text => alert(text)).catch(error => alert(error));

Ufa, confirmado. No momento, estamos executando scripts de usuário como "scripts de conteúdo" -- da extensão, com todas as permissões da extensão.

Eu examinei isso um pouco, mas até agora estou no escuro sobre como executar código sem privilégios ("escopo da web" - como chamamos isso agora que o escopo "conteúdo" é ambíguo?!). O mais próximo que posso encontrar é criar tags de script, que podem/serão bloqueadas pelo CSP da página, o que definitivamente não quero.

Atualmente, a única maneira de modificar o CSP é interceptar e modificar os cabeçalhos de cada solicitação de documento. Existem questões em aberto para isentar extensões da web de CSPs de conteúdo, mas não parece haver muita atividade nelas.

Além de injetar <script> tags window.eval também deve ser executado no escopo da página, eu acho.

Os termos oficiais são "escopo do script de conteúdo" versus "escopo da página".

Outro problema é que eles precisariam de processamento de string para envolvê-los em um escopo separado que poderia definir as APIs GM.

Eu também registrei um bug para equivalentes de Sandbox em extensões da web, mas também não é de alta prioridade.

AIUI tanto script quanto eval são vulneráveis ​​ao bloqueio pelo CSP. Mas confirmei que eval descarta privilégios.

https://bugzilla.mozilla.org/show_bug.cgi?id=1391669

Devemos ter <all_urls> se formos potencialmente executar um script de conteúdo em qualquer página. Se pedirmos isso, nosso script de conteúdo recebe isso e, portanto, pode XHR para qualquer lugar.

Pelo menos no Firefox ( https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Content_scripts#Using_eval ()_in_content_scripts ) podemos descer para o escopo da página, mas então somos realmente o escopo da página e não pode expor APIs com segurança ao script sem expô-lo a qualquer coisa/tudo em execução na página (AFAIK), o que é ainda pior.

fetch e xhr podem ser substituídos no script de conteúdo?
Talvez forneça uma busca modificada que faça sua própria verificação de CORS.

• GM.xmlhttpRequest() foi adicionado em 60a50d05b1e565571d8a3e638b0683a1a9c2beaa
• GM.getResourceText() será abordado em #2548
• GM.registerMenuCommand() está sendo ignorado intencionalmente.
• Cada script que herda a busca de origem cruzada (conforme comentário acima) é #2549

@the8472 Veja minha implementação de withUnsafeWindow() em https://github.com/greasemonkey/greasemonkey/issues/2232#issuecomment -326841025

Ele imita o comportamento da antiga função with (object) ... , apenas um pouco mais segura. (Precisa de navegadores modernos.)

@arantius escreveu em 25 de julho :

Eu pretendo nunca adicionar :

GM_log
GM_addStyle

Estes foram indicados na criação deste ticket (por @arantius em 3 de março ) como triviais (assumindo um mapeamento de GM_log para console.log).

Na minha experiência, essas são duas das chamadas de API mais usadas. Abandoná-los não quebraria muitos scripts antigos sem motivo? Ou você estava se referindo exclusivamente ao ramo dev?

No Tampermonkey, GM_addStyle tem uma habilidade especial de injetar estilo que pode contornar a restrição CSP (no caso de <style> inline ser proibido). Ficarei feliz se pudermos ter esse recurso no Greasemonkey também.