Chrome एक्सटेंशन: झटपट नेविगेशन के समर्थन के लिए API (एपीआई) बढ़ाना

Dave Tapuska

कम शब्दों में: ज़्यादा जानकारी के लिए नीचे पढ़ें.

Chrome, नेविगेशन को तेज़ बनाने के लिए लगातार काम कर रहा है. इंस्टैंट नेविगेशन टेक्नोलॉजी, जैसे कि बैक/फ़ॉरवर्ड कैश मेमोरी (Chrome 96 में, डेस्कटॉप पर शिप किया गया) और अनुमान लगाने के नियम (Chrome 103 में शिप किया गया), पीछे जाने और आने वाले समय के अनुभव को बेहतर बनाती हैं. इस पोस्ट में, हम ब्राउज़र एक्सटेंशन एपीआई में किए गए अपडेट के बारे में बताएंगे, ताकि इन नए वर्कफ़्लो को शामिल किया जा सके.

पेजों के टाइप को समझना

बैक/फ़ॉरवर्ड कैश मेमोरी और पेज को पहले से रेंडर करने की सुविधा के आने से पहले, किसी टैब में सिर्फ़ एक पेज चालू होता था. यह हमेशा दिखता था. अगर कोई उपयोगकर्ता पिछले पेज पर वापस जाता है, तो चालू पेज (पेज B) को मिटा दिया जाएगा और इतिहास में मौजूद पिछले पेज को पूरी तरह से फिर से बनाया जाएगा (पेज A). एक्सटेंशन को इस बात की चिंता नहीं करनी पड़ती थी कि पेज, लाइफ़ साइकल के किस चरण में हैं, क्योंकि टैब के लिए सिर्फ़ एक चरण था, वह भी चालू/दिखने वाला स्टेटस.

बैक/फ़ॉरवर्ड कैश मेमोरी और पेज को पहले से रेंडर करने की सुविधा के साथ, अब टैब और पेजों के बीच एक-एक का संबंध नहीं है. अब हर टैब में कई पेज सेव किए जाते हैं. साथ ही, पेजों को नष्ट करने और फिर से बनाने के बजाय, एक स्टेटस से दूसरे स्टेटस में ट्रांज़िशन किया जाता है.

उदाहरण के लिए, कोई पेज पहले से रेंडर किए गए (न दिखने वाले) पेज के तौर पर शुरू हो सकता है. जब उपयोगकर्ता किसी लिंक पर क्लिक करता है, तो वह पेज चालू (दिखने वाले) पेज में बदल जाता है. इसके बाद, जब उपयोगकर्ता किसी दूसरे पेज पर जाता है, तो वह पेज बैक/फ़ॉरवर्ड कैश मेमोरी (न दिखने वाले) में सेव हो जाता है. इस दौरान, पेज को कभी भी मिटाया नहीं जाता. इस लेख में आगे चलकर, हम नई प्रॉपर्टी के बारे में जानेंगे. इनसे, एक्सटेंशन को यह समझने में मदद मिलेगी कि पेज किस स्थिति में हैं.

ध्यान दें कि किसी टैब में, पहले से रेंडर किए गए पेजों की एक सीरीज़ हो सकती है, न कि सिर्फ़ एक. साथ ही, उसमें एक चालू (दिखने वाला) पेज और बैक/फ़ॉरवर्ड कैश मेमोरी में सेव किए गए पेजों की एक सीरीज़ भी हो सकती है.

एक्सटेंशन डेवलपर के लिए क्या बदलाव हो रहे हैं?

FrameId == 0

Chromium में, सबसे ऊपर/मुख्य फ़्रेम को सबसे बाहरी फ़्रेम कहा जाता है.

एक्सटेंशन के ऐसे लेखकों को समस्याएं आ सकती हैं जो सबसे बाहरी फ़्रेम का frameId 0 मानते हैं. यह एक पुराना सबसे सही तरीका है. अब किसी टैब में सबसे बाहरी कई फ़्रेम (पहले से रेंडर किए गए और कैश मेमोरी में सेव किए गए पेज) हो सकते हैं. इसलिए, यह मानना गलत है कि किसी टैब में सबसे बाहरी सिर्फ़ एक फ़्रेम होता है. frameId == 0 अब भी चालू पेज का सबसे बाहरी फ़्रेम दिखाता रहेगा. हालांकि, उसी टैब में अन्य पेजों के बाहरी फ़्रेम शून्य नहीं होंगे. इस समस्या को ठीक करने के लिए, एक नया फ़ील्ड frameType जोड़ा गया है. इस पोस्ट का “मैं यह कैसे तय करूं कि कोई फ़्रेम सबसे बाहरी फ़्रेम है या नहीं?” सेक्शन देखें.

फ़्रेम बनाम दस्तावेज़ों का लाइफ़ साइकल

एक्सटेंशन के साथ एक और समस्या है, वह है फ़्रेम का लाइफ़ साइकल. फ़्रेम में कोई दस्तावेज़ होस्ट किया जाता है, जो किसी कमिट किए गए यूआरएल से जुड़ा होता है. नेविगेट करने पर दस्तावेज़ बदल सकता है, लेकिन frameId नहीं बदलेगा. इसलिए, सिर्फ़ frameIds से यह पता लगाना मुश्किल है कि किसी खास दस्तावेज़ में क्या हुआ. हम documentId के बारे में बता रहे हैं. यह हर दस्तावेज़ के लिए एक यूनीक आइडेंटिफ़ायर होता है. अगर किसी फ़्रेम पर नेविगेट किया जाता है और कोई नया दस्तावेज़ खोला जाता है, तो आइडेंटिफ़ायर बदल जाएगा. इस फ़ील्ड की मदद से, यह भी तय किया जा सकता है कि पेजों की लाइफ़ साइकल की स्थिति, प्रीरेंडरिंग/ऐक्टिव/कैश मेमोरी में कब बदलती है. ऐसा इसलिए, क्योंकि पेज में कोई बदलाव नहीं होता.

वेब नेविगेशन इवेंट

chrome.webNavigation नेमस्पेस में मौजूद इवेंट, एक ही पेज पर कई बार फ़ायर हो सकते हैं. हालांकि, यह इस बात पर निर्भर करता है कि वह किस लाइफ़ साइकल में है. “मुझे कैसे पता चलेगा कि पेज किस लाइफ़ साइकल में है?” और “मुझे कैसे पता चलेगा कि पेज कब ट्रांज़िशन करेगा?” सेक्शन देखें.

मुझे यह कैसे पता चलेगा कि पेज किस लाइफ़ साइकल में है?

DocumentLifecycle टाइप को कई एक्सटेंशन एपीआई में जोड़ा गया है, जहां पहले frameId उपलब्ध था. अगर किसी इवेंट (जैसे, onCommitted) पर DocumentLifecycle टाइप मौजूद है, तो उसकी वैल्यू वह स्थिति होती है जिसमें इवेंट जनरेट हुआ था. WebNavigation getFrame() और getAllFrames() तरीकों से, जानकारी की क्वेरी कभी भी की जा सकती है. हालांकि, इवेंट की वैल्यू का इस्तेमाल करना हमेशा बेहतर होता है. अगर इनमें से किसी भी तरीके का इस्तेमाल किया जाता है, तो ध्यान रखें कि इवेंट जनरेट होने और दोनों तरीकों से मिलने वाले प्रॉमिस के रिज़ॉल्व होने के बीच, फ़्रेम की स्थिति बदल सकती है.

DocumentLifecycle के लिए ये वैल्यू इस्तेमाल की जा सकती हैं:

• "prerender" : फ़िलहाल, उपयोगकर्ता को नहीं दिखाया जा रहा है. हालांकि, इसे उपयोगकर्ता को दिखाने की तैयारी की जा रही है.
• "active": फ़िलहाल, उपयोगकर्ता को दिखाया जा रहा है.
• "cached": बैक/फ़ॉरवर्ड कैश मेमोरी में सेव किया जाता है.
• "pending_deletion": दस्तावेज़ को मिटाया जा रहा है.

मैं कैसे पता लगाऊं कि कोई फ़्रेम सबसे बाहरी फ़्रेम है या नहीं?

पहले, एक्सटेंशन यह जांच कर सकते थे कि frameId == 0, यह तय करने के लिए कि इवेंट सबसे बाहरी फ़्रेम के लिए है या नहीं. टैब में एक से ज़्यादा पेज होने पर, अब हमारे पास सबसे बाहरी फ़्रेम की संख्या ज़्यादा हो जाती है. इसलिए, frameId की परिभाषा में समस्या आती है. आपको कभी भी बैक/फ़ॉरवर्ड कैश मेमोरी में सेव किए गए फ़्रेम से जुड़े इवेंट नहीं मिलेंगे. हालांकि, पहले से रेंडर किए गए फ़्रेम के लिए, सबसे बाहरी फ़्रेम के लिए frameId शून्य नहीं होगा. इसलिए, frameId == 0 को सिग्नल के तौर पर इस्तेमाल करके, यह तय किया जा सकता है कि यह फ़्रेम सबसे बाहरी है या नहीं.

इसकी मदद से, हमने एक नया टाइप पेश किया है, जिसे FrameType कहा जाता है. इससे यह तय करना आसान हो जाता है कि फ़्रेम वाकई में सबसे बाहरी फ़्रेम है या नहीं. FrameType की ये वैल्यू हैं:

• "outermost_frame": आम तौर पर, इसे सबसे ऊपर वाला फ़्रेम कहा जाता है. ध्यान दें कि इनमें से कई वैरिएंट हैं. उदाहरण के लिए, अगर आपके पास पहले से रेंडर किए गए और कैश मेमोरी में सेव किए गए पेज हैं, तो हर पेज का सबसे बाहरी फ़्रेम होता है, जिसे सबसे ऊपर वाला फ़्रेम कहा जा सकता है.
• "fenced_frame": आने वाले समय में इस्तेमाल के लिए रिज़र्व किया गया.
• "sub_frame": आम तौर पर, iframe.

हम DocumentLifecycle को FrameType के साथ जोड़कर यह तय कर सकते हैं कि कोई फ़्रेम, सबसे बाहरी सक्रिय फ़्रेम है या नहीं. उदाहरण के लिए: tab.documentLifecycle === “active” && frameType === “outermost_frame”

फ़्रेम के इस्तेमाल के समय से जुड़ी समस्याओं को कैसे हल किया जा सकता है?

जैसा कि हमने ऊपर बताया है कि फ़्रेम, दस्तावेज़ को होस्ट करता है और फ़्रेम नए दस्तावेज़ पर जा सकता है. हालांकि, frameId में कोई बदलाव नहीं होगा. इससे उस समय समस्याएं पैदा होती हैं जब आपको सिर्फ़ frameId वाला कोई इवेंट मिलता है. अगर फ़्रेम का यूआरएल देखा जाता है, तो हो सकता है कि वह इवेंट के होने के समय से अलग हो. इसे इस्तेमाल के समय से जुड़ी समस्या कहा जाता है.

इस समस्या को हल करने के लिए, हमने documentId और parentDocumentId एट्रिब्यूट को जोड़ा है. webNavigation.getFrame() तरीके में, documentId एट्रिब्यूट की वैल्यू देने पर, frameId एट्रिब्यूट की वैल्यू देना ज़रूरी नहीं है. फ़्रेम पर नेविगेट किए जाने पर documentId बदल जाएगा.

मैं यह कैसे तय करूं कि पेज का ट्रांज़िशन कब हुआ?

किसी पेज के स्टेटस में बदलाव होने पर, साफ़ तौर पर सिग्नल मिलते हैं.

आइए, WebNavigation इवेंट पर नज़र डालते हैं.

किसी भी पेज पर पहली बार नेविगेट करने पर, आपको यहां दिए गए क्रम में चार इवेंट दिखेंगे. ध्यान दें कि ये चार इवेंट, DocumentLifecycle के स्टेटस के "prerender" या "active" होने पर हो सकते हैं.

onBeforeNavigate
onCommitted
onDOMContentLoaded
onCompleted

इसे नीचे दिए गए डायग्राम में दिखाया गया है. इसमें दिखाया गया है कि जब पहले से रेंडर किया गया पेज, ऐक्टिव पेज बन जाता है, तो documentId की वैल्यू "xyz" में बदल जाती है.

जब कोई पेज बैक/फ़ॉरवर्ड कैश मेमोरी या प्री-रेंडर से ऐक्टिव स्टेटस में ट्रांज़िशन करता है, तो तीन और इवेंट होंगे. हालांकि, DocumentLifecyle के बजाय "active" होगा.

onBeforeNavigate
onCommitted
onCompleted

documentId, ओरिजनल इवेंट जैसा ही रहेगा. documentId == xyz चालू होने पर, इसकी जानकारी ऊपर दी गई है. ध्यान दें कि onDOMContentLoaded इवेंट को छोड़कर, वही नेविगेशन इवेंट ट्रिगर होते हैं, क्योंकि पेज पहले ही लोड हो चुका है.

अगर आपका कोई टिप्पणी या सवाल है, तो कृपया बेझिझक Chromium-एक्सटेंशन ग्रुप पर जाएं.