Greasemonkey: Permitir a instalação de arquivos locais

Talvez este (documentos de padrão de correspondência)? Usando * no seletor de correspondências para o esquema apenas muda para http ou https. Sugira adicionar uma correspondência adicional para file:// .

Isso ou o seletor <all_urls> .

Adicionar um padrão de correspondência para detectar scripts file:/// apenas nos faz iniciar um XHR que falha ao ler o conteúdo dessa URL, o que é surpreendente.

Estive investigando isso um pouco. E cheguei a duas conclusões. O problema pode ter a ver com a proibição de acesso do sistema de arquivos a WebExtensions, mesmo que somente leitura por meio de XHR (nenhuma fonte diretamente; edite: aqui na parte inferior). Ou pode estar relacionado à política de mesma origem .

A partir do Gecko 1.9, os arquivos podem ler apenas alguns outros arquivos. Especificamente, um arquivo pode ler outro arquivo apenas se o diretório pai do arquivo de origem for um diretório ancestral do arquivo de destino.

Pode valer a pena trazer um relatório de bug para permitir o acesso do sistema de arquivos a caminhos definidos no manifesto com o protocolo file:// .

Sim, provavelmente é a regra "sem arquivos". Não sei onde obter orientação oficial sobre isso, mas sei que é verdade agora que penso sobre isso. Você só obtém exceções muito especiais, como a API de downloads para criar novos arquivos.

Poderíamos tentar encontrar uma solução alternativa como manipular diretamente o arrastar / soltar ou (LOL) ler o conteúdo da guia que já está aberta. Mas então não conseguiríamos buscar ícone / recurso / requisitos relativos, então ainda não funcionaria, sem ainda mais soluções alternativas.

Você não poderia usar storage.local para página de instalação ? Você já tem o conteúdo em uma variável. É claro que o cache teria que ser limpo depois de instalado / decididamente não instalado. Seria mais conveniente se WebExtensions tivesse algum tipo de armazenamento temporário para que não precisassem lidar manualmente com o despejo.

Tenho andado confuso com o que disse e não é tão simples como pensei. Em primeiro lugar, qualquer script de usuário tem acesso a browser.storage.local portanto, é um armazenamento inerentemente inseguro para complementos como o Greasemonkey. Em segundo lugar, o mesmo vale para o envio do conteúdo por meio de uma mensagem para um script de fundo. Não tenho certeza de como garantir que a mensagem foi enviada apenas de script-detect.js . E devido à natureza assíncrona dos scripts, não tenho certeza se script-detect.js é executado antes dos scripts do usuário (farei alguns testes nisso).

E, claro, a menos que eu esteja enganado, os scripts de segundo plano não recebem nenhuma referência ao DOM / conteúdo em nenhum dos ouvintes de navegação?

Acontece que você pode obter o conteúdo da página usando onBeforeRequest com uma correspondência em ['*://*/*.user.js'] e, em seguida, criando um StreamFilter . Eu implementei alguns códigos para testar isso em meu branch publicado recentemente, sem solicitação de pull no momento, já que não _fixa_ nada. No entanto, isso evita as preocupações de segurança que mencionei no meu post anterior.

Infelizmente, isso não resolve o problema do arquivo que foi discutido. Alguns tíquetes do bugzilla nele:
https://bugzilla.mozilla.org/show_bug.cgi?id=1341341
https://bugzilla.mozilla.org/show_bug.cgi?id=1266960

Fui direcionado aqui de # 2671

Se este tópico for sobre como importar de um arquivo local .... então ...
Por que você está usando o XHR para ler o arquivo local? Isso causa todos os tipos de complicações com origens e permissões.
A maneira fácil é usar new FileReader() do resultado de input type="file"

Se este tópico é sobre como reconhecer file:///.....user.js URLs como scripts e instalá-los, esse é um problema diferente e uma solução diferente.

A maneira fácil é usar o novo FileReader () a partir do resultado de input type = "file"

Ah, isso poderia funcionar. Não é tão elegante quanto navegar para um caminho file:// e ter a extensão fazendo tudo para você, mas pode funcionar. A maior parte do fluxo de trabalho pode permanecer o mesmo.

import script -> script selected -> contents cached in backend -> install dialog prompt -> retrieve content from backend -> continue install as usual

E é muito mais seguro do que os métodos que estava tentando usar ao tentar manter o fluxo de trabalho de navegação.

Encontrado um exemplo de webextension funcional usando "input type =" file "". Parece que não há necessidade de armazenar em cache, pode ser importado diretamente:
https://github.com/mdn/webextensions-examples/pull/171/files/6c066cfff4e8c662984f704cb17c8b39211ed062#diff -098de1750b345156f3cfd46f8199aa34

Parece que não há necessidade de cache, pode ser importado diretamente

Não é que o cache seja _necessário_, mas sim uma medida de segurança. Assim como quando você navega para um .user.js, a caixa de diálogo é exibida com algumas informações sobre o script. Acho que o mesmo deve acontecer quando você faz a importação. Portanto, você precisa armazenar, em algum lugar fora do banco de dados normal, o conteúdo do script de forma que, caso o usuário clique no botão de instalação, você ainda o tenha disponível e não precise solicitar ao usuário novamente.

Se isso é armazenado em cache usando uma API de armazenamento ou apenas em um objeto global em algum lugar, não importa particularmente para o fluxo de trabalho.

Também gostaria de dizer que um recurso de importação deve se tornar a principal prioridade [1], pois ajudaria com pessoas com problemas de migração. Eles podem apenas importar os arquivos do 3.x.

[1] Eu investigaria se @arantius tivesse algumas ideias de como o processo deve funcionar.

Eu tenho import./Export em vários dos meus addons se exemplos são necessários.

A importação é iniciada pelo usuário, portanto, não há necessidade de precauções / pop-ups / notificações / avisos extras.

Adicione um botão de importação (entrada de arquivo) a um dos diálogos
Depois que o usuário clica nele, o seletor de arquivos é aberto. O usuário seleciona o arquivo necessário e clica em abrir (HTTML5 integrado)
O arquivo é lido e analisado
Se estiver em conformidade com um script de USUÁRIO, é então adicionado ao BID
Em seguida, atualize os ouvintes em execução

Isso é tudo....

Eu faço o mesmo nas preferências de Importar / Exportar, Dados do tema (até 500kb) e muitos outros em meus add-ons com a função Importar / Exportar.

Também gostaria de dizer que um recurso de importação deve se tornar a principal prioridade [1]

Na verdade ... isso permite que os escritores de script escrevam novos scripts e importem para executar ou testar e, no caso da atualização do GM3 -> 4, adicionar os scripts perdidos.

O código e a função são muito simples ... poucas linhas de código que podem ser feitas em algumas horas.
Você pode usar meu código como base, se desejar.

... A importação é iniciada pelo usuário, portanto, não há necessidade de precauções / pop-ups / notificações / avisos extras. ... Se estiver em conformidade com um script de USUÁRIO, é então adicionado ao BID

Eu não tenho certeza sobre isso, no entanto. Eu particularmente não gosto de pular a caixa de diálogo de instalação padrão. Talvez @arantius possa dar algumas dicas sobre o que ele gostaria de ver no addon.

Eu não tenho certeza sobre isso, no entanto. Eu particularmente não gosto de pular a caixa de diálogo de instalação padrão.

O diálogo padrão é usado quando o usuário é confrontado com um script de usuário de uma fonte remota. Um diálogo de confirmação é então necessário.

No caso de importação iniciada pelo usuário:

• O usuário decide importar um script
• O usuário clica no botão de importação
• O usuário navega para o script selecionado pelo usuário
• É necessário perguntar ao usuário novamente com uma caixa de diálogo "Você realmente deseja instalar este script?" :)
  Isso parece irritante. No entanto, é necessário um aviso em caso de erros.

• O usuário navega para o script selecionado pelo usuário

Mas não é assim que funciona ... A instalação é por retorno de chamada (gatilho em * .user.js) ...

Mas não é assim que funciona ... A instalação é por retorno de chamada (gatilho em * .user.js) ...

Atualmente sim. Mas é possível adicionar um botão de importação para arquivos locais. E não faça instalação na navegação por file:// .

Ah, ok, para arquivos locais, isso é bastante apropriado. Não para arquivos remotos! ;-)

Mas não é assim que funciona ... A instalação é por retorno de chamada (gatilho em * .user.js) ...

Conforme mencionado, estamos falando sobre importação manual usando entrada de arquivo

Sim, eu entendi. Tudo bem para mim para arquivos locais (veja acima) ...

Eu acho que é possível apenas arrastar e soltar o .user.js na janela do Greasemonkey para carregar o código do script nele.
Uma vez que isso definitivamente funciona para o próprio Firefox (ou seja, eu poderia enviar o arquivo para o site, como imgur, ou megaupload descartando-o)

Existe uma maneira (mesmo uma desajeitada, sem arrastar e soltar) que me permite importar scripts locais do GM?

Exatamente em qual diretório "cache" os scripts devem ser finalmente colocados? Encontrei vários arquivos "cache" no perfil do Firefox

Eu acho que é possível apenas arrastar e soltar o .user.js na janela do Greasemonkey para carregar o código do script nele.

É possível, como qualquer outra caixa suspensa (verifique meu IMGoolge para um exemplo). No entanto, a entrada de arquivo direta seria o método mais fácil sem a necessidade de ouvintes e processos adicionais.

Mozilla atualizou o documento (resumo dos exemplos acima):
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Working_with_files

1. Abra arquivos em uma extensão usando um seletor de arquivos
2. Abra arquivos em uma extensão usando arrastar e soltar

Com isso implementado, teríamos o mesmo comportamento do GM3.

Portanto, há alguma sugestão possível para instalar manualmente um script que não é oferecido em um formulário online apropriado?

@Samizdata Atualmente a maneira mais fácil é obter o GM beta (https://addons.mozilla.org/en-US/firefox/addon/greasemonkey/versions/beta), abrir o menu do macaco -> novo script.

Se você tiver scripts que @requerem arquivos locais, só poderá fazer isso da maneira mais difícil. Por exemplo, pegue o Proxomitron (http://www.proxomitron.info/files/), execute-o, configure o FF para usar o proxy 127.0.0.1:8080, coloque seus arquivos na pasta HTML do Proxomitron e acesse-os depois no FF com " http: //bweb..local.ptron/YOURFILE.user.js ".

@kekkc , acho que uma nova versão com o problema de recurso remoto corrigido foi enviada para o AMO.

Saúde. Já está, @kekkc !

@kekkc , acho que uma nova versão com o problema de recurso remoto corrigido foi enviada para o AMO.
Ainda não .. pelo que posso ver

@Sxderp Estamos nos referindo ao # 2707?

@Eselce , sim. Isso _deve_ resolver os problemas presentes ao criar um novo script com o botão 'novo script' e, em seguida, aplicar uma tag @require ao script.

Para ter um .user.js ou um script necessário sendo servido localmente, existem várias possibilidades. Mas a maneira mais fácil é usar este Python one-liner em sua linha de comando:

• para Python 2.x:
  python -m SimpleHTTPServer

• para Python 3.x:
  python -m http.server

... que imediatamente começa a servir todos os arquivos no diretório onde você o executa, em http://127.0.0.1:8000/

(_notar que 8000 é a porta padrão; você pode mudar isso; veja abaixo_)

É assim que coloco meu .user.js e solicito os arquivos em um servidor http local. Eu faço isso para Greasemonkey, mas também para Tampermonkey.

Python é instalado por padrão no Linux e MacOs. Se você usasse o Windows e não o tivesse instalado e ainda planeje continuar se autodenominado um desenvolvedor, então ... _sério ?! o que há de errado com você? _ você tem problemas muito mais sérios do que pode começar a perceber! Eu sugeriria jardinagem: mudas: ou tricô como hobbies ao invés de computadores para você: wink: (_Ei, estou brincando! _)

Não há necessidade de instalar nenhum programa estranho - você _ pode _, mas isso é _absolutamente desnecessário_. Python não é um "aplicativo", é uma linguagem de programação fundamental. Mas você nem precisa "falar" Python para essa solução, então não desista nem se apresse em usar suas ferramentas de tricô ainda!

Procedimento trivial:

1. cd no diretório que contém seus .user.js e / ou arquivos necessários. Digamos, por exemplo, requiredFile1.js e requiredFile2.js

2. Nesse diretório: Para Python 2.x, execute

python -m SimpleHTTPServer

OU: para Phython 3.x, execute

python -m http.server

1. Certifique-se de que suas @require linhas sejam como estas:

// <strong i="42">@require</strong>  http://127.0.0.1:8000/requiredFile1.js
// <strong i="43">@require</strong>  http://127.0.0.1:8000/requiredFile2.js

... onde requiredFile1.js e requiredFile2.js são quaisquer arquivos locais necessários que você deseja servir.

1. Quando o seu script greasemonkey for acionado, ele pegará corretamente o requer, que está sendo servido pelo Python.

Feito.

Para fechar seu servidor local, vá para o console onde você executa o comando python e pressione <Ctrl><C> .

Além disso, -_- e espero que seja ridiculamente óbvio para você _--, por favor, não se esqueça de executar a linha de comando do servidor HTTP Python antes de esperar que Greasemonkey ou Tampermonkey seja capaz de encontrar os arquivos ...

Dica : Se você quiser usar uma porta diferente da 8000 padrão, basta digitar o número desejado (um número de porta válido) em seu comando, assim:

• para Python 2.x:
  python -m SimpleHTTPServer 12345

• para Python 3.x:
  python -m http.server 12345

... e naturalmente atualize os @require urls com esse número em vez de 8000.

Ok, suponha que eu clique no ícone da barra de ferramentas do GM e selecione "Novo script de usuário ...."

A nova guia correspondente é denominada automaticamente "Script sem nome 821696"

Em seguida, colo o código GM de um arquivo local no painel da guia e clico no ícone "salvar" no lado superior esquerdo.

Onde encontro mais tarde este script? Leia: Como posso editar este script posteriormente?

Como posso alterar o nome do script para, por exemplo, "foobar"?

@bsto O nome será obtido do script @name.
Todos os novos scripts aparecerão acima de "Novo script de usuário ...".
Para remover ou editar um clique no título do script, haverá um submenu.

Ok, obrigado.

Só mais uma pergunta:

Em 25 de novembro, o usuário kekkc nos disse em sua postagem (veja acima) que a Mozilla ofereceu uma maneira de arrastar e soltar arquivos (do WinExplorer).

Portanto, arrastar e soltar os arquivos do usuário deve ser possível agora.

Estou certo?

Quando será implementado no GM (disponível para arrastar e soltar arquivos * .user.js)?

FWIW, acho que podemos / devemos detectar a navegação para file://.../anything.user.js e anexar uma ação de página que poderia abrir uma IU com qualquer tipo de navegador de arquivos que possamos fazer funcionar.

Podemos detectar eventos de navegação, mas não obter conteúdo (talvez em um script de conteúdo)

Embora eu ache bobagem navegar para file:// apenas para abrir um navegador de arquivos (não acho que possamos fazer nada além de uma entrada do seletor de arquivos).

Embora eu ache bobagem navegar até um arquivo: // apenas para abrir um navegador de arquivos (não acho que possamos fazer outra coisa senão uma entrada do seletor de arquivos).

Sim, exatamente, estamos paralisados. Mas podemos detectar a intenção e ser o mais útil possível em nosso ambiente limitado.

Meus 2 centavos ...

FWIW, acho que podemos / devemos detectar a navegação para o arquivo: //.../anything.user.js ,
Podemos detectar eventos de navegação, mas não obter conteúdo (talvez em um script de conteúdo)

Como mencionado por Sxderp, é possível, mas um pouco confuso ...

• Adicione um ouvinte (como tabs.onUpdated.addListener já que você precisaria do conteúdo de qualquer maneira)
• Deixe a página carregar mostrando o script
• Injetar script de conteúdo para pegar o conteúdo da página e passar para o script bg
• Feche a página / guia

Alternativa ....

• Adicionar um ouvinte de navegação
• Interrompa o carregamento da página e exibe uma notificação para usar a opção de importação ... OU .... pop-up mostrando a opção de importação na qual o usuário deve clicar para iniciar o seletor de arquivos

Pessoalmente, se fosse eu, eu optaria por não adicionar ouvintes extras e simplesmente adicionaria a opção IMPORT ao pop-up browserAction

Além disso, não tenho usado o formato .user.js desde GM4 e acho que pode ser deixado para trás. ;)

Pessoalmente, se fosse eu, optaria por não adicionar ouvintes extras e simplesmente ..

Isso é o que eu quis dizer. Eu posso injetar interface do usuário na página de conteúdo, no entanto. Costumávamos abrir uma barra de informações se você navegasse até um script enquanto o GM estava desabilitado; esse tipo de coisas.

Além disso, não tenho usado o formato .user.js desde GM4 e acho que pode ser deixado para trás. ;)

O que isto significa?

O que isto significa?

GM3 exigia que os scripts fossem nomeados como abc.user.js para que pudessem ser reconhecidos como script GM.

No GM4, os scripts são salvos em IndexedDB e o nome do script realmente não importa, pois ele obtém o nome de @name . Portanto, tenho criado e salvo meus scripts (no computador) como abc.js (sem o .user ) e copie / cole no GM.

O manual IMPORT, eu imagino, não precisaria ser vinculado ao formato de nomenclatura .user .

Algum progresso nisso?

A extensão FireMonkey pode fazer isso:

https://addons.mozilla.org/en-US/firefox/addon/firemonkey/