webNavigation.onCommitted لا "يرى" إنشاء الإطار الأولي / عرض الصفحة ، على الرغم من أنه إذا تنقل الإطار في مكان آخر غير صفحته الأولية ، فسوف يلتقطه المستمع. إذا كانت الخيارات تتضمن المفتاح 'allFrames': true فإن المشكلة _ بعض الشيء_ تم حلها. سيتم إدخال النص البرمجي في أي إطار في صفحة html الثابتة ، على الرغم من أنك تواجه مشكلات مطابقة أصل / عنوان url. علاوة على ذلك ، إذا تم إنشاء إطار باستخدام Javascript ، فلن يتم حقن البرنامج النصي.

أسهل حل يمكن أن أفكر فيه هو استبدال webNavigation.onCommitted with webRequest.onResponse الذي يبدأ بفلتر {'urls': ['<all_urls>'], 'types': ['main_frame', 'sub_frame']} .

لقد أجريت بعض الاختبارات المحدودة ولم تكن هناك حاجة إلى مزيد من التغييرات. تمكنت من تنفيذ برنامج نصي داخل إطار وإطار تم إنشاؤه باستخدام جافا سكريبت.

arantius أي خطط لدمج الإصلاح من Sxderp ؟

يؤثر هذا على السيناريوهات التي تكون فيها إطارات iframe عبارة عن كائنات مشتركة الأصل ، لذا من المستحيل إجراء أي نوع من التعديل بدون تشغيل GM على إطارات ifram هذه المحددة.

شكرا !

غاب عن هذا ، سوف ننظر في الأمر قريبا.

مجرد ملاحظة أثناء اختبار النصوص القديمة ، لا أعرف ، إذا كانت تساعد ...

بالنظر إلى نص ، من المفترض أن يعمل على إطار iframe ،
يبدو كما لو أنه ينفذ التغييرات على الصفحة ،
ولكن بعد ذلك يتم التحديث مرة أخرى إلى الصفحة غير المعدلة.

لا أستطيع رؤية الوميض إلا عندما أقوم بتحديث الصفحة بسرعة كبيرة.

مجرد ملاحظة أثناء اختبار النصوص القديمة ، لا أعرف ، إذا كانت تساعد ...

هل هذا مع التصحيح الخاص بي أم مع الإصدار الذي تم إصداره؟

آه ، أعتقد أنه كان الإصدار 4.0 ...
I WAS @ 4.1b3 ، لكن بالنسبة للاختبارات ، أنا متأكد من أنني أعدت تثبيت نسخة الإصدار (حتى الآن!)

الشيء نفسه هنا مع إطارات iframe مثل Eselce. يتم تنفيذه بطريقة ما ، ولكن يتم إيقافه بعد تحميل إطار iframe أو الصفحة.

إذا قمت بحقن هذا البرنامج النصي ، فسأحصل على 1 و "self! == top":

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

لا يتم عرض "المهلة" في السجل ، ولا يتم عرض جميع الوظائف والروابط.

أنا استخدم 4.1b3.

لدي نفس المشكلة عند تشغيل GM 4.0 على Quantum. لقد كتبت مثالًا وهميًا بسيطًا للغاية من صفحتين: main.html و framed.html ، ونص GM يتم تحميله في كل صفحة ويخرج عنوان URL للصفحة التي تم تحميلها عليها.

في معظم الأوقات ، لا أتلقى سوى إشعارات حول main.html ، لكن في حوالي 5٪ من الحالات ، خاصة إذا ضغطت على F5 ، فقد أتلقى أيضًا إشعارًا بشأن framed.html .

هل هناك أي اختراق لإجبار GM 4.0 بشكل موثوق على التنفيذ داخل إطارات iframes حتى يتم إخراج التصحيح؟

لقد اكتشفت للتو أن نصوص المستخدمين يتم تنفيذها بشكل موثوق في <embed src="..."> ولكن ليس في <iframe src="..">
لقد كتبت نص اختبار صغير:
https://openuserjs.org/scripts/cuzi/iframe_embed_Test_Greasemonkey_4

بعض التفاصيل الإضافية: في بعض الحالات ، يتم تنفيذ البرامج النصية الخاصة بي بالكامل في الإطار (ولكن يتم استبدال العرض لاحقًا بنصوص الصفحة وما إلى ذلك).
في بعض الأحيان ، تنتهي الأجزاء المتزامنة من النص البرمجي ، لكن الأجزاء غير المتزامنة تنقطع فجأة عن طريق نشاط الصفحة ...
امل ان يساعد!

هل لدى أي شخص المزيد من المعلومات حول هذا؟

مجرد ملخص قصير لهذا الموضوع (المشكلة):

• ننسى معظم المنشورات ، فهي لا تنطبق
• على الأرجح ، يتم تنفيذ البرامج النصية دائمًا (ولكن ليس حتى النهاية)
• لسوء الحظ ، يتم تحديث الصفحة لاحقًا - تمت إعادة حساب التخطيط ، وتم إحباط التنفيذ
• ينطبق هذا في الغالب (ولكن ليس بالكامل) على الأجزاء غير المتزامنة من البرامج النصية

أنا لست مهتمًا كثيرًا بهذه العناصر الداخلية ، ولكن من المحتمل أن يكون هناك شخص ما ...

كإصلاح مؤقت ، كنت أقوم بتبديل إطارات iframes للتضمينات ( مثال على البرنامج النصي ) ، والذي يعمل للحصول على نص برمجي يتوافق مع الإطار المطلوب تشغيله ( cvzi لمعرفة أن <embed src="..."> يعمل) .

قد يكون من الجدير بالذكر أن Violentmonkey و Tampermonkey يعملان بشكل جيد داخل الإطارات المضمنة. نظرًا لأن VM مفتوح المصدر ، فربما ترى كيف فعلوه؟

لسوء الحظ ، لا يزال 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. كما أنني لم أقم مطلقًا بتنفيذ التغييرات المقترحة في تعليقات العلاقات العامة. بصراحة ، هذه التغييرات _لا يجب_ أن تكون مطلوبة ، ولكن نظرًا لأن Mozilla تفسد الأمور باستمرار ، فإن التغييرات مطلوبة.
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. انتقل إلى about:config في Firefox وقم بتعيين xpinstall.signatures.required إلى false
4. انتقل إلى about:addons في Firefox ، وانقر فوق الترس ثم حدد التثبيت من الملف.
5. حدد XPI الذي تم إنشاؤه في الخطوة 2.

[1] إذا كان إصدار git لديك لا يدعم العلامات -b و / أو --single-branch (إصدار أقدم من git) ، فيمكنك تنفيذ git clone https://github.com/Sxderp/greasemonkey.git و git checkout use-on-response-started-for-execute .

أهلا،
هل ستصلح المشكلة؟ إنه عيب قديم جدًا ويؤثر على جميع البرامج النصية بناءً على بنية إطارات iframe ...

للتذكير ، لدينا يوم 13 مارس غدًا (راجع Firefox 59.0 ) ...

أريد أن أشير إلى Sxderp :

webNavigation.onCommitted لا "يرى" إنشاء الإطار الأولي / عرض الصفحة ، على الرغم من أنه إذا تنقل الإطار في مكان آخر غير صفحته الأولية ، فسوف يلتقطه المستمع. إذا كانت الخيارات تتضمن المفتاح "allFrames": صحيح أن المشكلة قد تم حلها إلى حد ما. سيتم إدخال النص البرمجي في أي إطار في صفحة html الثابتة ، على الرغم من أنك تواجه مشكلات مطابقة أصل / عنوان url. علاوة على ذلك ، إذا تم إنشاء إطار باستخدام Javascript ، فلن يتم حقن البرنامج النصي.

في الواقع ، لدي دليل على أنه (على نظامي) يتم استدعاء المستمع executeUserscriptOnNavigation بشكل موثوق مع chrome.webNavigation.onCommitted ، لذلك يتم استدعاء chrome.tabs.executeScriptInFrame بـ frameId الصحيح . لماذا لا يحل هذا كل مشاكلنا مع الإطارات؟ لا نحتاج إلى chrome.webRequest.onResponseStarted للتفاعل مع iframe! (أم تقصد ، يتفاعل مع الحدث ، لكن الإطار غير مرئي؟) يطلق عليه بالتأكيد ...

هل هناك خطأ معروف في chrome.tabs.executeScriptInFrame و frameId ؟ كانت هناك مشاكل منذ سنوات ، لكنها تم حلها الآن. لم يتم تعيين all_frames ، لذا يجب أن يكون frameId صالحًا. يبدو أن تعيين الخيار matchAboutBlank إلى true مهم (وإلا فإن executeScript أرجع خطأ <unavailable> ) ، على الرغم من أنني لم أفهم تمامًا أن about:blank أشياء

أيه أفكار؟

سمات؟ هذه الوظيفة الأساسية مفقودة منذ البداية ... آمل ، لقد أساءت تفسير ذلك.

Eselce ، كان هذا منذ وقت طويل ولست متأكدًا من أنني أتذكر تمامًا ما كنت أشير إليه لكنني سأعطيها فرصة. علاوة على ذلك ، لا ينطبق هذا إلا إذا كان فهمي لمطابقة إطار GM 3.x صحيحًا. أي أن كل إطار أصل + مسار مطابق بشكل فردي لتحديد البرامج النصية التي يجب تشغيلها. ليس فقط الوثيقة الأصلية.

الآن ، حول هذه القضية. عندما أجريت الاختبار الأولي ، كان لدي صفحة ثابتة مع نفس الإطار الأصلي وإطار بعيد. عند التحميل الأولي للصفحة لم أتمكن من الحصول على رد الاتصال onCommitted مرة واحدة. تم تشغيله للمستند الرئيسي ولكن لم يتم إطلاقه لأي من الإطارات الثابتة في المستند [1]. وبالتالي لن يتم حقن أي نصوص فيها.

ومع ذلك ، بعد التحميل الأولي ، إذا تسببت في أحد الإطارات "للتنقل" في مكان ما ، فسيتم استدعاء رد الاتصال onCommitted وتم حقن البرامج النصية في الإطار في الموقع الجديد.

جرت محاولة لاستخدام مفتاح الخيار all_frames للتغلب على المشكلة المذكورة أعلاه. أثناء استخدام المفتاح تسبب في إدخال البرامج النصية في الإطارات الموجودة على الصفحة ، كان هناك عيب واضح يتمثل في عدم مطابقة أصل + مسار الإطار بشكل صحيح مع ما يجب أو لا ينبغي تشغيل النص عليه.

جانبا ، ذكرت أيضًا أن استخدام المفتاح all_frames لن يضخ البرامج النصية في الإطارات التي تم إنشاؤها بواسطة Javascript.

[1] لا أعرف ما إذا كانت هذه المشكلة لا تزال قائمة. إذا كنت أتذكر أن هذه المشكلة لم تكن موجودة في FF 52 ESR ولكنها كانت موجودة في 56 (57؟) (وبالتالي الانحدار). ربما تم إصلاحه.

أنا أتفق معك في جميع النقاط تقريبًا.

وأنت محق في أن كل إطار يتم مطابقته بشكل منفصل ، كما لو كان علامة تبويب كاملة (مع window الخاصة به و document ، مضمّن في إطار).

حسنًا ، لقد استخدمت دائمًا نفس بنية القائمة / الإطار تقريبًا ، لذلك ربما يجب أن أختبر بنية مختلفة.

عندما تقول "أطلقت" ، هل تقصد نداء المستمع الصافي؟

كما قلت ، لقد واجهت بعض الأمثلة مع executeScript ينتج عنها حالة خطأ ، لكن المستمع لا يزال يُستدعى.

all_frames لا يعمل ، بسبب الخطأ location (مختلف window ، مختلف document ). راجع للشغل: تتعامل القائمة فقط مع عناوين URL المركزية لكل علامة تبويب - إذا كانت القائمة خاطئة ، فهذا لا يعني أن البرنامج النصي لا يسمى ...

عندما تقول "أطلقت" ، هل تقصد نداء المستمع الصافي؟

في تلك الرسالة المعينة ، قصدت "تم استدعاء الوظيفة التي تم تمريرها إلى onCommitted.addListener ."

أهلا،

قرأت هذا المنشور بعناية ولكني لا أفهم كيفية استخدام الحل البديل الخاص بك على البرنامج النصي المحلي الخاص بي ".user.js". كيف يمكنني تطبيق الحل الخاص بك؟ اسف انا جديد.

(منذ تحديث Firefox ، لم يعد يتم التعرف على إطار iframe المنبثق بواسطة البرنامج النصي الإضافي ، ولكن إذا فتحت نفس النافذة المنبثقة في نافذة جديدة ، فسيتم تطبيق البرنامج النصي.)

شكرا لكم مقدما على مساعدتكم

لقد وصفت بالضبط ما هي المشكلة: إنه مثل @noframes مفعل. عنوان URL لمحتوى الإطار لا ينشط البرنامج النصي الخاص بك بشكل صحيح. نأمل أن يتم إصلاح ذلك قريبًا (فتح الإطارات في النوافذ الإضافية أمر مزعج) ...

شكرا Eselce.
ودائمًا منذ تحديث Firefox ، أجد نفسي مضطرًا في الرأس للإعلان عن استخدام جميع scipts '.js' (مع تتطلب) بالفعل على الموقع المستهدف. (بما في ذلك jquerry)
وهي ليست نفس الشيء ... إنها تخلق أخطاء أو صراعات.
هل تعرف هذه المشكلة أيضًا؟

يحتوي 2945 على مثال آخر للملاحظة ، أن البرامج النصية بدأت في إطارات ، ولكن تم التخلي عنها بعد بعض أجزاء من الألف من الثانية.

أنا متردد في إعطاء عناوين URL المحددة التي أختبرها لأنها خارجة عن إرادتي ، ولكني أجد بعض السلوكيات المتسقة والغريبة التي يجب تمريرها.

لدي موقع أحتاج إلى التفاعل معه. يقوم في البداية بتحميل مجموعة إطارات / إطار بالصفوف = "100٪ ، 0" (إطار واحد لملء الشاشة) في مجال مختلف. يحتوي هذا الإطار على مجموعة إطارات واحدة / 3 إطارات ضمن مجال مجموعة الإطارات / الإطار المتوسط.

بعض البرامج النصية لـ 1 + 3 من الإطارات الفرعية ستظهر إلى الوجود ، ثم تختفي بعد الدورة الأولية - ولن تعود أبدًا بعد أي عملية غير متزامنة. هذا يناسب بعض السلوك الموصوف في هذا الموضوع. لاحظ أن أيها "blip" والسلوك الموصوف أدناه يختلف باختلاف المتصفح / إصدار GM ، ولكنه ليس عشوائيًا ؛ الأنماط غريبة ولكنها قابلة للتكرار بنسبة 100٪ لأي إعداد معين.

1. لن تظهر مجموعة الإطارات / الإطار الأول إلى حيز الوجود مطلقًا. لقد حاولت فصل علامة الإطار وإعادة بنائها ، من خلال window.document و unsafeWindow.document ، في كل من الدورة الأولية وبعد تأخير ، ولكن لا شيء سيتسبب في أن يقوم البرنامج النصي GM للإطار بالإبلاغ عن أي شيء إلى console.log. ( include هو * ، بدون exclude أو أي فلترة أخرى لعناوين URL.)
2. ستختلف بعض السلوكيات اللاحقة بين Firefox 52.8 / GM 4.1 و Firefox 60.0 / GM 4.3 ، لكن يمكنني الحصول على البرامج النصية الخاصة بالإطارات المعدلة وراثيًا في كل حالة " blip " إلى الوجود سواء تم تعيين includes * ، ولا توجد عوامل تصفية URL أخرى. هذه يجب ألا تومض مع تعيين
3. في Firefox 52.8 / GM 4.1 ، ستظهر مجموعة الإطارات التالية / 3 إطارات إلى الوجود دائمًا. في Firefox 60.0 / GM 4.3 ، لا "تومض" عند تحميل الإطار الأولي.
4. في Firefox 60.0 / GM 4.3 ، يؤدي النقر فوق ارتباط في أحد الإطارات الثلاثة التي تتنقل في إطار آخر من الإطارات الثلاثة (عبر سمة "الهدف" على رابط الربط ، وليس النص البرمجي) إلى "انعكاس الضوء" - وليس عنوان URL الجديد ، ولكن عنوان URL القديم للإطار الذي تم التنقل فيه. (هذا أحد الإطارات التي تم مسحها عند التحميل الأولي في العنصر رقم 3.)
5. هذا هو الجزء الأكثر غرابة. في كل من إعدادات المستعرض - باتباع الخطوات ، فتحنا الصفحة الأولية بطبقتين من مجموعات الإطارات ، و 4 إطارات إجمالية ، وقمنا بالنقر فوق ارتباط في إطار واحد للتنقل في إطار مختلف في نفس الصفحة. لإعطاء أسماء لذلك ، كانت مجموعة إطارات المستوى الثاني المعروضة لدينا تحتوي على إطارات "top.htm" و "menu.htm" و "start، htm". لقد نقرنا على رابط في إطار "menu.htm" لجعل الإطار يحمل "start.htm" للانتقال إلى "content.htm" ، مع سلوك مشابه ولكنه مختلف قليلاً لكل إعداد متصفح ، كما هو مذكور أعلاه. الآن ، نضغط على رابط داخل إطار "content.htm" للتنقل داخل نفس الإطار ونفس المجال.

في هذه المرحلة ، لن يقوم البرنامج النصي الخاص بـ "content.htm" فقط بـ "blip" ... سيبقى أيضًا على قيد الحياة بعد اكتمال GM.xmlHttpRequest - حدث غير متزامن. في هذه المرحلة ، لا يظهر "content.htm" في أي مكان في شاشة المتصفح ، ولكن البرنامج النصي الخاص به سيستمر في العمل.

لذلك يبدو لي أن السبب وراء عدم عمل البرامج النصية لـ GM على الصفحات داخل الإطارات هو أنه يتم تحميل البرنامج النصي عند تفريغ الصفحة بدلاً من تحميل الصفحة. لم يتم تحسين إعداد @ run-at لبدء المستند ووضع البرنامج النصي في حدث DOMContentReady الخاص بـ unsafeWindow.document. (لا يؤدي إعداده على window.document إلى إطلاق الحدث أبدًا.)

-رايان

في Firefox 52.8 / GM 4.1 ، ستظهر مجموعة الإطارات التالية / 3 إطارات إلى الوجود دائمًا. في Firefox 60.0 / GM 4.3 ، لا "تومض" عند تحميل الإطار الأولي.

في الانتقال إلى Firefox 57 ، تغيرت Mozilla _something_. أيًا كان ما تم تغييره (أو تعطله) الطريقة التي يمكن بها تشغيل الإطارات. تم الحديث عن هذا بإيجاز في بعض القضايا الأخرى. ونتيجة لذلك ، لن تعمل البرامج النصية عند تحميل الإطار الأولي (57+).

التبديل النهائي إلى userScript أو contentScript APIs يجب أن يحل كل هذا على أي حال.

لذلك يستمر الناس في القول ، ومع ذلك يستمر Violentmonkey في التنفيذ في إطارات. لا يفصل VM بشكل صحيح نصوص المستخدمين عن محتوى صفحة الويب (يقوم CSPs بحظر نصوص المستخدمين ، ويمكن لصفحات الويب إعادة كتابة كائنات عالمية وما إلى ذلك) ، أو كنت قد قمت برمي Greasemonkey منذ فترة طويلة. ربما تكون هذه مشكلات ذات صلة ، لكني أستخدم محركات usercript لذلك لا يتعين علي استكشاف كروم Firefox بعمق كافٍ لمعرفة ذلك بنفسي.

حسنًا ، هذه مشكلة صعبة ، فبعض البرامج النصية الخاصة بي لم تعد تعمل لأنها لا تستطيع العمل مع إطارات iframe. لذلك يبدو أنه ليس من الممكن حقًا إصلاحه ، وعلينا أن نتحرك لموزيلا لتنفيذ بعض واجهة برمجة التطبيقات؟ ألا يوجد شيء يمكننا القيام به بأنفسنا ، مثل الحل البديل؟ أحتاج فقط إلى القيام ببعض الأشياء على صفحة في iframe ، وغالبًا حتى من نفس المجال.

الحل البديل الخاص بي في الوقت الحالي هو تشغيل Greasemonkey في الإطارات العلوية و Violentmonkey في الإطارات الفرعية. لا يمكنني استخدام Tampermonkey لأنه يحتوي على ترخيص محلي الصنع غامض ، ولكن إذا لم تكن هذه مشكلة بالنسبة لك ، فقد تعمل أو لا تعمل بشكل أفضل.

ضع في اعتبارك أن VM يسقط النص في سياق الصفحة الخاص. إنه مثل نظام GM's غير الآمن بدون المكافئ الآمن. واحدة من أكثر الأوقات التي لا تنسى هي تصحيح أخطاء نص برمجي حيث حدد محتوى الصفحة طريقة "toJSON ()" على Array.prototype ، مما تسبب في قيام JSON.stringify () ببصق JSON غير صالح داخل البرنامج النصي الخاص بي. دفاعًا عن الفخ وإصلاح هذه الأشياء كما وجدتها.

مصدر قلق كبير آخر لـ VM هو أنه يحترم سياسة أمان محتوى صفحة المحتوى ، لذا فإن أي توجيه يحد من مصادر البرامج النصية سيؤدي إلى عدم تنفيذ البرنامج النصي VM أبدًا. يمكنك رؤية هذا في وحدة تحكم المتصفح (ولكن ليس وحدة تحكم الويب). لهذا السبب لا يمكنني تشغيل VM بالكامل والتخلص من GM. لم أجد بعد طفلاً مع مجموعة CSP ، لكن عندما أفعل ذلك ، سيكون غير قابل للاستخدام تمامًا.

RyanHanekamp شكرا

هل يحتوي Violent أيضًا على شيء مثل GM_getValue المتزامن؟ هذه مشكلة إشكالية أخرى تكسر الكثير من البرامج النصية في Greasemonkey الجديد. ما زلت أثق في Greasemonkey أكثر من غيرها ، لأسباب مختلفة ، لذلك لن أتركه.

بالنسبة إلى إطارات iframe ، كنت أحاول استبدالها بعلامات الكائنات ، والتي يمكن على ما يبدو الوصول إليها مباشرةً باستخدام Javascript ، مثل:

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') ) الكائن.

لست خبيرًا في الأجهزة الافتراضية ، لكنني أعتقد أنها تطبق على الأقل معظم GM_ * API الأصلي. أعتقد أنه من الأفضل تكييف البرامج النصية الخاصة بك مع غير متزامن بدلاً من التراجع إلى نظام أساسي متزامن على المدى الطويل ، على الرغم من ذلك. حسب فهمي ، قام Greasemonkey بهذا لتعزيز الأداء ضمن إطار عمل Quantum الجديد ، والذي لا يسمح بإجراء مكالمات متزامنة بين البرامج النصية في الخلفية والمحتوى.

بالنسبة إلى حل الكائن ، فلن يحل مشكلتي بالذات ، لكنني سعيد لأن الآخرين قد وجدوه مفيدًا. بصرف النظر عن تنظيم CSS / properties / إلخ ، وجعلها تعمل مع الإطارات وكذلك إطارات iframe ، يجب أن أقوم بتصفية الكائنات في عملية الالتقاط باعتبارها غير آمنة. هناك طرق للتغلب على كل هذه المشاكل ، ولكن VM كان أسهل مؤقتًا حتى تقوم جنرال موتورز أخيرًا بعمل ما تقوله على القصدير.

أيضًا ، إذا كان لديك إطار أصل / إطار iframe ، فيمكنك الوصول إلى محتوى هؤلاء مباشرةً أيضًا. الجزء الأصعب هو الأصل المتقاطع ، ولهذا السبب أحتاج إلى نصوص مستخدم داخل الإطار. يقوم بإعداد قناة window.postMessage () للتحدث مرة أخرى إلى النافذة الأصلية.

RyanHanekamp من الجيد معرفة أن القرد العنيف لا يزال يمتلك GM_ * القديم والبسيط. أتمنى حقًا أن يكون Greasemonkey قد احتفظ بـ GM_getValue القديم والمتزامن للتوافق مع الإصدارات السابقة ، بالإضافة إلى الإصدار الجديد. قد أحاول تنفيذ الوظيفة الجديدة غير المتزامنة في برنامج نصي جديد ، لكنني لست مبرمجًا ولست متأكدًا مما إذا كان بإمكاني أن أجعلها تعمل. وأنا بالتأكيد غير قادر على إعادة تشكيل استخدام GM_getValue القديم في نص قديم مكون من 2000 سطر وجدته على الإنترنت ... الكثير من البرامج النصية معطلة الآن.

أنا أفهم لماذا كان Violent الخيار الأفضل لك. دعونا نأمل أن يكتشف أنتوني أو سكديرب أو أي شخص آخر كيفية تنفيذ ذلك في النهاية. أتمنى حقًا أن أتمكن من المساهمة ، لكنني شخص عادي تمامًا.

أوه ، يمكنك الوصول مباشرة إلى محتوى iframe من نفس الأصل (بدون postMessage وما إلى ذلك)؟ أتذكر قضاء الكثير من الوقت في محاولة إيجاد طريقة ، لكن لا يبدو ذلك ممكنًا. لهذا السبب قمت بالتبديل إلى postMessage أيضًا.

الإطارات و iframes لها خاصية contentWindow مكافئة لخاصية النافذة. كلاهما له خاصية وثيقة للوصول إلى DOM.

يتمثل أصعب جزء في العمل باستخدام إطارات iframe (على نفس الأصل) في اكتشاف وقت تحميل محتواها ، لأنه لا يمكنك القيام بالقرفصاء حتى يحدث ذلك. onload لا يعمل كيف يبدو. يوفر Firefox حدث DOMFrameContentLoaded يتم تنشيطه لكل إطار تم تحميله ، بما في ذلك إطارات grandchild / great-grandchild وما إلى ذلك ، والتي يمكنك مطابقتها مع عنصر frame / iframe الأصلي مع خاصية event.target. إذا كنت تتحكم في محتوى الإطار / iframe ، فيمكنك أيضًا جعله يتحدث إلى الوالد إما باستخدام postMessage أو استدعاء طريقة عامة على الكائن window.parent.

بالحديث عن ... هذا حل بديل محتمل لهذه المشكلة. إذا كانت هناك طريقة أو يمكن أن تكون طريقة لتشفير برنامج نصي لـ GM لإدخال نص مستخدم يدويًا في مرجع نافذة عبر المجال ، فسيستغرق الأمر الكثير من الترميز لمنشئ نصوص المستخدم ، ولكن يمكنه إنجاز المهمة. سيستمع النمط إلى DOMFrameContentLoaded ، تحقق مما إذا كان event.target من الجيل الأول ، ثم قم بحقن النص يدويًا إذا كان الأمر كذلك. (بافتراض أن النص البرمجي لإطار الجيل الأول يمكنه الاستماع إلى DOMContentLoaded لإطارات الجيل الثاني ، وبالتالي الحصول على سلسلة كاملة.) لن تكون هناك طريقة للحصول على سلوك @ run-at dom-start ، وقد تكون هناك أيضًا مشكلات في التوقيت ، ولكن ربما يمكننا حل هذه المشكلة في معظم حالات الاستخدام.

لقد تخليت شخصيًا عن حل هذه المشكلة على الإطلاق ، وانتقلت بدلاً من ذلك إلى ترميز الامتداد مباشرةً. الذي يعمل بشكل جيد في جميع الإطارات!

يبدو أن الاختلاف بين Greasemonkey و Violentmonkey في هذه النقطة هو أنه يتم تشغيل Violentmonkey من البرامج النصية للمحتوى مع ضبط all_frames على صحيح ، بينما لا يحتوي Greasemonkey على نصوص محتوى وقت التثبيت ويعتمد كليًا على القدرة المشكوك فيها للنص في الخلفية على الشم عند تم التنقل في إطار علامة التبويب. (وفشل Violentmonkey في صفحات CSP لأنه يقوم مؤقتًا بحقن علامة SCRIPT بدلاً من استخدام علامات التبويب الأكثر أمانًا.

ضع نصًا نصيًا ثابتًا للمحتوى مع all_frames ، run_at start ، يطابق كل شيء لإخطار عملية الخلفية لبدء / document.DOMContentLoaded / document.Idle لتشغيل نصوص المستخدمين لكل run_at ، وأنت على ما يرام. كمية عمل غير تافهة ولكن يمكن التحكم فيها لإزالة هذه المشكلة. كنت سأصلحها بنفسي ، لكن ليس لدي أي اهتمام بالتثاقل من خلال تبعيات المطورين الخاصة بك ويمكن فقط إنتاج كود الإخراج.

تضمين التغريدة

وبدلاً من ذلك انتقلت إلى ترميز الامتداد مباشرة. الذي يعمل بشكل جيد في جميع الإطارات!

هل أنت على استعداد لمشاركة كود الامتداد الخاص بك؟

التمديد الخاص بي ليس غرضًا عامًا. النقطة المهمة هي أنه باستخدام نص ثابت للمحتوى في البيان مع all_urls ، ستعمل all_frames على تشغيل البرنامج النصي كلما تم تحميل أي إطار أو التنقل فيه ، ويمكنه أيضًا تقييم / رمز مُنشئ الوظيفة بشكل جيد بغض النظر عن سياسة أمان المحتوى الخاصة بالصفحة.

لم أختبر الإطارات / النوافذ التي تم إنشاؤها برمجيًا ، لكنني أتخيل أنها ستعمل عند الإنشاء الأولي بغض النظر عن إعداد run_at ، لأن مثل هذه الإطارات يتم إنشاؤها في البداية فارغة ثم يتم ملؤها - ربما يرى المحرك الإنشاء الأولي فقط. لم أختبر أيضًا البيانات: عناوين url ، والتي قد تتطلب مطابقة صريحة - لست متأكدًا مما إذا كانت all_urls تغطيها أم لا فقط http / https.

قد لا يكون من الضروري أيضًا أن يكون مرجع content_script ثابتًا ، ولكن يبدو غير مؤكد من الوثائق إذا تم تحميل البرامج النصية للمحتوى التي يتم استدعاؤها ديناميكيًا تلقائيًا عند التنقل في الصفحة. انطباعي هو أنه يتم حقنها فقط في علامات التبويب / الإطارات المطابقة حاليًا لكل نمط المطابقة المقدم ، ولا يؤدي التنقل إلى إعادة الحقن. لكني لا أرى أي جانب سلبي لاستخدام نص محتوى ثابت لهذا الغرض.

من الواضح أن Greasemonkey لا يمكنه تضمين نصوص المستخدمين كمصادر ثابتة في البيان ، ولا يبدو أن البرامج النصية للمحتوى تتمتع بوصول مباشر إلى علامات التبويب. ولكن ما يمكن أن يفعله البرنامج النصي للمحتوى الثابت هو إرسال رسالة إلى عملية الخلفية لإعلامه بأنه تم التنقل في frameId وإلى أي عنوان URL. سيكون هذا أكثر موثوقية من الطريقة التي أدرك بها المحاولات المذكورة في هذا الموضوع لربط الحدث الصحيح في webRequest أو webNavigation. تصبح الإشارة من content_script الثابت الحدث الذي نبحث عنه لتشغيل محمل / حاقن مستخدم Greasemonkey.

من المحتمل أن يكون هناك تأخير لنصوص المستخدمين التي يجب أن تقوم بتشغيل_at document_start بدقة. استدعاء البرنامج النصي في الخلفية غير متزامن ، وسيكون المستند قد تقدم بحلول الوقت الذي يتم فيه استدعاء المستخدم. من المحتمل جدًا أن هذا هو سبب استخدام Violentmonkey لعلامة نصية مؤقتة بدلاً من علامات التبويب. قد أجد مجبرًا على التغلب على عدم اليقين في حالة المستند لأن يكون run_at document_start مزعجًا ، ولكنه أفضل من البرنامج النصي الذي لا يعمل على الإطلاق.

Greasemonkey ... CAN [استخدام برنامج نصي للمحتوى الثابت] لإرسال رسالة لعملية الخلفية لإعلامها بأن معرف frameId قد تم التنقل فيه ، وإلى أي عنوان URL ...

هذا ما اعتدنا فعله للكشف عن تنقلات .user.js . يبدو أنه حل واضح وجيد: اكتشف المحتوى عن طريق تشغيل سيناريو المحتوى!

ولكن اتضح أن النصوص البرمجية لمحتوى الامتداد يمكن كسرها بواسطة CSP (# 2631 و http://bugzil.la/1267027 و http://bugzil.la/1411641).

يمكنني تنفيذ المكون الإضافي الخاص بي ، بما في ذلك مُنشئ Function () من داخل content_script مباشرةً ، على Firefox 60.0.1 و 52.8.1ESR مع مجموعة CSP التالية:

بيانات frame-src :؛ كائن- src "لا شيء" ؛ script-src 'none' ؛ بيانات style-src "غير آمنة-مضمنة" :؛ connect-src "لا شيء" ؛ media-src "لا شيء" ؛

تم إغلاق 2631 ، على ما يبدو لأن Firefox أصلح الخلل الأساسي الخاص به. يشير bugzilla الأول إلى حقن علامات البرنامج النصي (طريقة Violentmonkey) ، وليس إلى content_script نفسه. والثاني يشير إلى سمة وضع الحماية لـ CSP ، وليس مفاجئًا لأنه يجبر المجال على عدم إكمال تطابق المجال بنجاح حتى مع نفسه. كندة مثل NaN! == NaN.

عندما تم تقديم هذا لأول مرة منذ عدة أشهر ، فعلنا الأشياء بشكل مختلف. نستخدم اليوم webNavigation.onCommitted لاكتشاف التنقل ، وفي الاختبار الذي أقوم بتشغيله الآن ، لسبب ما لا أرى أنه يتم تشغيله في إطار (ni)).

مرحبا ، هل تم حل هذا الآن؟

لم أتمكن من الحصول على برنامج نصي قمت بإنشائه لتشغيل Tampermonkey على iframe باستخدام Greasemonkey.

لم يتغير رمز التنفيذ من جانبنا. لذلك ، ما لم يغير Mozilla شيئًا ما من نهايته ، فلا يزال هذا معطلاً. لكن # 2663 يجب أن يحلها.

قد يكون من الجدير بالذكر أن Violentmonkey و Tampermonkey يعملان بشكل جيد داخل الإطارات المضمنة.

Tampermonkey لديه مشاكل مع iframes في Chrome ، على الأقل بالنسبة لي.

قد يكون من الجدير بالذكر أن Violentmonkey و Tampermonkey يعملان بشكل جيد داخل الإطارات المضمنة.

Tampermonkey لديه مشاكل مع iframes في Chrome ، على الأقل بالنسبة لي.

لكنها تعمل بالنسبة لي في Firefox Violentmonkey. لذا أتساءل كيف يمكن أن يعمل هناك؟

لقد لاحظت للتو أن البرنامج النصي الذي يستخدم المزامنة القديمة GM_GetValue لا يزال يعمل بشكل جيد في Violentmonkey أيضًا. كيف يعقل ذلك؟ اعتقدت أن Firefox قد أجبر GM.GetValue غير المتزامن؟ أنا في حيرة من أمري الآن: ربما كان على Violentmonkey التضحية بشيء آخر من أجل الاستمرار في دعم المزامنة والأشياء الأخرى؟

@ Cerberus-tm يعني التغيير في Firefox أنه لا يمكن طلب البيانات إلا من تخزين الامتدادات أو سياق الخلفية بشكل غير متزامن (يتم إرسال نصوص المستخدمين أنفسهم إلى البرنامج النصي للمحتوى بشكل غير متزامن). ومع ذلك ، يمكن توفير البيانات لنصوص المستخدمين بشكل متزامن ، إذا تم جلب كل نص برمجي لمحتوى GM4 مسبقًا وتخزينه مؤقتًا في البرنامج النصي للمحتوى ، فإن البيانات المخزنة لكل نص مستخدم يتم تحميله في تلك الصفحة.

تسمح ذاكرة التخزين المؤقت هذه لنص المحتوى بالاستجابة بشكل متزامن لطلبات المستخدمين للحصول على البيانات. يواجه تنفيذ ذاكرة التخزين المؤقت مشكلات تتعلق بالحفاظ على التناسق عبر البرامج النصية للمحتوى المختلفة ، ولكن هذا قابل للحل من خلال جعل نصوص المحتوى تستمع إلى جميع التغييرات التي تطرأ على مساحة تخزين الامتدادات الخاصة بـ GM4. بالإضافة إلى ذلك ، إذا كان نص المستخدم يخزن كمية كبيرة من البيانات ، فإن تخزينه مؤقتًا في كل نص برمجي للمحتوى حيث يتم تشغيل سكريبت المستخدم يؤدي أيضًا إلى زيادة الذاكرة المطلوبة لكل نص برمجي للمحتوى بشكل كبير.

اختار كل من TM و VM القيام بشيء مشابه لما ورد أعلاه من أجل عدم كسر التوافق مع واجهات برمجة تطبيقات Greasemonkey الأصلية عندما تم تنفيذ مديري نصوص المستخدمين هؤلاء على Chrome ، والذي لديه نفس القيود المذكورة. اتصال غير متزامن مع تخزين الامتداد ، وما إلى ذلك. نظرًا لأنهم يقومون بذلك بالفعل لـ Chrome ، فلا يوجد سبب لتغييرهم عند تطبيق Firefox.

لذلك ، فرض اقتطاع FF57 على WebExtensions إعادة كتابة GM ، لكنه لم يفرض اعتماد واجهات برمجة التطبيقات غير المتزامنة لـ GM.getValue ، GM.setValue ، إلخ. واجهات برمجة التطبيقات غير المتزامنة أسهل في التنفيذ من المتزامنة ، لكنها لم تجعلها مطلوبة.

أنا شخصياً أشعر أن الاختيار والخيارات الأخرى لكسر التوافق كانت / غير موفقة. يؤدي عدم التوافق مع البرامج النصية التي تعمل بشكل جيد في GM3 و / أو التوافق مع TM إلى اختيار العديد من الأشخاص عدم استخدام GM4. تجربتي هي أن أكثر من 30 من نصوص المستخدمين التي أستخدمها ، وكلها تعمل بشكل جيد في GM3 ، لا تعمل مع GM4 (أو على الأقل لم تعمل قبل إعادة كتابتها لتكون متوافقة مع GM4). لا يزال هناك 28 نصًا مستخدمًا أستخدمه يوميًا والتي تعمل بشكل جيد ضمن GM3 والتي لا تعمل مع GM4.

لقد قمت بنشر حل بديل لهذه المشكلة على Stack Overflow كإجابة على كيفية تطبيق Greasemonkey / ‌Tampermonkey / ‌userscript على iframe . في الأساس ، أنا في انتظار تحميل الإطار ثم أعمل على المصفوفة window.frames . أستخدم علامة مخصصة في جسم كل إطار للإشارة إلى أنني رأيت الإطار بالفعل.

ربما يمكن لتطبيق Greasemonkey تنفيذ حل بطريقة مماثلة؟

سيكون الأمر رائعًا إذا كان لدينا أيضًا GM.waitFor(css_selector, action_function) مثل waitForKeyElements () ، لكن هذا جانب.