Chrome 133 बीटा

Rachel Andrew

पब्लिश करने की तारीख: 15 जनवरी, 2024

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

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

इस वर्शन में, सीएसएस और यूज़र इंटरफ़ेस (यूआई) की सात नई सुविधाएं जोड़ी गई हैं.

सीएसएस का ऐडवांस attr() फ़ंक्शन

इसमें सीएसएस लेवल 5 में बताए गए attr() में सुधार किया गया है. इससे के अलावा, अन्य टाइप इस्तेमाल किए जा सकते हैं. साथ ही, इसका इस्तेमाल सीएसएस की सभी प्रॉपर्टी में किया जा सकता है. इसके अलावा, सूडो-एलिमेंट content के लिए मौजूदा सपोर्ट भी जारी रहेगा.<string>

ज़्यादा जानकारी के लिए, सीएसएस attr() फ़ंक्शन में किया गया अपग्रेड लेख पढ़ें.

सीएसएस की :open सूडो-क्लास

:open सूडो-क्लास, <dialog> और <details> से तब मैच करती है, जब वे खुले हों. इसके अलावा, यह <select> और <input> से तब मैच करती है, जब वे ऐसे मोड में हों जिनमें पिकर मौजूद हो और वह दिख रहा हो.

सीएसएस के स्क्रोल स्टेट कंटेनर क्वेरीज़

कंटेनर क्वेरीज़ का इस्तेमाल करके, कंटेनर के डिसेंडेंट को उनके स्क्रोल स्टेट के आधार पर स्टाइल करें.

क्वेरी कंटेनर, स्क्रोल कंटेनर होता है या ऐसा एलिमेंट होता है जिस पर स्क्रोल कंटेनर की स्क्रोल पोज़िशन का असर पड़ता है. इन स्टेट के बारे में क्वेरी की जा सकती है:

  • stuck: स्टिकी पोज़िशन वाला कंटेनर, स्क्रोल बॉक्स के किसी एक किनारे पर स्टक हो जाता है.
  • snapped: स्क्रोल स्नैप अलाइन किया गया कंटेनर, फ़िलहाल हॉरिज़ॉन्टली या वर्टिकली स्नैप किया गया है.
  • scrollable: क्वेरी की गई दिशा में, स्क्रोल कंटेनर को स्क्रोल किया जा सकता है या नहीं.

नए container-type: scroll-state की मदद से, कंटेनर के बारे में क्वेरी की जा सकती है.

#sticky {
  position: sticky;
  container-type: scroll-state;
}

@container scroll-state(stuck: top) {
  #sticky-child {
    font-size: 75%;
  }
}

ज़्यादा जानकारी के लिए, सीएसएस scroll-state() लेख पढ़ें.

सीएसएस की text-box, text-box-trim, और text-box-edge प्रॉपर्टी

टेक्स्ट कॉन्टेंट का बेहतर बैलेंस पाने के लिए, text-box-trim और text-box-edge प्रॉपर्टी के साथ-साथ, text-box शॉर्टहैंड प्रॉपर्टी का इस्तेमाल किया जा सकता है. इससे टेक्स्ट के वर्टिकल अलाइनमेंट को बेहतर तरीके से कंट्रोल किया जा सकता है.

text-box-trim प्रॉपर्टी से यह तय होता है कि ऊपर या नीचे की ओर से, किन किनारों को ट्रिम करना है. वहीं, text-box-edge प्रॉपर्टी से यह तय होता है कि किनारे को कैसे ट्रिम करना है.

इन प्रॉपर्टी की मदद से, फ़ॉन्ट मेट्रिक का इस्तेमाल करके, वर्टिकल स्पेसिंग को सटीक तरीके से कंट्रोल किया जा सकता है. ज़्यादा जानकारी के लिए, सीएसएस का text-box-trim लेख पढ़ें.

popover एट्रिब्यूट की hint वैल्यू

Popover API, popover एट्रिब्यूट की दो वैल्यू के लिए, व्यवहार तय करता है: auto और manual. इस सुविधा में, तीसरी वैल्यू popover=hint के बारे में बताया गया है. हिंट, आम तौर पर "टूलटिप" टाइप के व्यवहार से जुड़े होते हैं. इनका व्यवहार थोड़ा अलग होता है. मुख्य तौर पर, अंतर यह है कि पॉपओवर के नेस्टेड स्टैक खोलते समय, hint, auto के मुकाबले कम अहमियत रखता है. इसलिए, auto पॉपओवर के मौजूदा स्टैक के खुले रहने के दौरान, किसी दूसरे hint पॉपओवर को खोला जा सकता है.

इसका सबसे अच्छा उदाहरण यह है कि एक <select> पिकर खुला है (popover=auto) और एक होवर-ट्रिगर की गई टूलटिप (popover=hint) दिख रही है. इस कार्रवाई से <select> पिकर बंद नहीं होता.

पॉपओवर इन्वोकर और ऐंकर पोज़िशनिंग में सुधार

popover.showPopover({source}) की मदद से, पॉपओवर के बीच इन्वोकर के संबंध सेट करने का एक ज़रूरी तरीका जोड़ा गया है. इन्वोकर के संबंध, इंप्लिसिट ऐंकर एलिमेंट रेफ़रंस बनाने की सुविधा देते हैं.

इन्वोकर में नेस्ट किए गए पॉपओवर को फिर से इन्वोक नहीं किया जाना चाहिए

यहां दिए गए उदाहरण में, बटन पर क्लिक करने से पॉपओवर सही तरीके से ऐक्टिवेट होता है. हालांकि, इसके बाद पॉपओवर पर क्लिक करने से, पॉपओवर बंद नहीं होना चाहिए.

<button popovertarget=foo>Activate
  <div popover id=foo>Clicking me shouldn't close me</div>
</button>

पहले ऐसा होता था, क्योंकि पॉपओवर पर क्लिक करने से, <button> पर क्लिक करने जैसा असर होता था. इससे इन्वोकर ऐक्टिवेट हो जाता था और पॉपओवर बंद हो जाता था. अब इसे बदलकर, उम्मीद के मुताबिक व्यवहार कर दिया गया है.

वेब एपीआई

Animation.overallProgress

इससे डेवलपर को यह आसानी से और लगातार पता चलता है कि ऐनिमेशन, अपने इटरेटिव प्रोसेस में कितना आगे बढ़ चुका है. साथ ही, इससे कोई फ़र्क़ नहीं पड़ता कि उसकी टाइमलाइन कैसी है. overallProgress प्रॉपर्टी के बिना, आपको मैन्युअल तरीके से यह हिसाब लगाना होता है कि ऐनिमेशन कितना आगे बढ़ चुका है. इसके लिए, आपको ऐनिमेशन के इटरेटिव प्रोसेस की संख्या और यह हिसाब लगाना होता है कि ऐनिमेशन का currentTime, कुल समय का प्रतिशत है (जैसे, स्क्रोल-ड्रिवन ऐनिमेशन के मामले में) या ऐब्सलूट टाइम क्वॉन्टिटी (जैसे, टाइम-ड्रिवन ऐनिमेशन के मामले में).

Atomics ऑब्जेक्ट का pause() तरीका

Atomics नेमस्पेस ऑब्जेक्ट में pause() तरीका जोड़ा गया है, ताकि सीपीयू को यह बताया जा सके कि मौजूदा कोड, स्पिनलॉक को एक्ज़ीक्यूट कर रहा है.

स्क्रिप्ट के लिए, सीएसपी हैश की रिपोर्टिंग

सुरक्षा के मकसद से, अक्सर जटिल वेब ऐप्लिकेशन को उन सब-रिसॉर्स पर नज़र रखनी होती है जिन्हें वे डाउनलोड करते हैं.

खास तौर पर, आने वाले इंडस्ट्री स्टैंडर्ड और सबसे सही तरीकों (उदाहरण के लिए, PCI-DSS v4) के मुताबिक, वेब ऐप्लिकेशन को उन सभी स्क्रिप्ट की इन्वेंट्री रखनी होती है जिन्हें वे डाउनलोड और एक्ज़ीक्यूट करते हैं.

यह सुविधा, सीएसपी और Reporting API पर आधारित है. इसकी मदद से, दस्तावेज़ में लोड किए गए सभी स्क्रिप्ट रिसॉर्स के यूआरएल और हैश (सीओआरएस/सेम-ऑरिजिन के लिए) की रिपोर्ट की जा सकती है.

डीओएम स्टेट-प्रिज़र्विंग मूव

इसमें डीओएम प्रिमिटिव (Node.prototype.moveBefore) जोड़ा गया है. इसकी मदद से, एलिमेंट की स्टेट को रीसेट किए बिना, डीओएम ट्री में एलिमेंट को इधर-उधर ले जाया जा सकता है.

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

  • <iframe> एलिमेंट लोड रहते हैं.
  • ऐक्टिव एलिमेंट पर फ़ोकस बना रहता है.
  • पॉपओवर, फ़ुलस्क्रीन, और मॉडल डायलॉग बॉक्स खुले रहते हैं.
  • सीएसएस ट्रांज़िशन और ऐनिमेशन जारी रहते हैं.

<area> पर attributionsrc एट्रिब्यूट दिखाना

<area> पर attributionsrc एट्रिब्यूट को दिखाने की सुविधा, एट्रिब्यूट के मौजूदा प्रोसेसिंग बिहेवियर के साथ अलाइन की गई है. ऐसा तब भी होता है, जब इसे नहीं दिखाया जाता.

इसके अलावा, <area> पर एट्रिब्यूट को सपोर्ट करना सही है, क्योंकि यह एलिमेंट, नेविगेशन का एक अहम हिस्सा है. साथ ही, Chrome, <a> और window.open के अन्य हिस्सों पर पहले से ही इसे सपोर्ट करता है

एलिमेंट टाइमिंग और एलसीपी में, क्रॉस-ऑरिजिन renderTime को दिखाना (चाहे Timing-Allow-Origin कुछ भी हो)

एलिमेंट टाइमिंग और एलसीपी एंट्री में renderTime एट्रिब्यूट होता है. यह उस पहले फ़्रेम के साथ अलाइन होता है जिसमें कोई इमेज या टेक्स्ट पेंट किया गया था.

फ़िलहाल, क्रॉस-ऑरिजिन इमेज के लिए, इस एट्रिब्यूट को सुरक्षित रखा जाता है. इसके लिए, इमेज रिसॉर्स पर Timing-Allow-Origin हेडर की ज़रूरत होती है. हालांकि, इस पाबंदी से आसानी से बचा जा सकता है. उदाहरण के लिए, एक ही फ़्रेम में सेम-ऑरिजिन और क्रॉस-ऑरिजिन इमेज दिखाकर.

इससे भ्रम की स्थिति पैदा होती है. इसलिए, हम इस पाबंदी को हटाने की योजना बना रहे हैं. इसके बजाय, जब दस्तावेज़, क्रॉस-ऑरिजिन-आइसोलेटेड नहीं होता, तब हम सभी रेंडर टाइम को 4 मिसेकंड तक बढ़ा देंगे. ऐसा लगता है कि यह समय, क्रॉस-ऑरिजिन इमेज के डिकोडिंग-टाइम की किसी भी काम की जानकारी को लीक होने से रोकने के लिए काफ़ी है.

responseStart को पहले जैसा करना और firstResponseHeadersStart को जोड़ना

103 अर्ली हिंट चालू होने पर, रिस्पॉन्स में दो टाइमस्टैंप होते हैं:

  • अर्ली हिंट मिलने पर (103)
  • फ़ाइनल हेडर मिलने पर (जैसे, 200)

Chrome 115 में, इन दोनों टाइमस्टैंप को मेज़र करने के लिए firstInterimResponseStart जोड़ा गया था. साथ ही, हमने responseStart (जो टाइम टू फ़र्स्ट बाइट (टीटीएफ़बी) के लिए इस्तेमाल किया जाता है) का मतलब बदलकर "फ़ाइनल हेडर" कर दिया था. इससे, उन ब्राउज़र और टूल के साथ वेब कंपैटबिलिटी की समस्या पैदा हुई जिनमें इस आम तौर पर इस्तेमाल की जाने वाली मेट्रिक के लिए, ऐसा कोई बदलाव नहीं किया गया था.

Chrome 133 में, इस कंपैटबिलिटी की समस्या को हल करने के लिए, responseStart में किए गए बदलाव को पहले जैसा कर दिया गया है. साथ ही, firstResponseHeadersStart को जोड़ा गया है, ताकि साइटें, फ़ाइनल हेडर मिलने में लगने वाले समय को मेज़र कर सकें. इसके अलावा, टीटीएफ़बी की ओरिजनल डेफ़िनिशन भी बनी रहेगी.

FileSystemObserver इंटरफ़ेस

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

एनर्जी सेवर मोड चालू होने पर फ़्रीज़ होना

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

  • ऑडियो या वीडियो कॉन्फ़्रेंसिंग की सुविधा देता है. इसका पता, माइक्रोफ़ोन, कैमरा या स्क्रीन/विंडो/टैब कैप्चर या 'ओपन' RTCDataChannel या 'लाइव' MediaStreamTrack वाले RTCPeerConnection की पहचान करके लगाया जाता है.
  • किसी बाहरी डिवाइस को कंट्रोल करता है. इसका पता, WebUSB, Web Bluetooth, WebHID या Web Serial के इस्तेमाल से लगाया जाता है.
  • Web Lock या IndexedDB कनेक्शन रखता है, जो किसी दूसरे कनेक्शन पर वर्शन अपडेट या ट्रांज़ैक्शन को ब्लॉक करता है.

फ़्रीज़ करने का मतलब है, एक्ज़ीक्यूशन को रोकना. इसे Page Lifecycle API में आधिकारिक तौर पर तय किया गया है.

एनर्जी सेवर मोड चालू होने पर, सीपीयू के इस्तेमाल की थ्रेशोल्ड को कैलिब्रेट किया जाएगा, ताकि बैकग्राउंड में मौजूद करीब 10% टैब फ़्रीज़ हो जाएं.

एक से ज़्यादा इंपोर्ट मैप

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

इस सुविधा की मदद से, हर दस्तावेज़ के लिए एक से ज़्यादा इंपोर्ट मैप इस्तेमाल किए जा सकते हैं. इसके लिए, उन्हें एक जैसे और तय तरीके से मर्ज किया जाता है.

स्टोरेज ऐक्सेस हेडर

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

ClipboardItem की मदद से, Promise<DOMString> बनाना

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

WebAssembly Memory64

memory64 प्रपोज़ल में, 2^32 बिट से ज़्यादा साइज़ वाली लीनियर WebAssembly मेमोरी के लिए सपोर्ट जोड़ा गया है. इसमें कोई नया निर्देश नहीं दिया गया है. इसके बजाय, मौजूदा निर्देशों को बढ़ाया गया है, ताकि मेमोरी और टेबल के लिए 64-बिट इंडेक्स इस्तेमाल किए जा सकें.

​​वेब ऑथेंटिकेशन एपीआई: PublicKeyCredential getClientCapabilities() तरीका

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

WebGPU: 1-कॉम्पोनेंट वर्टेक्स फ़ॉर्मैट (और unorm8x4-bgra)

इसमें वर्टेक्स के ऐसे फ़ॉर्मैट जोड़े गए हैं जो WebGPU के शुरुआती वर्शन में मौजूद नहीं थे. ऐसा इसलिए, क्योंकि उनमें सपोर्ट नहीं था या macOS के पुराने वर्शन इस्तेमाल किए जा रहे थे. अब किसी भी ब्राउज़र पर, macOS के पुराने वर्शन काम नहीं करते. 1-कॉम्पोनेंट वर्टेक्स फ़ॉर्मैट की मदद से, ऐप्लिकेशन सिर्फ़ ज़रूरी डेटा का अनुरोध कर सकते हैं. पहले, उन्हें 8 और 16-बिट डेटा टाइप के लिए, कम से कम दो गुना ज़्यादा डेटा का अनुरोध करना पड़ता था. unorm8x4-bgra फ़ॉर्मैट की मदद से, BGRA-एनकोडेड वर्टेक्स कलर को लोड करना थोड़ा आसान हो जाता है. साथ ही, इसमें एक ही शेडर का इस्तेमाल किया जा सकता है.

वेब क्रिप्टोग्राफ़ी एपीआई का X25519 एल्गोरिदम

"X25519" एल्गोरिदम, [RFC7748] में बताए गए X25519 फ़ंक्शन का इस्तेमाल करके, की एग्रीमेंट करने के लिए टूल उपलब्ध कराता है. SubtleCrypto इंटरफ़ेस में, "X25519" एल्गोरिदम आइडेंटिफ़ायर का इस्तेमाल करके, लागू किए गए इन ऑपरेशन को ऐक्सेस किया जा सकता है: generateKey, importKey, exportKey, deriveKey, और deriveBits.

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

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

एनर्जी सेवर मोड चालू होने पर फ़्रीज़ होने से ऑप्ट-आउट करना

ऑप्ट-आउट करने के इस ट्रायल की मदद से, साइटें, Chrome 133 में शिप होने वाले एनर्जी सेवर मोड चालू होने पर फ़्रीज़ होने के बिहेवियर से ऑप्ट-आउट कर सकती हैं.

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

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

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

WebGPU की maxInterStageShaderComponents सीमा को बंद करना

maxInterStageShaderComponents limit को कई वजहों से बंद किया गया है. इसे Chrome 135 में हटाया जाएगा.

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

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

पहले, जब <link rel=prefetch> का इस्तेमाल करके किसी रिसॉर्स को प्रीफ़ेच किया जाता था, तब Chrome पांच मिनट के अंदर पहली बार इस्तेमाल करने के लिए, उसके कैश सिमैंटिक्स (यानी max-age और no-cache) को अनदेखा कर देता था, ताकि उसे फिर से फ़ेच न करना पड़े. अब Chrome, इस खास मामले को हटा देता है और सामान्य एचटीटीपी कैश सिमैंटिक्स का इस्तेमाल करता है.

इसका मतलब है कि वेब डेवलपर को <link rel=prefetch> से फ़ायदे पाने के लिए, सही कैशिंग हेडर (Cache-Control या Expires) शामिल करने होंगे.

इसका असर, नॉन-स्टैंडर्ड <link rel=prerender> पर भी पड़ता है.

पहली बार टैब चलाने के लिए, initial_preferences का इस्तेमाल करके Chrome के स्वागत पेज को ट्रिगर करने की सुविधा हटाना

initial_preferences फ़ाइल की first_run_tabs प्रॉपर्टी में chrome://welcome शामिल करने से अब कोई असर नहीं पड़ेगा. इसे इसलिए हटाया गया है, क्योंकि यह पेज, डेस्कटॉप प्लैटफ़ॉर्म पर ट्रिगर होने वाले फ़र्स्ट रन एक्सपीरियंस के साथ डुप्लीकेट है.