Greasemonkey: WebExt: Mendukung semua GM API

bug1323433 dan bug1332273 mungkin menarik di sini.

Terima kasih atas petunjuknya, saya setuju keduanya sangat berguna.

Oh, mungkin sejumlah pengiriman pesan sinkron dimungkinkan!

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/onMessage#Sending_a_synchronous_response

Uji ini. Apakah ini memungkinkan untuk menggunakan implementasi sinkron sederhana (didukung oleh API khusus latar belakang) untuk metode yang disebutkan di atas?

Itu mengembalikan janji di sisi konten, sehingga secara efektif async. saya pikir "sinkron" adalah keliru di sini, ini lebih seperti memasangkan pesan dari anak ke orang tua dengan respons sehingga seseorang tidak harus secara manual melacak respons yang tertunda.

Afaik, satu-satunya API sinkron yang tersedia adalah sinkronisasi XHR yang kemudian dapat dicegat dengan permintaan web atau semacamnya.

Sinkronisasi XHR tidak berfungsi dengan baik di skrip konten: https://bugzilla.mozilla.org/show_bug.cgi?id=1360968, jadi saat ini kami tidak memiliki saluran sinkronisasi dari konten > latar belakang.

Sepertinya GM_setValue dan GM_getValue dirancang sebagai operasi sinkronisasi dan dalam browser proses tunggal mereka berfungsi dengan baik ketika kami beroperasi di banyak tab, tetapi di e10 tidak (https://github.com/greasemonkey /greasemonkey/issues/2427). Dengan API ekstensi lama dapat dengan mudah diperbaiki, tetapi di WebExt tidak. Tanpa pesan sinkronisasi (bahkan untuk data kecil, hanya memancarkan nilai pendek) kami tidak dapat menyinkronkan nilai dengan benar di antara lebih banyak tab. di beberapa titik ini akan selalu menjadi kondisi balapan.

Terlepas dari bagaimana Anda memecahkan masalah di atas dalam versi WebExt, kita harus mendapatkan metode set/get baru yang dirancang dengan cara asinkron, jadi di mana penting kita dapat menulis skrip dengan cara asinkron. Dokumentasi harus memiliki beberapa informasi tentang kurangnya perilaku GM_setValue dan GM_getValue ketika beroperasi pada banyak tab.

imo, sangat jarang kasus penggunaan yang menggunakan GM_setValue / GM_getValue pada banyak tab dan urutannya harus diikuti. akibatnya, menyimpan salinan (cache) dari _GM_values_ dalam skrip konten, selalu membaca dari cache, menulis kembali asinkron, dan memperbarui cache dengan peristiwa yang dipicu oleh skrip latar belakang harus menjadi solusi yang dapat diterima.

btw, jika demikian, tambahkan API yang setara dengan GM_addValueChangeListener sangat bagus jika memungkinkan. (dan saya tidak suka nama addValueChangeListener sesuatu yang lain harus lebih baik mungkin

Dalam saya cabang dev ada dukungan untuk:

• GM.getResourceURL
• GM.deleteValue , GM.getValue , GM.listValues , GM.setValue

Saya berencana untuk tidak pernah menambahkan :

• GM_log
• GM_addStyle

Kami masih membutuhkan :

• GM_xmlhttpRequest

Saya berencana untuk menunda (atau mungkin menjatuhkan):

• GM_registerMenuCommand (yang ini selalu menjadi biaya dukungan yang sangat besar)
• GM_getResourceText

Yang berarti kemajuan di sini sebenarnya cukup dekat.

Umpan balik yang bagus di komit di atas, jangan lupa.

Saya baru saja mencoba add-on baru. Tampaknya permintaan xhr lintas domain telah diaktifkan tanpa fitur GM_xhr. Apakah ini memang perilaku?

Coba saja userscript grant none dengan kode berikut:

fetch(prompt()).then(resp => resp.text()).then(text => alert(text)).catch(error => alert(error));

Eh, dikonfirmasi. Saat ini kami menjalankan skrip pengguna sebagai "skrip konten" -- dari ekstensi, dengan semua izin ekstensi.

Saya telah melihat hal ini sedikit, tetapi sejauh ini saya tidak tahu bagaimana cara mengeksekusi kode unprivileged ("lingkup web" -- apa yang kita sebut ini sekarang karena lingkup "konten" ambigu?!). Hal terdekat yang dapat saya temukan adalah semua tentang membuat tag skrip, yang dapat/akan diblokir oleh CSP halaman, yang pasti tidak saya inginkan.

Saat ini satu-satunya cara untuk memodifikasi CSP adalah dengan mencegat dan memodifikasi header untuk setiap permintaan Dokumen. Ada masalah terbuka untuk mengecualikan ekstensi web dari CSP konten tetapi tampaknya tidak ada banyak aktivitas pada itu.

Selain menyuntikkan tag <script> window.eval juga harus berjalan di lingkup halaman, saya pikir.

Istilah resminya adalah "lingkup skrip konten" vs. "lingkup halaman".

Masalah lainnya adalah mereka memerlukan pemrosesan string untuk membungkusnya dalam lingkup terpisah yang dapat mendefinisikan GM API.

Saya juga telah mengajukan bug untuk Sandbox setara di webextensions, tetapi itu juga bukan prioritas tinggi.

AIUI baik skrip maupun eval rentan terhadap pemblokiran oleh CSP. Tetapi saya telah mengkonfirmasi bahwa eval menjatuhkan hak istimewa.

https://bugzilla.mozilla.org/show_bug.cgi?id=1391669

Kita harus memiliki <all_urls> jika kita berpotensi menjalankan skrip konten di halaman mana pun. Jika kami meminta itu, maka skrip konten kami mendapatkannya, dan dengan demikian dapat XHR ke mana saja.

Setidaknya di Firefox ( https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Content_scripts#Using_eval ()_in_content_scripts ) kami dapat turun ke cakupan halaman, tetapi kemudian kami benar-benar cakupan halaman dan kami tidak dapat dengan aman mengekspos API ke skrip tanpa memaparkannya ke apa pun/semua yang berjalan di halaman (AFAIK), yang bahkan lebih buruk.

Bisakah fetch dan xhr ditimpa dalam skrip konten?
Mungkin memberikan pengambilan yang dimodifikasi yang melakukan pemeriksaan CORS sendiri.

• GM.xmlhttpRequest() telah ditambahkan di 60a50d05b1e565571d8a3e638b0683a1a9c2beaa
• GM.getResourceText() akan dibahas dalam #2548
• GM.registerMenuCommand() sengaja dilewati.
• Setiap skrip yang mewarisi pengambilan silang (sesuai komentar di atas) adalah #2549

@ the8472 Lihat implementasi withUnsafeWindow() di https://github.com/greasemonkey/greasemonkey/issues/2232#issuecomment -326841025

Ini meniru perilaku fungsi with (object) ... , hanya sedikit lebih aman. (Perlu browser modern.)

@arantius menulis pada 25 Juli :

Saya berencana untuk tidak pernah menambahkan :

GM_log
GM_addStyle

Ini dilambangkan dalam pembuatan tiket ini (oleh @arantius pada 3 Mar ) sebagai hal yang sepele (dengan asumsi pemetaan GM_log ke console.log).

Dalam pengalaman saya, ini adalah dua panggilan API yang paling umum digunakan. Bukankah mengabaikannya akan merusak banyak skrip lama tanpa alasan? Atau apakah Anda secara eksklusif merujuk ke cabang dev?

Di Tampermonkey, GM_addStyle memiliki kemampuan khusus untuk menyuntikkan gaya yang dapat melewati batasan CSP (jika <style> inline dilarang). Saya akan senang jika kita dapat memiliki fitur ini di Greasemonkey juga.