Chrome 153 बीटा

Rachel Andrew

पब्लिश होने की तारीख: 20 अगस्त, 2026

यहां बताए गए बदलाव, Android, ChromeOS, Linux, macOS, और Windows के लिए Chrome के बीटा चैनल के सबसे नए वर्शन पर लागू होते हैं. हालांकि, अगर किसी बदलाव के बारे में अलग से बताया गया है, तो वह जानकारी मान्य होगी. इन सुविधाओं के बारे में ज़्यादा जानने के लिए, दिए गए लिंक का इस्तेमाल करें या ChromeStatus.com पर जाएं. Chrome का यह वर्शन, बीटा वर्शन है. डेस्कटॉप के लिए, Chrome का सबसे नया बीटा वर्शन Google.com से डाउनलोड किया जा सकता है. वहीं, Android के लिए, इसे Google Play Store से डाउनलोड किया जा सकता है.

सीएसएस और यूज़र इंटरफ़ेस (यूआई)

सिंगल-ऐक्सिस स्क्रोल कंटेनर

यह overflow प्रॉपर्टी को बढ़ाता है, ताकि स्क्रोल की जा सकने वाली वैल्यू के साथ-साथ clip का इस्तेमाल किया जा सके. उदाहरण के लिए, overflow: scroll clip. इससे position: sticky को हर ऐक्सिस के हिसाब से, अलग-अलग पैरंट स्क्रोल कंटेनर से सीमित किया जा सकता है. साथ ही, ऑथर को यह पक्का करने का तरीका मिलता है कि overflow: clip का इस्तेमाल करने वाला ऐक्सिस अपनी जगह पर बना रहे.

scroll-axis-lock प्रॉपर्टी

scroll-axis-lock एक सीएसएस प्रॉपर्टी है. इसका इस्तेमाल करके, डेवलपर ब्राउज़र को यह निर्देश दे सकते हैं कि वह उपयोगकर्ता के स्क्रोलिंग जेस्चर को एक ऐक्सिस तक सीमित न करे.

वेब ब्राउज़र अक्सर उपयोगकर्ता के स्क्रोलिंग जेस्चर को एक ही ऐक्सिस तक "लॉक" कर देते हैं. ऐसा तब होता है, जब वह जेस्चर, लंबवत ऐक्सिस के मुकाबले एक ऐक्सिस में ज़्यादा मूवमेंट के साथ शुरू होता है. कई मामलों में, इस व्यवहार से उपयोगकर्ता का अनुभव बेहतर होता है. ऐसा इसलिए, क्योंकि जब उपयोगकर्ता का इरादा सिर्फ़ एक ऐक्सिस को स्क्रोल करने का होता है, तब लंबवत ऐक्सिस के साथ गलती से स्क्रोल होने से बचा जा सकता है. हालांकि, अगर कोई डेवलपर चाहता है कि उसका एलिमेंट हमेशा डायगोनल तरीके से स्क्रोल किया जा सके, तो इस लॉकिंग व्यवहार की वजह से, उपयोगकर्ता को अपना जेस्चर ऐसे ऐंगल से शुरू करना पड़ता है जिससे लॉकिंग ट्रिगर न हो. अक्सर यह ऑथर के तय किए गए उपयोगकर्ता अनुभव के मुताबिक नहीं होता.

JavaScript

इटररेटर जॉइन

यह TC39 का एक प्रपोज़ल है. इसके तहत, JavaScript में एक ऐसा तरीका जोड़ा जाएगा जिससे इटररेटर के कॉन्टेंट को एक स्ट्रिंग में जोड़ा जा सकेगा. join() इंस्टेंस का Iterator तरीका, Array.prototype.join() जैसा ही होता है. यह एक स्ट्रिंग दिखाता है, जो इटररेटर से जनरेट किए गए सभी एलिमेंट को कॉमा या तय की गई सेपरेटर स्ट्रिंग से अलग करके बनाई जाती है.

जॉइंट इटरेशन

यह TC39 का एक प्रपोज़ल है. इसके तहत, एक साथ कई इटररेटर को आगे बढ़ाने की सुविधा जोड़ी जाएगी. इसे अक्सर zip कहा जाता है.

Web API

कैपेबिलिटी एलिमेंट: <camera> और <microphone>

<camera> और <microphone> कैपेबिलिटी एलिमेंट, डिक्लेरेटिव और उपयोगकर्ता की कार्रवाई से ट्रिगर होने वाले एचटीएमएल कंट्रोल होते हैं. ये <usermedia> MVP एलिमेंट के जैसे ही काम करते हैं. हालांकि, इनमें एक अहम अंतर होता है: इन्हें सिर्फ़ एक कैपेबिलिटी का अनुरोध करने के लिए डिज़ाइन किया गया है. <camera> एलिमेंट खास तौर पर वीडियो कैप्चर करने का अनुरोध करता है, जबकि <microphone> एलिमेंट खास तौर पर ऑडियो कैप्चर करने का अनुरोध करता है. ये <usermedia> MVP की तरह ही, पेज में ब्राउज़र से कंट्रोल होने वाला और खास स्टाइल वाला यूज़र इंटरफ़ेस (यूआई) एम्बेड करते हैं. इससे यह पक्का होता है कि अनुमति का प्रॉम्प्ट ट्रिगर होने या स्ट्रीम शुरू होने से पहले, उपयोगकर्ता की ओर से एक मज़बूत और जान-बूझकर किया गया सिग्नल (क्लिक) मिले.

<camera> और <microphone> एलिमेंट, इन सिंगल-कैपेबिलिटी इस्तेमाल के मामलों के लिए, खास और सिमेंटिक एचटीएमएल कंट्रोल उपलब्ध कराते हैं. ये <usermedia> MVP के जैसे ही सुरक्षा मॉडल, स्टाइलिंग की सख्त पाबंदियां, और अनुमति वापस पाने का इन-बिल्ट पाथ बनाए रखते हैं. हालांकि, ये उन डेवलपर के लिए ज़्यादा बेहतर और एर्गोनॉमिक एपीआई उपलब्ध कराते हैं जिन्हें मिक्स मीडिया ऐक्सेस की ज़रूरत नहीं होती.

इमर्सिव ऑडियो मॉडल और फ़ॉर्मैट (IAMF) को डिकोड करने की सुविधा

इससे, Media Source Extensions (MSE) के साथ एचटीएमएल मीडिया एलिमेंट में, इमर्सिव ऑडियो मॉडल और फ़ॉर्मैट (IAMF) कंटेनर को डिकोड करने और वापस चलाने की सुविधा मिलती है. IAMF, ओपन सोर्स और रॉयल्टी-फ़्री स्पेशल ऑडियो फ़ॉर्मैट है. यह चैनल-आधारित, सीन-आधारित, और ऑब्जेक्ट-आधारित ऑडियो प्रज़ेंटेशन के साथ काम करता है. इस फ़ॉर्मैट के साथ काम करने की सुविधा मिलने से, वेब डेवलपर अलग-अलग डिवाइसों पर, 3D ऑडियो के इमर्सिव अनुभव दे सकते हैं. इसके लिए, उन्हें मालिकाना हक वाले फ़ॉर्मैट पर निर्भर रहने या JavaScript में, अलग-अलग ऑडियो चैनल की जटिल राउटिंग को मैनेज करने की ज़रूरत नहीं होती.

transitionrun और मीडिया क्वेरी इवेंट के लिए, इंटरऑपरेबल डिस्पैच टाइमिंग

इससे, ऐनिमेशन transitionrun इवेंट और मीडिया क्वेरी change इवेंट के लिए, Blink की डिस्पैच टाइमिंग को एचटीएमएल स्पेसिफ़िकेशन के साथ अलाइन किया जाता है. इससे, टाइमिंग Gecko और WebKit के साथ इंटरऑपरेबल हो जाती है. ज़्यादा सटीक तरीके से कहें, तो एचटीएमएल विंडो इवेंट लूप स्पेसिफ़िकेशन के मुताबिक, transitionrun इवेंट, स्टेप 3.11 पर ट्रिगर होंगे. भले ही, उन्हें उसी इटरेशन में पहले बनाया गया हो. इन्हें बाद के इटरेशन के लिए डिले नहीं किया जाएगा. साथ ही, मीडिया क्वेरी change इवेंट, स्टेप 3.10 पर ट्रिगर होगा. यह पेंडिंग ऐनिमेशन इवेंट से पहले ट्रिगर होगा. इसे स्टेप 3.11 पर ऐनिमेशन इवेंट के साथ मिक्स नहीं किया जाएगा.

WebAudio: कॉन्फ़िगर किया जा सकने वाला रेंडर क्वांटम

AudioContext और OfflineAudioContext में, वैकल्पिक पैरामीटर renderSizeHint जोड़ा गया है. इससे डेवलपर, कोई खास पूर्णांक वैल्यू पास करके, WebAudio रेंडर क्वांटम का साइज़ पसंद के मुताबिक बना सकते हैं. हिंट को छोड़कर या "default" पास करके, 128 फ़्रेम के डिफ़ॉल्ट साइज़ का इस्तेमाल किया जा सकता है. इसके अलावा, "hardware" तय करके, ब्राउज़र से ऑप्टिमल साइज़ चुनने का अनुरोध किया जा सकता है.

WebGPU: buffer_view सुविधा

यह WGSL भाषा की एक सुविधा है. इसकी मदद से, वैरिएबल में मौजूद डेटा को फिर से इंटरप्रेट किया जा सकता है. इस सुविधा की मदद से, डेवलपर एक ही यूनिफ़ॉर्म, स्टोरेज या वर्कग्रुप वैरिएबल को कई लॉजिकल वैरिएबल में बांट सकते हैं. इससे, प्रोग्राम में वैरिएबल में मौजूद डेटा के टाइप को कई टाइप के तौर पर इंटरप्रेट किया जा सकता है.

XSLT के अलावा अन्य स्थितियों के लिए, रस्ट में एक्सएमएल पार्स करना

ब्राउज़र की सुरक्षा को बेहतर बनाने और मेमोरी से जुड़े जोखिम की आशंकाओं से उपयोगकर्ताओं को बचाने के लिए, Chrome 153 अपने एक्सएमएल पार्सिंग इंजन को मेमोरी-सेफ़ रस्ट इंप्लीमेंटेशन में बदल रहा है. यह बदलाव, कई सामान्य स्थितियों के लिए किया जा रहा है. यह एक बुनियादी अपडेट है, जो मेमोरी को नुकसान पहुंचाने से जुड़ी संभावित गड़बड़ियों को खत्म करता है. साथ ही, यह मौजूदा वेब स्पेसिफ़िकेशन के साथ पूरी तरह काम करता है.

Chrome ने XSLT का इस्तेमाल बंद करने और इसे हटाने की प्रोसेस पहले ही शुरू कर दी है. जब तक यह प्रोसेस जारी है, तब तक नया और ज़्यादा सुरक्षित पार्सर उन स्थितियों को हैंडल करेगा जिनमें XSLT की ज़रूरत नहीं होती:

1. DOMParser Web API.
2. XMLHttpRequest के responseXML को ऐक्सेस करना.
3. एसवीजी फ़ॉर्मैट में स्टैंडअलोन इमेज (यानी कि image.svg फ़ाइल को सीधे ब्राउज़र में मुख्य पेज के तौर पर खोलना).
4. एसवीजी फ़ॉर्मैट में बाहरी इमेज (इसमें किसी मुख्य दस्तावेज़ में, बाहरी इमेज रिसॉर्स के तौर पर एंबेड की गई एसवीजी इमेज भी शामिल है).

ऑरिजिन ट्रायल के नए एक्सपेरिमेंट

Chrome 153 में, ऑरिजिन ट्रायल के इन नए एक्सपेरिमेंट में शामिल हुआ जा सकता है.

JavaScript सेल्फ़-प्रोफ़ाइलिंग मार्कर

JavaScript Self-Profiling API की मदद से, वेब ऐप्लिकेशन अपने कॉल स्टैक का सैंपल ले सकता है. इससे, असली उपयोगकर्ताओं के डिवाइसों पर परफ़ॉर्मेंस को मापा जा सकता है. इस सुविधा के तहत, कैप्चर किए गए हर सैंपल में एक वैकल्पिक मार्कर फ़ील्ड जोड़ा जाता है. इससे, सैंपल लिए जाने के दौरान चल रही ब्राउज़र गतिविधि के टाइप की पहचान की जा सकती है. जैसे: स्क्रिप्ट, gc, स्टाइल, लेआउट, पेंट या अन्य. आम तौर पर, ट्रेस में स्टैक के बीच ऐसे गैप दिखते हैं जिन्हें इंटरप्रेट नहीं किया जा सकता. मार्कर की मदद से, डेवलपर उस समय को ब्राउज़र के काम के लिए एट्रिब्यूट कर सकते हैं. यह काम उनके JavaScript के बाहर होता है. उदाहरण के लिए, स्क्रिप्ट के एक्ज़ीक्यूशन को स्टाइल के फिर से कैलकुलेशन, लेआउट या गार्बेज कलेक्शन पॉज़ से अलग किया जा सकता है. इससे, धीमी ट्रेस को आसानी से ऐनलइज़ और ऑप्टिमाइज़ किया जा सकता है.

इस्तेमाल बंद की जा रही सुविधाएं और हटाई गई सुविधाएं

_current को टारगेट करने वाले, नॉन-स्टैंडर्ड नेविगेशन हटाएं

Blink फ़िलहाल, _current को टारगेट करने वाले नेविगेशन के साथ काम करता है. इस सुविधा को Chrome 153 से हटा दिया गया है, क्योंकि यह नॉन-स्टैंडर्ड है और वेब पर इसका इस्तेमाल बहुत कम होता है.

document.requestStorageAccessFor हटाएं

requestStorageAccessFor (rSAFor) API, Storage Access API का एक एक्सटेंशन है. इसकी मदद से, टॉप-लेवल की साइट, एम्बेड की गई साइटों की ओर से, बिना बंटे हुए ("पहले पक्ष की") कुकी को ऐक्सेस करने का अनुरोध कर सकती है. इसका इस्तेमाल सिर्फ़ Chrome में, मिलती-जुलती वेबसाइट के सेट की साइटों के बीच स्टोरेज ऐक्सेस का अनुरोध करने के लिए किया जा सकता है. इसलिए, इसे मिलती-जुलती वेबसाइट के सेट के साथ हटा दिया गया है.

मिलती-जुलती वेबसाइट के सेट हटाएं

मिलती-जुलती वेबसाइट के सेट (RWS) को पहले, पहले पक्ष के सेट के तौर पर जाना जाता था. यह डेवलपर के लिए एक फ़्रेमवर्क उपलब्ध कराता है. इसकी मदद से, साइटों के बीच के संबंधों के बारे में एलान किया जा सकता है. इससे, खास और उपयोगकर्ता के लिए ज़रूरी कामों के लिए, सीमित क्रॉस-साइट कुकी ऐक्सेस की सुविधा मिलती है. यह Storage Access API (SAA) और requestStorageAccessFor (rSAFor) के इस्तेमाल से मुमकिन होता है. RWS को ऐसे ब्राउज़र में इस्तेमाल करने के लिए डिज़ाइन किया गया था जिसमें तीसरे पक्ष की कुकी का इस्तेमाल नहीं किया जाता. Chrome ने एलान किया है कि तीसरे पक्ष की कुकी के लिए मौजूदा तरीका जारी रहेगा. इसलिए, अब Chrome से मिलती-जुलती वेबसाइट के सेट को हटा दिया गया है.