Saya benar-benar berpikir ini harus dipikirkan kembali. Baik VM dan TM berperilaku bertentangan dengan ini. Saat menavigasi ke skrip, Anda disajikan dengan halaman yang menyertakan konten/sumber skrip dan tombol instalasi. Meskipun Anda secara teknis 'dialihkan', pada dasarnya Anda masih 'menavigasi' ke skrip pengguna. Mungkin ini harus dibawa ke milis -users dan -dev dan melihat pendapat orang lain?

Saya mendukung diskusi komunitas.

Secara pribadi saya berpendapat bahwa ~tidak ada yang mengulas sumbernya, jadi adalah hal yang konyol untuk menunjukkannya kepada semua pengguna, termasuk mayoritas yang bahkan tidak dapat memahaminya.

Dan: meninjau hanya sumber utama, ketika ada juga @require , menghasilkan sangat sedikit.

Saya akan sangat sedih jika kemungkinan untuk meninjau kode sumber tidak kembali. Saya selalu merasa lebih nyaman dengan membaca kode. Dan jika ada @require termasuk yang tidak menunjuk ke perpustakaan terkenal (dihosting secara resmi jQuery dll), saya selalu skeptis dan biasanya membatalkan pemasangan kecuali saya benar-benar membutuhkan skrip itu (dalam hal ini saya membaca sekilas konten

Tetapi bahkan jika saya pengecualian dan kebanyakan orang tidak melihat atau memahami kodenya, saya pikir ada efek pencegahan bagi penulis skrip untuk mengetahui sumber ditampilkan saat menginstal.

Jika Anda masih memutuskan untuk tidak menampilkan kode sumber, harap tambahkan tautan sumber tampilan yang mudah diakses: yang menunjuk ke kode sumber saat memasang skrip (dan lebih disukai juga skrip @require yang disertakan).

Seperti yang disebutkan, saya juga menghargai kemampuan meninjau. Bagi sebagian kecil orang yang menginginkannya. Saya hanya ingin ini berfungsi seperti #2567 sehingga Anda dapat meninjau _semua_ sumbernya. Anda cukup mengklik edit setelah menginstal, dan dapatkan semua sumber dan sumber teks terlihat. Aktifkan atau hapus instalan sesuai pilihan Anda.

Ada beberapa implikasi kinerja yang memerlukan beberapa permintaan jaringan. Secara khusus, antara 3. dan 4. ada "unduh ke titik di mana kami memiliki metablock yang valid, sehingga kami dapat memunculkan dialog pemasangan".

Katakanlah file tersebut bukan skrip pengguna yang sebenarnya dan tidak memiliki metablock yang valid. Dialog instalasi tidak akan pernah muncul. Satu-satunya tindakan yang saya lihat adalah melanjutkan navigasi. Setelah navigasi dilanjutkan, file harus diunduh ulang. Permintaan yang tidak perlu (#2830 mengatasi ini dengan memperluas apa yang saat ini sedang dilakukan di onHeadersReceived ).

Anda telah membuat poin ini sebelumnya, dan itu harus dipertimbangkan. Apa yang terjadi jika koneksi lambat? Untuk keperluan misalnya, misalkan butuh waktu 10 detik untuk mendownload file tersebut. Pengguna tidak akan mendapat umpan balik selama 10 detik saat GM mencoba mengunduh untuk mencari skrip. Gagal dan menyerahkannya ke browser untuk melanjutkan navigasi. Sekali lagi 10 detik mengunduh file untuk ditampilkan.

Saya tidak akan mengatakan tidak ada jalan lain untuk ini. Misalnya data dapat di-cache atau semacamnya, dan kemudian menimpa output pada navigasi yang sebenarnya. Tapi saya merasa ini mengarah pada kerumitan kode yang tidak perlu hanya untuk melindungi pengguna.

Atau Anda dapat tetap membuka dialog instal dan gagal menginstal file non-skrip (VM ​​melakukan ini). Saya akan mempertimbangkan UX yang buruk itu.

Jika seseorang dapat menemukan cara yang bersih untuk melakukan ini tanpa permintaan tambahan, bagus. Kalau tidak, saya tidak bisa mendukung ini tanpa manfaat _aktual_. [1]

[1] Anda telah menyebutkan "dapat meninjau _semua_ kode sumber" karena #2567 sebagai potensi manfaat. Tapi saya tidak setuju. Saya merasa #2567 harus menjadi fitur _terlepas_ dari apakah kode sumber tersedia saat diinstal atau tidak.

Saya tidak tahu. Pada topik lain saya sudah bisa datang setelah beberapa diskusi. Tapi ini adalah salah satu yang saya tidak "melihat".

Dari sudut pandang saya, saya tidak terlalu peduli jika skrip segera terlihat, tetapi saya pikir jika saya membatalkan instalasi atau sesuatu yang saya harus dapat melihat file mentah seperti yang saya miliki jika greasemonkey tidak diinstal. Saya tidak terlalu peduli apakah itu disembunyikan secara default atau sesuatu tetapi beberapa cara untuk mengabaikan dialog instal dan kembali ke skrip tampaknya penting.

Saya tidak berpikir masuk akal untuk berhenti melihat hal-hal yang disebut *.user.js . Ini menghapus fungsionalitas browser.

Saya melihat skrip pengguna lebih sebagai ekstensi daripada halaman web. Anda juga tidak pernah menjelajah ke ekstensi. Anda mengunduh/menginstalnya, atau tidak.

Saya rasa tidak masuk akal untuk berhenti melihat hal-hal yang disebut *.user.js. Ini menghapus fungsionalitas browser.

Itu juga melakukan hal-hal seperti versi GM sebelumnya -- termasuk tidak menyentuh navigasi saat dinonaktifkan. Jika Anda sangat ingin melihat ini di browser Anda, matikan GM terlebih dahulu.

Saya melihat skrip pengguna lebih sebagai ekstensi daripada halaman web. Anda juga tidak pernah menjelajah ke ekstensi. Anda mengunduh/menginstalnya, atau tidak.

Saya tidak setuju dengan alasan ini. Ekstensi adalah paket file yang diarsipkan. Sebuah skrip pengguna tidak. Anda bisa membuat argumen tentang @requires dan @resources tapi saya pikir itu lemah. Tidak semua dari mereka menggunakan itu dan banyak dari mereka hanya teks biasa. Saat Anda menavigasi ke halaman teks mentah, Anda biasanya (dengan asumsi header lampiran / unduhan tidak disetel.. Yang menurut saya juga mengganggu) tidak perlu mengunduhnya sebelum melihatnya.

Itu juga melakukan hal-hal seperti versi GM sebelumnya

Tentu, tapi saya tidak berpikir ini adalah argumen yang bagus untuk atau menentang fitur tertentu. Versi sebelumnya dapat memberikan garis dasar tetapi bergerak maju saya pikir semuanya harus diperiksa ulang di bawah konteks baru. Ini termasuk kompleksitas kode, manfaat yang ditanamkan atau tidak ditanamkan, manfaat, dll.

Anda juga tidak pernah menjelajah ke ekstensi. Anda mengunduh/menginstalnya, atau tidak.

Menjadi file teks memang membuat perbedaan. Misalnya github memiliki opsi "lihat mentah" yang sekarang rusak.

termasuk tidak menyentuh navigasi saat dinonaktifkan.

Ini bagus untuk diketahui. Saya kira saya mungkin sudah menebak ini tetapi itu benar-benar tidak jelas. Saya hanya bingung karena saya mencoba melihat file dan tidak bisa dirender. Mungkin kami dapat memberikan petunjuk kepada pengguna bahwa ini dapat dilakukan ketika mereka menemukannya, daripada menampilkan halaman kosong.

Saya menghargai pengambilan keputusan desain yang memberikan nilai paling banyak kepada sebagian besar pengguna, jadi saya menghargai masukan.

Namun ini akan menjadi kasus yang jarang terjadi di mana saya meletakkan kaki saya ke bawah. Jangan repot-repot memperdebatkan pendekatan. Saya ingin perilaku: ada tautan ke skrip pengguna yang valid, saya mengklik tautan itu, saya melihat (hanya) dialog pemasangan, dan saya tidak pernah menavigasi ke file teks, bahkan tidak pernah melihat sumbernya. Aku akan melakukan apa yang diperlukan untuk membuat Greasemonkey bertindak seperti itu. Periode.

Sebelum WebExt, kami mendapatkan ini dengan menggunakan http-on-modify-request , untuk menangguhkan permintaan yang terlihat seperti skrip pengguna sesegera mungkin. Kami akan memicu dialog pemasangan, dan memulai operasi RemoteScript untuk mengunduh semua bagian, semuanya dalam permintaan baru. Jika ini mendeteksi hal yang bukan skrip pengguna (yaitu HTML) pada URL yang terlihat seperti skrip pengguna, itu akan membatalkan permintaan yang dimilikinya, dan ... sesuatu akan memulai ulang navigasi (saya pikir dengan melanjutkan saluran dengan tepat, tetapi Saya tidak dapat menemukannya).

Dengan skrip lambat , tidak ada yang terjadi pada awalnya -- setelah bagian ==UserScript== dimuat, dialog instal muncul, lalu bilah kemajuannya terisi saat sisanya diunduh -- skrip lainnya, sumber daya, memerlukan , dll.

Itu berhasil mengunduh skrip hanya dengan satu koneksi ke server.

Di bawah WebExt, semua API tentu saja berbeda, tetapi acara pemblokiran/pemfilteran onHeadersReceived sudah ada di HEAD _tampaknya_ menjadi hal terbaik untuk digunakan. Aku masih harus melakukan penelitian.

Saya ingin perilaku: ada tautan ke skrip pengguna yang valid, saya mengklik tautan itu, saya melihat (hanya) dialog pemasangan, dan saya tidak pernah menavigasi ke file teks, bahkan tidak pernah melihat sumbernya. Aku akan melakukan apa yang diperlukan untuk membuat Greasemonkey bertindak seperti itu.

Tapi ini adalah perubahan perilaku lama. GM 3.x Saya memiliki pilihan untuk mengklik view source alih-alih menginstal dan kemudian tidak ada yang diinstal, tetapi saya mendapat tab yang menampilkan sumber skrip. Dari sana saya memiliki kemungkinan untuk menginstal atau menutup tab dan tidak melakukan apa pun. Ini akan menjadi perilaku yang setidaknya ingin saya lihat lagi. Bagi saya tidak perlu selalu menampilkan sumbernya, tetapi opsi untuk memeriksanya sebelum saya menginstal apa pun seperti sebelumnya, akan sangat bagus.

Alasan permintaan ini adalah karena saya melihat bahaya yang dapat ditimbulkan oleh skrip berbahaya dan karenanya saya selalu memeriksa sumbernya sebelum menginstal apa pun. Inilah alasan mengapa saya juga melihat pembaruan otomatis senyap sebagai masalah karena dapat membawa kode berbahaya baru ke pengguna.

Dengan webRequest Anda dapat mengembalikan URL palsu untuk membatalkan pemuatan dan menyebabkan browser tetap berada di tempatnya. Tetapi melakukannya segera membatalkan koneksi, Anda juga tidak dapat menggunakan filter untuk mengamati/mengurai/mengubah konten, jadi Anda harus memulai koneksi baru. Saya pikir ini baik-baik saja dalam kasus ini, karena kami memiliki semua data yang kami butuhkan (metode permintaan, header respons) dalam cakupan sehingga kami dapat membuat keputusan yang meyakinkan tentang apakah ini benar-benar skrip pengguna atau tidak, dan itu juga sangat awal dalam siklus permintaan.

Saya memiliki opsi untuk .. memeriksanya sebelum saya menginstal apa pun ...

2567

Bagaimana jika itu terlihat seperti skrip pengguna, tetapi tidak? Misalnya, jika Anda mengambil contoh pemuatan lambat dan hanya menghapus // ==UserScript== . Buka di 3.x, dialog instal tidak pernah terbuka (benar) dan kemudian konten teks ditulis ke tab / halaman. Dengan WebEx jika Anda membuat koneksi baru di latar belakang, saya tidak melihat bagaimana Anda dapat menulis konten ke halaman. Sejauh yang saya ketahui, satu-satunya cara langsung untuk menulis beberapa konten ke halaman di latar belakang adalah melalui filter aliran.

Saya dapat memikirkan beberapa cara untuk 'mengatasinya'. Sekali lagi tidak ada solusi yang baik. Lewati data ke skrip konten yang hanya akan menggemakan konten (seharusnya bisa dilakukan, saya pikir). Arahkan ulang ke halaman ekstensi, tetapi itu akan merusak riwayat. Atau menyebabkan FF memulai kembali permintaan dengan beberapa tanda yang disetel untuk mengabaikan pemeriksaan skrip. Tapi kemudian itu permintaan ketiga..

Mungkin aku kehilangan sesuatu..

Buka di 3.x, dialog instal tidak pernah terbuka (benar) dan kemudian konten teks ditulis ke tab / halaman.

Eh, saya ingin mengoreksi poin ini. Saya salah, saya salah ketik di user ketika saya menguji awalnya.

@Sxderp izinkan saya mengulangi bahwa saya sangat menghargai kontribusi yang Anda buat hingga saat ini dan berharap Anda akan melanjutkannya.

Tetapi untuk sedikit lebih jelas tentang keputusan saya yang diuraikan di atas: Saya telah membersihkan pekerjaan saya yang sedang berlangsung; pertama saya memindahkan beberapa pekerjaan yang tidak terkait ke komit terpisah . Yang tersisa adalah rename file dan kemudian commit besar ini , yang hanya +425 -491.

Kelas Downloader merangkum semua logika tentang (mengunduh dan) menginstal skrip, apa pun sumbernya. Anda hanya perlu mengatur input -- hanya URL untuk penginstalan, tetapi juga sumber skrip utama dan mungkin memerlukan/konten sumber daya jika sudah diketahui (untuk kasus edit), ia mengunduh hal lain yang hilang (yaitu edit di persyaratan baru /resource) dan selalu meneruskan satu format yang sama ke user-script-regstry yang mempertahankannya hanya dalam satu cara. Seluruh downloader.js berada di bawah 250 baris. Akibatnya, lebih sedikit pesan yang dikirimkan antara latar belakang/konten dan tidak ada port baru.

Ada kalanya sangat masuk akal untuk memecah bagian besar dari kode yang kompleks menjadi bagian yang lebih kecil dan lebih sederhana. Tapi IMO bukan ini. Data yang mengalir adalah sama, apakah kita memasang skrip "baru", atau memperbaruinya, atau mengeditnya di tempat. Hanya hal-hal kecil yang berubah (apakah kita sudah mengetahui UUID dari script yang sudah terpasang? apakah kita sudah tahu atau perlu mendownload ini atau itu?).

Apakah ini juga menyelesaikan struktur rekursif parsedDetails (ada masalah di suatu tempat, tidak punya waktu untuk mencarinya)?

Saya tidak tahu. Aku meragukan itu?

Apakah ini juga menyelesaikan struktur rekursif dari parsedDetails (ada masalah di suatu tempat, tidak punya waktu untuk mencarinya)?

Apakah yang Anda maksud: 2806