Chrome 142 बीटा

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

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

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

:target-before और :target-after सूडो-क्लास

ये स्यूडो-क्लास, स्क्रोल मार्कर से मेल खाती हैं. ये स्क्रोल मार्कर, एक ही स्क्रोल मार्कर ग्रुप में मौजूद ऐक्टिव मार्कर (:target-current से मेल खाने वाला) से पहले या बाद में होते हैं. इनका क्रम, फ़्लैट ट्री के क्रम के हिसाब से तय होता है:

  • :target-before: यह ग्रुप में फ़्लैट ट्री के क्रम में, चालू मार्कर से पहले आने वाले सभी स्क्रोल मार्कर से मेल खाता है.
  • :target-after: यह ग्रुप में फ़्लैट ट्री के क्रम में, चालू मार्कर के बाद आने वाले सभी स्क्रोल मार्कर से मेल खाता है.

::view-transition एलिमेंट के लिए ऐब्सलूट पोज़िशनिंग

व्यू ट्रांज़िशन, एलिमेंट के स्यूडो सबट्री का इस्तेमाल करते हैं. इसमें ::view-transition ट्रांज़िशन का रूट होता है. पहले, ::view-transition एलिमेंट के लिए position: fixed तय किया गया था. सीएसएस वर्किंग ग्रुप ने इस position: absolute को लागू करने का फ़ैसला किया है. इसलिए, Chrome में अब यह बदलाव दिख रहा है.

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

दस्तावेज़ पर activeViewTransition प्रॉपर्टी

View Transitions API की मदद से, डेवलपर अलग-अलग स्थितियों के बीच विज़ुअल ट्रांज़िशन शुरू कर सकते हैं. मुख्य एसपीए एंट्री पॉइंट startViewTransition() है. यह ट्रांज़िशन ऑब्जेक्ट दिखाता है. इस ऑब्जेक्ट में कई प्रॉमिस और फ़ंक्शन शामिल होते हैं. इनकी मदद से, ट्रांज़िशन की प्रोग्रेस को ट्रैक किया जा सकता है. साथ ही, ट्रांज़िशन में बदलाव किया जा सकता है. उदाहरण के लिए, ट्रांज़िशन को स्किप किया जा सकता है या उसके टाइप में बदलाव किया जा सकता है.

Chrome 142 से, डेवलपर को इस ऑब्जेक्ट को सेव करने की ज़रूरत नहीं है. document.activeViewTransition प्रॉपर्टी इस ऑब्जेक्ट को दिखाती है. अगर कोई ट्रांज़िशन नहीं हो रहा है, तो null प्रॉपर्टी इस ऑब्जेक्ट को दिखाती है.

यह एमपीए ट्रांज़िशन पर भी लागू होता है. इनमें ऑब्जेक्ट सिर्फ़ pageswap और pagereveal इवेंट के ज़रिए उपलब्ध होता है. इस अपडेट में, ट्रांज़िशन की अवधि के लिए इस ऑब्जेक्ट पर document.activeViewTransition सेट किया गया है.

स्टाइल कंटेनर क्वेरी और if() के लिए रेंज सिंटैक्स

Chrome, रेंज सिंटैक्स के लिए सहायता जोड़कर, सीएसएस स्टाइल क्वेरी और if() फ़ंक्शन को बेहतर बनाता है.

यह स्टाइल क्वेरी को, वैल्यू के सटीक मिलान से आगे बढ़ाता है. उदाहरण के लिए, style(--theme: dark). डेवलपर, तुलना ऑपरेटर (जैसे कि > और <) का इस्तेमाल करके, कस्टम प्रॉपर्टी, लिटरल वैल्यू (उदाहरण के लिए, 10 पिक्सल या 25%) की तुलना कर सकते हैं. साथ ही, attr() और env() जैसे सब्स्टिट्यूशन फ़ंक्शन से मिली वैल्यू की तुलना कर सकते हैं. तुलना सही तरीके से करने के लिए, दोनों तरफ़ के डेटा का टाइप एक जैसा होना चाहिए. यह सिर्फ़ इन संख्या टाइप के लिए उपलब्ध है: <length>, <number>, <percentage>, <angle>, <time>, <frequency>, और <resolution>.

उदाहरण:

किसी कस्टम प्रॉपर्टी की तुलना लिटरल लेंथ से करना:

@container style(--inner-padding > 1em) {
  .card {
    border: 2px solid;
  }
}

दो लिटरल वैल्यू की तुलना करना

@container style(1em < 20px) {
  /* ... */
}

if() में स्टाइल रेंज का इस्तेमाल करना:

.item-grid {
  background-color: if(style(attr(data-columns, type<number>) > 2): lightblue; else: white);
}

दिलचस्पी बढ़ाने वाले (interestfor एट्रिब्यूट)

Chrome, <button> और <a> एलिमेंट में interestfor एट्रिब्यूट जोड़ता है. इस एट्रिब्यूट से, एलिमेंट में "दिलचस्पी" से जुड़ी गतिविधियां जोड़ी जाती हैं. जब कोई उपयोगकर्ता एलिमेंट में "दिलचस्पी दिखाता है", तो टारगेट एलिमेंट पर कार्रवाइयां ट्रिगर होती हैं. उदाहरण के लिए, पॉपओवर दिखाना. उपयोगकर्ता एजेंट यह पता लगाता है कि उपयोगकर्ता ने एलिमेंट में "दिलचस्पी दिखाई" है या नहीं. इसके लिए, वह इन तरीकों का इस्तेमाल करता है: एलिमेंट पर पॉइंटर को घुमाना, कीबोर्ड पर खास हॉटकी दबाना या टचस्क्रीन पर एलिमेंट को दबाकर रखना. जब दिलचस्पी दिखाई जाती है या कम हो जाती है, तो टारगेट पर InterestEvent फ़ायर होता है. इसमें पॉपओवर के लिए डिफ़ॉल्ट कार्रवाइयां होती हैं. जैसे, पॉपओवर दिखाना और छिपाना.

font-language-override प्रॉपर्टी

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

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

SVG <a> एलिमेंट में मौजूद download एट्रिब्यूट

Chrome ने SVGAElement इंटरफ़ेस पर download एट्रिब्यूट के लिए सहायता शुरू की है. यह SVG 2 स्पेसिफ़िकेशन के मुताबिक है. download एट्रिब्यूट की मदद से लेखक यह तय कर सकते हैं कि एसवीजी हाइपरलिंक के टारगेट पर नेविगेट करने के बजाय, उसे डाउनलोड किया जाए. यह HTMLAnchorElement में पहले से मौजूद सुविधा की तरह ही काम करता है. यह मुख्य ब्राउज़र पर इंटरऑपरेबिलिटी को बढ़ावा देता है. साथ ही, एचटीएमएल और एसवीजी <a> एलिमेंट के बीच एक जैसा व्यवहार पक्का करता है. इससे डेवलपर के अनुभव और उपयोगकर्ता की उम्मीदों को बेहतर बनाने में मदद मिलती है.

चुनिंदा एलिमेंट रेंडरिंग मोड के लिए, मोबाइल और डेस्कटॉप पर एक जैसा अनुभव

size और multiple एट्रिब्यूट का इस्तेमाल करके, <select> एलिमेंट को पेज पर मौजूद लिस्टबॉक्स या पॉप-अप वाले बटन के तौर पर रेंडर किया जा सकता है. हालांकि, ये मोड मोबाइल और डेस्कटॉप Chrome पर एक साथ उपलब्ध नहीं होते. मोबाइल पर, पेज में मौजूद लिस्टबॉक्स को रेंडर करने की सुविधा उपलब्ध नहीं है. साथ ही, जब multiple एट्रिब्यूट मौजूद होता है, तब डेस्कटॉप पर पॉप-अप वाला बटन उपलब्ध नहीं होता.

इस अपडेट के बाद, मोबाइल पर लिस्टबॉक्स और डेस्कटॉप पर एक से ज़्यादा आइटम चुनने वाला पॉप-अप जुड़ जाएगा. साथ ही, यह पक्का किया जाएगा कि size और multiple एट्रिब्यूट के साथ ऑप्ट-इन करने पर, मोबाइल और डेस्कटॉप पर एक ही रेंडरिंग मोड दिखे. बदलावों के बारे में जानकारी यहां दी गई है:

  • जब size एट्रिब्यूट की वैल्यू 1 से ज़्यादा होती है, तब हमेशा पेज पर रेंडरिंग का इस्तेमाल किया जाता है. मोबाइल डिवाइसों पर, पहले इस सेटिंग को अनदेखा कर दिया जाता था.
  • size एट्रिब्यूट सेट न होने पर, multiple एट्रिब्यूट का इस्तेमाल करके पेज पर रेंडरिंग की जाती है. मोबाइल डिवाइसों पर, पहले पेज पर मौजूद लिस्टबॉक्स के बजाय पॉप-अप का इस्तेमाल किया जाता था.
  • multiple एट्रिब्यूट को size=1 पर सेट करने पर, पॉप-अप का इस्तेमाल किया जाता है. डेस्कटॉप डिवाइसों पर, पहले पेज पर मौजूद लिस्टबॉक्स का इस्तेमाल किया जाता था.

एक ही ऑरिजिन वाले रेंडरर से शुरू किए गए नेविगेशन के दौरान, उपयोगकर्ता के ऐक्टिवेशन की स्थिति बनी रहती है

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

इसमें ब्राउज़र से शुरू किए गए नेविगेशन के अनुरोध शामिल नहीं हैं. जैसे, फिर से लोड करना, इतिहास में नेविगेट करना, पता बार में टाइप किया गया यूआरएल वगैरह.

Web APIs

WebGPU: primitive_index सुविधा

WebGPU में एक नई वैकल्पिक सुविधा जोड़ी गई है. इससे एक नया WGSL शेडर बिल्ट-इन, primitive_index दिखता है. यह सुविधा, vertex_index और instance_index बिल्ट-इन की तरह ही, काम करने वाले हार्डवेयर पर फ़्रैगमेंट शेडर के लिए, हर प्रिमिटिव इंडेक्स उपलब्ध कराती है. प्रिमिटिव इंडेक्स, वर्चुअल ज्यामिति जैसी बेहतर ग्राफ़िकल तकनीकों के लिए फ़ायदेमंद होता है.

WebGPU: टेक्सचर फ़ॉर्मैट टियर1 और टियर2

रेंडर अटैचमेंट, ब्लेंडिंग, मल्टीसैंपलिंग, रिज़ॉल्व, और storage_binding जैसी सुविधाओं के साथ, जीपीयू टेक्सचर फ़ॉर्मैट के लिए सहायता बढ़ाएं.

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

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

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

यह सुविधा सिर्फ़ contenteditable एलिमेंट पर लागू होती है. फ़ॉर्म कंट्रोल (textarea, input) के लिए, यह सुविधा पहले की तरह काम करती रहेगी.

इस प्रॉपर्टी की मदद से, Chrome को Safari और Firefox के साथ इंटरऑपरेबल बनाया जा सकता है.

मीडिया सेशन: enterpictureinpicture कार्रवाई की जानकारी में वजह जोड़ें

यह Media Session API में, enterpictureinpicture कार्रवाई को भेजे गए MediaSessionActionDetails में enterPictureInPictureReason जोड़ता है. इससे डेवलपर, enterpictureinpicture उपयोगकर्ता की ओर से साफ़ तौर पर ट्रिगर की गई कार्रवाइयों (उदाहरण के लिए, उपयोगकर्ता एजेंट में मौजूद बटन से) और enterpictureinpicture उपयोगकर्ता एजेंट की ओर से अपने-आप ट्रिगर की गई कार्रवाइयों के बीच अंतर कर सकते हैं. ऐसा इसलिए होता है, क्योंकि कॉन्टेंट दिखना बंद हो जाता है.

Web Speech API में कॉन्टेक्स्ट के हिसाब से पूर्वाग्रह को कम करना

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

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

JSON मॉड्यूल के लिए, *+json MIME टोकन की ज़्यादा सख्त पुष्टि

ऐसे JSON मॉड्यूल स्क्रिप्ट रिस्पॉन्स को अस्वीकार करें जिनके MIME टाइप के टाइप या सबटाइप में, *+json से मैच होने पर नॉन-एचटीटीपी टोकन कोड पॉइंट (उदाहरण के लिए, स्पेस) शामिल हों. यह MIME Sniffing की खास बातों और अन्य इंजन के मुताबिक है. यह Interop2025 के मॉड्यूल फ़ोकस एरिया का हिस्सा है.

FedCM—यूज़र इंटरफ़ेस (यूआई) में तीसरे पक्ष के iframe ऑरिजिन दिखाने की सुविधा

Chrome 142 से पहले, FedCM हमेशा अपने यूज़र इंटरफ़ेस (यूआई) में टॉप-लेवल साइट दिखाता था.

यह तब बेहतर तरीके से काम करता है, जब iframe कॉन्सेप्ट के हिसाब से पहले पक्ष (ग्राहक) का हो. उदाहरण के लिए, foo.com के पास foostatic.com iframe हो सकता है, जो उपयोगकर्ता के लिए काम का नहीं है.

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

ऑरिजिन-की आधारित प्रोसेस आइसोलेशन

यह कुकी, प्रोसेस आइसोलेशन की नीति को किसी साइट (उदाहरण के लिए, example.com) के लिए प्रोसेस लॉक करने से बदलकर, किसी खास ऑरिजिन (उदाहरण के लिए, foo.example.com) के लिए प्रोसेस लॉक करने पर सेट करती है.

सुरक्षा को और बेहतर बनाने के लिए, Chrome "ऑरिजिन आइसोलेशन" नाम के प्रोसेस आइसोलेशन मॉडल पर स्विच कर रहा है. Chrome, "साइट आइसोलेशन" का इस्तेमाल करता था. इससे एक ही साइट के अलग-अलग ऑरिजिन, जैसे कि a.example.com और b.example.com, को एक ही रेंडरर प्रोसेस में ग्रुप किया जाता था.

ऑरिजिन आइसोलेशन की मदद से, हर ऑरिजिन (जैसे, https://foo.example.com) को उसके रेंडरर प्रोसेस में आइसोलेट किया जाता है. यह Chrome के सुरक्षा आर्किटेक्चर को बेहतर बनाता है. इसके लिए, यह प्रोसेस बाउंड्री को वेब के मूल ऑरिजिन-आधारित सुरक्षा मॉडल के साथ अलाइन करता है. इससे साइटों में संभावित कमज़ोरियों से ज़्यादा सुरक्षा मिलती है.

pointerrawupdate इवेंट को सिर्फ़ सुरक्षित कॉन्टेक्स्ट में दिखाया जाता है

PointerEvents स्पेसिफ़िकेशन ने 2020 में, pointerrawupdate को सुरक्षित कॉन्टेक्स्ट तक सीमित कर दिया था. इससे असुरक्षित कॉन्टेक्स्ट से इवेंट फ़ायरिंग और ग्लोबल इवेंट लिसनर, दोनों को छिपा दिया गया था. इस अपडेट के बाद, Chrome अपडेट किए गए स्पेसिफ़िकेशन के मुताबिक काम करता है. साथ ही, यह अन्य मुख्य ब्राउज़र के साथ मिलकर काम कर सकता है.

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

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

डिवाइस बाउंड सेशन के क्रेडेंशियल

यह वेबसाइटों के लिए, किसी सेशन को सुरक्षित तरीके से एक डिवाइस से बाइंड करने का तरीका है.

इससे सर्वर, किसी सेशन को डिवाइस से सुरक्षित तरीके से बाइंड कर पाते हैं. जब सर्वर अनुरोध करता है, तो ब्राउज़र समय-समय पर सेशन को रिन्यू करता है. इसके लिए, ब्राउज़र को निजी कुंजी के मालिकाना हक का सबूत देना होता है.

हर टॉप-लेवल साइट के लिए टीसीपी सॉकेट पूल

इस एक्सपेरिमेंट में, हर प्रोफ़ाइल के लिए टीसीपी सॉकेट पूल के साइज़ को 256 (डिफ़ॉल्ट) से बदलकर 513 करने के असर का आकलन किया जाता है. साथ ही, हर टॉप-लेवल साइट के लिए 256 की कैप जोड़ी जाती है, ताकि यह पक्का किया जा सके कि दो टैब पूल को खत्म न कर सकें. हर प्रोफ़ाइल के लिए सीमा को 512 तक बढ़ाने की संभावना का अध्ययन किया गया और इससे कोई नकारात्मक नतीजा नहीं मिला. हर टॉप-लेवल साइट के लिए 256 की सीमा, हर प्रोफ़ाइल के लिए डिफ़ॉल्ट सीमा के बराबर होती है. इसलिए, इससे परफ़ॉर्मेंस पर बुरा असर नहीं पड़ना चाहिए. ये सीमाएं, WebSocket पूल और सामान्य (एचटीटीपी) सॉकेट पूल के लिए अलग-अलग लागू की जाती हैं.

अगर कोई बुरा असर नहीं पड़ता है, तो इस एक्सपेरिमेंट को सीधे तौर पर लॉन्च किया जाएगा.