Greasemonkey: لا تنتقل إلى البرنامج النصي ، عند ظهور مربع حوار التثبيت

تم إنشاؤها على ٢٦ يناير ٢٠١٨  ·  20تعليقات  ·  مصدر: greasemonkey/greasemonkey

إذا كنت أتذكر بشكل صحيح ، حتى 3.x تصرفت بهذه الطريقة. يجب أن يظل بإمكاننا ، باستخدام واجهات برمجة تطبيقات WebExt:

  1. إذا تم الكشف عن التنقل إلى أي .user.js ، فقم بإلغاء التنقل.
  2. أعد بدء تنزيل عنوان URL هذا في الخلفية.
  3. إذا نتج عن هذا التنزيل MIME غير مطابق ، فأعد تشغيل التنقل - تمت تصفيته حتى لا نقوم بإجهاضه.
  4. خلاف ذلك ، انبثاق حوار التثبيت وتابع جميع التنزيلات.

التعليق الأكثر فائدة

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

ولكن حتى لو كنت استثناءً ومعظم الناس لا ينظرون إلى الكود أو يفهمونه ، أعتقد أن هناك تأثيرًا وقائيًا لكتاب السيناريو لمعرفة أن المصدر يظهر عند التثبيت.

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

ال 20 كومينتر

أعتقد حقًا أنه يجب إعادة التفكير في هذا. يتصرف كل من VM و TM بشكل مخالف لهذا. عند الانتقال إلى برنامج نصي ، يتم تقديمك بصفحة تتضمن محتوى / مصدر البرنامج النصي وزر التثبيت. أثناء "إعادة توجيهك" تقنيًا ، لا تزال ، في الأساس ، "تتنقل" إلى البرنامج النصي للمستخدم. ربما يجب طرح ذلك في القائمة البريدية -users و -dev والاطلاع على آراء الآخرين؟

أنا أدعم مناقشة المجتمع.

أنا شخصياً أرى أنه لا أحد يراجع المصدر ، لذا من السخف أن نعرضه على جميع المستخدمين ، بما في ذلك الأغلبية التي لا تستطيع حتى فهمها.

و: مراجعة المصدر الرئيسي فقط ، عندما يكون هناك أيضًا @require ، يحقق القليل جدًا.

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

ولكن حتى لو كنت استثناءً ومعظم الناس لا ينظرون إلى الكود أو يفهمونه ، أعتقد أن هناك تأثيرًا وقائيًا لكتاب السيناريو لمعرفة أن المصدر يظهر عند التثبيت.

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

كما ذكرنا ، أنا أقدر أيضًا القدرة على المراجعة. لأقلية من الناس الذين يريدون ذلك. أريد فقط أن يعمل مثل # 2567 حتى تتمكن من مراجعة _جميع _ المصدر. ما عليك سوى النقر فوق "تعديل" بعد التثبيت ، وإظهار جميع المصادر وموارد النص. قم بتمكين أو إلغاء التثبيت حسب اختيارك.

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

لنفترض أن الملف ليس برنامجًا نصيًا فعليًا للمستخدم ولا يحتوي على رمز تعريف صالح. لن يظهر مربع حوار التثبيت أبدًا. مسار العمل الوحيد الذي أراه هو استئناف التنقل. بمجرد استئناف التنقل ، يجب إعادة تنزيل الملف. طلب غير ضروري (# 2830 يعالج هذا من خلال توسيع ما يتم القيام به حاليًا في onHeadersReceived ).

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

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

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

إذا كان بإمكان شخص ما التوصل إلى طريقة نظيفة للقيام بذلك دون الطلبات الإضافية ، فهذا رائع. خلاف ذلك ، لا يمكنني الحصول على ما وراء هذا دون الفوائد _ الفعلية. [1]

[1] لقد ذكرت "القدرة على مراجعة _ جميع_ شفرة المصدر" نظرًا لأن رقم 2567 يمثل فائدة محتملة. لكني لا أوافق. أشعر أن # 2567 يجب أن تكون ميزة _ بغض النظر_ عن ما إذا كان كود المصدر متاحًا عند التثبيت أم لا.


انا لا اعرف. لقد تمكنت من التطرق إلى مواضيع أخرى بعد بعض المناقشة. لكن هذا هو الشيء الذي لا "أراه".

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

لا أعتقد أنه من المنطقي كسر عرض أشياء تسمى *.user.js . هذا هو إزالة وظائف المتصفح.

أرى البرنامج النصي للمستخدم باعتباره امتدادًا أكثر من كونه صفحة ويب. أنت لا تتصفح أبدًا للوصول إلى امتداد أيضًا. تقوم بتنزيله / تثبيته أو لا تفعله.

لا أعتقد أنه من المنطقي كسر عرض أشياء تسمى * .user.js. هذا هو إزالة وظائف المتصفح.

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

أرى البرنامج النصي للمستخدم باعتباره امتدادًا أكثر من كونه صفحة ويب. أنت لا تتصفح أبدًا للوصول إلى امتداد أيضًا. تقوم بتنزيله / تثبيته أو لا تفعله.

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

كما أنها تقوم بأشياء مثلما فعلت الإصدارات السابقة من جنرال موتورز

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

أنت لا تتصفح أبدًا للوصول إلى امتداد أيضًا. تقوم بتنزيله / تثبيته أو لا تفعله.

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

بما في ذلك عدم لمس التنقلات عند التعطيل.

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

أنا أقدر اتخاذ قرارات التصميم التي تقدم أكبر قيمة لمعظم المستخدمين ، لذلك أنا أقدر المدخلات.

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


قبل WebExt ، حصلنا على هذا عن طريق استخدام http-on- modification لتعليق أي طلب يبحث عن البرنامج النصي للمستخدم في أسرع وقت ممكن. سنقوم بتشغيل مربع حوار التثبيت ، ونبدأ عملية RemoteScript لتنزيل جميع الأجزاء ، وكل ذلك في طلبات جديدة. لقد اكتشف هذا الأمر شيئًا غير مستخدم لبرنامج نصي (أي HTML) في عنوان URL يبحث عن البرنامج النصي للمستخدم ، وسوف يلغي الطلب الذي يمتلكه ، و ... شيء ما سيعيد التنقل (أعتقد أنه من خلال استئناف القناة تمامًا ، ولكن لا يمكنني العثور على ذلك).

باستخدام نص برمجي بطيء ، لا يحدث شيء في البداية - بمجرد تحميل الجزء ==UserScript== ، يظهر مربع حوار التثبيت ، ثم يمتلئ شريط التقدم الخاص به بينما يتم تنزيل الباقي - يتطلب باقي البرنامج النصي ، المورد ، ، إلخ.

إنه ينجح في تنزيل البرنامج النصي باتصال واحد فقط بالخادم.


ضمن WebExt ، تختلف جميع واجهات برمجة التطبيقات بالطبع ، ولكن حدث الحظر / التصفية onHeadersReceived موجود بالفعل في HEAD _seems_ ليكون أفضل شيء يمكن استخدامه. لا يزال يتعين علي القيام بالبحث.

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

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

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

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

كان لدي خيار .. فحصه قبل أن أقوم بتثبيت أي شيء ...

2567

ماذا لو كان يبدو كبرنامج نصي للمستخدم ، لكنه ليس كذلك؟ على سبيل المثال ، إذا أخذت مثال التحميل البطيء وأزلت فقط // ==UserScript== الأولي. افتحه في 3.x ، ولن يفتح مربع حوار التثبيت (صحيح) ، ثم تتم كتابة محتوى النص في علامة التبويب / الصفحة. باستخدام WebEx ، إذا قمت بإنشاء اتصال جديد في الخلفية ، فلا أرى كيف يمكنك كتابة المحتويات على الصفحة. بقدر ما أدرك أن الطريقة المباشرة الوحيدة لكتابة بعض المحتوى إلى صفحة في الخلفية هي من خلال مرشح الدفق.

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

ربما أفتقد شيئا ..

افتحه في 3.x ، ولن يفتح مربع حوار التثبيت (صحيح) ، ثم تتم كتابة محتوى النص في علامة التبويب / الصفحة.

إيه ، أود تصحيح هذه النقطة. لم أكن على خطأ ، فقد كان لدي خطأ إملائي في user عندما اختبرت في البداية.

Sxderp اسمحوا لي أن أكرر أنني أقدر بشدة المساهمات التي قدمتها حتى الآن وآمل أن تستمر.

ولكن لمزيد من الوضوح فيما يتعلق بقراري الموضح أعلاه: لقد قمت بتنظيف عملي قيد التقدم ؛ أولاً قمت بنقل بعض الأعمال غير ذات الصلة لفصل الالتزامات . ما تبقى هو إعادة تسمية الملف ثم هذا الالتزام الكبير ، وهو + 425 -491 فقط.

تتضمن فئة Downloader كل المنطق حول (تنزيل وتثبيت) نص برمجي ، بغض النظر عن المصدر. تحتاج فقط إلى إعداد المدخلات - فقط عنوان URL للتثبيت ، ولكن أيضًا مصدر البرنامج النصي الرئيسي وربما تتطلب / محتويات الموارد إذا كانت معروفة بالفعل (لحالة التحرير) ، فهي تقوم بتنزيل أي شيء آخر مفقود (على سبيل المثال ، التحرير في طلب جديد / مورد) ويمرر دائمًا تنسيقًا واحدًا إلى user-script-regstry والذي يستمر في طريقة واحدة فقط. downloader.js بالكامل أقل من 250 سطرًا. ونتيجة لذلك ، تم تمرير عدد أقل من الرسائل بين الخلفية / المحتوى ولا توجد منافذ جديدة.

هناك أوقات يكون من المنطقي فيها تقسيم جزء كبير معقد من التعليمات البرمجية إلى أجزاء أصغر وأبسط. لكن IMO هذا ليس هو. البيانات المتدفقة هي نفسها ، سواء كنا نقوم بتثبيت برنامج نصي "جديد" ، أو تحديث واحد ، أو تعديل واحد في مكانه. تتغير الأشياء البسيطة فقط (هل نعرف بالفعل UUID للنص المثبت بالفعل؟ هل نعرف بالفعل أو نحتاج إلى تنزيل هذا أو ذاك؟).

هل يؤدي هذا أيضًا إلى حل البنية العودية لـ parsedDetails (هناك مشكلة في مكان ما ، ليس لديك وقت للبحث عنها)؟

انا لا اعرف. أنا أشك في ذلك؟

هل يؤدي هذا أيضًا إلى حل البنية العودية للتفاصيل المحلل (هناك مشكلة في مكان ما ، ليس لديك وقت للبحث عنها)؟

تقصد # 2806؟

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات