אם לא צוין אחרת, השינויים הבאים חלים על מהדורת הערוץ היציב של Chrome 124 ל-Android, ל-ChromeOS, ל-Linux, ל-macOS ול-Windows. אפשר לקבל מידע נוסף על התכונות שמפורטות כאן בקישורים המצורפים או ברשימה בכתובת ChromeStatus.com. גרסה 124 של Chrome יציבה החל מ-16 באפריל 2024. תוכלו להוריד את העדכונים האחרונים מ-Google.com למחשב או מחנות Google Play ל-Android.
רוצה רק את המיטב? כדאי לקרוא את המאמר חדש בגרסה 124 של Chrome.
שינויים בדפדפן וכלים למפתחים
התקנה אוניברסלית
ודאו שאפשר להתקין כל דף, גם אם הוא לא עומד בקריטריונים הנוכחיים של יכולת ההתקנה של PWA.
מאגרי גלילה עם מיקוד באמצעות המקלדת
שיפור הנגישות על ידי מתן אפשרות להתמקד בקונטיינרים של גלילה באמצעות ניווט רציף במיקוד. לפני השינוי הזה, מקש Tab לא מתמקד בגלילה, אלא אם כן tabIndex מוגדר במפורש לערך 0 או יותר.
על ידי הגדרת האפשרות למיקוד גלילה כברירת מחדל, משתמשים שלא יכולים (או לא רוצים) להשתמש בעכבר יוכלו להתמקד בתוכן חתוך באמצעות הכרטיסייה של המקלדת ומקשי החצים. ההתנהגות הזו מופעלת רק אם פס הגלילה לא מכיל צאצאים שניתן להתמקד בהם במקלדת.
התכונה הזו תושק בהדרגה החל מ-Chrome 124, ותהיה זמינה לכל המשתמשים עד Chrome 125.
רכיבי גלילה שניתן להתמקד בהם במקלדת | באג #40113891 | רשומת ChromeStatus.com | מפרט
בקשת הרשאות ל-Web MIDI API
התכונה הזו מגבילה את הגישה ל-Web MIDI API מאחורי בקשה להרשאות. בעבר, כדי להשתמש בהודעות SysEx באמצעות ה-Web MIDI API, נדרשת הרשאה מפורשת של המשתמש.החל מגרסה 125 של Chrome, כל גישה ל-Web MIDI API מחייבת הרשאת משתמש.
התכונה הזו תושק בהדרגה החל מ-Chrome 124, ותהיה זמינה לכל המשתמשים עד Chrome 125.
באג מעקב #40063295 | רשומה של ChromeStatus.com | מפרט
HTML ו-DOM
המאפיין writingsuggestions
דפדפנים מתחילים להציג הצעות כתיבה למשתמשים בזמן שהם מקלידים במגוון שדות שניתן לערוך באינטרנט. בדרך כלל האפשרות הזו שימושית למשתמשים, אבל במקרים מסוימים מפתחים ירצו להשבית את העזרה בכתיבה שמסופקת על ידי הדפדפן, כמו תוספים או אתרים שמספקים פונקציונליות דומה משלהם.
למאפיין החדש writingsuggestions יש ערכים של true או false שמאפשרים למפתחים להפעיל או להשבית את ההצעות לכתיבה שסופקו על ידי הדפדפן. המצב של המאפיין יכול לעבור בירושה גם מרכיבי ישות אב, וכך לאפשר למפתחים לשלוט ביכולת הזו ברמת רכיב, לכל מסמך או מסמך משנה.
בטעינה
רמז לקוח ל-Sec-CH-UA-Form-Factors
הרמז הזה מספק פרטי שרת על גורמי הצורה של סוכן המשתמש. הפונקציה מחזירה אחד או יותר מהערכים הבאים של גורמי הצורה:
- מחשב: סוכן משתמש שפועל במחשב אישי.
- כלי רכב: סוכן משתמש שמוטמע ברכב, ויכול להיות שהמשתמש אחראי לתפעל את הרכב ולא יכול לקלוט פרטים קטנים.
- נייד: מכשיר קטן ומבוסס מגע בדרך כלל לנשיאה על אדם.
- טאבלט: מכשיר מבוסס-מגע שגדול יותר מ'נייד', ולרוב לא נישא על ידי המשתמש.
- XR: מכשירים סוחפים שמרחיבים את הסביבה של המשתמש או מחליפים אותה.
- EInk: מכשיר שמאופיין בעדכוני מסך איטיים וברזולוציה מוגבלת או ללא רזולוציית צבע.
- שעון: מכשיר נייד עם מסך קטנטן (בדרך כלל פחות מ-2 אינץ'), שמוקף כך שהמשתמש יכול להביט בו במהירות.
הרשאת גישה לרשת הפרטית כדי להקל על תוכן מעורב
כדי ליצור חיבורים למכשירים ברשת מקומית שאין להם שמות ייחודיים גלובליים ולכן הם לא יכולים לקבל אישורי TLS, התכונה הזו מציגה אפשרות חדשה ל-fetch() להכריז על הכוונה של המפתחים לפנות למכשיר כזה. התכונות החדשות כוללות תכונה חדשה, מבוקרת באמצעות מדיניות, שבעזרתה ניתן להגביל את הגישה של כל אתר ליכולת הזו, וכותרות חדשות לתגובת קדם-ההפעלה של השרת כדי לספק מטא-נתונים נוספים.
כותרת של בקשת HTTP priority
הפעולה הזו מוסיפה את כותרת הבקשה priority לכל בקשות ה-HTTP עם פרטי העדיפות של הבקשה בזמן שליחתה.
RFC 9218 (סכמת עדיפות ניתנת להרחבה ל-HTTP) מגדיר כותרת של בקשת HTTP מסוג priority לשימוש לאותת עדיפות בקשה למקורות (ולמתווכים). כמו כן, הוא מגדיר תהליכי משא ומתן ומסגרות ברמת הפרוטוקול של HTTP/2 ו-HTTP/3 כדי להעביר את אותו מידע עדיפות.
הכותרת יכולה לציין את העדיפות הראשונית של משאב רק בפעם הראשונה שהוא התבקש, ואילו המנגנונים מבוססי-המסגרות מאפשרים לשנות את העדיפות לאחר מעשה.
הכותרת יכולה לפעול מקצה לקצה לשרתי המקור (ולספק מנגנון לביטול העדיפות של המקור אם הוא מזוהה על ידי מתווכים), בזמן שהפריימים מוגבלים לפעול ברמת קישור.
התכונה הזו מיועדת במיוחד לתמיכה בסכמה של תעדוף מבוסס כותרת.
באג מעקב #40252001 | רשומה של ChromeStatus.com | מפרט
חסימת עיבוד של מסמכים
התכונה הזו מאפשרת למחברים לחסום רינדור של מסמכים עד שינותח התוכן הקריטי, וכך להבטיח שהצבע הראשון יהיה עקבי בכל הדפדפנים. בלי התכונה הזו, המצב של הצגת התמונה הראשונה תלוי בהיוריסטיקה של מנתח הנתונים, שיכולה להשתנות בהתאם לדפדפנים.
הדבר חשוב במיוחד למעברים בין תצוגות, שבהם מצב ה-DOM המנותח במסגרת הראשונה יכול לשנות משמעותית את המעבר שנוצר.
שימו לב שהתכונה הזו מטמיעה תחביר <link rel=expect href="#id"> שמאפשר לאלמנט קישור להפנות לרכיב צפוי אחר בדף. לאחר מכן, העיבוד ייחסם עד שהרכיב הצפוי ינותח במלואו. הפעולה הזו מחליפה את ההטמעה הקודמת של מאפיין HTML שמאפשרת חסימה של עיבוד המסמך כולו.
אנקפסולציה של מפתח X25519Kyber768 ל-TLS
מגן על התנועה הנוכחית ב-TLS ב-Chrome מפני קריפטאנליזה קוונטית עתידית, באמצעות פריסת האלגוריתם Kyber768 העמיד להסכם מפתח (Kyber768).
זהו הסכם מפתח היברידי X25519 ו-Kyber768 שמבוסס על תקן IETF. המפרט וההשקה האלה לא נכללים בהיקף של W3C. הסכם המפתח הזה יושק כצופן TLS, ועליו להיות שקוף למשתמשים.
הגנה על התנועה ב-Chrome באמצעות Hybrid Kyber KEM | באג #40910498 | רשומת ChromeStatus.com | מפרט
מדיה
מאפיין אחד (jitterBufferTarget)
המאפיין jitterBufferTarget מאפשר לאפליקציות לציין משך זמן יעד, באלפיות שנייה של מדיה, כדי לשמור את מאגר הרעידות של RTCRtpReceiver. הפעולה הזו משפיעה על כמות אגירת הנתונים שסוכן המשתמש מבצע, ומשפיעה על השידורים מחדש ועל התאוששות מאובדן מנות. שינוי של ערך היעד מאפשר לאפליקציות לשלוט באיזון בין עיכוב בהפעלה לבין הסיכון של פריימים של אודיו או וידאו בגלל רעידות ברשת.
באג מעקב #324276557 | רשומה של ChromeStatus.com | מפרט
ממשקי API לאינטרנט
ממשק ה-API של WebSocketStream
ה-WebSocket API מספק ממשק JavaScript לפרוטוקול RFC6455 WebSocket. אומנם השירות היה טוב, אבל הוא נראה מוזר מנקודת המבט של ארגונומיה, וחסרה בו התכונה החשובה של לחץ לאחור. המטרה של ממשק ה-API של WebSocketStream היא לפתור את הליקויים האלה על-ידי שילוב של עדכוני whatWG עם ה-WebSocket API.
WebSocketStream: שילוב זרמים עם WebSocket API | באג #41470216 | רשומת ChromeStatus.com | מפרט
setHTMLUnsafe וגם parseHTMLUnsafe
השיטות setHTMLUnsafe ו-parseHTMLUnsafe מאפשרות להשתמש ב-DOM של Declarative Shadow מ-JavaScript. השיטות האלה גם מציעות דרך קלה יותר לניתוח HTML ל-DOM באופן מיידי, בהשוואה ל-innerHTML או DOMParser.
Streams API: איטרציה אסינכרונית של ReadableStream
ממשקי ה-API של מקורות הנתונים מספקים פרימיטיבים בכל מקום, פועלים בצורה הדדית, ליצירה, לחיבור ולצריכה של מקורות נתונים. בעקבות השינוי הזה נוסיף תמיכה בפרוטוקול אסינכרוני איטרציה ל-ReadableStream API, כדי לאפשר שימוש בזרמים קריאים כמקור ללולאות await...of.
באג מעקב #40612900 | רשומה של ChromeStatus.com | מפרט
אירוע אחד (pageswap)
האירוע pageswap מופעל באובייקט חלון של מסמך, כאשר ניווט יחליף את המסמך הזה במסמך חדש. האירוע מספק מידע על ההפעלה של הניווט (type, NavigationHistoryEntry למסמך החדש).
אם בניווט יש מעבר לתצוגה של מסמכים שונים, האירוע יישלח לפני מצב התיעוד של המסמך הישן. כך המפתח יכול להגדיר את המצב הישן שתועד למעבר, על סמך פרטי ההפעלה של הניווט והמצב החזותי הנוכחי של המסמך הישן.
באג מעקב #41495176 | רשומה של ChromeStatus.com | מפרט
תוספות ל-Attribution Reporting API
הוספנו תכונות ל-Attribution Reporting API כדי ליצור יכולות נוספות לניפוי באגים על ידי תמיכה בניתוח דוחות ניפוי באגים, שיפור הארגונומיה של ה-API על ידי תמיכה בשדה לציון פלטפורמת רישום מועדפת ושיפור הפרטיות.
תמונה בתוך תמונה במסמך: הוספת אפשרות להסתרת הלחצן 'חזרה לכרטיסייה'
הפעולה הזו מוסיפה פרמטר חדש (disallowReturnToOpener) ל-Document Picture-in-picture API, וכשמגדירים את הערך true, הדפדפן רומז לכך שלא אמור להופיע לחצן בחלון של התמונה בתוך תמונה, שמאפשר למשתמש לחזור לכרטיסייה הפתוחה.
כשמדובר במצב של תמונה בתוך תמונה, הוספת לחצן לחזרה לכרטיסיית הפתיחה תמיד הגיונית (אפשר להחזיר את שידור הווידאו לרכיב הווידאו בכרטיסייה הפותחת), אבל לא תמיד זה המצב במקרה של תמונה בתוך תמונה במסמך. כך המפתחים יכולים לקבל שליטה רבה יותר על חוויית המשתמש כשהם סבורים שלחצן כזה לא מתאים לתרחיש לדוגמה שלהם.
מסמכי תיעוד של תמונה בתוך תמונה במסמך | רשומת ChromeStatus.com | מפרט
עיבוד וגרפיקה
SVG context-fill ו-context-stroke
הטמעת תכונת SVG קיימת שמאפשרת את מילות המפתח context-fill ו-context-stroke כשמציינים מאפייני מילוי וקווים. הפעולה הזו משפיעה רק על עצי משנה של SVG שיוצרים באמצעות אלמנט <use>, ועל רכיבי <marker> שנוצרים באמצעות המאפיין marker ברכיב <path>. בנסיבות האלה, הערכים context-fill ו-context-stroke תואמים לערך של המאפיינים fill ו-stroke ב-<use> או ב-<path>.
WebGPU: תמיכה ב-ServiceWorker וב-SharedWorker
תמיכה ב-ServiceWorker וב-SharedWorker נוספת ל-WebGPU, בהתאם ליכולות הקיימות של WebGL.
קובצי Service Workers מאפשרים יכולות אופליין ועיבוד ברקע ל-WebGPU. המשמעות היא שאפליקציות אינטרנט עתירות גרפיקה או תוספים ל-Chrome יכולים לשמור משאבים במטמון ולבצע חישובים גם כשהמשתמש לא יוצר אינטראקציה פעילה עם הדף.
Shared Workers מאפשר למספר כרטיסיות או הקשרים של תוספים כדי לתאם ולשתף משאבים של WebGPU. כך הביצועים חלקים יותר ושימוש יעיל יותר בחומרת הגרפיקה של המשתמש.
באג מעקב #41494731 | רשומה של ChromeStatus.com | מפרט
גרסאות מקור לניסיון מתבצעות
ב-Chrome 124 אפשר לאשר את גרסאות המקור לניסיון החדשות הבאות.
ניסוי להוצאה משימוש של אירועי מוטציה
אירועי מוטציה, כולל DOMSubtreeModified, DOMNodeInserted, DOMNodeRemoved, DOMNodeRemovedFromDocument, DOMNodeInsertedIntoDocument ו-DOMCharacterDataModified, עלולים לפגוע בביצועי הדפים וגם להגדיל משמעותית את המורכבות של הוספת תכונות חדשות לאינטרנט. ממשקי ה-API האלה הוצאו משימוש מהמפרט בשנת 2011 והוחלפו (ב-2012) ב-Mutation Overer API, המעוצב בצורה הרבה יותר טובה.
התמיכה באירועי מוטציה תושבת כברירת מחדל החל מגרסה 127 של Chrome, בסביבות 30 ביולי 2024. כדאי להעביר את הקוד ל-Mutation Writeer API לפני התאריך הזה כדי למנוע שיבושים באתר. אם נדרש עוד זמן, נרשמים לתקופת ניסיון להוצאה משימוש של אירועי מוטציה כדי להפעיל מחדש את התכונה לזמן מוגבל באתר נתון. ניתן להשתמש ב-Chrome בגרסה 134, עד 25 במרץ 2025.
לחלופין, אפשר להשתמש גם במדיניות הארגון MutationEventsEnabled לאותה מטרה, גם דרך Chrome 134.
גרסת מקור לניסיון | באג #40268638 במעקב | רשומת ChromeStatus.com | מפרט
הוצאה משימוש והסרות
בגרסה הזו של Chrome נוציא משימוש את הגרסה הזו והוספנו אותה בהמשך. נכנסים לכתובת ChromeStatus.com כדי להציג רשימות של הוצאות משימוש והסרות.
אין מוציאים משימוש או הסרות בגרסה 124 של Chrome.
קריאה נוספת
רוצה עוד? תוכלו לעיין במקורות המידע הנוספים האלה.