Chrome के वर्शन 148 से, सभी Chrome एक्सटेंशन एपीआई, मौजूदा chrome नेमस्पेस के अलावा, browser नेमस्पेस के तहत भी उपलब्ध हैं. उदाहरण के लिए, browser.tabs.create({}) और chrome.tabs.create({}) एक ही काम करते हैं.
यह नेमस्पेस, उन सभी जगहों पर उपलब्ध है जहां एक्सटेंशन एपीआई को कॉल किया जा सकता है. इनमें कॉन्टेंट स्क्रिप्ट, सर्विस वर्कर, और ऑफ़स्क्रीन दस्तावेज़ शामिल हैं. यह
के जैसे ही एपीआई ऑब्जेक्ट की ओर इशारा करता है. इसलिए, chrome.chrome.tabs === browser.tabs
`browser` नेमस्पेस,
WebExtensions Community Group (WECG) के काम का नतीजा है. यह W3C कम्यूनिटी ग्रुप है, जिसमें ब्राउज़र वेंडर, शेयर किए गए एक्सटेंशन
स्टैंडर्ड पर मिलकर काम करते हैं. chrome नेमस्पेस बंद नहीं किया जा रहा है. दोनों नेमस्पेस काम करते रहेंगे.
तय करें कि ब्राउज़र नेमस्पेस को अपनाना है या नहीं
अगर webextension-polyfill का इस्तेमाल किया जा रहा है, तो कोई भी बदलाव करने से पहले, पॉलीफ़िल इस्तेमाल करने वाले लोगों के लिए नोट पर जाएं. आपके लिए जवाब अलग है.
अगर नया एक्सटेंशन बनाया जा रहा है, तो
minimum_chrome_version
को "148" पर सेट करें और बिना किसी शर्त के browser का इस्तेमाल करें. आपको इसके बाद पढ़ने की ज़रूरत नहीं है. इस सेक्शन का बाकी हिस्सा, मौजूदा एक्सटेंशन के लिए है, जो यह तय कर रहे हैं कि इसे कैसे अपनाया जाए.
देखें कि आपके उपयोगकर्ता Chrome के किन वर्शन का इस्तेमाल कर रहे हैं
अगर आपके पास कोई मौजूदा एक्सटेंशन है, तो स्विच करने से पहले देखें कि आपके उपयोगकर्ता Chrome के किन वर्शन का इस्तेमाल कर रहे हैं. Chrome अपने-आप अपडेट हो जाता है. हालांकि, कुछ उपयोगकर्ता अपडेट की सुविधा बंद कर देते हैं. वहीं, कुछ उपयोगकर्ता पुराने डिवाइसों का इस्तेमाल करते हैं, जिन पर Chrome का नया वर्शन नहीं चल सकता. अपने Analytics डेटा से इसकी पुष्टि करें. अगर आपने अब तक Analytics सेट अप नहीं किया है है, तो शुरू करने के लिए, Google Analytics 4 की मदद से अपने एक्सटेंशन की परफ़ॉर्मेंस की निगरानी करना लेख पढ़ें.
इसके बाद, कोई एक तरीका चुनें:
- अगर आपके उपयोगकर्ता Chrome के वर्शन 148 या इसके बाद वाले वर्शन का इस्तेमाल कर रहे हैं, तो बिना किसी शर्त के इसे अपनाएं.
- अगर आपके ज़्यादातर उपयोगकर्ता Chrome के वर्शन 147 या इससे पहले वाले वर्शन का इस्तेमाल कर रहे हैं, तो रनटाइम गार्ड का इस्तेमाल करें.
बिना किसी शर्त के इसे अपनाएं
अपने मेनिफ़ेस्ट में minimum_chrome_version
सेट करें और बिना किसी शर्त के browser का इस्तेमाल करें. इसके लिए, रनटाइम गार्ड की ज़रूरत नहीं है:
{
"minimum_chrome_version": "148"
}
minimum_chrome_version बढ़ाने के लिए, चरण दर चरण रोल आउट का इस्तेमाल करें. अगर कोई गड़बड़ी होती है, तो Chrome वेब स्टोर में अपने एक्सटेंशन को रोल बैक किया जा सकता है.
रनटाइम गार्ड का इस्तेमाल करना
browser को कहीं और रेफ़र करने से पहले, अपने एक्सटेंशन के स्टार्टअप कोड में यह स्निपेट जोड़ें:
if (!globalThis.browser) {
globalThis.browser = chrome;
// Consider firing an analytics event here to measure how often
// your users hit this fallback path.
}
इससे, Chrome के पुराने वर्शन पर browser, chrome का एलियास बन जाता है. इसलिए, आपके कोड का बाकी हिस्सा, बिना किसी शर्त के browser का इस्तेमाल कर सकता है.
पॉलीफ़िल इस्तेमाल करने वाले लोगों के लिए नोट
अगर आपका एक्सटेंशन,
webextension-polyfill का इस्तेमाल करता है, तो यह
Chrome के वर्शन 148 और इसके बाद वाले वर्शन पर काम नहीं करेगा. जब browser पहले से तय किया गया था, तब पॉलीफ़िल ने रैप करने की प्रोसेस छोड़ दी थी. ऐसा इसलिए किया गया था, क्योंकि यह माना गया था कि होस्ट ब्राउज़र ने पहले ही एपीआई उपलब्ध करा दिया है.
Chrome के वर्शन 136 में नेमस्पेस शिप करने की पिछली कोशिश को इस वजह से
रोल बैक कर दिया गया था: browser को नए सिरे से तय करने पर, पॉलीफ़िल ने रैप करने की प्रोसेस छोड़ दी थी. हालांकि,
Chrome के browser.runtime.onMessage ने अब तक, प्रॉमिस-रिटर्निंग
लिसनर के लिए सहायता उपलब्ध नहीं कराई थी. पॉलीफ़िल, प्रॉमिस-रिटर्निंग लिसनर की सुविधा उपलब्ध करा रहा था. इस वजह से, उस पैटर्न पर निर्भर एक्सटेंशन काम नहीं कर पाए. Chrome के वर्शन 148 में, नेमस्पेस और नेटिव प्रॉमिस-रिटर्निंग onMessage लिसनर, दोनों को एक साथ शिप किया जाता है, ताकि इस समस्या से बचा जा सके.
जब आपके ज़्यादातर उपयोगकर्ता Chrome के वर्शन 148 पर माइग्रेट कर लेंगे, तब पॉलीफ़िल की डिपेंडेंसी को हटाया जा सकता है.
अन्य सुविधाएं
runtime.sendMessage में एसिंक्रोनस जवाब
Chrome के वर्शन 148 में, runtime.onMessage लिसनर, एसिंक्रोनस जवाब भेजने के लिए सीधे तौर पर Promise को वापस कर सकते हैं. यह सुविधा, chrome.* या browser.* का इस्तेमाल करके कॉल करने पर भी काम करती है.
पहले, एसिंक्रोनस तरीके से जवाब देने का सिर्फ़ एक तरीका था. इसके लिए, लिसनर से लिटरल true को वापस करना होता था और बाद में sendResponse को कॉल करना होता था:
// Old pattern - requires returning true to keep the channel open
chrome.runtime.onMessage.addListener((message, sender, sendResponse) => {
fetch('https://example.com')
.then(response => sendResponse({ statusCode: response.status }));
return true; // keeps the message channel open for the async response
});
अब सीधे तौर पर Promise को वापस किया जा सकता है या async फ़ंक्शन का इस्तेमाल किया जा सकता है:
// New pattern - return a promise or use async/await
browser.runtime.onMessage.addListener(async (message, sender) => {
const response = await fetch('https://example.com');
return { statusCode: response.status };
});
return true पैटर्न अब भी काम करता है. इसलिए, मौजूदा कोड में बदलाव करने की ज़रूरत नहीं है.