Como os códigos de script do usuário estão realmente envolvidos em uma função async , fornecer um polyfill usando @require não funcionará se o script do usuário tiver await no nível superior.

Talvez um polyfill como:

async function main (GM) {
  // UserScript code goes here...
  await GM.setValue('foobar', 123)
  let value = await GM.getValue('foobar') // -> 123
}

typeof GM === 'object' ? main(GM) : main({
  info: GM_info,
  getValue: function (key, def) {
    return Promise.resolve(GM_getValue(key, def))
  },
  setValue: function (key, value) {
    return Promise.resolve(GM_setValue(key, value))
  }
})

Você precisa ter certeza de que envolveu todo o código em uma função assíncrona. Caso contrário, não funcionará no GM legado!

(async () => {

if (typeof GM === "undefined") {
    GM = new Object();
    GM.info = GM_info;
    GM.listValues = function() {
        return Promise.resolve(GM_listValues.apply(null, arguments));
    };
    GM.getValue = function() {
        return Promise.resolve(GM_getValue.apply(null, arguments));
    };
    GM.setValue = function() {
        return Promise.resolve(GM_setValue.apply(null, arguments));
    };
    GM.deleteValue = function() {
        return Promise.resolve(GM_deleteValue.apply(null, arguments));
    };
    GM.xmlhttpRequest = function() {
        return Promise.resolve(GM_xmlhttpRequest.apply(null, arguments));
    };
}

console.log(GM.info);
console.log(await GM.listValues());
})();

Acabei de fazer meu maior script (cerca de 5000 linhas) compatível com GM3 e posso dizer: Não é legal.

O script usa muitas funções e apenas algumas delas usam a API GM. Portanto, essas funções devem ser assíncronas. Mas se a função de chamada depende do trabalho da função chamada, você também precisa aguardar essa função, portanto, é necessário assíncronizar a função de chamada ... e assim por diante.

Melhor seria reescrever todo o roteiro e apenas torná-lo assíncrono como um todo. Mas isso seria um pé no saco ...

A) Eu comecei o script polyfill, se você quiser uma visualização:
https://arantius.com/misc/greasemonkey/imports/greasemonkey4-polyfill.js

B) Certifique-se de incluir nas alterações de caso de documentação: GM_xmlhttpRequest torna-se GM.xmlHttpRequest ; GM_getResourceURL torna-se GM.getResourceUrl ; talvez outros.

Testará o polyfill, mas salva apenas cerca de 30 linhas de código. O maior problema é fazer um script de sincronização rodar com partes assíncronas ^^

Polyfill funciona, mas:

a) GM.info é uma função, mas precisa ser uma matriz / objeto
b) Eu, pessoalmente, acho que seria melhor reverter o polyfill: Portanto, você precisa chamar GM.listValues ​​() em vez de GM_listValues ​​(). Isso mostra que o script está pronto para GM4.

@arantius Eu vi que GM_registerMenuCommand foi substituído pelo menu de contexto HTML5. Existe algum plano para adicioná-lo ao GM 4.x? Não consigo encontrar o problema de rastreamento.

Eu não testei, mas pode ser uma boa ideia não sobrescrever APIs existentes

function GM_addStyle(...) {...}
// v.s.
if (!this.GM_addStyle) {
    this.GM_addStyle = function(...) {...};
}

O openInTab também foi excluído do gm4 ???

o mesmo que https://github.com/greasemonkey/greasemonkey/issues/2559#issuecomment-332227253 b) Eu preferiria codificar no estilo GM4 agora e para sempre, em vez de seguir o antigo estilo de API

e o mesmo que https://github.com/greasemonkey/greasemonkey/issues/2559#issuecomment -332382317, na verdade, não entendo como isso funcionaria com o GM4

e um falso no segundo comentário no arquivo, há 2 gm4, um deve ser "gm antes de 4" ou algo assim

Eu, pessoalmente, acho que seria melhor reverter o polyfill: então, você precisa chamar GM.listValues ​​() em vez de GM_listValues ​​().

Não tenho certeza do que você quer dizer, que (chamar APIs de novo estilo) já é o modelo pretendido. O que o polyfill faz é fazer com que as chamadas de API de novo estilo funcionem em gerenciadores de script de API antigos.

Eu vi que GM_registerMenuCommand foi substituído pelo menu de contexto HTML5. Existe algum plano para adicioná-lo ao GM 4.x?

Não. A política do Greasemonkey tem sido (por muito tempo) não implementar recursos de "espaço do usuário". Qualquer script pode fazer isso, ou @require algo como este polyfill que faz isso. O Greasemonkey não precisa construir nem suportar esse recurso para habilitar scripts para usá-lo. O objetivo aqui é apenas fazer o que o polyfill faz: tornar mais fácil atualizar os scripts para serem compatíveis com as versões antigas e novas do Greasemonkey.

Não. A política do Greasemonkey tem sido (por muito tempo) não implementar recursos de "espaço do usuário". Qualquer script pode fazer isso, ou @require algo como este polyfill que faz isso. O Greasemonkey não precisa construir nem suportar esse recurso para habilitar scripts para usá-lo. O objetivo aqui é apenas fazer o que o polyfill faz: tornar mais fácil atualizar os scripts para serem compatíveis com as versões antigas e novas do Greasemonkey.

Eu quis dizer se o GM4 também fornecerá uma API para executar comandos de script da IU do gerenciador de userscript como o antigo GM_registerMenuCommand, sem perguntar se haverá uma API de menu de contexto HTML5 no GM. GM_registerMenuCommand é frequentemente usado para iniciar a caixa de diálogo de configuração do script, que não deve ser polyfilled como um IMHO de menu de contexto HTML5.

BTW, eu criei uma biblioteca para trabalhar com o menu contextual HTML apenas alguns meses atrás, que reutilizaria a propriedade contextmenu na página se ela já estiver definida:
https://github.com/eight04/GM_context

GM_registerMenuCommand é frequentemente usado para iniciar a caixa de diálogo de configuração do script, que não deve ser preenchida como um IMHO de menu de contexto HTML5

Por que não?

Há mais trabalho a fazer, especialmente atualizar o wiki, mas a postagem no blog já é um progresso suficiente por enquanto ...

Por que não?

1. O comando no menu de contexto deve ser:

   • Uma ação que funciona em um contexto (elemento) especificado. Por exemplo, quando algum texto é selecionado, o comando "Copiar", que é uma ação para trabalhar com a seleção, é mostrado.
   • Um atalho para executar o comando especificado por conveniência.

   Um comando "My userscript setting" não se enquadra em ambas as categorias. Não depende do contexto, também não há necessidade de usar um atalho para configuração.

2. Não é confiável. Ele pode ser bloqueado / substituído por scripts de página.

Eu concordo com as dificuldades de nível conceitual. Não tenho mais extensões que usam o menu de contexto para configurações. Ficaria muito ocupado rapidamente se o fizessem, já que executo muitas extensões.

Mas a principal razão que vejo é que o Chrome removeu o menu de contexto HTML5 das especificações , o que significa que provavelmente será removido do Firefox também. Eu nem sabia que ele existia, visto que nunca vi nenhum site usá-lo. Os aplicativos simplesmente giram por conta própria, bloqueando o menu de contexto real (o que é um aborrecimento enorme na maioria dos casos. Isso remove a funcionalidade).

Além disso, uma pergunta: haverá alguma maneira de injetar no início do documento? Ou agora também é assíncrono? A injeção no início do documento é o principal motivo pelo qual ainda trato o Greasemonkey como meu mecanismo de desenvolvimento principal (embora o Chrome seja meu navegador principal agora). Eu odeio pop-in.

Além disso, uma pergunta: haverá alguma maneira de injetar no início do documento?

2526

Eu empurrei meu primeiro userscript FF57 com compatibilidade com versões anteriores para o upstream hoje.

Deu bastante trabalho fazer tudo funcionar, mas acho que consegui.

Você pode querer dar uma olhada nele: http://wod.zerosgaming.de/scripts/mm_skills/mm_skills_0_23.user.js