webNavigation.onCommitted प्रारंभिक फ्रेम निर्माण / पृष्ठ प्रतिपादन 'देख' नहीं करता है, हालांकि यदि फ्रेम अपने प्रारंभिक पृष्ठ के अलावा कहीं और नेविगेशन करता है तो श्रोता इसे पकड़ लेगा। यदि विकल्प कुंजी 'allFrames': true को शामिल करने के लिए थे तो समस्या _somewhat_ हल हो गई है। स्थिर एचटीएमएल पेज में किसी भी फ्रेम में स्क्रिप्ट इंजेक्शन होगी, हालांकि आपके पास मूल/यूआरएल मिलान की समस्याएं हैं। इसके अलावा, यदि जावास्क्रिप्ट का उपयोग करके एक फ्रेम बनाया जाता है तो स्क्रिप्ट को इंजेक्ट नहीं किया जाता है।

सबसे आसान समाधान जिसके बारे में मैं सोच सकता था, वह होगा webNavigation.oncommitted को webRequest.onResponseStarted के साथ {'urls': ['<all_urls>'], 'types': ['main_frame', 'sub_frame']} फ़िल्टर से बदलना।

मैंने कुछ सीमित परीक्षण किए और आगे किसी बदलाव की आवश्यकता नहीं थी। मैं जावास्क्रिप्ट का उपयोग करके बनाए गए फ्रेम और फ्रेम के भीतर एक स्क्रिप्ट निष्पादित करने में सक्षम था।

@arantius कोई योजना @Sxderp से ठीक विलय करने के लिए?

यह उन परिदृश्यों को प्रभावित कर रहा है जहां आईफ्रेम क्रॉस-ओरिजिनल ऑब्जेक्ट हैं, इसलिए उन विशेष आईफ्रेम पर जीएम चलाए बिना किसी भी प्रकार का संशोधन करना असंभव है।

धन्यवाद !

इसे याद किया, जल्द ही इस पर गौर करेंगे।

पुरानी लिपियों के परीक्षण के दौरान बस एक अवलोकन, पता नहीं, अगर यह मदद करता है ...

एक स्क्रिप्ट को देखते हुए, जिसे आईफ्रेम पर काम करना चाहिए,
ऐसा लगता है कि यह पृष्ठ पर परिवर्तन निष्पादित करता है,
लेकिन फिर असंशोधित पृष्ठ पर फिर से ताज़ा हो जाता है।

जब मैं पृष्ठ को बहुत तेज़ी से रीफ्रेश करता हूं तो मैं केवल झिलमिलाहट देख सकता हूं।

पुरानी लिपियों के परीक्षण के दौरान बस एक अवलोकन, पता नहीं, अगर यह मदद करता है ...

क्या यह मेरे पैच के साथ है या जारी किए गए संस्करण के साथ है?

उह, मुझे लगता है कि यह 4.0 रिलीज थी ...
मैं @4.1b3 था, लेकिन परीक्षणों के लिए, मुझे पूरा यकीन है कि मैंने रिलीज़ संस्करण (अब तक!)

यहाँ वही iframes जैसे Eselce वर्णन करता है। किसी तरह इसे निष्पादित किया जाता है, लेकिन फिर आईफ्रेम या पेज लोड होने के बाद बंद कर दिया जाता है।

अगर मैं इस स्क्रिप्ट को इंजेक्ट करता हूं, तो मुझे केवल 1 और "स्वयं! == शीर्ष" मिलता है:

console.log('1');
if (self !== top) {
   console.log('self !== top');
   setTimeout(function() {
      console.log('Timeout');
   }, 2000);  
} else {
   console.log('self === top');
}

लॉग में "टाइमआउट" नहीं दिखाया गया है, न ही सभी फ़ंक्शन और बाइंड हैं।

मैं 4.1b3 का उपयोग करता हूं।

मेरे पास क्वांटम पर जीएम 4.0 चलाने का एक ही मुद्दा है। मैंने दो पृष्ठों के साथ एक बहुत ही सरल डमी उदाहरण लिखा: main.html और framed.html , और एक जीएम स्क्रिप्ट जो प्रत्येक पृष्ठ पर लोड हो जाती है और उस पृष्ठ के यूआरएल को आउटपुट करती है जिस पर यह लोड होता है।

अधिकांश समय, मुझे केवल main.html बारे में सूचनाएं प्राप्त होती हैं, लेकिन लगभग 5% मामलों में, विशेष रूप से यदि मैं F5 को दबाए रखता हूं, तो मुझे framed.html बारे में एक सूचना भी मिल सकती है।

क्या पैच के बाहर होने तक जीएम 4.0 को आईफ्रेम के अंदर निष्पादित करने के लिए विश्वसनीय रूप से मजबूर करने के लिए कोई हैक है?

मुझे अभी पता चला है कि उपयोगकर्ता लिपियों को <embed src="..."> में मज़बूती से निष्पादित किया जाता है लेकिन <iframe src="..">
मैंने एक छोटी टेस्ट स्क्रिप्ट लिखी:
https://openuserjs.org/scripts/cuzi/iframe_embed_Test_Greasemonkey_4

कुछ और विवरण: कुछ मामलों में, मेरी लिपियों को पूरी तरह से फ्रेम में निष्पादित किया जाता है (लेकिन बाद में पृष्ठ स्क्रिप्ट द्वारा दृश्य को अधिलेखित कर दिया जाता है)।
कभी-कभी, मेरी स्क्रिप्ट के समकालिक भाग समाप्त हो जाते हैं, लेकिन पृष्ठ गतिविधि द्वारा अतुल्यकालिक भाग अचानक बाधित हो जाते हैं...
उम्मीद है की वो मदद करदे!

क्या किसी को इसके बारे में और जानकारी है?

इस सूत्र का संक्षिप्त सारांश (मुद्दा):

• अधिकांश पोस्टिंग भूल जाओ, वे लागू नहीं होते हैं
• शायद, लिपियों को हमेशा निष्पादित किया जाता है (लेकिन अंत तक नहीं)
• दुर्भाग्य से, पृष्ठ को बाद में ताज़ा किया जाता है - लेआउट की पुनर्गणना की जाती है, निष्पादन रद्द कर दिया जाता है
• यह ज्यादातर (लेकिन पूरी तरह से नहीं) स्क्रिप्ट के async भागों पर लागू होता है

मैं इन इंटर्नल में इतना नहीं हूं, लेकिन शायद कोई है ...

एक अस्थायी सुधार के रूप में, मैं एम्बेड ( उदाहरण स्क्रिप्ट ) के @cvzi को यह पता लगाने के लिए कि <embed src="..."> काम करता है) .

यह ध्यान देने योग्य हो सकता है कि वायलेंटमोनकी और टैम्परमोनकी एम्बेडेड फ्रेम के अंदर ठीक काम करते हैं। चूंकि वीएम खुला स्रोत है, शायद देखें कि उन्होंने यह कैसे किया?

दुर्भाग्य से, Violentmonkey और Tampermonkey अभी भी विशेष कार्यों के लिए पुरानी GM_ नामकरण योजना का उपयोग करते हैं, इसलिए स्क्रिप्ट अभी तक पोर्टेबल नहीं हैं।

https://github.com/greasemonkey/gm4-polyfill

Tampermonkey => GM.* कॉल, यदि प्रदान नहीं किया गया है
Violentmonkey => GM.* कॉल
Greasemonkey -3.17 / FF -56.0 => GM.* कॉल
Greasemonkey 4.0+ / FF 57.0+ => निर्मित GM.* कॉल

// <strong i="11">@grant</strong>        GM.getValue
// <strong i="12">@grant</strong>        GM.setValue
// <strong i="13">@require</strong>      https://greasemonkey.github.io/gm4-polyfill/gm4-polyfill.js
// <strong i="14">@grant</strong>        GM_getValue
// <strong i="15">@grant</strong>        GM_setValue

क्या @Sxderp का फिक्स अभी तक मुख्य शाखा में शामिल किया गया है? यदि नहीं, तो मैं उसका कांटा कैसे स्थापित कर सकता हूं?

क्या @Sxderp का फिक्स अभी तक मुख्य शाखा में शामिल किया गया है? यदि नहीं, तो मैं उसका कांटा कैसे स्थापित कर सकता हूं?

1. नहीं ऐसा नहीं है।
2. दुर्भाग्य से यह मेरे पीआर में से एक है कि मैं मास्टर के साथ सिंक नहीं कर रहा हूं और इसलिए रिबेस नहीं किया गया है। तो शाखा स्वयं कुछ मौजूदा परिवर्तनों को याद कर रही है।
3. मैंने पीआर टिप्पणियों में सुझाए गए परिवर्तनों को भी कभी लागू नहीं किया। ईमानदारी से, उन परिवर्तनों की आवश्यकता नहीं होनी चाहिए, लेकिन क्योंकि मोज़िला लगातार चीजों को खराब करता है, परिवर्तनों की आवश्यकता होती है।
4. यदि आप अभी भी इसका उपयोग करना चाहते हैं (अनुशंसित नहीं) तो आप नीचे दिए गए चरणों का पालन कर सकते हैं।

1. git clone -b use-on-response-started-for-execute --single-branch https://github.com/Sxderp/greasemonkey.git [1]
2. ./package.sh चलाएँ, यह एक XPI फ़ाइल बनाएगा।
3. Firefox में about:config पर जाएं और xpinstall.signatures.required से false
4. फ़ायरफ़ॉक्स में about:addons पर जाएं, कॉग पर क्लिक करें और फिर फ़ाइल से इंस्टॉल करें चुनें।
5. चरण 2 में बनाए गए XPI का चयन करें।

[1] यदि आपका गिट का संस्करण -b और / या --single-branch झंडे (गिट का पुराना संस्करण) का समर्थन नहीं करता है तो आप git clone https://github.com/Sxderp/greasemonkey.git और git checkout use-on-response-started-for-execute ।

नमस्ते,
क्या आप इस मुद्दे को ठीक करने जा रहे हैं? यह बहुत पुराना दोष है और आईफ्रेम संरचना के आधार पर सभी स्क्रिप्ट को प्रभावित करता है ...

एक अनुस्मारक के रूप में, हमारे पास कल 13 मार्च है ( Firefox 59.0 )...

मैं @Sxderp का उल्लेख करना चाहता

webNavigation.onCommitted प्रारंभिक फ्रेम निर्माण / पृष्ठ प्रतिपादन 'देख' नहीं करता है, हालांकि यदि फ्रेम अपने प्रारंभिक पृष्ठ के अलावा कहीं और नेविगेशन करता है तो श्रोता इसे पकड़ लेगा। यदि विकल्प कुंजी 'ऑलफ्रेम' को शामिल करने के लिए थे: सच है कि समस्या कुछ हद तक हल हो गई है। स्थिर एचटीएमएल पेज में किसी भी फ्रेम में स्क्रिप्ट इंजेक्शन होगी, हालांकि आपके पास मूल/यूआरएल मिलान की समस्याएं हैं। इसके अलावा, यदि जावास्क्रिप्ट का उपयोग करके एक फ्रेम बनाया जाता है तो स्क्रिप्ट को इंजेक्ट नहीं किया जाता है।

असल में, मेरे पास सबूत है, कि (मेरे सिस्टम पर) श्रोता executeUserscriptOnNavigation को chrome.webNavigation.onCommitted साथ भरोसेमंद कहा जाता है, ताकि chrome.tabs.executeScriptInFrame को सही frameId साथ बुलाया जा सके। . यह फ्रेम के साथ हमारी सभी समस्याओं का समाधान क्यों नहीं करता है? आईफ्रेम पर प्रतिक्रिया करने के लिए हमें chrome.webRequest.onResponseStarted आवश्यकता नहीं होनी चाहिए! (या आपका मतलब था, यह घटना पर प्रतिक्रिया करता है, लेकिन फ्रेम दिखाई नहीं दे रहा है?) इसे निश्चित रूप से कहा जाता है ...

क्या chrome.tabs.executeScriptInFrame और frameId साथ कोई ज्ञात बग है? सालों पहले समस्याएं थीं, लेकिन अब उन्हें ठीक कर लिया गया है। all_frames सेट नहीं है, इस प्रकार frameId मान्य होना चाहिए। विकल्प matchAboutBlank को true करना मायने रखता है (अन्यथा executeScript ने एक त्रुटि <unavailable> लौटा दी), हालांकि मुझे पूरी तरह से समझ नहीं आया कि about:blank सामान (यह कहाँ है?)...

कोई विचार?

विशेषताएं? यह मूल कार्यक्षमता है जो प्रारंभ से गायब है... मुझे आशा है, मैंने इसका गलत अर्थ निकाला है।

@Eselce , यह बहुत समय पहले था और मुझे यकीन नहीं है कि मुझे पूरी तरह याद है कि मैं क्या कह रहा था लेकिन मैं इसे एक शॉट दूंगा। इसके अलावा, यह केवल तभी लागू होता है जब जीएम 3.x फ्रेम मिलान की मेरी समझ सही हो। यही है, प्रत्येक फ्रेम मूल + पथ व्यक्तिगत रूप से मेल खाता है यह निर्धारित करने के लिए कि कौन सी स्क्रिप्ट को चलाने की आवश्यकता है। सिर्फ मूल दस्तावेज नहीं।

अब, मुद्दे पर। जब मैंने अपना प्रारंभिक परीक्षण किया तो मेरे पास एक ही मूल फ्रेम और रिमोट फ्रेम वाला एक स्थिर पृष्ठ था। प्रारंभिक पृष्ठ लोड पर मुझे केवल एक बार आग लगने के लिए onCommitted कॉलबैक मिल सकता है। यह मुख्य दस्तावेज़ के लिए सक्रिय हुआ लेकिन दस्तावेज़ में किसी भी स्थिर फ़्रेम के लिए सक्रिय नहीं हुआ [1]। इस प्रकार उनमें कोई स्क्रिप्ट इंजेक्ट नहीं की जाएगी।

हालांकि, प्रारंभिक लोड के बाद, अगर मैंने कहीं एक फ्रेम को 'नेविगेट' करने का कारण बना दिया तो onCommitted कॉलबैक को कॉल किया जाएगा और स्क्रिप्ट को नए स्थान पर फ्रेम में इंजेक्ट किया जाएगा।

उपरोक्त समस्या को हल करने के लिए all_frames विकल्प कुंजी का उपयोग करने का प्रयास किया गया था। कुंजी का उपयोग करते समय स्क्रिप्ट को पृष्ठ पर फ़्रेम में अंतःक्षिप्त किया गया था, फ़्रेम के मूल + पथ का ठीक से मिलान न करने की स्पष्ट कमी थी कि स्क्रिप्ट को क्या चलना चाहिए या क्या नहीं चलना चाहिए।

एक तरफ, मैंने यह भी उल्लेख किया है कि all_frames कुंजी का उपयोग स्क्रिप्ट को जावास्क्रिप्ट द्वारा बनाए गए फ्रेम में इंजेक्ट नहीं करेगा।

[1] क्या यह मुद्दा अभी भी मौजूद है, मुझे नहीं पता। अगर मुझे याद है कि यह मुद्दा एफएफ 52 ईएसआर में मौजूद नहीं था, लेकिन 56 (57?) (इसलिए प्रतिगमन) में मौजूद था। शायद इसे ठीक कर दिया गया है।

मैं आपसे लगभग सभी बिंदुओं पर सहमत हूं।

और आप सही हैं कि प्रत्येक फ्रेम अलग से मेल खाता है, जैसे कि यह एक संपूर्ण टैब था (अपने स्वयं के window और अपने स्वयं के document , एक फ्रेम में एम्बेडेड)।

खैर, मैंने लगभग हमेशा एक ही मेनू/फ्रेम संरचना का उपयोग किया है, इसलिए शायद मुझे एक अलग परीक्षण करना चाहिए।

जब आप कहते हैं "यह निकाल दिया", क्या आपका मतलब श्रोता की शुद्ध कॉल है?

जैसा कि मैंने कहा, मुझे कुछ उदाहरणों का सामना करना पड़ा है जिसमें executeScript एक त्रुटि स्थिति उत्पन्न कर रहा है, लेकिन श्रोता को अभी भी बुलाया गया था।

all_frames गलत location (अलग window , अलग document ) के कारण काम नहीं कर सकता। बीटीडब्लू: मेनू केवल प्रत्येक टैब के मेनफ्रेम यूआरएल को संभालता है - यदि मेनू गलत है, तो इसका मतलब यह नहीं है कि स्क्रिप्ट को नहीं कहा जाता है ...

जब आप कहते हैं "यह निकाल दिया", क्या आपका मतलब श्रोता की शुद्ध कॉल है?

उस विशेष संदेश में मेरा मतलब था ' onCommitted.addListener में पारित समारोह को बुलाया गया था।'।

नमस्ते,

मैंने इस पोस्ट को ध्यान से पढ़ा लेकिन मुझे समझ नहीं आ रहा है कि मैं अपनी स्थानीय लिपि ".user.js" पर अपने वैकल्पिक समाधान का उपयोग कैसे करूं। मैं आपका समाधान कैसे लागू कर सकता हूं? क्षमा करें, मैं नया हूँ।

(फ़ायरफ़ॉक्स को अपडेट करने के बाद से, एक जेनरेट किया गया पॉपअप-आईफ्रेम अब अतिरिक्त स्क्रिप्ट द्वारा पहचाना नहीं जाता है, लेकिन अगर मैं एक ही पॉपअप को एक नई विंडो में खोलता हूं, तो स्क्रिप्ट लागू होती है।)

आपकी सहायताके लिए अग्रिम में आपका शुक्रिया

आपने ठीक-ठीक वर्णन किया है कि समस्या क्या है: यह @noframes की तरह सक्रिय है। फ़्रेम सामग्री का URL आपकी स्क्रिप्ट को सही ढंग से सक्रिय नहीं करता है। उम्मीद है कि यह जल्द ही ठीक हो जाएगा (अतिरिक्त विंडो में फ्रेम खोलना कष्टप्रद है) ...

धन्यवाद एसेल्स।
और हमेशा फ़ायरफ़ॉक्स के अपडेट के बाद से, मैं हेडर में लक्षित साइट पर पहले से उपयोग किए गए सभी scipts '.js' (आवश्यकता के साथ) घोषित करने के लिए बाध्य हूं। (jquery सहित)
और यह वही नहीं है.... यह बग या विरोध पैदा करता है।
क्या आप भी जानते हैं यह समस्या?

2945 में अवलोकन के लिए एक और उदाहरण है, कि स्क्रिप्ट फ़्रेम में शुरू होती हैं, लेकिन कुछ मिलीसेकंड के बाद छोड़ दी जाती हैं।

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

मेरे पास एक साइट है जिसके साथ मुझे बातचीत करने की आवश्यकता है। यह शुरू में एक अलग डोमेन पर पंक्तियों = "100%, 0" (स्क्रीन को भरने के लिए एक फ्रेम) के साथ एक फ्रेमसेट/फ्रेम लोड करता है। इस फ़्रेम में मध्यवर्ती फ़्रेमसेट/फ़्रेम के डोमेन के भीतर एक फ़्रेमसेट / 3 फ़्रेम होते हैं।

कुछ 1+3 चाइल्ड फ्रेम की जीएम स्क्रिप्ट अस्तित्व में "ब्लिप" हो जाएगी, फिर प्रारंभिक चक्र के बाद गायब हो जाएगी - वे किसी भी एसिंक्रोनस ऑपरेशन के बाद कभी वापस नहीं आती हैं। यह इस धागे पर वर्णित कुछ व्यवहारों पर फिट बैठता है। ध्यान दें कि कौन से "ब्लिप" और नीचे वर्णित व्यवहार ब्राउज़र/जीएम संस्करण द्वारा भिन्न होते हैं, लेकिन यह यादृच्छिक नहीं है; पैटर्न अजीब हैं लेकिन किसी भी सेटअप के लिए 100% दोहराने योग्य हैं।

1. पहला फ्रेमसेट/फ्रेम कभी भी अस्तित्व में नहीं आएगा। मैंने प्रारंभिक चक्र में और देरी के बाद, window.document और असुरक्षितविंडो.दस्तावेज़ दोनों के माध्यम से फ्रेम टैग को अलग करने और पुनर्निर्माण करने का प्रयास किया है, लेकिन कुछ भी उस फ्रेम की जीएम स्क्रिप्ट को कंसोल.लॉग को कुछ भी रिपोर्ट करने का कारण नहीं बनता है। ( @include * है, जिसमें कोई @exclude या अन्य URL फ़िल्टरिंग नहीं है।)
2. बाद के कुछ व्यवहार फ़ायरफ़ॉक्स 52.8/जीएम 4.1 और फ़ायरफ़ॉक्स 60.0/जीएम 4.3 के बीच भिन्न होंगे, लेकिन मैं प्रत्येक मामले में फ्रेम 'जीएम स्क्रिप्ट प्राप्त कर सकता हूं ताकि अस्तित्व में "ब्लिप" हो सके कि @noframes सेट है या नहीं। यह @includes * के साथ है, कोई अन्य URL फ़िल्टर नहीं है। इन्हें कभी भी @noframes सेट के साथ ब्लिप नहीं करना चाहिए। मैंने सत्यापित किया है कि window.top!==window, यानी ब्राउज़र जानता है (या पता होना चाहिए) ये फ्रेम में हैं।
3. फ़ायरफ़ॉक्स 52.8 / जीएम 4.1 में, अगला फ्रेमसेट / 3 फ्रेम हमेशा अस्तित्व में रहेगा। फ़ायरफ़ॉक्स 60.0/जीएम 4.3 में, वे प्रारंभिक फ्रेम लोड पर "ब्लिप" नहीं करते हैं।
4. फ़ायरफ़ॉक्स 60.0/जीएम 4.3 में, 3 फ्रेम में से एक में एक लिंक पर क्लिक करना जो 3 फ्रेम में से एक को नेविगेट करता है (एंकर लिंक पर "लक्ष्य" विशेषता के माध्यम से, स्क्रिप्ट नहीं) "ब्लिप" करेगा - नया यूआरएल नहीं, लेकिन नेविगेट किए गए फ़्रेम के लिए पुराना URL. (यह उन फ़्रेमों में से एक है जो आइटम # 3 में प्रारंभिक लोड पर ब्लिप हो गए थे।)
5. यहाँ सबसे अजीब हिस्सा है। दोनों ब्राउज़र सेटअप में --- चरणों का पालन करते हुए, हमने फ्रेमसेट की 2 परतों, 4 कुल फ़्रेमों के साथ प्रारंभिक पृष्ठ खोला है, और एक ही पृष्ठ पर एक अलग फ़्रेम को नेविगेट करने के लिए एक फ़्रेम में एक लिंक पर क्लिक किया है। इसे नाम देने के लिए, हमारे शुरू में प्रदर्शित दूसरे स्तर के फ्रेमसेट में "top.htm", "menu.htm" और "start,htm" फ्रेम थे। हमने "menu.htm" फ्रेम में एक लिंक पर क्लिक किया है, जिससे फ्रेम "start.htm" को "content.htm" पर नेविगेट करने के लिए प्रेरित करता है, ऊपर बताए गए प्रति ब्राउज़र सेटअप के समान लेकिन थोड़ा अलग व्यवहार के साथ। अब, हम "content.htm" फ्रेम के अंदर एक लिंक पर क्लिक करते हैं, उसी फ्रेम, एक ही डोमेन के अंदर नेविगेट करने के लिए।

इस बिंदु पर, "content.htm" की स्क्रिप्ट न केवल "ब्लिप" होगी... यह GM.xmlHttpRequest के पूरा होने के बाद भी जीवित रहेगी - एक अतुल्यकालिक घटना। इस समय, "content.htm" ब्राउज़र डिस्प्ले पर कहीं नहीं है, लेकिन इसकी स्क्रिप्ट काम करना जारी रखेगी।

तो मुझे ऐसा प्रतीत होता है कि फ्रेम के भीतर पृष्ठों पर जीएम स्क्रिप्ट काम नहीं कर रही है क्योंकि पेज लोड के बजाय पेज अनलोड पर स्क्रिप्ट लोड की जा रही है। @run-at को दस्तावेज़-प्रारंभ में सेट करना और स्क्रिप्ट को असुरक्षितविंडो.दस्तावेज़ के DOMContentReady ईवेंट में डालने से कोई सुधार नहीं हुआ। (इसे विंडो पर सेट करना। दस्तावेज़ कभी भी घटना को सक्रिय नहीं करता है।)

-रयान

फ़ायरफ़ॉक्स 52.8 / जीएम 4.1 में, अगला फ्रेमसेट / 3 फ्रेम हमेशा अस्तित्व में रहेगा। फ़ायरफ़ॉक्स 60.0/जीएम 4.3 में, वे प्रारंभिक फ्रेम लोड पर "ब्लिप" नहीं करते हैं।

फ़ायरफ़ॉक्स 57 में संक्रमण में मोज़िला ने _something_ को बदल दिया। जो कुछ भी था वह बदल गया (या टूट गया) जिस तरह से फ्रेम्स को ट्रिगर किया जा सकता था। इसके बारे में संक्षेप में किसी अन्य मुद्दे में बात की गई थी। परिणामस्वरूप स्क्रिप्ट प्रारंभिक फ्रेम लोड (57+) पर नहीं चलेंगी।

अंततः userScript या contentScript API पर स्विच करने से यह सब हल हो जाना चाहिए।

तो लोग कहते रहते हैं, फिर भी वायलेंटमंकी तख्ते में अमल करना जारी रखता है। वीएम वेब पेज सामग्री से उपयोगकर्ता स्क्रिप्ट को ठीक से अलग नहीं करता है (सीएसपी ब्लॉक यूजरस्क्रिप्ट, वेब पेज वैश्विक वस्तुओं को फिर से लिख सकते हैं), या मैंने बहुत पहले Greasemonkey को चकित कर दिया था। शायद ये संबंधित समस्याएं हैं, लेकिन मैं यूजरस्क्रिप्ट इंजन का उपयोग कर रहा हूं, इसलिए मुझे फ़ायरफ़ॉक्स के क्रोम को अपने दम पर खोजने के लिए पर्याप्त गहराई से तलाशने की जरूरत नहीं है।

हम्म यह एक कठिन मुद्दा है, मेरी कुछ स्क्रिप्ट अब काम नहीं करती हैं क्योंकि वे iframes के साथ काम नहीं कर सकती हैं। तो ऐसा लगता है कि इसे ठीक करना वास्तव में संभव नहीं है, और हमें मोज़िला के लिए कुछ एपीआई लागू करने के लिए रास्ता तय करना होगा? क्या वर्कअराउंड की तरह हम स्वयं कुछ नहीं कर सकते? मुझे आईफ्रेम में किसी पृष्ठ पर कुछ सामान करने की ज़रूरत है, अक्सर उसी डोमेन से भी।

इस समय के लिए मेरा अपना समाधान है Greasemonkey को टॉप फ्रेम में और Violentmonkey को चाइल्ड फ्रेम में चलाना। मैं टैम्पर्मोनकी का उपयोग नहीं कर सकता क्योंकि इसमें एक अस्पष्ट होममेड लाइसेंस है, लेकिन अगर यह आपके लिए कोई समस्या नहीं है, तो यह बेहतर काम कर भी सकता है और नहीं भी।

ध्यान रखें कि वीएम स्क्रिप्ट को पेज के अपने संदर्भ में छोड़ देता है। यह सुरक्षित समकक्ष के बिना जीएम के असुरक्षित विन्डो की तरह है। सबसे यादगार समयों में से एक मैं एक स्क्रिप्ट डिबग कर रहा था, जहां पृष्ठ सामग्री ने Array.prototype पर एक 'toJSON ()" विधि को परिभाषित किया था, जिससे JSON.stringify () मेरी स्क्रिप्ट के अंदर अमान्य JSON को थूक देता था। मुझे करना पड़ा रक्षात्मक रूप से जाल और इन्हें ठीक करें जैसा कि मैंने उन्हें पाया है।

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

@RyanHanekamp टिप के लिए धन्यवाद! शायद मैं कुछ लिपियों के लिए वायलेंटमोनकी का उपयोग करूंगा।

क्या हिंसक के पास भी तुल्यकालिक GM_getValue जैसा कुछ है? यह एक और समस्याग्रस्त मुद्दा है जो नए Greasemonkey में एक टन स्क्रिप्ट को तोड़ता है। मैं अभी भी Greasemonkey पर सबसे अधिक भरोसा करता हूं, हालांकि, विभिन्न कारणों से, इसलिए मैं इसे नहीं छोड़ूंगा।

आईफ्रेम के रूप में, मैं उन्हें ऑब्जेक्ट टैग के साथ बदलने की कोशिश कर रहा हूं, जो स्पष्ट रूप से जावास्क्रिप्ट का उपयोग करके सीधे पहुंच सकता है, जैसे:

myObject= document.createElement('object');
myObject.setAttribute('id', 'myObject'); 
document.body.appendChild(myObject);
myObject.setAttribute('src', 'https://example.com');

फिर, ऑब्जेक्ट लोड होने के बाद:
document.querySelector('#myObject').contentDocument.defaultView.document.querySelectorAll('someElementInsideObjectPage')
कम से कम यह मेरे लिए एक स्क्रिप्ट में काम करता है जहां वस्तु मुख्य पृष्ठ के समान होस्ट पर होती है। आप ऑब्जेक्ट से और को ( ... contentDocument.defaultView.postMessage('hello, object') ) संदेश भी भेज सकते हैं।

मैं वीएम विशेषज्ञ नहीं हूं, लेकिन मेरा मानना ​​है कि यह कम से कम अधिकांश मूल जीएम_* एपीआई को लागू करता है। मुझे लगता है कि लंबे समय में एक सिंक्रोनस प्लेटफॉर्म पर बैकट्रैक करने की तुलना में आपकी स्क्रिप्ट को एसिंक्रोनस में अनुकूलित करना बेहतर है। मेरी समझ के अनुसार, Greasemonkey ने इसे नए क्वांटम ढांचे के भीतर प्रदर्शन को बढ़ावा देने के रूप में किया, जो पृष्ठभूमि और सामग्री स्क्रिप्ट के बीच सिंक्रोनस कॉल की अनुमति नहीं देता है।

वस्तु समाधान के लिए, यह मेरी विशेष समस्या का समाधान नहीं करेगा, लेकिन मुझे खुशी है कि दूसरों ने इसे उपयोगी पाया है। सीएसएस/गुणों/आदि को मार्शल करने और फ्रेम के साथ-साथ आईफ्रेम के साथ काम करने के अलावा, मुझे संभावित रूप से असुरक्षित के रूप में कैप्चर प्रक्रिया में ऑब्जेक्ट्स को फ़िल्टर करना होगा। इन सभी समस्याओं के आसपास के तरीके हैं, लेकिन वीएम तब तक आसान अंतरिम था जब तक कि जीएम आखिरकार टिन पर जो कहता है वह करता है।

साथ ही, यदि आपके पास समान मूल फ्रेम/आईफ्रेम है, तो आप सीधे उनकी सामग्री तक भी पहुंच सकते हैं। कठिन हिस्सा क्रॉस-ओरिजिनल है, यही वजह है कि मुझे फ्रेम के अंदर यूजरस्क्रिप्ट की जरूरत है। यह पैरेंट विंडो पर वापस बात करने के लिए एक window.postMessage() चैनल सेट करता है।

@RyanHanekamp यह जानकर अच्छा लगा कि हिंसक बंदर के पास अभी भी पुराना, सरल GM_* है। मैं वास्तव में चाहता हूं कि नए संस्करण के अलावा, Greasemonkey ने पुराने, तुल्यकालिक GM_getValue को पिछड़े संगतता के लिए रखा था। मैं एक नई स्क्रिप्ट में नए एसिंक्रोनस फ़ंक्शन को लागू करने का प्रयास कर सकता हूं, लेकिन मैं प्रोग्रामर नहीं हूं और मुझे यकीन नहीं है कि मैं इसे काम कर सकता हूं या नहीं। और मैं निश्चित रूप से पुराने GM_getValue के उपयोग को 2000 लाइनों की एक प्राचीन लिपि में पुन: सक्रिय करने में असमर्थ हूं जो मुझे ऑनलाइन मिली ... इतनी सारी स्क्रिप्ट अब टूट गई हैं।

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

ओह, आप सीधे समान-मूल आईफ्रेम (पोस्टमैसेज आदि के बिना) की सामग्री तक पहुंच सकते हैं? मुझे याद है कि रास्ता खोजने में बहुत समय लगा, लेकिन यह संभव नहीं लग रहा था। इसलिए मैंने पोस्टमैसेज पर भी स्विच किया।

फ्रेम्स और आईफ्रेम में एक कंटेंटविंडो प्रॉपर्टी होती है जो विंडो प्रॉपर्टी के बराबर होती है। दोनों के पास डीओएम तक पहुंचने के लिए दस्तावेज़ संपत्ति है।

iframes (उसी मूल पर) के साथ काम करने का सबसे कठिन हिस्सा यह पता लगाना है कि इसकी सामग्री कब लोड होती है, क्योंकि ऐसा होने तक आप स्क्वाट नहीं कर सकते। ऑनलोड काम नहीं करता है कि यह कैसा दिखता है। फ़ायरफ़ॉक्स एक DOMFrameContentLoaded ईवेंट प्रदान करता है जो लोड किए गए प्रत्येक फ़्रेम के लिए सक्रिय होता है, जिसमें पोते/महान-पोते आदि फ़्रेम शामिल हैं, जिन्हें आप इवेंट.टारगेट प्रॉपर्टी के साथ मूल फ्रेम/iframe तत्व से मिला सकते हैं। यदि आप फ्रेम/आईफ्रेम की सामग्री को नियंत्रित करते हैं, तो आप इसे या तो पोस्टमैसेज के साथ माता-पिता से बात कर सकते हैं या विंडो पर वैश्विक विधि को कॉल कर सकते हैं। पैरेंट ऑब्जेक्ट।

जिसके बारे में बोलते हुए... यह इस मुद्दे के लिए एक संभावित समाधान है। यदि किसी उपयोगकर्ता स्क्रिप्ट को क्रॉस-डोमेन विंडो संदर्भ में मैन्युअल रूप से इंजेक्ट करने के लिए जीएम स्क्रिप्ट को कोड करने का कोई तरीका है या हो सकता है, तो यह उपयोगकर्तास्क्रिप्ट निर्माता के लिए बहुत अधिक कोडिंग करेगा, लेकिन यह काम पूरा कर सकता है। पैटर्न को DOMFrameContentLoaded को सुना जाएगा, जांचें कि क्या event.target पहली पीढ़ी का है, और यदि ऐसा है तो मैन्युअल रूप से स्क्रिप्ट इंजेक्ट करें। (यह मानते हुए कि पहली पीढ़ी के फ्रेम की स्क्रिप्ट दूसरी पीढ़ी के फ्रेम के लिए DOMContentLoaded को सुन सकती है, और इस तरह एक पूरी श्रृंखला प्राप्त कर सकती है।) @ रन-एट डोम-स्टार्ट व्यवहार प्राप्त करने का कोई तरीका नहीं होगा, और समय के मुद्दे भी हो सकते हैं, लेकिन हम शायद अधिकांश उपयोग-मामलों के लिए उनके आसपास काम कर सकते हैं।

मैंने व्यक्तिगत रूप से इस मुद्दे को हल करने के लिए छोड़ दिया है, और इसके बजाय एक एक्सटेंशन को सीधे कोडिंग करने के लिए आगे बढ़ गया हूं। जो सभी फ्रेम में ठीक काम करता है!

इस बिंदु पर Greasemonkey और Violentmonkey के बीच का अंतर यह प्रतीत होता है कि Violentmonkey को सामग्री स्क्रिप्ट से सभी_फ्रेम के साथ सत्य पर सेट किया जा रहा है, जबकि Greasemonkey के पास कोई इंस्टाल-टाइम सामग्री स्क्रिप्ट नहीं है और पूरी तरह से पृष्ठभूमि स्क्रिप्ट की संदिग्ध क्षमता पर निर्भर करता है जब एक टैब का फ्रेम नेविगेट किया गया है। (और Violentmonkey सीएसपी पृष्ठों पर विफल रहता है क्योंकि यह अस्थायी रूप से अधिक सुरक्षित tabs.executeScript() का उपयोग करने के बजाय एक एससीआरआईपीटी टैग इंजेक्ट करता है।)

All_frames के साथ एक स्थिर सामग्री स्क्रिप्ट में रखें, run_at start, प्रारंभ / दस्तावेज़ के लिए पृष्ठभूमि प्रक्रिया को सूचित करने के लिए सब कुछ से मेल खाता है। DOMContentLoaded / document.Idle प्रत्येक run_at के लिए उपयोगकर्ता स्क्रिप्ट को ट्रिगर करने के लिए, और आप जाने के लिए अच्छे हैं। इस समस्या को दूर करने के लिए एक गैर-तुच्छ लेकिन प्रबंधनीय मात्रा में काम। मैं इसे स्वयं ठीक कर दूंगा, लेकिन मुझे आपकी देव निर्भरताओं के माध्यम से आगे बढ़ने में कोई दिलचस्पी नहीं है और केवल आउटपुट कोड उत्पन्न कर सकता है।

@RyanHanekamp

और इसके बजाय एक एक्सटेंशन को सीधे कोडिंग करने के लिए आगे बढ़े हैं। जो सभी फ्रेम में ठीक काम करता है!

क्या आप अपना वह एक्सटेंशन कोड साझा करना चाहेंगे?

मेरा विस्तार सामान्य उद्देश्य नहीं है। मुद्दा यह है कि all_urls के साथ मेनिफेस्ट में एक स्थिर सामग्री_स्क्रिप्ट का उपयोग करके, जब भी कोई फ्रेम लोड या नेविगेट किया जाता है तो all_frames स्क्रिप्ट चलाएगा, और पृष्ठ की सामग्री-सुरक्षा-नीति के बावजूद eval/फ़ंक्शन कन्स्ट्रक्टर कोड भी ठीक हो सकता है।

मैंने प्रोग्रामेटिक रूप से निर्मित फ्रेम/विंडो के साथ परीक्षण नहीं किया है, लेकिन मुझे लगता है कि वे रन_एट सेटिंग की परवाह किए बिना प्रारंभिक निर्माण पर चलेंगे, क्योंकि ऐसे फ्रेम शुरू में खाली और फिर पॉप्युलेट किए जाते हैं - इंजन शायद केवल प्रारंभिक निर्माण को देखेगा। मैंने डेटा का परीक्षण भी नहीं किया: यूआरएल, जिसके लिए स्पष्ट मिलान की आवश्यकता हो सकती है - मुझे यकीन नहीं है कि क्या all_urls उन्हें कवर करता है, या सिर्फ http/https।

यह एक स्थिर content_script संदर्भ भी नहीं हो सकता है, लेकिन यह दस्तावेज़ीकरण से अनिश्चित प्रतीत होता है यदि पृष्ठ को नेविगेट करने पर गतिशील रूप से आमंत्रित सामग्री स्क्रिप्ट स्वचालित रूप से लोड हो जाती है। मेरी धारणा यह है कि उन्हें केवल आपूर्ति किए गए मिलान पैटर्न के अनुसार मिलान करने वाले टैब/फ़्रेम में ही अंतःक्षिप्त किया जाता है, और नेविगेशन पुन: इंजेक्शन को ट्रिगर नहीं करता है। लेकिन मुझे इस उद्देश्य के लिए स्थिर सामग्री_स्क्रिप्ट का उपयोग करने में कोई कमी नहीं दिख रही है।

Greasemonkey स्पष्ट रूप से उपयोगकर्ता स्क्रिप्ट को मेनिफेस्ट में स्थिर संसाधनों के रूप में शामिल नहीं कर सकता है, और सामग्री स्क्रिप्ट में tabs.executeScript तक सीधी पहुंच नहीं है (हालांकि मैं शायद ही इस पर एक विशेषज्ञ हूं क्योंकि मैं केवल कुछ दिनों में हूं), लेकिन एक स्थिर सामग्री स्क्रिप्ट क्या कर सकती है पृष्ठभूमि प्रक्रिया को यह बताने के लिए संदेश देती है कि फ्रेम आईडी नेविगेट किया गया है, और किस यूआरएल पर। webRequest या webNavigation में सही घटना को हुक करने के लिए इस थ्रेड पर उल्लिखित प्रयासों को मैं कैसे समझता हूं, यह अधिक विश्वसनीय होगा। स्थैतिक सामग्री_स्क्रिप्ट से संकेत वह घटना बन जाता है जिसे हम Greasemonkey के उपयोगकर्तास्क्रिप्ट लोडर / इंजेक्टर को ट्रिगर करने के लिए देख रहे हैं।

उन उपयोक्ताओं के लिए देरी हो सकती है, जिन्हें document_start पर कड़ाई से run_at करना होगा। बैकग्राउंड स्क्रिप्ट के लिए कॉल एसिंक्रोनस है, और उपयोगकर्ता स्क्रिप्ट के लागू होने तक दस्तावेज़ आगे बढ़ चुका होगा। संभवतः यही कारण है कि Violentmonkey tabs.executeScript के बजाय एक अस्थायी स्क्रिप्ट टैग का उपयोग करता है, क्योंकि स्क्रिप्ट टैग इंजेक्शन सीधे content_script से सिंक्रोनाइज़ किया जा सकता है। मुझे दस्तावेज़ की स्थिति की अनिश्चितता के आसपास काम करने के लिए मजबूर होना पड़ेगा run_at document_start परेशानी के लिए, लेकिन स्क्रिप्ट के लिए बेहतर नहीं चल रहा है।

Greasemonkey ... पृष्ठभूमि प्रक्रिया को संदेश [के लिए एक स्थिर सामग्री स्क्रिप्ट का उपयोग कर सकता है] यह बताने के लिए कि फ्रेम आईडी नेविगेट किया गया है, और किस यूआरएल पर ...

इसी को हम है इस्तेमाल किया करने के लिए करते हैं पता लगाने के लिए .user.js नेविगेशन। एक स्पष्ट और अच्छे समाधान की तरह लगता है: सामग्री स्क्रिप्ट चलाकर सामग्री का पता लगाएं!

लेकिन यह पता चला है कि एक्सटेंशन सामग्री स्क्रिप्ट को भी सीएसपी (#2631 और http://bugzil.la/1267027 और http://bugzil.la/1411641) द्वारा तोड़ा जा सकता है।

मैं निम्नलिखित सीएसपी सेट के साथ फ़ायरफ़ॉक्स 60.0.1 और 52.8.1ESR पर सीधे content_script के भीतर से फंक्शन () कंस्ट्रक्टर सहित अपना खुद का प्लगइन निष्पादित कर सकता हूं:

फ्रेम-src डेटा :; वस्तु-स्रोत 'कोई नहीं'; स्क्रिप्ट-स्रोत 'कोई नहीं'; शैली-स्रोत 'असुरक्षित-इनलाइन' डेटा :; कनेक्ट-src 'कोई नहीं'; मीडिया-स्रोत 'कोई नहीं';

2631 को बंद कर दिया गया है, जाहिरा तौर पर क्योंकि फ़ायरफ़ॉक्स ने इसके अंतर्निहित बग को ठीक कर दिया है। पहला बगज़िला स्क्रिप्ट टैग (वायलेंटमोनकी विधि) को इंजेक्ट करने के संदर्भ में है, न कि सामग्री_स्क्रिप्ट को। दूसरा सीएसपी के लिए सैंडबॉक्स विशेषता के संदर्भ में है, आश्चर्य की बात नहीं है क्योंकि यह डोमेन को कभी भी सफलतापूर्वक एक डोमेन मैच को स्वयं तक पूरा करने के लिए मजबूर नहीं करता है। थोड़े NaN की तरह! == NaN।

जब यह पहली बार कई महीने पहले दायर किया गया था तो हमने चीजों को अलग तरह से किया था। आज हम नेविगेशन का पता लगाने के लिए webNavigation.onCommitted का उपयोग करते हैं, और परीक्षण में मैं अभी चल रहा हूं, किसी कारण से मैं इसे (नी) फ्रेम पर ट्रिगर नहीं देख रहा हूं)।

हैलो, क्या यह अब हल हो गया है?

मैं एक स्क्रिप्ट नहीं प्राप्त कर सका जिसे मैंने टैम्परमोनकी के लिए ग्रीसमोनकी के साथ आईफ्रेम पर लॉन्च करने के लिए बनाया था।

निष्पादन के लिए कोड हमारी ओर से नहीं बदला गया है। इसलिए जब तक मोज़िला ने अपने अंत में कुछ नहीं बदला है तब भी यह टूटा हुआ है। हालांकि #2663 इसे हल करना चाहिए।

यह ध्यान देने योग्य हो सकता है कि वायलेंटमोनकी और टैम्परमोनकी एम्बेडेड फ्रेम के अंदर ठीक काम करते हैं।

कम से कम मेरे लिए, टैम्पर्मोनकी को क्रोम में आईफ्रेम की समस्या है।

यह ध्यान देने योग्य हो सकता है कि वायलेंटमोनकी और टैम्परमोनकी एम्बेडेड फ्रेम के अंदर ठीक काम करते हैं।

कम से कम मेरे लिए, टैम्पर्मोनकी को क्रोम में आईफ्रेम की समस्या है।

लेकिन यह मेरे लिए फ़ायरफ़ॉक्स वायलेंटमोनकी में काम करता है। तो मुझे आश्चर्य है कि यह वहां कैसे काम कर सकता है?

मैंने अभी देखा है कि पुरानी सिंक GM_GetValue का उपयोग करने वाली एक स्क्रिप्ट अभी भी Violentmonkey में भी ठीक काम करती है। वो कैसे संभव है? मैंने सोचा था कि फ़ायरफ़ॉक्स ने एसिंक्स GM.GetValue को मजबूर कर दिया था? मैं अब बहुत उलझन में हूँ: संभवतः वायलेंटमोनकी को सिंक और अन्य सामान का समर्थन करने के लिए कुछ और बलिदान करना पड़ा?

@ Cerberus-tm फ़ायरफ़ॉक्स में परिवर्तन का मतलब है कि डेटा केवल एक्सटेंशन स्टोरेज या पृष्ठभूमि संदर्भ से असीमित रूप से अनुरोध किया जा सकता है (उपयोगकर्ता स्क्रिप्ट स्वयं को असीमित रूप से सामग्री स्क्रिप्ट पर भेजी जाती है)। हालाँकि, डेटा उपयोगकर्ता स्क्रिप्ट को समकालिक रूप से प्रदान किया जा सकता है, यदि प्रत्येक GM4 सामग्री स्क्रिप्ट को सामग्री स्क्रिप्ट में प्रीफ़ेच और कैश किया जाता है, तो उस पृष्ठ में लोड की जा रही प्रत्येक उपयोगकर्ता स्क्रिप्ट के लिए संग्रहीत डेटा।

ऐसा कैश सामग्री स्क्रिप्ट को डेटा के लिए उपयोगकर्तास्क्रिप्ट के अनुरोधों के लिए समकालिक रूप से प्रतिक्रिया करने की अनुमति देगा। कैश को लागू करने से विभिन्न सामग्री स्क्रिप्ट में निरंतरता बनाए रखने में समस्याएं आती हैं, लेकिन GM4 के एक्सटेंशन स्टोरेज में सभी परिवर्तनों के लिए सामग्री स्क्रिप्ट को सुनने से इसका समाधान किया जा सकता है। इसके अलावा, यदि कोई उपयोगकर्ता स्क्रिप्ट बड़ी मात्रा में डेटा संग्रहीत कर रहा है, तो इसे प्रत्येक सामग्री स्क्रिप्ट में कैशिंग करना जहां उपयोगकर्तास्क्रिप्ट चलाया जाता है, प्रत्येक सामग्री स्क्रिप्ट के लिए आवश्यक स्मृति को भी महत्वपूर्ण रूप से बढ़ाता है।

TM और VM ने मूल Greasemonkey API के साथ संगतता को न तोड़ने के लिए उपरोक्त के समान कुछ करना चुना, जब उन उपयोगकर्तास्क्रिप्ट प्रबंधकों को क्रोम के लिए लागू किया गया था, जिसमें समान प्रतिबंध wrt हैं। विस्तार भंडारण, आदि के साथ अतुल्यकालिक संचार। यह देखते हुए कि वे इसे पहले से ही क्रोम के लिए कर रहे हैं, फ़ायरफ़ॉक्स के लिए लागू होने पर उनके बदलने का कोई कारण नहीं था।

इसलिए, WebExtensions के FF57 कट-ओवर ने GM के पुनर्लेखन को बाध्य किया, लेकिन इसने GM.getValue , GM.setValue आदि के लिए अतुल्यकालिक API को अपनाने के लिए बाध्य नहीं किया। WebExtensions ने इसका उपयोग किया सिंक्रोनस की तुलना में एसिंक-आधारित एपीआई को लागू करना आसान होगा, लेकिन इसने इसे आवश्यक नहीं बनाया।

व्यक्तिगत रूप से, मुझे लगता है कि पसंद, और संगतता को तोड़ने के अन्य विकल्प, दुर्भाग्यपूर्ण थे/हैं। स्क्रिप्ट के साथ पश्चगामी संगतता की कमी जो GM3 में ठीक चल रही थी और/या TM के साथ संगतता के परिणामस्वरूप बहुत से लोग GM4 का उपयोग नहीं करने का विकल्प चुनते हैं। मेरा अनुभव यह है कि मेरे द्वारा उपयोग की जाने वाली 30 से अधिक उपयोगकर्ता स्क्रिप्ट, जिनमें से सभी GM3 में ठीक काम करती हैं, GM4 के साथ काम नहीं करती हैं (या कम से कम GM4 के साथ संगत होने के लिए फिर से लिखे जाने से पहले काम नहीं करती हैं)। अभी भी 28 उपयोगकर्ता स्क्रिप्ट हैं जिनका मैं दैनिक उपयोग करता हूं जो GM3 के तहत ठीक चलती हैं जो GM4 के साथ काम नहीं करती हैं।

मैंने स्टैक ओवरफ्लो पर इस मुद्दे पर एक वर्कअराउंड पोस्ट किया है कि कैसे एक iframe पर Greasemonkey/‌Tampermonkey/userscript को लागू करने के उत्तर के रूप में। मूल रूप से, मैं फ्रेम लोड होने की प्रतीक्षा कर रहा हूं और फिर मैं window.frames सरणी पर काम कर रहा हूं। मैं प्रत्येक फ्रेम के शरीर में एक कस्टम मार्कर का उपयोग यह दर्शाने के लिए करता हूं कि मैंने पहले ही फ्रेम देखा है।

शायद Greasemonkey एक समान तरीके से समाधान लागू कर सकता है?

यह बहुत अच्छा होगा अगर हमारे पास GM.waitFor(css_selector, action_function) जैसे WaitForKeyElements() भी हो , लेकिन यह एक तरफ है।