Chrome के लगभग हर वर्शन में, हमें प्रॉडक्ट, उसकी परफ़ॉर्मेंस, और वेब प्लैटफ़ॉर्म की सुविधाओं में कई अपडेट और सुधार दिखते हैं. इस लेख में, Chrome 60 में बंद की गई सुविधाओं और हटाए गए एलिमेंट के बारे में बताया गया है. यह वर्शन 8 जून से बीटा वर्शन में उपलब्ध है. इस सूची में कभी भी बदलाव किया जा सकता है.
सुरक्षा
crypto.subtle के लिए अब सुरक्षित ऑरिजिन की ज़रूरत है
Web Crypto API, Chrome 37 से काम कर रहा है. यह हमेशा असुरक्षित ऑरिजिन पर काम करता है. Chrome की बेहतर सुविधाओं के लिए सुरक्षित ऑरिजिन को प्राथमिकता देने की पुरानी नीति की वजह से, crypto.subtle सिर्फ़ सुरक्षित ऑरिजिन पर नहीं दिखता.
हटाने का इंटेंट | Chromium में मौजूद गड़बड़ी
डेटा यूआरएल पर, कॉन्टेंट से शुरू होने वाले टॉप फ़्रेम नेविगेशन हटाना
ब्राउज़र के गैर-तकनीकी उपयोगकर्ताओं को इस स्कीम के बारे में जानकारी नहीं होती. इसलिए, हम देख रहे हैं कि स्पूफ़िंग और फ़िशिंग हमलों में data: स्कीम का इस्तेमाल बढ़ रहा है. इससे बचने के लिए, हम वेब पेजों को सबसे ऊपर मौजूद फ़्रेम में data: यूआरएल लोड करने से रोक रहे हैं. यह <a> टैग, window.open,
window.location, और मिलते-जुलते तरीकों पर लागू होता है. data: स्कीम, अब भी किसी पेज से लोड किए गए संसाधनों के लिए काम करेगी.
इस सुविधा को Chrome 58 में बंद कर दिया गया था और अब इसे हटा दिया गया है.
हटाने का इंटेंट | Chromestatus ट्रैकर | Chromium बग
कुछ ब्लॉब के लिए, navigator.sendBeacon() को कुछ समय के लिए बंद करना
navigator.sendBeacon() फ़ंक्शन, Chrome 39 से उपलब्ध है.
मूल रूप से लागू किए गए फ़ंक्शन के data आर्ग्युमेंट में, कोई भी मनमुताबिक ब्लॉब शामिल हो सकता है, जिसका टाइप सीओआरएस की सेफ़लिस्ट में शामिल नहीं है. हमारा मानना है कि यह सुरक्षा के लिए एक संभावित खतरा है. हालांकि, अब तक किसी ने भी इसका गलत इस्तेमाल करने की कोशिश नहीं की है. हम इस समस्या को तुरंत ठीक नहीं कर सकते. इसलिए, कुछ समय के लिए, sendBeacon() को उन ब्लॉब पर इस्तेमाल नहीं किया जा सकता जिनका टाइप, सीओआरएस की सेफ़लिस्ट में शामिल नहीं है.
हालांकि, यह बदलाव Chrome 60 के लिए लागू किया गया था, लेकिन अब इसे Chrome 59 में वापस मर्ज कर दिया गया है.
सीएसएस
शैडो-पियर्सिंग डिसेंटेंट कॉम्बिनेटर को डिसेंटेंट कॉम्बिनेटर की तरह काम करने दें
शैडो-पियर्सिंग डिसेंटेंट कॉम्बिनेटर (>>>), सीएसएस स्कोपिंग मॉड्यूल लेवल 1 का हिस्सा है. इसका मकसद, किसी खास पैरंट एलिमेंट के चाइल्ड एलिमेंट से मैच करना है. भले ही, वे शैडो ट्री में दिखते हों. हालांकि, इसकी कुछ सीमाएं थीं.
पहला, स्पेसिफ़िकेशन के मुताबिक, इसका इस्तेमाल सिर्फ़ querySelector() जैसे JavaScript कॉल में किया जा सकता था. साथ ही, यह स्टाइलशीट में काम नहीं करता था. सबसे अहम बात यह है कि ब्राउज़र वेंडर, शैडो DOM के एक लेवल से ज़्यादा काम नहीं कर पाए.
इसलिए, शैडो डीओएम v1 के साथ-साथ, काम के स्पेसिफ़िकेशन से डिसेंटेंट कॉम्बिनेटर को हटा दिया गया है. Chromium से इस सिलेक्टर को हटाकर, वेब पेजों को बंद करने के बजाय, हमने शैडो-पियर्सिंग डिसेंटेंट कम्बिनेटर को डिसेंटेंट कम्बिनेटर के नाम से जाना है. मूल व्यवहार को Chrome 45 में बंद कर दिया गया था. यह सुविधा, Chrome 61 में लागू की गई है.
हटाने का इंटेंट | Chromestatus ट्रैकर | Chromium बग
JavaScript
RTCPeerConnection.getStreamById() को बंद करना और हटाना
करीब दो साल पहले, getStreamById() को WebRTC स्पेसिफ़िकेशन से हटा दिया गया था. ज़्यादातर अन्य ब्राउज़र ने इसे अपने इंप्लीमेंटेशन से पहले ही हटा दिया है. हालांकि, ऐसा माना जाता है कि इस फ़ंक्शन का इस्तेमाल बहुत कम किया जाता है. साथ ही, यह भी माना जाता है कि Safari के अलावा, Edge और WebKit पर आधारित ब्राउज़र के साथ इंटरऑपरेबिलिटी का थोड़ा जोखिम है. हालांकि, Safari पर getStreamById() अब भी काम करता है. जिन डेवलपर को कोई दूसरा तरीका अपनाना है वे नीचे दिए गए, 'हटाने का इंटेंट' में उदाहरण के तौर पर दिया गया कोड देख सकते हैं.
यह सुविधा Chrome 62 में हटा दी गई है.
हटाने का इंटेंट | Chromestatus ट्रैकर | Chromium बग
SVGPathElement.getPathSegAtLength को बंद करना
दो साल से ज़्यादा पहले, getPathSegAtLength() को SVG स्पेसिफ़िकेशन से हटा दिया गया था. httparchive में इस तरीके के लिए सिर्फ़ कुछ हिट हैं. इसलिए, इसे Chrome 60 में बंद किया जा रहा है. Chrome 62 में, इस सुविधा को हटा दिया जाएगा. यह वर्शन, अक्टूबर की शुरुआत या बीच में रिलीज़ किया जाएगा.
इस्तेमाल बंद करने का फ़ैसला | Chromestatus ट्रैकर | Chromium में मौजूद गड़बड़ी
getContextAttributes() को फ़्लैग के पीछे ले जाना
getContextAttributes() फ़ंक्शन, 2013 से CanvasRenderingContext2D पर काम करता है. हालांकि, यह सुविधा किसी भी स्टैंडर्ड का हिस्सा नहीं थी और न ही तब से किसी स्टैंडर्ड का हिस्सा बनी है. इसे --enable-experimental-canvas-features कमांड लाइन फ़्लैग के पीछे लागू किया जाना चाहिए था, लेकिन गलती से ऐसा नहीं किया गया. Chrome 60 में इस गड़बड़ी को ठीक कर दिया गया है. ऐसा माना जाता है कि यह बदलाव सुरक्षित है, क्योंकि ऐसा कोई डेटा नहीं है जिससे पता चलता हो कि कोई भी व्यक्ति इस तरीके का इस्तेमाल कर रहा है.
Headers.prototype.getAll() हटाएं
फ़ेच स्पेसिफ़िकेशन के नए वर्शन के मुताबिक, Headers.prototype.getAll() फ़ंक्शन को हटाया जा रहा है.
हटाने का इंटेंट | Chromestatus ट्रैकर | Chromium बग
indexedDB.webkitGetDatabaseNames() को हटाएं
हमने यह सुविधा तब जोड़ी थी, जब Chrome में इंडेक्स किया गया DB अपेक्षाकृत नया था और प्रीफ़िक्स करना काफ़ी लोकप्रिय था. एपीआई, किसी ऑरिजिन में मौजूद डेटाबेस के नामों की सूची को असींक्रोनस तरीके से दिखाता है.
माफ़ करें, डिज़ाइन में गड़बड़ी है. ऐसा हो सकता है कि नतीजे मिलने के तुरंत बाद वे अमान्य हो जाएं. इसलिए, इसका इस्तेमाल सिर्फ़ लॉगिंग के लिए किया जा सकता है, न कि ऐप्लिकेशन के लॉजिक के लिए. GitHub की समस्या, वैकल्पिक तरीकों के बारे में हुई पिछली चर्चा को ट्रैक/लिंक करती है. इसके लिए, आपको अलग तरीका अपनाना होगा. डेवलपर इस बारे में कभी-कभी सोचते हैं, लेकिन अलग-अलग ब्राउज़र पर काम करने की सुविधा उपलब्ध न होने की वजह से, लाइब्रेरी के लेखकों ने इस समस्या को हल कर लिया है.
जिन डेवलपर को यह सुविधा चाहिए उन्हें खुद का समाधान बनाना होगा. उदाहरण के लिए, Dexie.js जैसी लाइब्रेरी, डेटाबेस के नामों को ट्रैक करने के लिए एक ग्लोबल टेबल का इस्तेमाल करती हैं. यह टेबल, अपने-आप एक और डेटाबेस बन जाती है.
इस सुविधा को Chrome 58 में बंद कर दिया गया था और अब इसे हटा दिया गया है.
हटाने का इंटेंट | Chromestatus ट्रैकर | Chromium बग
WEBKIT_KEYFRAMES_RULE और WEBKIT_KEYFRAME_RULE को हटाना
सीएसएस नियम से, स्टैंडर्ड के मुताबिक न होने वाले WEBKIT_KEYFRAMES_RULE और WEBKIT_KEYFRAME_RULE कॉन्स्टेंट हटा दिए गए हैं.
डेवलपर को इसके बजाय, KEYFRAMES_RULE और KEYFRAME_RULE का इस्तेमाल करना चाहिए.
हटाने का इंटेंट | Chromestatus ट्रैकर | Chromium बग
यूज़र इंटरफ़ेस
beforeunload डायलॉग बॉक्स के लिए, उपयोगकर्ता के जेस्चर की ज़रूरत है
Chrome 60 से, beforeunload डायलॉग सिर्फ़ तब दिखेगा, जब उसे दिखाने की कोशिश करने वाले फ़्रेम को उपयोगकर्ता से कोई जेस्चर या इंटरैक्शन मिला हो. इसके अलावा, अगर किसी एम्बेड किए गए फ़्रेम को ऐसा जेस्चर मिला हो, तब भी यह डायलॉग दिखेगा. साफ़ तौर पर कहें, तो इससे beforeunload इवेंट के डिस्पैच में कोई बदलाव नहीं होगा. यह सिर्फ़ इस बात में बदलाव है कि डायलॉग दिखेगा या नहीं.
beforeunload डायलॉग, ऐप्लिकेशन-मोडल डायलॉग बॉक्स है. इसलिए, यह मूल रूप से उपयोगकर्ता के लिए ठीक नहीं है. इसका मतलब है कि यह उपयोगकर्ता के नेविगेशन के जवाब में, उपयोगकर्ता के फ़ैसले पर सवाल उठाता है. इस सुविधा का इस्तेमाल कई कामों के लिए किया जा सकता है. उदाहरण के लिए, इसका इस्तेमाल अक्सर उपयोगकर्ताओं को चेतावनी देने के लिए किया जाता है, ताकि वे नेविगेट करते समय डेटा न खो दें.
beforeunload डायलॉग के लिए, पेज पर टेक्स्ट उपलब्ध कराने की सुविधा को कुछ समय पहले हटा दिया गया था. हालांकि, beforeunload डायलॉग का गलत इस्तेमाल अब भी किया जा रहा है. खास तौर पर, beforeunload डायलॉग बॉक्स, धोखाधड़ी वाली वेबसाइटों का एक हिस्सा होते हैं. इनमें अपने-आप चलने वाले ऑडियो और धमकी देने वाले टेक्स्ट की वजह से, Chromium के "क्या आपको वाकई इस पेज से जाना है" मैसेज से डर लगता है.
हम beforeunload
डायलॉग बॉक्स के सही इस्तेमाल को ही अनुमति देना चाहते हैं. डायलॉग का इस्तेमाल तब किया जा सकता है, जब उपयोगकर्ता की ऐसी स्थिति हो जो शायद गायब हो गई हो. अगर उपयोगकर्ता ने पेज से कभी इंटरैक्ट नहीं किया है, तो हो सकता है कि उपयोगकर्ता की कोई ऐसी स्थिति न हो जिसे मिटाया जा सके. इसलिए, हम उस स्थिति में डायलॉग को दबाकर, उपयोगकर्ता के डेटा को मिटाने का जोखिम नहीं उठाते.