Chrome 143 बीटा

Rachel Andrew

पब्लिश करने की तारीख: 29 अक्टूबर, 2025

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

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

सीएसएस में ऐंकर की गई फ़ॉलबैक कंटेनर क्वेरी

इस सुविधा में @container anchored(fallback) को शामिल किया गया है. इसकी मदद से, ऐंकर-पोज़िशन वाले एलिमेंट के डिसेंडेंट को स्टाइल किया जा सकता है. यह इस बात पर निर्भर करता है कि position-try-fallbacks की कौनसी वैल्यू लागू की गई है.

उदाहरण के लिए, इन क्वेरी का इस्तेमाल करके, ऐंकर किए गए एलिमेंट के टेदर या उसके ऐनिमेशन को स्टाइल किया जा सकता है. यह इस बात पर निर्भर करता है कि ऐंकर और ऐंकर किए गए एलिमेंट को एक-दूसरे के हिसाब से कैसे पोज़िशन किया गया है.

उदाहरण:

#anchored {
 position-try-options: flip-block;
 container-type: anchored;
}

@container anchored(fallback: flip-block) {
  #anchored > .arrow {
    --arrow-rotation: 180deg;
   }
}

Chrome 143 से ऐंकर की गई कंटेनर क्वेरी की मदद से फ़ॉलबैक पोज़िशन का पता लगाना लेख में इसके बारे में ज़्यादा जानें.

EditContext: TextFormat underlineStyle और underlineThickness

Chromium ने EditContext API को एक गड़बड़ी के साथ शिप किया है. इसमें EditContext/textformatupdate_event से मिले TextFormat ऑब्जेक्ट, underlineStyle और underlineThickness प्रॉपर्टी के लिए गलत वैल्यू देता है. Chromium में, इसकी संभावित वैल्यू None, Solid, Dotted, Dashed, Squiggle और None, Thin, Thick हैं. हालांकि, EditContext स्पेसिफ़िकेशन के मुताबिक, उन्हें none, solid, dotted, dashed, wavy और none, thin, thick होना चाहिए.

Web APIs

JavaScript DOM API में ज़्यादा वर्णों का इस्तेमाल करने की अनुमति दें

एचटीएमएल पार्सर, एलिमेंट और एट्रिब्यूट को हमेशा (या लंबे समय से) कई तरह के मान्य वर्ण और नाम इस्तेमाल करने की अनुमति देता है. हालांकि, एक ही तरह के एलिमेंट और एट्रिब्यूट बनाने के लिए JavaScript DOM API, ज़्यादा सख्त होते हैं और पार्सर से मेल नहीं खाते.

इस बदलाव से, JavaScript DOM API की पुष्टि करने की प्रोसेस को आसान बनाया गया है, ताकि यह एचटीएमएल पार्सर से मेल खा सके.

इस बारे में ज़्यादा जानकारी यहां दी गई है: github.com/whatwg/dom/issues/849

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

अनुमान लगाने के नियम: मोबाइल पर 'ईगर' मोड को बेहतर बनाया गया

मोबाइल पर, 'eager' ईगरनेस के लिए प्रीफ़ेच और प्रीरेंडर स्पेकुलेशन के नियम अब तब ट्रिगर होते हैं, जब एचटीएमएल ऐंकर एलिमेंट कुछ समय के लिए व्यूपोर्ट में होते हैं.

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

सीएसएस प्रॉपर्टी font-language-override लागू करना

इस सुविधा की मदद से, Chromium में font-language-override सीएसएस प्रॉपर्टी का इस्तेमाल किया जा सकता है. इस प्रॉपर्टी की मदद से डेवलपर, OpenType ग्लिफ़ के बदले में इस्तेमाल की जाने वाली सिस्टम की भाषा को बदल सकते हैं. इसके लिए, उन्हें सीएसएस में सीधे तौर पर चार वर्णों वाला भाषा टैग डालना होगा.

इससे टाइपोग्राफ़िक कंट्रोल को बेहतर तरीके से मैनेज किया जा सकता है. यह कई भाषाओं में उपलब्ध कॉन्टेंट या भाषा के हिसाब से अलग-अलग ग्लिफ़ वैरिएंट वाले फ़ॉन्ट के लिए फ़ायदेमंद है.

WebGPU: टेक्सचर कॉम्पोनेंट स्वैप करना

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

ICU 77 (यूनिकोड 16 के साथ काम करता है)

यूनिकोड सपोर्ट लाइब्रेरी ICU (इंटरनेशनल कॉम्पोनेंट फ़ॉर यूनिकोड) को वर्शन 74.2 से 77.1 पर अपग्रेड किया गया है. इससे यूनिकोड 16 के लिए सपोर्ट जोड़ा गया है और स्थानीय भाषा के डेटा को अपडेट किया गया है. दो बदलावों से, उन वेब ऐप्लिकेशन को खतरा हो सकता है जो Intl JavaScript API से किसी खास फ़ॉर्मैट का इस्तेमाल करते हैं:

• इटैलियन नंबर फ़ॉर्मैटिंग के डिफ़ॉल्ट फ़ॉर्मैट में अब चार अंकों की संख्याओं के लिए, हज़ार के सेपरेटर को शामिल नहीं किया जाता है. उदाहरण के लिए, new Intl.NumberFormat("it").format(1234) "1.234" के बजाय "1234" दिखाता है. Intl.NumberFormat कंस्ट्रक्टर के लिए useGrouping पैरामीटर का इस्तेमाल करके, पुराने तरीके से काम किया जा सकता है.
• अंग्रेज़ी की कुछ भाषाओं (जैसे, en-AU, en-GB, और en-IN) में, हफ़्ते के दिनों के पूरे नाम के बाद कॉमा जोड़ा गया था. इससे "Saturday 30 April 2011" बदलकर "Saturday, 30 April 2011" हो गया था. वेब ऐप्लिकेशन को तारीखों के सटीक फ़ॉर्मैट पर भरोसा नहीं करना चाहिए.
• Intl और RegExp (V8): कई छोटे-छोटे बदलाव किए गए हैं. इटैलियन नंबर फ़ॉर्मैट में बदलाव करना सबसे ज़्यादा जोखिम भरा होता है. इसके लिए, एक खास फ़्लैग होता है.
• IDNA: इस अपग्रेड से आम तौर पर ज़्यादा सुविधाएं मिलती हैं. साथ ही, WPT में टेस्ट के कुल नतीजे बेहतर होते हैं.
• टेक्स्ट सेगमेंटेशन: सबसे अहम बदलाव यह है कि word-break: auto-phrase का इस्तेमाल करने पर, जापानी भाषा में लाइन तोड़ने की सुविधा को बेहतर बनाया गया है. यह https://chromestatus.com/feature/5133892532568064 से जुड़ा है.

insertFromPaste, insertFromDrop, और insertReplacementText इनपुट इवेंट के लिए DataTransfer प्रॉपर्टी

यह सुविधा, इनपुट इवेंट पर dataTransfer प्रॉपर्टी को भरती है. इसमें insertFromPaste, insertFromDrop, और insertReplacementText के inputType शामिल होते हैं. इससे contenteditable एलिमेंट में बदलाव करते समय, क्लिपबोर्ड और ड्रैग-ड्रॉप किए गए डेटा को ऐक्सेस किया जा सकता है.

dataTransfer ऑब्जेक्ट में वही डेटा होता है जो beforeinput इवेंट के दौरान उपलब्ध था.

यह सुविधा सिर्फ़ contenteditable एलिमेंट पर लागू होती है. फ़ॉर्म कंट्रोल (textarea, input) के लिए, व्यवहार में कोई बदलाव नहीं होता. data प्रॉपर्टी में डाला गया टेक्स्ट होता है और dataTransfer शून्य रहता है. Safari और Firefox, दोनों में यह सुविधा पहले से उपलब्ध है. Chrome में इस सुविधा को अपनाने से, अलग-अलग ब्राउज़र के बीच काम करने की क्षमता बढ़ती है. इससे वेब लेखकों को बेहतर अनुभव मिलता है.

FedCM—Support Structured JSON Responses from IdPs

इस सुविधा की मदद से, आइडेंटिटी प्रोवाइडर (IdP), id_assertion_endpoint के ज़रिए, भरोसा करने वाली पार्टियों (आरपी) को सादे स्ट्रिंग के बजाय स्ट्रक्चर्ड JSON ऑब्जेक्ट भेज सकते हैं.

इस बदलाव से, डेवलपर के लिए इंटिग्रेशन आसान हो जाता है. ऐसा इसलिए, क्योंकि अब उन्हें JSON स्ट्रिंग को मैन्युअल तरीके से क्रम से लगाने और पार्स करने की ज़रूरत नहीं पड़ती. यह ज़्यादा डाइनैमिक और फ़्लेक्सिबल पुष्टि करने की प्रोसेस उपलब्ध कराता है. इससे आरपी, जटिल जवाबों को सीधे तौर पर समझ पाते हैं. साथ ही, यह OAuth2, OIDC या IndieAuth जैसे अलग-अलग प्रोटोकॉल के साथ काम करता है. इसके लिए, आउट-ऑफ़-बैंड समझौते की ज़रूरत नहीं होती.

WebTransport ऐप्लिकेशन प्रोटोकॉल नेगोशिएशन

WebTransport ऐप्लिकेशन प्रोटोकॉल नेगोशिएशन की मदद से, WebTransport हैंडशेक के दौरान वेब ऐप्लिकेशन के इस्तेमाल किए गए प्रोटोकॉल पर बातचीत की जा सकती है.

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

आइसोलेटेड वेब ऐप्लिकेशन के लिए Web Smart Card API

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

एडमिन, इस एपीआई की उपलब्धता को दो तरीकों से कंट्रोल कर सकते हैं:

• दुनिया भर में—DefaultSmartCardConnectSetting नीति का इस्तेमाल करके
• हर ऐप्लिकेशन के लिए—SmartCardConnectAllowedForUrls और SmartCardConnectBlockedForUrls नीतियों का इस्तेमाल करके

वेब ऐप्लिकेशन मेनिफ़ेस्ट: अपडेट करने की ज़रूरी शर्तें बताएं. साथ ही, आइकॉन के यूआरएल के लिए Cache-Control: immutable सेट करें

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

ज़्यादा डेटा इस्तेमाल करने वाले विज्ञापनों को रोकने की सुविधा: एम्बेड किए गए फ़्रेम को भेजी गई रिपोर्ट

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

ऑरिजिन ट्रायल चल रहे हैं

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

Digital Credentials API (सर्टिफ़िकेट जारी करने में मदद करता है)

इस सुविधा की मदद से, क्रेडेंशियल जारी करने वाली वेबसाइटें (जैसे, कोई यूनिवर्सिटी, सरकारी एजेंसी या बैंक) सीधे तौर पर किसी व्यक्ति के मोबाइल वॉलेट ऐप्लिकेशन में डिजिटल क्रेडेंशियल प्रोविज़निंग (जारी करने) की प्रोसेस शुरू कर सकती हैं. इससे यह प्रोसेस सुरक्षित तरीके से पूरी होती है. Android पर, यह सुविधा Android IdentityCredential CredMan सिस्टम (Credential Manager) का इस्तेमाल करती है. डेस्कटॉप पर, यह CTAP प्रोटोकॉल के साथ-साथ, अलग-अलग डिवाइसों पर काम करने वाले तरीकों का इस्तेमाल करता है. यह डिजिटल क्रेडेंशियल दिखाने के लिए, अलग-अलग डिवाइसों पर काम करने वाले फ़्लो की तरह ही होता है.

टीसीपी सॉकेट पूल की सीमा को रैंडम तरीके से सेट करना

Chrome पर कनेक्शन पूल के साइज़ की सीमाओं का फ़ायदा उठाकर, आपको क्रॉस-साइट स्टेट के बारे में जानकारी मिल सकती है. इसके बिना, इस जानकारी को ऐक्सेस नहीं किया जा सकता. खास तौर पर, कुछ आंकड़ों के आधार पर यह पता लगाया जा सकता है कि उपयोगकर्ता ने लॉगिन किया है या नहीं, उसने कौन-कौनसे पेज देखे हैं या Gmail के इनबॉक्स में कोई ईमेल मौजूद है या नहीं.

इस समस्या को कम करने के लिए, टीसीपी सॉकेट पूल को सीमित करने के तरीके में रैंडम तरीके से बदलाव किया जाता है. इससे, निगरानी करने वाली साइट इस जानकारी का अनुमान नहीं लगा पाती.

बंद की गई और हटाई गई सुविधाएं

Chrome के इस वर्शन में, इन सुविधाओं को बंद कर दिया गया है और इन्हें हटा दिया गया है. ChromeStatus.com पर जाकर, बंद की जाने वाली सुविधाओं, फ़िलहाल बंद की गई सुविधाओं, और पहले हटाई गई सुविधाओं की सूचियां देखें.

Chrome के इस वर्शन में, दो सुविधाएं बंद कर दी गई हैं

Intl Locale Info के गैटर बंद करना

Intl Locale Info API, ECMAScript TC39 का तीसरा स्टेज वाला प्रस्ताव है. इसका मकसद, Intl.Locale ऑब्जेक्ट को बेहतर बनाना है. इसके लिए, यह स्थानीय भाषा की जानकारी दिखाता है. जैसे, हफ़्ते का डेटा (हफ़्ते का पहला दिन, सप्ताहांत शुरू होने का दिन, सप्ताहांत खत्म होने का दिन, पहले हफ़्ते का सबसे कम दिन) और स्थानीय भाषा में इस्तेमाल होने वाला टेक्स्ट डायरेक्शन आवर साइकल.

इस सुविधा को Chrome 99 में लागू किया गया था. हालांकि, बाद में तीसरे चरण में प्रस्ताव में बदलाव किया गया और कई गेटर को फ़ंक्शन में बदल दिया गया. अब इस्तेमाल नहीं किए जा रहे गेटर को हटाना होगा. साथ ही, जिन फ़ंक्शन के नाम बदल दिए गए हैं उन्हें फिर से लॉन्च करना होगा.

XSLT का इस्तेमाल बंद करना

XSLT v1.0, जिसका इस्तेमाल सभी ब्राउज़र करते हैं. इसे 1999 में स्टैंडर्ड बनाया गया था. इस बीच, XSLT को v2.0 और v3.0 में अपडेट किया गया है. इसमें नई सुविधाएं जोड़ी गई हैं और यह ब्राउज़र में लागू किए गए वर्शन से अलग है. इस वजह से, क्लाइंट-साइड XSLT का इस्तेमाल काफ़ी कम हो गया है. साथ ही, JavaScript लाइब्रेरी और फ़्रेमवर्क का इस्तेमाल बढ़ गया है. ये लाइब्रेरी और फ़्रेमवर्क, DOM में बदलाव करने के लिए ज़्यादा विकल्प और बेहतर सुविधाएं देते हैं. JavaScript पर आधारित टेक्नोलॉजी, जैसे कि JSON और React ने वेब ब्राउज़र में इसकी भूमिका को काफ़ी हद तक बदल दिया है.

Chromium, इन बदलावों को प्रोसेस करने के लिए libxslt लाइब्रेरी का इस्तेमाल करता है. हालांकि, 2025 में libxslt को करीब छह महीने तक अपडेट नहीं किया गया था. Libxslt एक जटिल और पुराना C कोडबेस है. इसमें मेमोरी सेफ़्टी से जुड़ी गड़बड़ियां हो सकती हैं. जैसे, बफ़र ओवरफ़्लो. इनकी वजह से, आर्बिट्रेरी कोड एग्ज़ीक्यूट हो सकता है. क्लाइंट-साइड XSLT अब एक खास सुविधा है, जिसका इस्तेमाल बहुत कम किया जाता है. इसलिए, इन लाइब्रेरी का रखरखाव और सुरक्षा जांच, मुख्य JavaScript इंजन की तुलना में कम होती है. हालांकि, ये गैर-भरोसेमंद वेब कॉन्टेंट को प्रोसेस करने के लिए, सीधे तौर पर हमला करने की जगह का प्रतिनिधित्व करते हैं. दरअसल, XSLT की वजह से हाल ही में सुरक्षा से जुड़ी कई गंभीर समस्याएं हुई हैं. इससे ब्राउज़र इस्तेमाल करने वाले लोगों को अब भी खतरा बना हुआ है.

इन वजहों से, Chromium वेब प्लैटफ़ॉर्म से XSLT को बंद करने और हटाने की योजना बना रहा है. WHATWG ने XSLT को बंद करने का फ़ैसला किया है.

इस सुविधा के बंद होने के बारे में ज़्यादा जानकारी और XSLT पर निर्भर रहने पर क्या करना चाहिए, यह जानने के लिए ज़्यादा सुरक्षित ब्राउज़र के लिए XSLT हटाना लेख पढ़ें.