Greasemonkey: वेबएक्सटेंशन संगतता

मैं इस बारे में एक गुच्छा सोच रहा था। मेरे पास स्पष्ट "निर्णय" नहीं है, लेकिन कुछ बिंदु:

• हमने _just_ e10s संगतता के लिए पोर्टिंग की प्रक्रिया को पूरा कर लिया है। जब हमने शुरुआत की थी तो यह बहुत कठिन था; उदाहरण के लिए Services.ppmm और .cpmm अच्छे शॉर्टकट हैं, जिन पर शुरू से ही भरोसा करना अच्छा होता, लेकिन जब हमने (जिम्मेदारी से) शुरुआत की तो वे मौजूद नहीं थे।
• वह काम लंबा और बहुत दर्दनाक था, और मैं इसे प्रभावी ढंग से दोहराने की उम्मीद नहीं कर रहा हूं।
• e10s रोलआउट फ़ायरफ़ॉक्स 36 (सितंबर 2014 तक) से फ़ायरफ़ॉक्स 42 (अभी, सितंबर 2015 तक), या कम से कम नौ महीने तक फिसल गया है।
• घोषणा कहती है कि webextensions-only कम से कम 1 या 2 वर्ष दूर है; यह अब से घटकर 2, 3, 4 वर्ष हो जाएगा?
• अगर हम ऐसा करने जा रहे हैं, तो मुझे लगता है कि यह एक साफ ब्रेक और फिर से आर्किटेक्ट करने का सही समय है।
  
  
  
  • मैं खुद को चाहता हूं कि हमारे पास अर्ध-अक्सर अच्छे यूनिट परीक्षण हों, भले ही हमारे पास बहुत से मुद्दे हों जो वे कभी नहीं पकड़ पाएंगे, हमारे पास कुछ भी होंगे।
  
  
  • हम अंत में Android समर्थन जोड़ सकते हैं?
  
  
  • हमें वास्तव में खरोंच से फिर से लिखने की ज़रूरत नहीं है, लेकिन यह सोचकर कि हम किस कोड को बनाए रखते हैं और जिसे हम छोड़ते हैं, वारंट हो सकता है।
  
  
• इससे पहले कि हम इस बड़े कार्य को शुरू करें, मैं वास्तव में एक बहुत मजबूत Greasemonkey/Mozilla संबंध रखना पसंद करूंगा। मेरे पास केवल कमजोर अनुमान हैं कि इसे कैसे वास्तविकता बनाया जाए।
  
  
  
  • मुझे लगता है कि आज हम वेबएक्सटेंशन जैसी किसी चीज़ को पोर्ट करने के लिए प्रभावी रूप से एक यातना परीक्षण हैं; इन वर्षों में हमने कुछ उन्नत सुविधाओं का निर्माण किया है। योजना के हिस्से के रूप में दोतरफा संचार शायद बहुत मदद करेगा।
  
  

एक डिज़ाइन दस्तावेज़ से शुरू करना एक अच्छा विचार होगा। अनिवार्य रूप से हमें सभी Greasemonkey को रिवर्स इंजीनियर करने की आवश्यकता है क्योंकि यह सभी को संरचित करने के लिए एक अनियोजित व्यवस्थित तरीके से विकसित होने के बजाय एक अच्छे तरीके से योजना में मौजूद है।

उदाहरण के लिए Services.ppmm और .cpmm अच्छे शॉर्टकट हैं, जिन पर शुरू से ही भरोसा करना अच्छा होता, लेकिन जब हमने (जिम्मेदारी से) शुरुआत की तो वे मौजूद नहीं थे।

मैं निश्चित रूप से अभी तक WebExtensions का उपयोग करने की वकालत नहीं कर रहा हूं, वे GM . जैसी किसी चीज़ के लिए अपरिपक्व हैं

हमें वास्तव में खरोंच से फिर से लिखने की ज़रूरत नहीं है, लेकिन यह सोचकर कि हम किस कोड को बनाए रखते हैं और जिसे हम छोड़ते हैं, वारंट हो सकता है।

एचआरएम, ठीक है, मैं इसे ज्यादातर एक प्रौद्योगिकी पीओवी से देख रहा था। अभी यूआई साझा क्रोम वातावरण में एक्सयूएल ओवरले और प्रत्यक्ष स्क्रिप्ट निष्पादन का उपयोग करता है।

तो चीजों को एचटीएमएल में परिवर्तित करना और प्रत्येक चीजों को एक स्वतंत्र विंडो संदर्भ में चलाना और केवल संदेश-पासिंग के माध्यम से संवाद करना ऐसा लगता है कि भविष्य में चीजों को कैसे किया जाना चाहिए।

संदेश प्रबंधक मूल रूप से निम्नतम स्तर है जहां इसे लागू किया गया है। उस पर उच्च स्तरीय अमूर्तता का निर्माण होता है। WebChannel.jsm/BroadcastChannel/MessageChannel/WebExtension चैनल और ऐसे।

एक डिज़ाइन दस्तावेज़ से शुरू करना एक अच्छा विचार होगा।

क्या जीएच विकी उसके लिए सही जगह होगी? क्या यह सहयोगी कार्य को सरल बनाने के लिए संपादन पर सूचनाएं करता है?

मुझे लगता है कि हमें ज्यादातर एक फीचर/आंतरिक प्लंबिंग सूची की जरूरत है और प्रत्येक को साफ तरीके से कैसे लागू किया जाए।

यदि आप इस मुद्दे के विषय में रुचि रखते हैं, तो कृपया पढ़ें:

https://groups.google.com/d/topic/greasmonkey-dev/K6IyDUWnTQc/चर्चा

धन्यवाद!

उपयुक्त:

• 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

यह एक सुपर दिलचस्प एपीआई है, लेकिन "यह सुविधा गैर-मानक है और मानक ट्रैक पर नहीं है" और संगतता बहुत सीमित है।

पूरी तरह से चित्रित Greasemonkey-under-WebExtensions को डिजाइन करने के मेरे सभी हालिया प्रयास (#2483, #2484 देखें) निराशाजनक रहे हैं। मैं विकास की एक अधिक प्रगतिशील शैली पर विचार करना शुरू कर रहा हूं: सुविधाओं का अधिक सीमित सेट चुनें और केवल उसी का समर्थन करें। थोड़ा उपयोगी बनें, फिर उम्मीद है कि बाद में और अधिक कार्यक्षमता की दिशा में एक रास्ता खोजें।

मेरे 3.x इंस्टॉल का निरीक्षण करते हुए, मैं देखता हूं कि (मेरे लिए) प्रत्येक स्क्रिप्ट <strong i="6">@grant</strong> none । 27 में से, केवल छह @run-at document-start , और उनमें से अधिकांश कम से कम कुछ हद तक इनायत से कार्य करेंगे यदि वह समर्थित नहीं था। @require सुविधा का भारी उपयोग किया जाता है, और @resource काफ़ी हद तक उपयोग किया जाता है।

तो यह पहले लक्ष्य के लिए एक सभ्य लक्ष्य की तरह लगता है: <strong i="12">@grant</strong> none मोड में सादे उपयोगकर्ता स्क्रिप्ट का समर्थन करें, किसी भी GM_ एपीआई के लिए कोई समर्थन नहीं। समर्थन @require । आशा है कि किसी तरह @resource का समर्थन करने के लिए, शायद अक्षम रूप से।

(साइड नोट, क्योंकि मैं इसे भूलता रहता हूं : त्रुटियों को थोड़ा और अधिक पठनीय बनाने के लिए बनाएं । देखें कि क्या एकाधिक स्रोत URL समर्थित हैं, या क्या हमें @require फैक्टरिंग करते हुए एक स्रोत मैप बनाना होगा (क्या हम?)

हम WebExtension वाले के अलावा सादे वेब API तक पहुँच प्राप्त करते हैं, इसलिए:

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

? WebExtension के लिए IndexedDB की संग्रहण सीमा क्या है? यह storage.local से कहीं बेहतर विकल्प की तरह दिखता है। इंटरफ़ेस सबसे सरल नहीं है, लेकिन यह हमें स्क्रिप्ट को एक-दूसरे से अलग करने और चुनिंदा पढ़ने की अधिक शक्ति देता है। मुझे लगता है। डॉक्स का उपयोग करना भी सबसे आसान नहीं है।

https://github.com/mdn/webextensions-examples/pull/171 में इंडेक्सडडीबी के लिए मूल्यवान चर्चा और उदाहरण प्रतीत होता है

मैंने कुछ प्रगति की है।

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

खरोंच से पुन: कार्यान्वित। चेक आउट करें, about:debugging , "अस्थायी ऐड-ऑन लोड करें" दबाएं और मूल स्थान से किसी भी फ़ाइल का चयन करें। आप स्थापित कर सकते हैं और बस मुश्किल से उपयोगकर्ता स्क्रिप्ट चला सकते हैं। बिल्कुल अभी तक कोई अन्य विशेषता नहीं है। (ठीक है, बंदर मेनू है, लेकिन यह एक खाली नकली है जो ठीक दिखने के अलावा कुछ भी नहीं करता है।) बहुत सारे TODO कोड के चारों ओर बिखरे हुए हैं, यहां तक ​​​​कि इस मामूली सुविधा सेट के लिए भी। गारंटी नहीं दे सकता कि इनमें से कोई भी अधिक सुविधाओं के लिए "सही रास्ता" है या नहीं।

चूंकि Tampermonkey के पुराने संस्करण, साथ ही Violentmonkey, खुले स्रोत हैं, क्या उस कोड में से कुछ का उपयोग यहां किया जा सकता है, क्योंकि WebExtensions क्रोमियम एक्सटेंशन के समान है?
संपादित करें: असल में, इसे देखकर, मैं पुराने टैम्परमोनकी के साथ लाइसेंस संगतता के बारे में निश्चित नहीं हूं। लेकिन Violentmonkey MIT-लाइसेंस प्राप्त है, इसलिए यह संगत है।

@PorygonZRocks : Violentmonkey Greasemonkey बन रहा है?

मुझे कोडिंग का बहुत अनुभव नहीं है, लेकिन मैं सोच रहा था कि चीजों को लागू करने पर कम से कम कुछ दिशानिर्देश हो सकते हैं। दोबारा, बहुत अनुभवी/जानकार नहीं, इसलिए मैं गलत हो सकता हूं।

यह ध्यान देने योग्य है कि FF56 ने सभी गैर-मल्टीप्रोसेस संगत ऐडऑन को अक्षम कर दिया है, इसलिए समय सीमा को बदलने की आवश्यकता हो सकती है।

मेरी देव शाखा देखें। जो काफी रफ है लेकिन कम से कम फंक्शनल है। यह किया जा रहा है, इस व्यापक दायरे वाले मुद्दे में विशेष रूप से ट्रैक करने के लिए कुछ भी नहीं है।

@arantius जिज्ञासा से बाहर, क्या आप नया कोड लिख रहे हैं या पुराने का पुन: उपयोग कर रहे हैं?

क्या आपको मदद की ज़रूरत है?

फिर से जिज्ञासा से बाहर, उदाहरण के लिए, "parse-meta-line.js" का उद्देश्य केवल मेटा डेटा को किसी ऑब्जेक्ट में पार्स करना है?

@arantius जिज्ञासा से बाहर, क्या आप नया कोड लिख रहे हैं या पुराने का पुन: उपयोग कर रहे हैं?

ज्यादातर नया। कॉपी करना कब/कहाँ मददगार हो। (अब तक, स्क्रिप्ट पार्सिंग एक बड़ा उदाहरण है।)

क्या आपको मदद की ज़रूरत है?

मदद अच्छी होगी। समन्वय करना कठिन होगा।

फिर से जिज्ञासा से बाहर, उदाहरण के लिए, "parse-meta-line.js" का उद्देश्य केवल मेटा डेटा को किसी ऑब्जेक्ट में पार्स करना है?

इसकी एक पंक्ति, हाँ।

इसकी एक पंक्ति, हाँ।
मेरा मतलब था, क्या यह इनके बीच मेटा डेटा को पार्स करने के अलावा कुछ और करता है:

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

ऐसा लगता है कि बहुत सारे कोड हैं यदि यही एकमात्र उद्देश्य है।

हाँ यही करता है। यह उत्पन्न कोड है। कृपया इस चर्चा को https://groups.google.com/d/topic/greasmonkey-dev पर ले

मैं Google समूहों का उपयोग नहीं करता :(
अगर यह मैं होता... मैं शायद इसे अलग तरीके से करता।

Google समूह अब मौजूद नहीं है।

खराब लिंक: https://groups.google.com/forum/#!forum/greasmonkey -dev

पूरी तरह से सुनिश्चित नहीं है कि यह इसके लिए सही स्थान है, लेकिन यहां वैसे भी है। यदि आप चाहते हैं कि मैं एक अलग अंक @arantius खोलूं , तो निश्चित रूप से।
क्या 4.0.0 मौजूदा स्क्रिप्ट को माइग्रेट नहीं करना चाहिए? मैंने अल्फा 3 (नवीनतम गैर-बीटा से आ रहा है) में अपडेट किया और देखा कि मेरे पास अब कोई स्क्रिप्ट नहीं थी।

@Phyxion , यदि आप 3.14 स्थापित करते हैं तो स्क्रिप्ट को माइग्रेट किया जाना चाहिए। सुनिश्चित करें कि आपने इंस्टॉल करने के बाद ब्राउज़र को पुनरारंभ किया है।

उसके बाद जब आप 4.x इंस्टॉल करते हैं तो आपके पास स्क्रिप्ट होनी चाहिए। यदि आप ऐसा नहीं करते हैं तो नए अंक में कुछ विस्तृत पुनरुत्पादन चरण सहायक होंगे।

Greasemonkey 4 alpha Firefox 57 के साथ असंगत है।

@erkinalp , क्या आप विस्तृत कर सकते हैं? मैं अपने बहुत सारे परीक्षण और संशोधनों के लिए 4alpha2 का उपयोग कर रहा हूं, यह काम करता है, हालांकि 3.x में सभी सुविधाएं उपलब्ध नहीं हैं। मैंने 4alpha3 में परिवर्तन नहीं खींचे हैं, इसलिए मुझे नहीं पता कि उस संस्करण के लिए कुछ कमिट कुछ भी तोड़ते हैं।

@Sxderp ठीक है, इसे मेरी मशीन पर पुन: प्रस्तुत करना आसान है। मेरे पास 10 उपयोगकर्ता स्क्रिप्ट के साथ 3.14 स्थापित है। एएमओ पर जाएं और नवीनतम अल्फा डाउनलोड करें। पूछे जाने पर पुनः आरंभ करें। फिर यह सिर्फ इतना कहता है कि कोई उपयोगकर्तास्क्रिप्ट स्थापित नहीं है। यह सुनिश्चित नहीं है कि इसे पुन: पेश करने के लिए यह कितना उपयोगी है।

मैंने अभी तक इसका परीक्षण नहीं किया है, लेकिन मेरा मानना ​​​​है कि GM4 को अनइंस्टॉल करने के बाद अपना कॉन्फ़िगरेशन खोना चाहिए, जबकि GM3 को इसे रखना चाहिए, इसलिए मेरा सुझाव है कि आप कोशिश करें:

1. Greasemonkey को पूरी तरह से अनइंस्टॉल करें
2. फ़ायरफ़ॉक्स को पुनरारंभ करें
3. Greasemonkey 3.14 स्थापित करें (पुनरारंभ सहित)
4. अच्छे उपाय के लिए फ़ायरफ़ॉक्स को पुनरारंभ करें
5. Greasemonkey 4 स्थापित करें (कुछ भी डॉट करें)

क्या उससे मदद हुई?

मुझे लगता है कि शीर्ष स्तर की प्रतीक्षा है - यानी एक एसिंक फ़ंक्शन में सबकुछ लपेटना - एक अच्छा डिज़ाइन विकल्प नहीं है क्योंकि यह भविष्य के कार्यान्वयन को प्रतिबंधित करता है (उदाहरण के लिए जब हमें सैंडबॉक्स वापस मिलते हैं या भविष्य के क्षेत्र)। यह चीजों को वेनिला जेएस निष्पादन के साथ असंगत बनाता है जहां शीर्ष स्तर की प्रतीक्षा उपलब्ध नहीं है और स्क्रिप्ट निष्पादित होती है ... ठीक है ... शीर्ष स्तर पर।

@arantius
यहाँ अभी भी कुछ नहीं है :(
BTW, 4.0 इस तरह दिखना चाहिए: https://i.imgur.com/CPuWWKM.png
स्क्रिप्ट जोड़ने के लिए कोई बटन या कुछ भी नहीं है।

... एक async फ़ंक्शन में सब कुछ लपेटना ...

अब जो उपलब्ध है उसके साथ मेरे पास स्कोप उद्देश्यों के लिए फ़ंक्शन में लपेटने के लिए "है"। मुझे लगता है कि मैं इसे एसिंक नहीं बनाने के लिए आपका तर्क खरीदता हूं। (कम से कम, स्क्रिप्ट में एक एसिंक्स रैपर फ़ंक्शन जोड़ना छोटा है।)

हाँ, यह ज्यादातर एसिंक/प्रतीक्षा के बारे में था, क्योंकि वर्तमान में जानबूझकर जावास्क्रिप्ट में इसकी अनुमति नहीं है , इसलिए इसे उपयोगकर्तास्क्रिप्ट में सक्षम करना भविष्य के परिवर्तनों के लिए खतरे की तरह लगता है। मुझे पता है कि रैपर वर्तमान में अपरिहार्य है, लेकिन मुझे उम्मीद है कि भविष्य में चीजों को शीर्ष स्तर पर वापस ले जाया जा सकता है।

@arantius नीचे वोट क्यों?

@arantius ने 2017 पर टिप्पणी की 28. 14:57 सीईएसटी :

... एक async फ़ंक्शन में सब कुछ लपेटना ...

अब जो उपलब्ध है उसके साथ मेरे पास स्कोप उद्देश्यों के लिए फ़ंक्शन में लपेटने के लिए "है"। मुझे लगता है कि मैं इसे एसिंक नहीं बनाने के लिए आपका तर्क खरीदता हूं। (कम से कम, स्क्रिप्ट में एक एसिंक्स रैपर फ़ंक्शन जोड़ना छोटा है।)

[मोज़िला प्रोफ़ाइल]\भंडारण\डिफ़ॉल्ट\ की सामग्री को हटाने का प्रयास करें (इसका बैकअप लेने के बाद)
फिर पुनः प्रयास करें।

UserScript ऑब्जेक्ट्स की बात करें तो, मैं तीन UserScript क्लासेस रखने के लिए डिज़ाइन निर्णय को समझ नहीं पा रहा हूँ। फिलहाल उनके पास एक विलक्षण विरासत का पेड़ है जो थोड़ा मूर्खतापूर्ण है।

इसके अलावा, RemoteUserScript का उपयोग केवल एक बार किया जाता है और इसके लिए इसे केवल id हथियाने के लिए बनाया जाता है। और RunnableUserScript कभी भी सीधे उपयोग नहीं किया जाता है।

सिर्फ जानकारी के लिए...

मैं FF57.0a1 पर हूं और लीगेसी एडऑन और जीएम 3.13 चला रहा हूं
अफसोस की बात है कि मुझे अपडेट (3.14, 3.15) नहीं मिलते क्योंकि उनका अधिकतम संस्करण 56 पर सेट है।*

हालांकि इसे मैन्युअल रूप से स्थापित किया जा सकता है ..

जीएम 3.16 अभी भी स्टार्ट-अप पर ब्राउज़र को लटका देता है (मुझे लगता है कि यह डीबी अपडेट कर रहा है)