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

Dave Tapuska
Dave Tapuska

कम शब्दों में: ज़्यादा जानकारी नीचे दी गई है.

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

अलग-अलग तरह के पेजों को समझना

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

ऐक्टिव पेज को हटाना
मौजूदा पेज को हटाना.

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

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

पेज किस तरह के हैं
पेज किस तरह के हैं.

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

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

फ़्रेम आईडी == 0

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

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

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

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

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

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

मैं यह कैसे पता करूं कि पेज किस लाइफ़ साइकल में है?

DocumentLifecycle टाइप को ऐसे कई एक्सटेंशन एपीआई में जोड़ा गया है जिनमें frameId पहले उपलब्ध था. अगर किसी इवेंट में DocumentLifecycle टाइप मौजूद है (जैसे कि onCommitted), तो इसकी वैल्यू वह स्थिति होती है जिसमें इवेंट जनरेट हुआ था. 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 के साथ मिलाकर यह पता लगा सकते हैं कि कोई फ़्रेम, सबसे बाहरी फ़्रेम पर चल रहा है या नहीं. उदाहरण के लिए: js tab.documentLifecycle == “active” && frameType == “outermost_frame”

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

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

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

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

यह पता करने के लिए अश्लील सिग्नल होते हैं कि कोई पेज कब राज्यों के बीच बदलता है.

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

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

onBeforeNavigate
onCommitted
onDOMContentLoaded
onCompleted

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

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

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

onBeforeNavigate
onCommitted
onCompleted

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

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