पब्लिश करने की तारीख: 5 फ़रवरी, 2025
यहां दिए गए बदलाव, Android, ChromeOS, Linux, macOS, और Windows के लिए Chrome के बीटा चैनल की सबसे नई रिलीज़ पर लागू होते हैं. हालांकि, अगर किसी बदलाव के बारे में अलग से जानकारी दी गई है, तो वह जानकारी लागू होगी. यहां दी गई सुविधाओं के बारे में ज़्यादा जानने के लिए, दिए गए लिंक पर क्लिक करें या ChromeStatus.com पर मौजूद सूची देखें. Chrome 134, 5 फ़रवरी, 2025 से बीटा वर्शन के तौर पर उपलब्ध है. डेस्कटॉप के लिए, Google.com से या Android पर Google Play Store से, सबसे नया वर्शन डाउनलोड किया जा सकता है.
सीएसएस
इस रिलीज़ में, पांच नई सीएसएस और यूज़र इंटरफ़ेस (यूआई) सुविधाएं जोड़ी गई हैं.
सीएसएस की dynamic-range-limit प्रॉपर्टी
इस कुकी की मदद से, पेज पर एचडीआर कॉन्टेंट की ज़्यादा से ज़्यादा चमक को सीमित किया जा सकता है.
पसंद के मुताबिक बनाया जा सकने वाला <select> एलिमेंट
appearance की base-select वैल्यू के साथ नए वर्शन का इस्तेमाल करके, एचटीएमएल <select> एलिमेंट को पसंद के मुताबिक बनाने की सुविधा जोड़ी गई है. ऑप्ट-इन करने के बाद, इमेज जैसा रिच कॉन्टेंट जोड़ा जा सकता है. साथ ही, विकल्पों को स्टाइल भी किया जा सकता है.
डायलॉग लाइट को खारिज करना
Popover API की एक अच्छी सुविधा यह है कि यह पॉपओवर को बंद करने के लिए, लाइट डिसमिस बिहेवियर का इस्तेमाल करता है. यह सुविधा, <dialog> में भी उपलब्ध है. closedby एट्रिब्यूट की नई वैल्यू से, इस सुविधा के काम करने के तरीके को कंट्रोल किया जा सकता है:
<dialog closedby=none>: उपयोगकर्ता की ओर से किसी भी डायलॉग को बंद नहीं किया गया है.<dialog closedby=closerequest>:ESC(या बंद करने का कोई अन्य ट्रिगर) दबाने पर, डायलॉग बंद हो जाता है.<dialog closedby=any>: डायलॉग बॉक्स के बाहर क्लिक करने या ESC दबाने से, डायलॉग बॉक्स बंद हो जाता है. यहpopover=autoके जैसा ही काम करता है.
सीएसएस हाइलाइट इनहेरिटेंस
सीएसएस हाइलाइट इनहेरिटेंस की मदद से, सीएसएस हाइलाइट सूडो-क्लास, जैसे कि ::selection और ::highlight, अपनी प्रॉपर्टी को सूडो हाइलाइट चेन से इनहेरिट करती हैं. ये प्रॉपर्टी, एलिमेंट चेन से इनहेरिट नहीं की जाती हैं. इससे हाइलाइट में प्रॉपर्टी इनहेरिटेंस के लिए, ज़्यादा बेहतर मॉडल तैयार किया जा सकता है.
ज़्यादा जानने के लिए, Igalia के Stephen Chenney की लिखी गई ब्लॉग पोस्ट Inheritance changes for CSS selection styling पढ़ें.
:has-slotted स्यूडो-क्लास
:has-slotted छद्म क्लास, स्लॉट किए गए कॉन्टेंट वाले स्लॉट एलिमेंट को दिखाती है. जैसे, टेक्स्ट नोड या एलिमेंट. इसका इस्तेमाल, इस आधार पर एलिमेंट को स्टाइल करने के लिए किया जा सकता है कि वे स्लॉट फ़ॉलबैक कॉन्टेंट का इस्तेमाल कर रहे हैं या नहीं.
Web APIs
एट्रिब्यूशन रिपोर्टिंग सुविधा: ट्रिगर कॉन्टेक्स्ट आईडी के शून्य नहीं होने पर, एग्रीगेट की जा सकने वाली रिपोर्ट की सीमा हटाएं
यह बदलाव, एपीआई कॉलर से मिले सुझाव, राय या शिकायत के आधार पर किया गया है. साथ ही, कुछ उपयोगकर्ता फ़्लो के लिए ज़्यादा कन्वर्ज़न इवेंट मेज़र करने की ज़रूरत को ध्यान में रखकर किया गया है.
फ़िलहाल, एपीआई में एक सीमा है. इसके तहत, सोर्स रजिस्ट्रेशन के हिसाब से ज़्यादा से ज़्यादा 20 एग्रीगेट की जा सकने वाली रिपोर्ट जनरेट की जा सकती हैं. यह उन मामलों में पाबंदी लगाता है जहां उपयोगकर्ता का यूज़र जर्नी लंबा हो सकता है. इस बदलाव से, एग्रीगेट की जा सकने वाली रिपोर्ट की सीमा हट जाती है. ऐसा तब होता है, जब रजिस्ट्रेशन के दौरान ट्रिगर कॉन्टेक्स्ट आईडी दिया जाता है. इस सीमा को सिर्फ़ तब हटाया जा सकता है, जब ट्रिगर कॉन्टेक्स्ट आईडी की जानकारी दी गई हो. ऐसा इसलिए, क्योंकि जब इसकी जानकारी दी जाती है, तो एपीआई ज़्यादा संख्या में शून्य रिपोर्ट लागू करता है. इससे रिपोर्ट की संख्या के ज़रिए, एक से ज़्यादा साइटों पर जानकारी लीक होने से रोकने में मदद मिलती है.
इसके अलावा, एग्रीगेट की जा सकने वाली रिपोर्ट पर अब भी अन्य सीमाएं लागू होंगी. इनसे, मेज़र की जा सकने वाली जानकारी की कुल मात्रा सीमित हो जाती है. जैसे, हर सोर्स के लिए L1 कॉन्ट्रिब्यूशन बजट (65,536) और एट्रिब्यूशन रेट लिमिट.
BLOB यूआरएल का पार्टिशन करना: फ़ेचिंग/नेविगेशन
यह कुकी, स्टोरेज पार्टीशनिंग के तहत काम करती है. यह स्टोरेज कुंजी (टॉप-लेवल साइट, फ़्रेम ऑरिजिन, और has-cross-site-ancestor बूलियन) के हिसाब से, BLOB यूआरएल के ऐक्सेस को पार्टीशन करती है. हालांकि, टॉप-लेवल नेविगेशन को सिर्फ़ फ़्रेम ऑरिजिन के हिसाब से पार्टीशन किया जाएगा. यह तरीका, फ़िलहाल Firefox और Safari, दोनों में इस्तेमाल किए जा रहे तरीके जैसा ही है. साथ ही, यह Blob यूआरएल के इस्तेमाल को Storage Partitioning के तहत, अन्य स्टोरेज एपीआई के इस्तेमाल की पार्टीशनिंग स्कीम के साथ अलाइन करता है. इसके अलावा, Chrome, रेंडरर की ओर से शुरू किए गए टॉप-लेवल नेविगेशन पर noopener को लागू करेगा. यह उन BLOB यूआरएल के लिए होगा जहां संबंधित साइट, नेविगेशन करने वाली टॉप-लेवल साइट के साथ क्रॉस-साइट है. इससे Chrome, Safari के जैसा ही काम करेगा. साथ ही, इन बदलावों को दिखाने के लिए ज़रूरी स्पेसिफ़िकेशन अपडेट कर दिए गए हैं.
PartitionedBlobURLUsage नीति सेट करके, इस बदलाव को कुछ समय के लिए पहले जैसा किया जा सकता है. जब स्टोरेज पार्टिशनिंग से जुड़ी अन्य एंटरप्राइज़ नीतियां काम नहीं करेंगी, तब यह नीति भी काम नहीं करेगी.
Document-Policy: expect-no-linked-resources
Document-Policy में मौजूद expect-no-linked-resources कॉन्फ़िगरेशन पॉइंट की मदद से, कोई दस्तावेज़ उपयोगकर्ता एजेंट को यह जानकारी दे सकता है कि वह अपनी लोडिंग सीक्वेंस को बेहतर तरीके से ऑप्टिमाइज़ करे. जैसे, स्पेकुलेटिव पार्सिंग के डिफ़ॉल्ट व्यवहार का इस्तेमाल न करना. इसे प्रीलोड स्कैनर भी कहा जाता है.
उपयोगकर्ता एजेंट, एचटीएमएल की स्पेकुलेटिव पार्सिंग लागू करते हैं. इससे एचटीएमएल मार्कअप में मौजूद संसाधनों को स्पेकुलेटिव तरीके से फ़ेच किया जा सकता है. इससे पेज को तेज़ी से लोड करने में मदद मिलती है. वेब पर मौजूद ज़्यादातर पेजों के लिए, ऑप्टिमाइज़ेशन फ़ायदेमंद होता है. इन पेजों में, एचटीएमएल मार्कअप में रिसॉर्स के बारे में बताया गया होता है. साथ ही, ऐसे रिसॉर्स का पता लगाने के लिए चुकाई गई कीमत, एक अच्छा ट्रेडऑफ़ है. हालांकि, इन स्थितियों में एचटीएमएल पार्स करने में लगने वाले समय की तुलना में, परफ़ॉर्मेंस पर असर पड़ सकता है. ऐसा इसलिए होता है, ताकि फ़ेच किए जाने वाले सब-रिसॉर्स का पता लगाया जा सके:
- ऐसे पेज जिनके एचटीएमएल में कोई रिसॉर्स नहीं बताया गया है.
- बड़े एचटीएमएल पेज, जिनमें बहुत कम या कोई भी संसाधन लोड नहीं होता. ये पेज, प्रीलोडिंग के लिए उपलब्ध अन्य तरीकों का इस्तेमाल करके, संसाधनों को साफ़ तौर पर प्रीलोड कर सकते हैं.
expect-no-linked-resources Document-Policy, User Agent को यह जानकारी देता है कि वह इस तरह के सब-रिसोर्स का पता लगाने में लगने वाले समय को ऑप्टिमाइज़ कर सकता है.
संसाधन को मैनेज करने की सुविधा (एसिंक्रोनस और सिंक्रोनस)
ये सुविधाएं, सॉफ़्टवेयर डेवलपमेंट में एक सामान्य पैटर्न को ठीक करती हैं. यह पैटर्न, अलग-अलग संसाधनों (जैसे कि मेमोरी और I/O) के लाइफ़टाइम और मैनेजमेंट से जुड़ा है. इस पैटर्न में आम तौर पर, किसी संसाधन को असाइन करना और अहम संसाधनों को साफ़ तौर पर रिलीज़ करने की सुविधा शामिल होती है.
मेज़रमेंट और प्रज़ेंटेशन के विकल्पों के साथ काम करने के लिए, console.timeStamp एपीआई को बेहतर बनाया गया है
यह सुविधा, console.timeStamp() एपीआई को पुराने सिस्टम के साथ काम करने वाले तरीके से बढ़ाती है. इससे ऐप्लिकेशन को इंस्ट्रुमेंट करने और DevTools में परफ़ॉर्मेंस पैनल को टाइमिंग डेटा दिखाने का बेहतर तरीका मिलता है.
एपीआई की मदद से जोड़ी गई टाइमिंग की एंट्री में, कस्टम टाइमस्टैंप, अवधि, और प्रज़ेंटेशन के विकल्प (ट्रैक, स्विमलेन, और रंग) हो सकते हैं.
OffscreenCanvas getContextAttributes
CanvasRenderingContext2D से OffscreenCanvasRenderingContext2D तक getContextAttributes इंटरफ़ेस जोड़ता है.
Private Aggregation API: Shared Storage API को कॉल करने वालों के लिए, हर कॉन्टेक्स्ट के हिसाब से योगदान की सीमाएं
इस कुकी की मदद से, Shared Storage का इस्तेमाल करने वाले लोग, Private Aggregation की हर रिपोर्ट के लिए योगदान की संख्या को पसंद के मुताबिक बना सकते हैं.
इस सुविधा की मदद से, Shared Storage का इस्तेमाल करने वाले लोग, हर कॉन्टेक्स्ट के हिसाब से योगदान की सीमाएं कॉन्फ़िगर कर सकते हैं. इसके लिए, उन्हें maxContributions नाम के नए फ़ील्ड का इस्तेमाल करना होगा. कॉल करने वाले लोग इस फ़ील्ड को सेट करते हैं, ताकि हर रिपोर्ट में योगदान की डिफ़ॉल्ट संख्या को बदला जा सके. इसमें बड़ी और छोटी, दोनों संख्याओं का इस्तेमाल किया जा सकता है. Chrome, maxContributions की वैल्यू 1 से 1000 के बीच स्वीकार करेगा. इससे ज़्यादा वैल्यू को 1000 माना जाएगा.
पैडिंग की वजह से, हर रिपोर्ट के पेलोड का साइज़, हर रिपोर्ट के लिए चुनी गई योगदानों की संख्या के हिसाब से तय होगा. हमें उम्मीद है कि बड़ी रिपोर्ट का विकल्प चुनने से, एग्रीगेशन सेवा को चलाने की लागत बढ़ जाएगी.
इस सुविधा से, Protected Audience के कॉलर पर कोई असर नहीं पड़ेगा. हालांकि, हम आने वाले समय में Protected Audience की रिपोर्ट के लिए, योगदान की संख्या को पसंद के मुताबिक बनाने की सुविधा जोड़ने का प्लान कर रहे हैं.
PaintCanvas में ImageSmoothingQuality के लिए सहायता
Paint Canvas पर imageSmoothingQuality एट्रिब्यूट के लिए सहायता जोड़ी गई. इससे वेब डेवलपर को इमेज का साइज़ बदलते समय, परफ़ॉर्मेंस के मुकाबले क्वालिटी को चुनने का विकल्प मिलता है.
imageSmoothingQuality के लिए, तीन मान्य विकल्प हैं: low, medium, और high.
WebGPU सबग्रुप
इस सुविधा से, WebGPU में सबग्रुप की सुविधा जोड़ी जाती है. सबग्रुप ऑपरेशन, SIMT ऑपरेशन करते हैं, ताकि इनवॉकेशन के ग्रुप के बीच बेहतर तरीके से कम्यूनिकेशन और डेटा शेयरिंग हो सके. इन कार्रवाइयों का इस्तेमाल, ऐप्लिकेशन की परफ़ॉर्मेंस को बेहतर बनाने के लिए किया जा सकता है. इसके लिए, इंटर-इनवोकेशन कम्यूनिकेशन की वजह से होने वाले मेमोरी ओवरहेड को कम किया जाता है.
नए ऑरिजिन ट्रायल
Chrome 134 में, इन नए ऑरिजिन ट्रायल के लिए ऑप्ट इन किया जा सकता है.
Digital Credential API
आजकल, वेबसाइटें कई तरीकों से मोबाइल वॉलेट ऐप्लिकेशन से क्रेडेंशियल पा सकती हैं. उदाहरण के लिए, कस्टम यूआरएल हैंडलर और क्यूआर कोड स्कैनिंग. इस सुविधा की मदद से साइटें, Android के IdentityCredential CredMan सिस्टम का इस्तेमाल करके, वॉलेट से पहचान की जानकारी का अनुरोध कर सकती हैं. इसे कई क्रेडेंशियल फ़ॉर्मैट (उदाहरण के लिए, ISO mDoc और W3C वेरिफ़ायबल क्रेडेंशियल) के साथ काम करने के लिए बढ़ाया जा सकता है. साथ ही, इससे कई वॉलेट ऐप्लिकेशन इस्तेमाल किए जा सकते हैं. ऐसे तरीके जोड़े जा रहे हैं जिनसे असल दुनिया की पहचान के गलत इस्तेमाल के जोखिम को कम किया जा सके.
Chrome 134 में शुरू हो रहे ऑरिजिन ट्रायल में, डेस्कटॉप प्लैटफ़ॉर्म पर इस एपीआई के लिए सहायता जोड़ी गई है. यहां डेस्कटॉप पर Chrome, Android फ़ोन पर मौजूद डिजिटल वॉलेट के साथ सुरक्षित तरीके से कम्यूनिकेट करेगा, ताकि अनुरोध किए गए क्रेडेंशियल को फ़ेच किया जा सके.
बंद की गई और हटाई गई सुविधाएं
Chrome के इस वर्शन में, यहां दिए गए बदलाव किए गए हैं. ChromeStatus.com पर जाकर, बंद की जाने वाली सुविधाओं, फ़िलहाल बंद की गई सुविधाओं, और पहले हटाई गई सुविधाओं की सूचियां देखें.
Chrome के इस वर्शन में, एक सुविधा हटा दी गई है.
getUserMedia ऑडियो की नॉन-स्टैंडर्ड पाबंदियों को हटाना
Blink, getUserMedia के लिए goog प्रीफ़िक्स वाली कई नॉनस्टैंडर्ड शर्तों का समर्थन करता है. ये शर्तें, शर्तों के सही तरीके से स्टैंडर्ड होने से पहले से लागू हैं.
इनका इस्तेमाल काफ़ी कम हो गया है. अब इनका इस्तेमाल 0.000001% से 0.0009% के बीच होता है. यह सीमा पर निर्भर करता है. साथ ही, Chromium ऑडियो-कैप्चर स्टैक में हुए बदलावों की वजह से, इनमें से कुछ का कोई असर नहीं पड़ता. जल्द ही, आने वाले अन्य बदलावों की वजह से, इनमें से किसी भी बदलाव का कोई असर नहीं पड़ेगा.
हमें नहीं लगता कि इस बदलाव की वजह से, परफ़ॉर्मेंस में कोई बड़ी गिरावट आएगी. इन शर्तों का इस्तेमाल करने वाले ऐप्लिकेशन काम करते रहेंगे. हालांकि, उन्हें डिफ़ॉल्ट सेटिंग के साथ ऑडियो मिलेगा. ऐसा माना जाएगा कि कोई शर्त नहीं दी गई है. वे स्टैंडर्ड कंस्ट्रेंट पर माइग्रेट करने का विकल्प चुन सकते हैं.