Eu realmente acho que isso deve ser repensado. Tanto o VM quanto o TM se comportam de forma contrária a isso. Ao navegar para um script, você verá uma página que inclui o conteúdo / fonte do script e um botão de instalação. Embora seja tecnicamente "redirecionado", você ainda está, em essência, "navegando" para o script do usuário. Talvez isso deva ser trazido à lista de discussão -users e -dev e ver as opiniões dos outros?

Eu apóio a discussão da comunidade.

Pessoalmente, sou da opinião de que ~ ninguém revisa a fonte, então é uma coisa boba mostrá-la a todos os usuários, incluindo a maioria que nem consegue entendê-la.

E: revisar apenas a fonte principal, quando também há @require , realiza muito pouco.

Eu ficaria muito triste se a possibilidade de revisar o código-fonte não retornasse. Sempre me sinto mais confortável com a leitura do código. E se houver inclui @require que não aponta para uma biblioteca bem conhecida (jQuery oficialmente hospedada etc.), estou sempre cético e geralmente aborta a instalação a menos que eu realmente precise desse script (nesse caso, eu folheio o conteúdo de @require também).

Mas mesmo que eu seja uma exceção e a maioria das pessoas não olhe ou entenda o código, acho que há um efeito preventivo para os escritores de script saberem que o código-fonte é mostrado durante a instalação.

Caso você ainda decida não mostrar o código-fonte, adicione links de fácil acesso view-source: apontando para o código-fonte ao instalar um script (e de preferência também quaisquer scripts @require incluídos).

Como mencionei, também valorizo ​​a capacidade de revisão. Para a minoria de pessoas que o desejam. Só quero que funcione como o # 2567 para que você possa revisar _todas_ a fonte. Basta clicar em editar após a instalação e obter todos os recursos de fonte e texto visíveis. Habilite ou desinstale como você escolher.

Existem algumas implicações de desempenho ao exigir várias solicitações de rede. Especificamente, entre seu 3. e 4. há o "download até o ponto em que temos um metablock válido, para que possamos abrir a caixa de diálogo de instalação".

Digamos que o arquivo não seja um script de usuário real e não tenha um metablock válido. A caixa de diálogo de instalação nunca aparecerá. O único curso de ação que vejo é retomar a navegação. Assim que a navegação for retomada, o arquivo deve ser baixado novamente. Uma solicitação desnecessária (# 2830 resolve isso expandindo o que está sendo feito atualmente em onHeadersReceived ).

Você já fez isso antes e deve ser considerado. O que acontece se a conexão for lenta? Por exemplo, digamos que leve 10 segundos para fazer o download do arquivo. O usuário terá 10 segundos sem feedback enquanto o GM tenta fazer o download em busca de um script. Ele falha e o entrega ao navegador para continuar a navegação. Novamente outros 10 segundos baixando o arquivo para exibição.

Não vou dizer que não há maneira de contornar isso. Por exemplo, os dados podem ser armazenados em cache ou algo assim e, em seguida, sobrescrever a saída na navegação real. Mas eu sinto que isso leva a uma complexidade de código desnecessária apenas para proteger os usuários.

Como alternativa, você pode abrir a caixa de diálogo de instalação de qualquer maneira e apenas falhar ao instalar o arquivo não-script (o VM faz isso). Eu consideraria isso UX ruim.

Se alguém puder sugerir uma maneira limpa de fazer isso sem os pedidos extras, ótimo. Caso contrário, não posso apoiar isso sem benefícios _atuais_. [1]

[1] Você mencionou "poder revisar _todo_ o código-fonte" devido a # 2567 como um benefício potencial. Mas eu discordo. Eu sinto que # 2567 deve ser um recurso _ independentemente_ de se o código-fonte está disponível na instalação ou não.

Eu não sei. Em outros tópicos, pude abordar depois de alguma discussão. Mas este é um que eu simplesmente não estou "vendo".

Do meu ponto de vista, não me importo se o script ficará imediatamente visível, mas acho que se cancelar a instalação ou algo assim, poderei ver o arquivo bruto como faria se o greasemonkey não estivesse instalado. Eu realmente não me importo se ele está oculto por padrão ou algo assim, mas alguma forma de descartar a caixa de diálogo de instalação e voltar ao script parece crítica.

Não acho que faça sentido interromper a visualização de coisas chamadas *.user.js . Isso está removendo a funcionalidade do navegador.

Eu vejo um script de usuário mais como uma extensão do que uma página da web. Você também nunca navega para uma extensão. Você baixa / instala ou não.

Não acho que faça sentido interromper a visualização de coisas chamadas * .user.js. Isso está removendo a funcionalidade do navegador.

Ele também está fazendo coisas exatamente como as versões anteriores do GM - incluindo não tocar nas navegações quando desativado. Se você precisa desesperadamente ver isso em seu navegador, desligue o GM primeiro.

Eu vejo um script de usuário mais como uma extensão do que uma página da web. Você também nunca navega para uma extensão. Você baixa / instala ou não.

Eu discordo desse raciocínio. Uma extensão é um pacote de arquivos arquivados. Um script de usuário não é. Você poderia argumentar sobre @requires e @resources mas acho isso tênue. Nem todos os usam e muitos deles são apenas texto simples. Quando você navega para uma página de texto bruto, geralmente (presumindo que o cabeçalho do anexo / download não esteja definido. O que eu também acho irritante) não é obrigado a baixá-lo antes de visualizá-lo.

Ele também está fazendo coisas exatamente como as versões anteriores do GM faziam

Claro, mas não acho que esse seja um grande argumento a favor ou contra qualquer recurso específico. A versão anterior pode fornecer uma linha de base, mas, no futuro, acho que tudo deve ser reexaminado em novos contextos. Isso inclui a complexidade do código, benefícios que ele incute ou não, méritos, etc.

Você também nunca navega para uma extensão. Você baixa / instala ou não.

Ser um arquivo de texto faz a diferença. Por exemplo, o github tem uma opção "view raw" que agora está quebrada.

incluindo não tocar nas navegações quando desativado.

É bom saber disso. Eu acho que posso ter adivinhado isso, mas realmente não é óbvio. Só estou confuso porque estava tentando visualizar um arquivo e ele não é renderizado. Talvez pudéssemos fornecer uma dica ao usuário de que isso pode ser feito quando o encontrar, em vez de exibir uma página em branco.

Eu valorizo ​​tomar decisões de design que forneçam o maior valor para a maioria dos usuários, então eu valorizo ​​a entrada.

No entanto, este será um caso raro em que estou batendo o pé. Não se preocupe em debater abordagens. Desejo o comportamento de: há um link para um script de usuário válido, clico nesse link, vejo (apenas) a caixa de diálogo de instalação e nunca navego para um arquivo de texto, nunca de fato vejo a fonte. Vou fazer o que for preciso para fazer o Greasemonkey agir dessa forma. Período.

Antes do WebExt, conseguíamos isso usando http-on-modify-request , para suspender qualquer solicitação que parecesse um script do usuário o mais rápido possível. Iríamos acionar a caixa de diálogo de instalação e iniciar uma operação RemoteScript para baixar todas as partes, tudo em novas solicitações. Se isso detectasse um não-script de usuário (ou seja, HTML) em uma URL semelhante a um script de usuário, isso cancelaria a solicitação que ele possui e ... algo iria reiniciar a navegação (acho que retomando o canal exatamente, mas Não consigo encontrar isso).

Com um script lento , nada acontece a princípio - uma vez que a parte ==UserScript== é carregada, a caixa de diálogo de instalação aparece, então sua barra de progresso é preenchida conforme o resto é baixado - o resto do script, o recurso, requer etc.

Ele consegue baixar o script com apenas uma conexão com o servidor.

No WebExt, todas as APIs são diferentes, é claro, mas o evento de bloqueio / filtragem onHeadersReceived já em vigor no HEAD _parece_ ser a melhor coisa a se usar. Eu ainda tenho que fazer pesquisas.

Desejo o comportamento de: há um link para um script de usuário válido, clico nesse link, vejo (apenas) a caixa de diálogo de instalação e nunca navego para um arquivo de texto, nunca de fato vejo a fonte. Vou fazer o que for preciso para fazer o Greasemonkey agir dessa forma.

Mas esta é uma mudança para o antigo comportamento. GM 3.x Tive a opção de clicar em ver o código-fonte em vez de instalar e nada foi instalado, mas obtive uma guia que exibia o código-fonte do script. A partir daí tive a possibilidade de instalar ou apenas fechar a aba e não fazer nada. Esse seria o comportamento que eu gostaria pelo menos de ver novamente. Para mim, não é necessário exibir sempre o código-fonte, mas uma opção de inspecioná-lo antes de instalar qualquer coisa como estava antes seria ótimo.

O motivo dessa solicitação é que vi os danos que scripts maliciosos podem causar e, portanto, sempre inspeciono a fonte antes de instalar qualquer coisa. Este é o motivo pelo qual também vejo a atualização automática silenciosa como um problema, pois pode trazer novos códigos maliciosos para o usuário.

Com webRequest você pode retornar uma URL falsa para abortar o carregamento e fazer com que o navegador fique onde está. Mas fazer isso aborta imediatamente a conexão, você também não pode usar o filtro para observar / analisar / alterar o conteúdo, então você precisará iniciar uma nova conexão. Acho que está tudo bem neste caso, porque temos todos os dados de que precisamos (método de solicitação, cabeçalhos de resposta) no escopo e, portanto, podemos tomar uma decisão segura sobre se este é realmente um script de usuário ou não, e também bem no início do ciclo de solicitação.

Eu tive a opção de .. inspecionar antes de instalar qualquer coisa ...

2567

E se parecer um script de usuário, mas não for? Por exemplo, se você pegar seu exemplo de carregamento lento e apenas remover o // ==UserScript== . Abra-o na 3.x, a caixa de diálogo de instalação nunca é aberta (correta) e o conteúdo do texto é gravado na guia / página. Com o WebEx, se você criar uma nova conexão em segundo plano, não vejo como você pode escrever o conteúdo da página. Pelo que eu sei, a única maneira direta de escrever algum conteúdo em uma página em segundo plano é por meio do filtro de fluxo.

Posso pensar em algumas maneiras de "contornar" isso. Mais uma vez, não há boas soluções. Passe os dados para um script de conteúdo que apenas ecoará o conteúdo (deve ser factível, eu acho). Redirecione para uma página de extensão, mas isso quebrará a história. Ou faça com que o FF reinicie a solicitação com algum sinalizador definido para ignorar a verificação do script. Mas então esse é um terceiro pedido ..

Talvez eu esteja faltando alguma coisa ..

Abra-o na 3.x, a caixa de diálogo de instalação nunca é aberta (correta) e o conteúdo do texto é gravado na guia / página.

Eh, eu gostaria de corrigir este ponto. Eu estava incorreto, cometi um erro de digitação em user quando fiz o teste inicial.

@Sxderp, deixe-me repetir que valorizo ​​muito as contribuições que você fez até agora e espero que continue.

Mas para um pouco mais de clareza quanto à minha decisão delineada acima: limpei meu trabalho em andamento; primeiro movi algum trabalho não relacionado para separar commits . O que sobrou é uma renomeação de arquivo e então este grande commit , que é de apenas + 425 -491.

A classe Downloader encapsula toda a lógica sobre (baixar e) instalar um script, independentemente da fonte. Você só precisa configurar as entradas - apenas a URL para uma instalação, mas também a fonte do script principal e talvez o conteúdo do requerimento / recurso se já conhecido (para o caso de edição), ele baixa tudo o que está faltando (ou seja, edite em um novo requer / recurso) e passa sempre um mesmo formato para user-script-regstry que o persiste de apenas uma maneira. Todo o downloader.js tem menos de 250 linhas. Como resultado, há menos mensagens passadas entre o fundo / conteúdo e nenhuma porta nova.

Às vezes, faz muito sentido dividir uma grande parte complexa do código em partes menores e mais simples. Mas IMO não é isso. Os dados que circulam são os mesmos, quer estejamos instalando um "novo" script, atualizando um ou editando um no local. Apenas pequenas coisas mudam (já sabemos o UUID do script já instalado? Já sabemos ou precisamos fazer o download deste ou daquele?).

Isso também resolve a estrutura recursiva de parsedDetails (há um problema em algum lugar, não tenho tempo para procurá-lo)?

Eu não sei. Eu duvido?

Isso também resolve a estrutura recursiva de parsedDetails (há um problema em algum lugar, não tenho tempo para procurá-lo)?

Você quer dizer # 2806?