Greasemonkey: Adicionar backup / restauração

Bem, o Firefox e seus problemas. Então, eu estava implementando isso (e, claro, uma função de 'importação'). Estou quase terminando, mas há um obstáculo. Só funciona quando você abre browser toolbox e seleciona "não fechar automaticamente os pop-ups". A importação é feita através de um <input type="file"> (que é a única forma), porém, no foco da janela de navegação o popup normalmente fecha, assim a janela é destruída e nenhuma função é executada. Bugs relevantes:
https://bugzilla.mozilla.org/show_bug.cgi?id=1292701
https://bugzilla.mozilla.org/show_bug.cgi?id=1366330

É tão chato ter um ambiente medíocre para trabalhar.

Além disso, se aplica a # 2612. Que pode ser resolvido ao mesmo tempo que este problema é.

@Sxderp Se o fechamento do pop-up for um problema, a maneira normal de resolver / contornar isso é simplesmente abrir uma guia ou janela (apontando para uma página HTML dentro da extensão) na qual você executa tudo o que precisa fazer. Essas guias / janelas não são fechadas automaticamente e apresentam o mesmo ambiente de um pop-up. Embora isso possa não ser tão claro quanto ter tudo dentro do pop-up do navegador, deve ser funcional.

Eu poderia fazer isso. Isso envolveria mover um monte de código ao redor. Vou examinar isso outra hora.

Concluí o material de importação / exportação. Sem testes e muito pouco tratamento de erros. Mas funciona. Porém, para simplificar, fiz isso de forma que uma importação sobrescrevesse todo o banco de dados. Com um prompt de confirmação, é claro.

Acho que o ideal é que o usuário possa escolher substituir ou mesclar a importação. O Stylus apenas se funde, o que também é um IME ruim. A escolha do usuário, com padrões que podem funcionar, parece a melhor.

Claro, mas então encontramos muitas condicionais. Eu gostaria de ver um diagrama de fluxo de algum tipo sobre a natureza _exata_ da fusão.

Principalmente em termos de conflitos. Sobrescrever conteúdo, sobrescrever chaves / valores (sim, esses também são exportados), solicitar tudo (isso parece uma experiência ruim para o usuário), etc?

Quero dizer apenas: importe cada script no arquivo (e sobrescreva completamente para aquele estado), mas não toque / exclua scripts que não estão no arquivo.

Oh. Isso é muito mais simples. Sim, parece bom.

Portanto, implementei três métodos de importação diferentes.

1. Merge. Não toque em nenhum script instalado. Apenas scripts que não existem atualmente [1] serão adicionados ao banco de dados.
2. Substituir. Desinstale todos os scripts atuais e substitua-os pelos importados.
3. Substituir. Como a fusão, mas se um conflito for encontrado [1], os scripts que estão sendo importados têm precedência.

Aguardando outros PRs antes de enviar.

[1] Eu determino a exclusividade por id um script.

Que tal isso?

1. Atualizar. Importe (substitua) apenas scripts que já existem.

Isso é complementar a 1. Mesclar

1. Substituir. Como a fusão, mas se um conflito for encontrado [1], os scripts que estão sendo importados têm precedência.

@Sxderp Eu acho que "Like merge" não inclui a restrição "Apenas scripts que não existem atualmente" ...
(esta restrição não faz sentido aqui) Isso significa que, Sobrescrever = Importar todos os scripts, os scripts conflitantes são substituídos pelo arquivo ...

Qual dessas opções (atualizar / mesclar / etc.) O VM, TM ou de outra forma oferece?

1. Atualizar. Importe (substitua) apenas scripts que já existem.

Claro, isso deve ser viável.

Isso significa que, Overwrite = Importar todos os scripts, os scripts conflitantes são substituídos pelo arquivo ...

Correto.

Qual dessas opções (atualizar / mesclar / etc.) O VM, TM ou de outra forma oferece?

Não tenho certeza. Mas isso trouxe outra preocupação minha. Compatibilidade com arquivos. Supondo que esses complementos suportem a exportação total do banco de dados (scripts + dados), o ideal é que as importações sejam compatíveis entre si.

Atualizar. Importe (substitua) apenas scripts que já existem.

Agora que penso sobre isso (tudo em cerca de 3 minutos), tenho uma preocupação. E os dados associados (get / setValue)? Os dados armazenados atualmente devem permanecer? Os dados importados devem ter precedência? Algum tipo de fusão? E, em seguida, representar claramente essa opção / estado para o usuário. Na verdade, isso é um pouco mais complicado do que à primeira vista.

Fiz algumas verificações rápidas, isso não é 100% completo, mas dá uma visão geral, bem como o que provavelmente devo mudar em relação à minha implementação.

VM e TM exportam para arquivos zip. Dentro dos arquivos zip, você pode encontrar .user.js arquivos para cada um de seus scripts. No entanto, quanto à exportação de detalhes específicos de armazenamento / implementação, os dois fazem isso de maneira um pouco diferente. VM envolve detalhes específicos de implementação e dados de script, para o que parece ser todos os scripts, em um único arquivo, violentmonkey . TM faz isso de maneira um pouco mais saudável. Os detalhes específicos da implementação, para cada script, são exportados para .options.js arquivos, enquanto os dados do script são exportados para .storage.json .

Acho que vou retrabalhar minha implementação para seguir a TM. Em geral, acho que é um padrão melhor, pois separa os detalhes de implementação dos dados.

Quanto ao 'método de importação' (descrito em minha postagem acima):

TM fornece uma interface para 'selecionar cada script'. Ao importar um arquivo, você seleciona se deseja importar cada script específico. Se você marcar, substituirá todos os dados desse script.

VM só parece oferecer o que descrevi acima como 'Substituir'. No entanto, há uma opção para NÃO importar dados de script associados (global para todos os scripts). Do ponto de vista da IU, acho que implementar essa opção no GM seria difícil. No entanto, se adotarmos a abordagem TM para exportar / importar o banco de dados, o usuário poderá simplesmente abrir o arquivo e remover o arquivo .storage.json .

Se alguém quiser testar, atualizei meu branch, sxderp:import-export-database-merge , para incluir a funcionalidade .zip que mencionei anteriormente. Não implementei a opção update que @Eselce sugeriu porque ainda não tenho certeza sobre os detalhes.

@Sxderp Obrigado por desenvolver este recurso. Criei o pacote e instalei-o no Firefox Developer Edition (para permitir a instalação de extensões não assinadas). Eu atualizei um perfil existente com essa versão do navegador, substituí a instalação existente do GreaseMonkey e exportei meu banco de dados sem problemas.

No entanto, importar um novo perfil do Firefox com o GreaseMonkey instalado causou um problema. Parece que um script de usuário específico que é muito grande (ambos user.js e gm_details.js têm cerca de 230 K. está causando problemas de importação. Depois de substituir o banco de dados, o GM para de funcionar. Clicar no ícone do GM abre uma lista suspensa vazia (cerca de 10x10 quadrados).

Prefiro não compartilhar o script de usuário específico publicamente. Usando esse truque , encontrei seu endereço de e-mail e enviarei uma mensagem assim.

Editar: A única maneira de fazer o GM funcionar depois de quebrar é remover a extensão, reiniciar o Firefox e adicioná-lo novamente.

GMexport_20180 2 17_164139.zip ???

Importou um monte de (em parte) scripts grandes (> 20) de um arquivo zip de 3,4 MB sem reclamação. No entanto, nenhum exame detalhado ...

  return 'GMexport_'
       + date.getFullYear().toString()
       + date.getMonth().toString().padStart(2, '0')
       + date.getDate().toString().padStart(2, '0')
       + '_'
       + date.getHours().toString().padStart(2, '0')
       + date.getMinutes().toString().padStart(2, '0')
       + date.getSeconds().toString().padStart(2, '0')
       + '.zip'

IIRC, getMonth() começa em 0 ... ; faltando ...

IIRC, getMonth () começa em 0 ...; ausente...

RASGAR

Eu não trabalho neste ramo há algum tempo. Vou aproveitar o dia de hoje e fazer um rebase no master e fazer várias limpezas.

Reestruturei meu branch no master e fiz algumas mudanças significativas no layout que acho que oferece melhor legibilidade.
@ArmEagle No meu branch atualizado, consegui importar o arquivo que você enviou. Se você ainda estiver tendo problemas, me avise e eu analisarei mais a fundo.

Mesclado com as alterações em 7fe8bfe94efbadeb1da1a6491aaf424fc8275f09. Reabertura para acompanhar / discutir alguns problemas que vi.

Reabertura para acompanhar / discutir alguns problemas que vi.

Quais foram os problemas?

Foi um teste rápido único, não tenho certeza, alguma quantidade de script que eu esperava que fosse instalado não estava listado. Mas quero repeti-lo, rastrear cuidadosamente e anotar os resultados. Existem muitos casos possíveis.

Eu finalmente analisei um pouco isso.

Ele faz backup apenas de .user.js e dos "detalhes". O que acidentalmente inclui o conteúdo requer, mas perde os recursos (JSON serializando o blob para {} ). AFAICT irá .setKnownResources() com blobs vazios / quebrados e, portanto, não funcionará.

Pareceria melhor se cada script tivesse sua própria pasta, essa pasta contém um arquivo para o .user.js , para cada @require e @resource , e então talvez o restante analisado / detalhes personalizados e valores armazenados. Acho que isso pode até ser melhor o suficiente para que eu renuncie a qualquer compatibilidade de plataforma cruzada.

Totalmente de acordo. Exatamente como salvar um documento "como página da web", o que criaria um htm -documento mais uma pasta com o mesmo nome (base) com as dependências ...

O que acontece de incluir acidentalmente o requer conteúdo ...

Não foi por acaso. Inclui propositalmente, para quaisquer alterações locais que possam ter ocorrido. Eu consideraria os recursos / requer como 'detalhes de implementação' e, portanto, exportados como "detalhes". TM nem mesmo exporta recursos / requer.

mas perde os recursos (JSON serializando o blob até {}). AFAICT irá .setKnownResources () com blobs vazios / quebrados e, portanto, não funcionará.

Há um TODO para descobrir se os blobs se tornam bem estruturados. Este recurso foi tecnicamente mesclado antes de eu enviar um PR para ele.

Por enquanto, o problema do Blob seria resolvido com o # 2937.

Quanto à criação de mais arquivos no arquivo de backup, não acho que isso traria todos os benefícios. Embora arquivar recursos e requisitos e tudo o que for extraído em arquivos separados possa _parecer_ bom quando extraído, fazer isso provavelmente tornaria o código mais complexo, pois você está lidando com várias coisas pequenas em vez de um simples despejo.

Este é o "grande recurso" do 4.4, então eu realmente espero terminar / melhorar isso em breve.

Pensando bem, isso é funcional. Existem algumas melhorias que eu gostaria de acompanhar, mas um problema de cada uma dessas alterações direcionadas será mais fácil de gerenciar.