Greasemonkey: Compatibilidade WebExtension

Tenho pensado muito sobre isso. Não tenho uma "decisão" clara, mas alguns pontos:

• _Já_ concluímos o processo de portabilidade para compatibilidade com o e10s. Foi muito mais difícil quando começamos; por exemplo, Services.ppmm e .cpmm são bons atalhos, nos quais teria sido bom confiar desde o início, mas eles não existiam quando (responsavelmente) começamos.
• Esse trabalho foi longo e muito doloroso, e não estou ansioso para repeti-lo efetivamente.
• O lançamento do e10s caiu do Firefox 36 (em setembro de 2014) para o Firefox 42 (a partir de agora, setembro de 2015), ou pelo menos nove meses.
• O anúncio diz que as extensões da web estão a pelo menos 1 ou 2 anos de distância; vai cair para 2, 3, 4 anos a partir de agora?
• Se vamos fazer isso, acho que é o momento certo para fazer uma pausa limpa e refazer a arquitetura.
  
  
  
  • Eu me encontro desejando que tivéssemos bons testes de unidade quase sempre, embora tenhamos muitos problemas que eles nunca pegariam, temos alguns que eles também teriam.
  
  
  • Podemos finalmente adicionar suporte para Android?
  
  
  • Não precisamos realmente reescrever do zero, mas pode ser garantido ser cuidadoso quanto ao código que retemos e ao que eliminamos.
  
  
• Eu realmente adoraria que houvesse uma relação Greasemonkey / Mozilla muito mais forte antes de iniciarmos outra tarefa tão grande. Tenho apenas suposições fracas de como tornar isso uma realidade.
  
  
  
  • Acho que somos efetivamente um teste de tortura para portar para algo como extensões da web hoje; ao longo dos anos, criamos alguns recursos avançados. Uma comunicação bidirecional como parte do plano provavelmente ajudará muito.
  
  

Começar com um documento de design seria uma ótima ideia. Essencialmente, precisamos fazer a engenharia reversa de todo o Greasemonkey conforme ele existe em um plano para uma boa maneira, em vez de uma maneira não planejada de cultivo orgânico, para que tudo seja estruturado.

por exemplo, Services.ppmm e .cpmm são bons atalhos, nos quais teria sido bom confiar desde o início, mas eles não existiam quando (responsavelmente) começamos.

Certamente não estou defendendo o uso de WebExtensions ainda, eles são muito imaturos para algo como GM

Não precisamos realmente reescrever do zero, mas pode ser garantido ser cuidadoso quanto ao código que retemos e ao que eliminamos.

Hrm, bem, eu estava olhando principalmente de um ponto de vista de tecnologia. No momento, a IU usa sobreposições XUL e execução direta de script no ambiente de cromo compartilhado.

Portanto, converter coisas para HTML e executar cada uma delas em um contexto de janela independente e apenas se comunicar por meio de troca de mensagens parece ser como as coisas devem ser feitas no futuro.

O gerenciador de mensagens é basicamente o nível mais baixo em que é implementado. As abstrações de nível superior se baseiam nisso. Canais WebChannel.jsm / BroadcasstChannel / MessageChannel / WebExtension e outros.

Começar com um documento de design seria uma ótima ideia.

O GH wiki seria o lugar certo para isso? Ele faz notificações na edição para simplificar o trabalho colaborativo?

Acho que precisamos principalmente de uma lista de recursos / encanamento interno e como implementar cada um de maneira limpa.

Se você estiver interessado no tópico deste problema, leia:

https://groups.google.com/d/topic/greasemonkey-dev/K6IyDUWnTQc/discussion

Obrigado!

Relevante:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1271553
• https://bugzilla.mozilla.org/show_bug.cgi?id=1334174

https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API/Introduction

Esta é uma API superinteressante, mas "Este recurso não é padrão e não está no caminho dos padrões" e a compatibilidade é muito limitada.

Todas as minhas tentativas recentes (ver # 2483, # 2484) de projetar extensões Greasemonkey-under-Web com todos os recursos têm sido frustrantes. Estou começando a considerar um estilo de desenvolvimento mais progressivo: escolha um conjunto mais limitado de recursos e suporte apenas isso. Seja um pouco útil e, com sorte, encontre um caminho para mais funcionalidades mais tarde.

Inspecionando minha instalação 3.x, vejo que (para mim) cada script é <strong i="6">@grant</strong> none . De 27, apenas seis usam @run-at document-start , e a maioria deles funcionaria pelo menos um tanto graciosamente se isso não fosse suportado. O recurso @require é muito usado e @resource bastante.

Portanto, esse parece ser um alvo decente a se apontar primeiro: Suporte a scripts de usuário simples no modo <strong i="12">@grant</strong> none , sem suporte para quaisquer GM_ APIs. Apoie @require . Espero apoiar @resource alguma forma, talvez de forma ineficiente.

(Observação, porque sempre me esqueço disso: planeje usar @require em consideração.)

Temos acesso a APIs da Web simples, além das WebExtension, então:

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API

? Qual é o limite de armazenamento de IndexedDB, para um WebExtension? Parece uma opção muito melhor do que storage.local . A interface não é a mais simples, mas nos dá mais poder para separar scripts uns dos outros e fazer leituras seletivas. Eu penso. Documentos também não são os mais fáceis de usar.

https://github.com/mdn/webextensions-examples/pull/171 parece ter uma discussão valiosa e um exemplo para IndexedDB

Eu fiz alguns progressos.

https://github.com/arantius/greasemonkey/tree/webbymonkey (em 88d53b4c67b7825858405eb2591f27c8487ce413)

Reimplementado do zero. Confira, vá para about:debugging , pressione "Carregar complemento temporário" e selecione qualquer arquivo do local raiz. Você pode instalar e apenas executar scripts de usuário. Absolutamente nenhum outro recurso ainda. (Bem, há o menu do macaco, mas é uma farsa vazia que não faz nada além de parecer OK.) Muitos TODOs espalhados pelo código até mesmo para este pequeno conjunto de recursos. Não posso garantir que nada disso seja o "caminho certo" para mais recursos ou não.

Como as versões anteriores do Tampermonkey, bem como do Violentmonkey, são de código aberto, parte desse código poderia ser usado aqui, já que WebExtensions é semelhante às extensões do Chromium?
EDIT: Na verdade, olhando para ele, não tenho certeza sobre a compatibilidade da licença com o Tampermonkey antigo. Mas Violentmonkey é licenciado pelo MIT, por isso é compatível.

@PorygonZRocks : Violentmonkey se tornando Greasemonkey?

Não tenho muita experiência com codificação, mas estava pensando que poderia ter pelo menos algumas orientações sobre como implementar as coisas. Novamente, não tenho muita experiência / conhecimento, então posso estar errado.

É importante notar que o FF56 desabilitou todos os addons não compatíveis com multiprocessos, então o prazo pode precisar ser alterado.

Veja meu branch dev . O que é bastante rudimentar, mas é minimamente funcional. Isso está sendo feito, não há nada para rastrear especificamente neste problema de escopo amplo.

@arantius Por curiosidade, você está escrevendo um novo código ou reutilizando o antigo?

Você precisa de ajuda?

Mais uma vez, por curiosidade, por exemplo, o objetivo de "parse-meta-line.js" é simplesmente analisar os metadados em um objeto?

@arantius Por curiosidade, você está escrevendo um novo código ou reutilizando o antigo?

Principalmente novo. Copiar quando / onde for útil. (Até agora, a análise de script é um grande exemplo.)

Você precisa de ajuda?

Ajuda seria bom. A coordenação seria difícil.

Mais uma vez, por curiosidade, por exemplo, o objetivo de "parse-meta-line.js" é simplesmente analisar os metadados em um objeto?

Uma linha disso, sim.

Uma linha disso, sim.
Quero dizer, ele faz alguma outra coisa, exceto analisar os metadados entre estes:

// ==UserScript==
....
// ==/UserScript==

Parece muito código se esse for o único objetivo.

Sim, é isso que faz. É um código gerado. Leve esta discussão para https://groups.google.com/d/topic/greasemonkey-dev .

Eu não uso grupos do Google :(
Se fosse eu ... provavelmente faria diferente.

O grupo google não existe mais.

Link incorreto: https://groups.google.com/forum/#!forum/greasemonkey -dev

Não tenho certeza se este é o local correto para ele, mas aqui está. Se você quiser que eu abra um problema separado, @arantius , com certeza.
O 4.0.0 não deveria migrar os scripts existentes? Eu atualizei para alfa 3 (vindo do não beta mais recente) e percebi que não tinha mais scripts.

@Phyxion , se você instalar o 3.14, os scripts devem ser migrados. Certifique-se de reiniciar o navegador após a instalação.

Depois disso, ao instalar o 4.x, você deverá ter os scripts. Se você não fizer isso, algumas etapas de reprodução detalhadas em uma nova edição serão úteis.

Greasemonkey 4 alpha é incompatível com Firefox 57.

@erkinalp , você poderia explicar? Tenho usado o 4alpha2 para muitos dos meus testes e modificações, ele funciona, embora nem todos os recursos do 3.x estejam disponíveis. Eu não puxei as alterações no 4alpha3, então não sei os poucos commits para essa versão quebram nada.

@Sxderp Bem, reproduzi-lo na minha máquina é fácil. Eu tenho 3.14 instalado com 10 scripts de usuário. Vá para AMO e baixe o alfa mais recente. Reinicie quando solicitado. Em seguida, apenas informa que não há scripts de usuário instalados. Não tenho certeza de como isso é útil para reproduzi-lo.

Eu não testei isso ainda, mas acredito que GM4 deve perder sua configuração após uma desinstalação, enquanto GM3 deve mantê- lo, então sugiro que você tente:

1. Desinstale completamente o Greasemonkey
2. Reinicie o Firefox
3. Instale o Greasemonkey 3.14 (incluindo reinicialização)
4. Reinicie o Firefox para uma boa medida
5. Instale o Greasemonkey 4 (ponto qualquer coisa)

Isso ajuda?

Acho que o nível superior espera - ou seja, envolver tudo em uma função assíncrona - não é uma boa escolha de design, pois restringe implementações futuras (por exemplo, se / quando recebermos sandboxes de volta ou reinos es-future). Isso torna as coisas inconsistentes com a execução de JS vanilla, onde o nível superior await não está disponível e os scripts são executados ... bem ... em um nível superior.

@arantius
Ainda nada aqui :(
BTW, o 4.0 deveria ter a seguinte aparência: https://i.imgur.com/CPuWWKM.png
Não há botões ou nada para adicionar um script.

... envolvendo tudo em uma função assíncrona ...

Com o que está disponível agora, "tenho" que envolver em uma função para fins de escopo. No entanto, acho que compro seu raciocínio por não torná-lo assíncrono. (No mínimo, adicionar uma função de wrapper assíncrona no próprio script é trivial.)

Sim, era principalmente sobre async / await, uma vez que atualmente não é permitido intencionalmente em javascript , então habilitá-lo em scripts de usuário parece um perigo para mudanças futuras. Eu sei que o invólucro é inevitável no momento, mas espero que as coisas possam ser movidas de volta para o nível superior no futuro.

@arantius Por que o voto negativo?

@arantius comentou em 2017. szept.

... envolvendo tudo em uma função assíncrona ...

Com o que está disponível agora, "tenho" que envolver em uma função para fins de escopo. No entanto, acho que compro seu raciocínio por não torná-lo assíncrono. (No mínimo, adicionar uma função de wrapper assíncrona no próprio script é trivial.)

Tente excluir o conteúdo de [perfil do mozilla] \ storage \ default \ (depois de fazer o backup)
Em seguida, tente novamente.

Por falar em objetos UserScript, não entendo muito bem a decisão de design para ter três classes UserScript. No momento, eles têm uma árvore de herança singular que é um pouco boba.

Além disso, RemoteUserScript é usado apenas uma vez e, para isso, é criado apenas para obter o id . E RunnableUserScript nunca é usado diretamente.

Apenas para informação ...

Estou no FF57.0a1 e executando addons legados e GM 3.13
Infelizmente, não recebo as atualizações (3.14, 3.15), pois a versão máxima está definida para 56. *

Porém, ele pode ser instalado manualmente.

GM 3.16 ainda trava o navegador na inicialização (acho que está atualizando o banco de dados)