Greasemonkey: Kompatibilitas WebExtension

Aku sudah memikirkan ini banyak. Saya tidak memiliki "keputusan" yang jelas, tetapi beberapa poin:

• Kami _hanya_ menyelesaikan proses porting untuk kompatibilitas e10s. Jauh lebih sulit ketika kami memulai; misalnya Services.ppmm dan .cpmm adalah cara pintas yang bagus, yang akan menyenangkan untuk diandalkan sejak awal, tetapi mereka tidak ada ketika kami (secara bertanggung jawab) memulai.
• Pekerjaan itu panjang dan sangat menyakitkan, dan saya tidak berharap untuk mengulanginya secara efektif.
• Peluncuran e10s telah tergelincir dari Firefox 36 (per Sep 2014) ke Firefox 42 (mulai sekarang, Sep 2015), atau setidaknya sembilan bulan.
• Pengumuman mengatakan hanya ekstensi web setidaknya 1 atau 2 tahun lagi; itu akan tergelincir ke 2, 3, 4 tahun dari sekarang?
• Jika kita akan melakukan ini, saya pikir ini waktu yang tepat untuk membuat terobosan bersih dan merancang ulang.
  
  
  
  • Saya mendapati diri saya berharap kami memiliki tes unit yang baik semi-sering, meskipun kami memiliki banyak masalah yang tidak akan pernah mereka tangkap, kami juga memiliki beberapa yang akan mereka miliki.
  
  
  • Kami akhirnya dapat menambahkan dukungan Android?
  
  
  • Kami tidak harus benar-benar menulis ulang dari awal, tetapi dengan mempertimbangkan kode mana yang kami pertahankan dan mana yang kami jatuhkan mungkin diperlukan.
  
  
• Saya sangat menyukai hubungan Greasemonkey/Mozilla yang jauh lebih kuat sebelum kita memulai tugas lain sebesar ini. Saya hanya memiliki tebakan yang lemah tentang bagaimana mewujudkannya.
  
  
  
  • Saya pikir kami secara efektif merupakan ujian siksaan untuk porting ke sesuatu seperti ekstensi web hari ini; selama bertahun-tahun kami telah membangun beberapa fitur canggih. Komunikasi dua arah sebagai bagian dari rencana mungkin akan banyak membantu.
  
  

Memulai dengan dokumen desain akan menjadi ide bagus. Pada dasarnya kita perlu merekayasa balik semua Greasemonkey seperti yang ada ke dalam rencana untuk cara yang baik, daripada cara yang tumbuh secara organik yang tidak direncanakan, agar semuanya terstruktur.

misalnya Services.ppmm dan .cpmm adalah cara pintas yang bagus, yang akan menyenangkan untuk diandalkan sejak awal, tetapi mereka tidak ada ketika kami (secara bertanggung jawab) memulai.

Saya tentu saja belum menganjurkan menggunakan WebExtensions, mereka masih belum matang untuk sesuatu seperti GM

Kami tidak harus benar-benar menulis ulang dari awal, tetapi dengan mempertimbangkan kode mana yang kami pertahankan dan mana yang kami jatuhkan mungkin diperlukan.

Hrm, yah, saya melihatnya sebagian besar dari POV teknologi. Saat ini UI menggunakan overlay XUL dan eksekusi skrip langsung di lingkungan chrome bersama.

Jadi mengonversi sesuatu menjadi HTML dan menjalankan setiap hal dalam konteks jendela independen dan hanya berkomunikasi melalui penyampaian pesan tampaknya merupakan hal yang seharusnya dilakukan di masa mendatang.

Manajer pesan pada dasarnya adalah tingkat terendah di mana itu diterapkan. Abstraksi tingkat yang lebih tinggi dibangun di atasnya. Saluran WebChannel.jsm/BroadcastChannel/MessageChannel/WebExtension dan semacamnya.

Memulai dengan dokumen desain akan menjadi ide bagus.

Akankah GH wiki menjadi tempat yang tepat untuk itu? Apakah itu melakukan notifikasi saat diedit untuk membuat pekerjaan kolaboratif menjadi sederhana?

Saya pikir kita sebagian besar membutuhkan fitur / daftar pipa internal dan bagaimana menerapkan masing-masing dengan cara yang bersih.

Jika Anda tertarik dengan topik masalah ini, silakan baca:

https://groups.google.com/d/topic/greasemonkey-dev/K6IyDUWnTQc/discussion

Terima kasih!

Relevan:

• https://bugzilla.mozilla.org/show_bug.cgi?id=1271553
• https://bugzilla.mozilla.org/show_bug.cgi?id=1334174

https://developer.mozilla.org/en-US/docs/Web/API/File_and_Directory_Entries_API/Introduction

Ini adalah API yang sangat menarik, tetapi "Fitur ini tidak standar dan tidak berada pada jalur standar" dan kompatibilitasnya sangat terbatas.

Semua upaya saya baru-baru ini (lihat #2483, #2484) dalam merancang fitur lengkap Greasemonkey-under-WebExtensions telah membuat frustrasi. Saya mulai mempertimbangkan gaya pengembangan yang lebih progresif: pilih serangkaian fitur yang lebih terbatas dan dukung hanya itu. Jadilah sedikit berguna, lalu semoga menemukan jalan menuju lebih banyak fungsi nanti.

Memeriksa instalasi 3.x saya, saya melihat bahwa (bagi saya) setiap skrip adalah <strong i="6">@grant</strong> none . Dari 27, hanya enam yang menggunakan @run-at document-start , dan sebagian besar akan berfungsi setidaknya dengan baik jika tidak didukung. Fitur @require banyak digunakan, dan @resource cukup sering digunakan.

Jadi itu sepertinya target yang layak untuk dituju terlebih dahulu: Mendukung skrip pengguna biasa dalam mode <strong i="12">@grant</strong> none , tidak ada dukungan untuk API GM_ . Dukung @require . Berharap untuk mendukung @resource entah bagaimana, mungkin tidak efisien.

(Catatan tambahan, karena saya selalu melupakannya: Rencanakan untuk menggunakan sourceURL untuk membuat kesalahan sedikit lebih mudah dibaca. Lihat apakah beberapa sourceURL didukung, atau apakah kita harus (bisakah?) membuat sourceMap, dengan memperhitungkan @require menjadi pertimbangan.)

Kami mendapatkan akses ke API Web biasa selain yang WebExtension, jadi:

https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API

? Berapa batas penyimpanan IndexedDB, untuk WebExtension? Ini sepertinya pilihan yang jauh lebih baik daripada storage.local . Antarmukanya bukan yang paling sederhana, tetapi memberi kita lebih banyak kekuatan untuk memisahkan skrip dari satu sama lain dan melakukan pembacaan selektif. Menurut saya. Documents juga bukan yang termudah untuk digunakan.

https://github.com/mdn/webextensions-examples/pull/171 tampaknya memiliki diskusi dan contoh yang berharga untuk IndexedDB

Saya telah membuat beberapa kemajuan.

https://github.com/arantius/greasemonkey/tree/webbymonkey (di 88d53b4c67b7825858405eb2591f27c8487ce413 )

Diimplementasikan kembali dari awal. Periksa, buka about:debugging , tekan "Muat Pengaya Sementara" dan pilih file apa saja dari lokasi root. Anda dapat menginstal dan hampir tidak menjalankan skrip pengguna. Sama sekali belum ada fitur lain. (Yah, ada menu monyet, tapi itu palsu kosong yang tidak melakukan apa-apa selain terlihat OK.) Banyak TODO tersebar di sekitar kode bahkan untuk set fitur kecil ini. Tidak dapat menjamin semua ini adalah "jalan yang benar" menuju lebih banyak fitur atau tidak.

Karena versi Tampermonkey yang lebih lama, serta Violentmonkey, adalah open source, dapatkah sebagian dari kode itu digunakan di sini, karena WebExtensions mirip dengan Chromium Extensions?
EDIT: Sebenarnya, melihatnya, saya tidak yakin tentang kompatibilitas lisensi dengan Tampermonkey lama. Tapi Violentmonkey berlisensi MIT, jadi kompatibel.

@PorygonZRocks : Violentmonkey menjadi Greasemonkey?

Saya tidak terlalu berpengalaman dengan pengkodean, tetapi saya pikir setidaknya ada beberapa pedoman dalam mengimplementasikan sesuatu. Sekali lagi, tidak terlalu berpengalaman/berpengetahuan, jadi saya mungkin salah.

Perlu dicatat bahwa FF56 menonaktifkan semua add-on yang kompatibel dengan non-multiproses sehingga tenggat waktu mungkin perlu diubah.

Lihat cabang dev saya. Yang cukup kasar tetapi berfungsi minimal. Ini sedang dilakukan, tidak ada yang perlu dilacak secara khusus dalam masalah cakupan luas ini.

@arantius Karena penasaran, apakah Anda menulis kode baru atau menggunakan kembali yang lama?

Apakah Anda memerlukan bantuan?

Lagi-lagi karena penasaran, misalnya, apakah tujuan dari "parse-meta-line.js" hanyalah untuk mengurai meta data menjadi sebuah objek?

@arantius Karena penasaran, apakah Anda menulis kode baru atau menggunakan kembali yang lama?

Sebagian besar baru. Menyalin kapan/di mana itu membantu. (Sejauh ini, penguraian skrip adalah contoh besar.)

Apakah Anda memerlukan bantuan?

Bantuan akan menyenangkan. Koordinasi akan sulit.

Lagi-lagi karena penasaran, misalnya, apakah tujuan dari "parse-meta-line.js" hanyalah untuk mengurai meta data menjadi sebuah objek?

Satu baris, ya.

Satu baris, ya.
Maksud saya, apakah itu melakukan hal lain kecuali menguraikan data meta di antara ini:

// ==UserScript==
....
// ==/UserScript==

Sepertinya banyak kode jika itu satu-satunya tujuan.

Ya itulah yang dilakukannya. Ini kode yang dihasilkan. Silakan bawa diskusi ini ke https://groups.google.com/d/topic/greasemonkey-dev .

Saya tidak menggunakan grup Google :(
Jika itu aku... Aku mungkin akan melakukannya secara berbeda.

Grup google sudah tidak ada.

Tautan buruk: https://groups.google.com/forum/#!forum/greasemonkey -dev

Tidak sepenuhnya yakin apakah ini adalah lokasi yang tepat untuk itu, tetapi ini dia. Jika Anda ingin saya membuka edisi terpisah @arantius , tentu saja.
Bukankah 4.0.0 seharusnya memigrasikan skrip yang ada? Saya memperbarui ke alpha 3 (berasal dari non-beta terbaru) dan menyadari bahwa saya tidak memiliki skrip lagi.

@Phyxion , jika Anda menginstal 3.14 maka skrip harus dimigrasi. Pastikan Anda me-restart browser setelah menginstal.

Setelah itu ketika Anda menginstal 4.x Anda harus memiliki skrip. Jika tidak, maka beberapa langkah reproduksi mendetail dalam edisi baru akan sangat membantu.

Greasemonkey 4 alpha tidak kompatibel dengan Firefox 57.

@erkinalp , Bisakah Anda menjelaskannya? Saya telah menggunakan 4alpha2 untuk banyak pengujian dan modifikasi saya, itu berfungsi, meskipun tidak semua fitur di 3.x tersedia. Saya belum menarik perubahan di 4alpha3, jadi saya tidak tahu beberapa komit untuk versi itu merusak apa pun.

@Sxderp Nah, mereproduksinya di mesin saya itu mudah. Saya telah menginstal 3,14 dengan 10 skrip pengguna. Buka AMO dan unduh alpha terbaru. Mulai ulang saat diminta. Maka itu hanya mengatakan tidak ada skrip pengguna yang diinstal. Tidak yakin seberapa berguna ini untuk mereproduksinya.

Saya belum menguji ini tetapi saya yakin GM4 akan kehilangan konfigurasinya setelah uninstall, sementara GM3 harus menyimpannya , jadi saya sarankan Anda mencoba:

1. Hapus sepenuhnya Greasemonkey
2. Mulai ulang Firefox
3. Instal Greasemonkey 3.14 (termasuk restart)
4. Mulai ulang Firefox untuk ukuran yang baik
5. Instal Greasemonkey 4 (titik apa saja)

Apakah itu membantu?

Saya pikir tingkat atas menunggu - yaitu membungkus semuanya dalam fungsi async - bukanlah pilihan desain yang baik karena membatasi implementasi di masa mendatang (misalnya jika/ketika kita mendapatkan kembali kotak pasir atau alam masa depan). Itu membuat hal-hal tidak konsisten dengan eksekusi Vanilla JS di mana menunggu tingkat atas tidak tersedia dan skrip dijalankan ... yah ... di tingkat atas.

@arantius
Masih tidak ada apa-apa di sini :(
BTW, 4.0 seharusnya terlihat seperti ini: https://i.imgur.com/CPuWWKM.png
Tidak ada tombol atau apa pun untuk menambahkan skrip.

... membungkus semuanya dalam fungsi async ...

Dengan apa yang tersedia sekarang saya "harus" membungkus suatu fungsi untuk tujuan ruang lingkup. Saya pikir saya membeli alasan Anda untuk tidak membuatnya asinkron. (Setidaknya, menambahkan fungsi pembungkus async dalam skrip itu sendiri adalah hal yang sepele.)

Ya, itu sebagian besar tentang async/menunggu, karena saat ini sengaja tidak diizinkan di javascript , jadi mengaktifkannya di skrip pengguna sepertinya berbahaya untuk perubahan di masa mendatang. Saya tahu bahwa pembungkus saat ini tidak dapat dihindari, tetapi saya berharap semuanya dapat dipindahkan kembali ke tingkat atas di masa depan.

@arantius Mengapa suara turun?

@arantius berkomentar pada 2017. szept.

... membungkus semuanya dalam fungsi async ...

Dengan apa yang tersedia sekarang saya "harus" membungkus suatu fungsi untuk tujuan ruang lingkup. Saya pikir saya membeli alasan Anda untuk tidak membuatnya asinkron. (Setidaknya, menambahkan fungsi pembungkus async dalam skrip itu sendiri adalah hal yang sepele.)

Coba hapus konten [profil mozilla]\storage\default\ (Setelah dicadangkan)
Kemudian coba lagi.

Berbicara tentang objek UserScript, saya tidak begitu mengerti keputusan desain untuk memiliki tiga kelas UserScript. Saat ini mereka memiliki pohon warisan tunggal yang sedikit konyol.

Selanjutnya, RemoteUserScript hanya digunakan sekali dan untuk itu hanya dibuat untuk mengambil id . Dan RunnableUserScript tidak pernah langsung digunakan.

Sekedar Info...

Saya menggunakan FF57.0a1 dan menjalankan add-on lawas dan GM 3.13
Sayangnya, saya tidak mendapatkan pembaruan (3.14, 3.15) karena versi maksimalnya diatur ke 56.*

Padahal bisa di install manual..

GM 3.16 masih hang browser saat start-up (saya kira itu memperbarui DB)