ম্যানিফেস্ট V3 এ স্থানান্তরিত করার সময় পরিচিত সমস্যা, ম্যানিফেস্ট V3 এ স্থানান্তরিত করার সময় পরিচিত সমস্যাগুলি

এই পৃষ্ঠায় Manifest V3-তে রূপান্তরের সময় সমাধান করা প্ল্যাটফর্মের ঘাটতিগুলো নথিভুক্ত করা হয়েছে এবং মাইগ্রেশন সংক্রান্ত প্রায়শই জিজ্ঞাসিত প্রশ্নগুলোর উত্তর দেওয়া হয়েছে।

প্ল্যাটফর্মের ফাঁকগুলি সমাধান করা হয়েছে

সাধারণ মাইগ্রেশন প্রতিবন্ধকতাগুলো মোকাবেলা করার জন্য নিম্নলিখিত সক্ষমতাগুলো যোগ করা হয়েছে:

  1. chrome.fileBrowserHandler (Chrome 120)-এর প্রতিস্থাপন হিসেবে ChromeOS-এ ফাইল হ্যান্ডলিং-এর জন্য সমর্থন ।
  2. ইউজার স্ক্রিপ্ট সাপোর্ট: নতুন userScripts API (Chrome 120) ব্যবহার করে যেকোনো কোড দিয়ে কন্টেন্ট স্ক্রিপ্ট রেজিস্টার করার সুবিধা।
  3. পাঁচ মিনিটের বেশি সময় ধরে চলা নির্দিষ্ট কিছু অপারেশনের জন্য অতিরিক্ত শক্তিশালী সার্ভিস ওয়ার্কার কিপঅ্যালাইভ প্রয়োজন ।
    • Chrome 116-এ permissions.request() , desktopCapture.chooseDesktopMedia() , identity.launchWebAuthFlow() এবং management.uninstall() যোগ করা হয়েছে।
    • ক্রোম ১১৮-এ chrome.debugger যোগ করা হয়েছে।
  4. ডিক্লারেটিভ নেট রিকোয়েস্ট (DNR)-এর জন্য স্ট্যাটিক এবং এনাবলড রুলসেটের সংখ্যা বাড়ানো হয়েছে । এনাবলড স্ট্যাটিক রুলসেটের সংখ্যা ১০ থেকে বাড়িয়ে ৫০ করা হয়েছে এবং মোট স্ট্যাটিক রুলসেটের সংখ্যা ৫০ থেকে বাড়িয়ে ১০০ করা হয়েছে (ক্রোম ১২০)।
  5. অফস্ক্রিন ডকুমেন্ট ব্যবহারের আরও কারণ সমর্থন করার জন্য অফস্ক্রিন ডকুমেন্ট কার্যকারিতা প্রসারিত করা হয়েছে। ক্রোম ১১৬-এ GEOLOCATION যোগ করা হয়েছে।
  6. chrome.tabCapture API-এর জন্য সমর্থনের উন্নতি (ক্রোম ১১৬):
    • সার্ভিস ওয়ার্কার থেকে getMediaStreamId() কল করার সুবিধা।
    • অফস্ক্রিন ডকুমেন্টে থাকা স্ট্রিম আইডি থেকে MediaStream প্রাপ্তির সুবিধা।
  7. সক্রিয় WebSocket সংযোগ থাকা অবস্থায় সার্ভিস ওয়ার্কারের জীবনকাল বাড়ানো (ক্রোম ১১৬)।

ম্যানিফেস্ট V3 প্রায়শই জিজ্ঞাসিত প্রশ্নাবলী

প্রশ্ন: আমরা কি স্থায়ী পরিষেবা কর্মীদের সমর্থন করার পরিকল্পনা করছি?
ব্যাকগ্রাউন্ড স্ক্রিপ্ট থেকে সার্ভিস ওয়ার্কারে স্থানান্তরের অন্যতম প্রধান কারণ হলো আরও বেশি মেমরি-সাশ্রয়ী ইভেন্ট-ড্রাইভেন প্রোগ্রামিং মডেল, যা সার্ভিস ওয়ার্কারের ক্ষণস্থায়ী প্রকৃতির কারণে সম্ভব হয়। ফলস্বরূপ , আমরা স্থায়ী সার্ভিস ওয়ার্কার সমর্থন করার পরিকল্পনা করছি না। তবে, এক্সটেনশন ডেভেলপারদের নির্দিষ্ট চাহিদা মেটাতে আমরা সার্ভিস ওয়ার্কারের অনেক উন্নতি সাধন করে চলেছি। বিশেষ করে:

  • সমস্ত এক্সটেনশন ইভেন্ট এবং এপিআই কল সার্ভিস ওয়ার্কারের জীবনকাল বাড়িয়ে দেবে।
  • নেটিভ মেসেজিং-এর মতো নির্বাচিত কিছু ব্যবহারের ক্ষেত্রে এক্সটেনশন সার্ভিস ওয়ার্কারগুলো ৫ মিনিটের বেশি সময় ধরে সক্রিয় থাকবে।

সার্ভিস ওয়ার্কারগুলিতে DOM অ্যাক্সেস করার কোনো উপায় আছে কি?
এ: আমরা ওয়েব প্ল্যাটফর্মের গৃহীত পদ্ধতি অনুসরণ করি, যেখানে ওয়েব ওয়ার্কারদের (যার মধ্যে সার্ভিস ওয়ার্কারও অন্তর্ভুক্ত) মধ্যে DOM অ্যাক্সেস অন্তর্ভুক্ত করা হয় না। সার্ভিস ওয়ার্কারদের থেকে ব্যাকগ্রাউন্ডে DOM অ্যাক্সেসের প্রয়োজন হয় এমন ব্যবহারের ক্ষেত্রগুলোকে সমর্থন করার জন্য, আমরা স্বল্পস্থায়ী অফস্ক্রিন ডকুমেন্টগুলিতে ব্যাকগ্রাউন্ডের কাজ অর্পণ করার সুযোগ চালু করেছি, যা সম্পূর্ণ DOM অ্যাক্সেস প্রদান করে।

ম্যানিফেস্ট ভি৩-তে রিমোট কোড সমর্থন করার কোনো উপায় থাকবে কি?
ক্রোম এক্সটেনশনগুলোকে আরও সুরক্ষিত করার জন্য, আমরা ক্রোম এক্সটেনশনগুলোতে যথেচ্ছভাবে রিমোটলি হোস্ট করা কোড এক্সিকিউট করা নিষিদ্ধ রাখব। তবে , এর মানে এই নয় যে আমরা সব ধরনের ডাইনামিক কোড এক্সিকিউশন নিষিদ্ধ করছি। আমরা এখনও ক্রোম এক্সটেনশনগুলোতে ডাইনামিকভাবে কোড এক্সিকিউট করার বিভিন্ন বিকল্প সমর্থন করি:

আমার Manifest V2 এক্সটেনশনটি webRequestBlocking-এর উপর নির্ভরশীল, যা Manifest V3-তে সমর্থিত নয়। আমি কীভাবে Manifest V3-তে একই কার্যকারিতা প্রদান করা চালিয়ে যেতে পারি?
আমরা আত্মবিশ্বাসী যে নতুন declarativeNetRequest এপিআই (declarativeNetRequest API) ব্যবহার করে বেশিরভাগ রিকোয়েস্ট ব্লকিং সমস্যার সমাধান করা সম্ভব। এর বাড়তি সুবিধা হলো, এটি ইন্টারপ্রসেস কমিউনিকেশনের পারফরম্যান্স ওভারহেড, প্রতিটি রিকোয়েস্টে কোড এক্সিকিউট করা, অথবা রিকোয়েস্টের সময় একটি সক্রিয় এক্সটেনশন প্রসেসের প্রয়োজনীয়তা এড়িয়ে চলে। তবে , জটিল এন্টারপ্রাইজ (বা শিক্ষা) ব্যবহারের ক্ষেত্রে ডাইনামিক রিকোয়েস্ট ব্লকিং এখনও সমর্থিত।

আমরা কি কিছু বাদ দিয়েছি? অনুগ্রহ করে আমাদের জানান ।