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