Greasemonkey: WebExt: دعم جميع واجهات برمجة تطبيقات GM

قد يكون bug1323433 و bug1332273 موضع اهتمام هنا.

شكرًا على المؤشرات ، أوافق على أن كلاهما مفيد للغاية.

أوه ، ربما يكون من الممكن تمرير قدر من الرسائل المتزامنة!

https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/runtime/onMessage#Sending_a_synchronous_response

إختبر هذا. هل هذا يجعل من الممكن استخدام تنفيذ متزامن بسيط (مدعوم بواسطة واجهات برمجة التطبيقات في الخلفية فقط) لتلك الطرق المذكورة أعلاه؟

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

Afaik هي واجهة برمجة التطبيقات المتزامنة الوحيدة المتاحة هي XHRs المتزامنة والتي يمكن بعد ذلك اعتراضها باستخدام webrequest أو شيء من هذا القبيل.

لا تعمل مزامنة XHR بشكل صحيح في البرنامج النصي للمحتوى: https://bugzilla.mozilla.org/show_bug.cgi؟id=1360968 ، لذلك ليس لدينا حاليًا أي قناة مزامنة من المحتوى> الخلفية.

يبدو أن GM_setValue و GM_getValue قد تم تصميمهما كعملية مزامنة وفي متصفح واحد procecss يعملان بشكل جيد عندما نعمل في علامات تبويب متعددة ، ولكن في e10s لا (https://github.com/greasemonkey / greasemonkey / قضايا / 2427). باستخدام واجهة برمجة تطبيقات extenstion القديمة ، يمكن إصلاحه بسهولة ، ولكن لا يمكن إصلاحه في WebExt. بدون رسالة المزامنة (حتى بالنسبة للبيانات الصغيرة ، فقط تصدر قيمة قصيرة فقط) لا يمكننا مزامنة القيمة بشكل صحيح عند ظهور المزيد من علامات التبويب. في مرحلة ما سيكون هذا دائمًا حالة سباق.

بغض النظر عن كيفية حل المشكلات المذكورة أعلاه في إصدار WebExt ، يجب أن نحصل على طريقة تعيين / الحصول جديدة مصممة بطريقة غير متزامنة ، لذلك من المهم أن نكتب البرنامج النصي بطريقة غير متزامنة. يجب أن تحتوي الوثائق على بعض المعلومات حول عدم وجود سلوك GM_setValue و GM_getValue عند العمل في علامات تبويب متعددة.

imo ، نادرًا ما تستخدم حالات استخدام GM_setValue / GM_getValue في علامات تبويب متعددة ويجب اتباع الترتيب. نتيجة لذلك ، يجب أن يكون حلاً مقبولاً تخزين نسخة (ذاكرة تخزين مؤقت) من _GM_values_ في النص البرمجي للمحتوى ، والقراءة دائمًا من ذاكرة التخزين المؤقت ، وإعادة الكتابة غير المتزامنة ، وتحديث ذاكرة التخزين المؤقت بالأحداث التي يتم تشغيلها بواسطة البرنامج النصي في الخلفية.

راجع للشغل ، إذا كان الأمر كذلك ، فإن إضافة واجهة برمجة تطبيقات تعادل GM_addValueChangeListener رائعة إن أمكن. (وأنا لا أحب الاسم addValueChangeListener شيء آخر ربما يكون أفضل

في بلدي فرع ديف هناك دعم ل:

• GM.getResourceURL
• GM.deleteValue ، GM.getValue ، GM.listValues ، GM.setValue

أخطط لعدم إضافة :

• GM_log
• GM_addStyle

ما زلنا بحاجة إلى :

• GM_xmlhttpRequest

أخطط لتأجيل (أو ربما أسقط):

• GM_registerMenuCommand (لطالما كانت هذه تكلفة دعم ضخمة)
• GM_getResourceText

مما يعني أن التقدم هنا قريب جدًا في الواقع.

ردود فعل جيدة في أعلاه الالتزام ، لا تنسى.

لقد قمت فقط بتجربة الوظيفة الإضافية الجديدة. يبدو أن طلب xhr عبر المجال قد تم تمكينه بالفعل بدون ميزات GM_xhr. هل هذا بالفعل سلوك؟

ما عليك سوى تجربة أحد برامج المستخدمين التي لا تمنح أيًا من الرموز التالية:

fetch(prompt()).then(resp => resp.text()).then(text => alert(text)).catch(error => alert(error));

لاف ، أكد. نقوم حاليًا بتنفيذ البرامج النصية للمستخدم على أنها "نصوص برمجية للمحتوى" - للامتداد ، مع جميع أذونات الامتداد.

لقد بحثت في هذا قليلاً ولكن حتى الآن لا أعرف كيفية تنفيذ رمز غير مميز ("نطاق الويب" - ماذا نسمي هذا الآن لأن نطاق "المحتوى" غامض ؟!). إن أقرب شيء يمكنني العثور عليه هو كل شيء عن إنشاء علامات البرنامج النصي ، والتي يمكن / سيتم حظرها بواسطة CSP للصفحة ، وهو ما لا أريده بالتأكيد.

الطريقة الوحيدة حاليًا لتعديل CSP هي اعتراض وتعديل الرؤوس لكل طلب مستند. هناك مشكلات مفتوحة لإعفاء إضافات الويب من CSPs للمحتوى ولكن لا يبدو أن هناك نشاطًا كبيرًا على هؤلاء.

بالإضافة إلى حقن <script> tags window.eval يجب أيضًا تشغيلها في نطاق الصفحة ، على ما أعتقد.

المصطلحات الرسمية هي "نطاق البرنامج النصي للمحتوى" مقابل "نطاق الصفحة".

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

لقد قدمت أيضًا خطأً لمكافئات Sandbox في إضافات الويب ، لكنها ليست ذات أولوية عالية أيضًا.

يعد كل من البرنامج النصي والتقييمات الخاصة بـ AIUI عرضة للانسداد بواسطة CSP. لكنني أكدت أن EVAL قطرات الامتيازات.

https://bugzilla.mozilla.org/show_bug.cgi؟id=1391669

يجب أن يكون لدينا <all_urls> إذا كنا سنقوم بتشغيل برنامج نصي للمحتوى في أي صفحة. إذا طلبنا ذلك ، فسيحصل نص المحتوى الخاص بنا على ذلك ، وبالتالي يمكن لـ XHR الوصول إلى أي مكان.

على الأقل في Firefox ( https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Content_scripts#Using_eval () _in_content_scripts) يمكننا النزول إلى نطاق الصفحة ، ولكن بعد ذلك نحن حقًا نطاق الصفحة ونحن لا يمكن تعريض واجهات برمجة التطبيقات (API) للنص البرمجي بأمان دون تعريضه لأي شيء / كل شيء يتم تشغيله في الصفحة (AFAIK) ، وهو الأمر الأسوأ.

هل يمكن الكتابة فوق الجلب و xhr في نص المحتوى؟
ربما توفر إحضارًا معدلًا يقوم بفحص CORS الخاص به.

• GM.xmlhttpRequest() في 60a50d05b1e565571d8a3e638b0683a1a9c2beaa
• سيتم تغطية GM.getResourceText() في # 2548
• تم تخطي GM.registerMenuCommand() عمدًا.
• كل نص برمجي يرث أحضار عبر الأصل (حسب التعليق أعلاه) هو # 2549

@ the8472 شاهد تنفيذي لـ withUnsafeWindow() في https://github.com/greasemonkey/greasemonkey/issues/2232#issuecomment -326841025

إنها تحاكي سلوك الوظيفة with (object) ... القديمة ، لكنها أكثر أمانًا قليلاً. (بحاجة إلى متصفحات حديثة.)

كتب arantius في 25 يوليو :

أخطط لعدم إضافة :

GM_log
GM_addStyle

تم الإشارة إلى هذه في إنشاء هذه البطاقة (بواسطة arantius في 3 مارس ) على أنها تافهة (بافتراض تعيين GM_log إلى console.log).

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

في Tampermonkey ، يتمتع GM_addStyle بقدرة خاصة على حقن النمط الذي يمكنه تجاوز قيود CSP (في حالة حظر <style> المضمن). سأكون سعيدًا إذا كان بإمكاننا الحصول على هذه الميزة في Greasemonkey أيضًا.