תאריך פרסום הגרסה היציבה: 4 במרץ 2025
אלא אם צוין אחרת, השינויים הבאים חלים על הגרסה של Chrome 134 בערוץ היציב ל-Android, ChromeOS, Linux, macOS ו-Windows.
HTML ו-DOM
רכיב <select> שניתן להתאמה אישית
<select> בהתאמה אישית מאפשר למפתחים לשלוט באופן מלא ברינדור של רכיבי <select> על ידי הוספת המאפיין והערך appearance: base-select ב-CSS.
התכונה הזו מסתמכת על הדגל SelectParserRelaxation, שמשנה את המערכת לניתוח HTML כדי לאפשר יותר תגים בתוך התג <select>.
מעקב אחרי באג מס' 40146374 | הרשומה ב-ChromeStatus.com | מפרט
בחירת הרפיה של מנתח
בעקבות השינוי הזה, המערכת לניתוח HTML תאפשר תגים נוספים ב-<select> מלבד <option>, <optgroup> ו-<hr>.
התכונה הזו מוגבלת על ידי המדיניות הזמנית (SelectParserRelaxationEnabled). מדובר בתקופת מעבר זמנית, והמדיניות תפסיק לפעול החל מגרסה 141 של Chrome.
אם נתקלת בבעיות שלדעתך נגרמו מהשינוי הזה, יש תקופת ניסיון להיפוך המקור כדי להשבית את ההרפיה של הניתוח.
מעקב אחרי באג מס' 335456114 | רשומה ב-ChromeStatus.com | מפרט
סגירה של תיבת דו-שיח באמצעות התאורה
אחת מהתכונות הנחמדות של Popover API היא התנהגות הסגירה הקלה שלו.
ההתנהגות הזו היא עכשיו חלק מ-<dialog>, עם מאפיין closedby חדש שקובע את ההתנהגות:
<dialog closedby="none">: לא ניתן לסגור תיבת דו-שיח בכלל על ידי המשתמש.<dialog closedby="closerequest">: הקשה על Esc (או גורם אחר לסגירה) סוגרת את תיבת הדו-שיח<dialog closedby="any">: לחיצה מחוץ לתיבת הדו-שיח או הקשה על Esc סוגרת את תיבת הדו-שיח. דומה להתנהגות שלpopover="auto".
מעקב אחרי באג מס' 376516550 | הרשומה ב-ChromeStatus.com | מפרט
CSS
תורשה של הדגשה ב-CSS
בירושה של הדגשה ב-CSS, פסאודו-הכיתבים של הדגשה ב-CSS, כמו ::selection ו-::highlight, יורשים את המאפיינים שלהם דרך שרשרת הדגשה של הפסאודו, ולא דרך שרשרת הרכיבים.
התוצאה היא מודל אינטואיטיבי יותר לירושה של מאפיינים ברגעים מיוחדים.
הרשומה ב-ChromeStatus.com | מפרט
PWA
כותרת המשנה של המסמך (תיקון שמות של אפליקציות PWA)
התכונה הזו מאפשרת לציין מידע משלים על החלון הנוכחי של אפליקציית PWA מותקנת שפועלת. הוא מוסיף כותרת משנה לדף כדי לספק מידע לפי הקשר שמוצג בסרגל הכותרת של החלון. הטקסט הזה מחליף את הטקסט שמופיע ברכיב הכותרת ב-HTML.
מעקב אחרי באג מס' 1351682 | רשומה ב-ChromeStatus.com | מפרט
תיעוד של קישורי משתמשים באפליקציות PWA
קישורים לדפי אינטרנט אחרים מפנים משתמשים באופן אוטומטי לאפליקציות אינטרנט מותקנות.
כדי לתת מענה לציפיות המשתמשים בנוגע לחוויית השימוש באפליקציות מותקנות, קל יותר ב-Chrome לעבור בין הדפדפן לאפליקציות האינטרנט המותקנות.
כשהמשתמש לוחץ על קישור שאפליקציית אינטרנט מותקנת יכולה לתמוך בו, הקישור ייפתח באפליקציית האינטרנט המותקנת. המשתמשים יכולים לשנות את ההתנהגות הזו דרך ההגדרות של אפליקציית האינטרנט המותקנת.
מפתחים יכולים לשלוט בהתנהגות הזו באמצעות מאפיין המניפסט launch_handler, ולעיין במסמכי התיעוד למפתחים כדי לקבל מידע נוסף על האופן שבו קישור עומק פועל עם אפליקציות אינטרנט מותקנות.
ביצועים
Document-Policy: expect-no-linked-resources
נקודת ההגדרה expect-no-linked-resources במדיניות המסמך מאפשרת למסמך להציע לסוכנות המשתמשים לבצע אופטימיזציה טובה יותר של רצף הטעינה שלו, למשל, לא להשתמש בהתנהגות ברירת המחדל של ניתוח ספקולטיבי.
סוכנויות משתמשים הטמיעו ניתוח ספקולטיבי של HTML כדי לאחזר באופן ספקולטיבי משאבים שנמצאים בסימון ה-HTML, כדי לזרז את טעינת הדף. ברוב הדפים באינטרנט שיש בהם משאבים שמוצהרים ב-HTML, האופטימיזציה מועילה והעלות של זיהוי המשאבים האלה היא פשרה סבירה. עם זאת, בתרחישים הבאים ייתכן שתבחרו באפשרות עם ביצועים פחות אופטימליים מאשר הזמן הנדרש לניתוח ה-HTML כדי לקבוע אילו משאבי משנה לאחזר:
- דפים שלא הוצהרו עליהם משאבים ב-HTML.
- דפי HTML גדולים עם עומסי משאבים מינימליים או ללא עומסי משאבים, שיכולים לשלוט באופן מפורש בטעינה מראש של משאבים באמצעות מנגנונים אחרים של טעינה מראש שזמינים.
המדיניות של המסמך expect-no-linked-resources מאפשרת לסוכן המשתמש לבחור לבצע אופטימיזציה של הזמן שחולף בקביעה של משאבים משניים כאלה.
באג מעקב מס' 365632977 | רשומה ב-ChromeStatus.com | מפרט
ניהול משאבים מפורש (אסינכרוני)
התכונות האלה עוסקות בדפוס נפוץ בפיתוח תוכנה בנוגע לחיי המדף ולניהול של משאבים שונים (לדוגמה, זיכרון ו-I/O). הדפוס הזה כולל בדרך כלל הקצאה של משאב ויכולת לשחרר משאבים קריטיים באופן מפורש.
באג מעקב מס' 42203814 | הרשומה ב-ChromeStatus.com | מפרט
ניהול משאבים מפורש (סנכרון)
התכונות האלה עוסקות בדפוס נפוץ בפיתוח תוכנה לגבי משך החיים והניהול של משאבים שונים (לדוגמה, זיכרון ו-I/O). הדפוס הזה כולל בדרך כלל הקצאה של משאב ויכולת לשחרר משאבים קריטיים באופן מפורש.
באג מעקב מס' 42203506 | הרשומה ב-ChromeStatus.com | מפרט
הרחבת ה-API של console.timeStamp כדי לתמוך באפשרויות מדידה והצגה
הרחבה של ממשק ה-API console.timeStamp(), באופן תואם לאחור, כדי לספק שיטה בעלת ביצועים גבוהים להטמעת נתונים באפליקציות ולהצגת נתוני תזמון בחלונית 'ביצועים' ב-DevTools.
אפשר להוסיף חותמת זמן, משך זמן ואפשרויות תצוגה (טראק, נתיב מים וצבע) בהתאמה אישית לרשומות של תזמון באמצעות ה-API.
הרשומה ב-ChromeStatus.com | מפרט
ממשקי API של אתרים
מתן הרשאה לקריאת קבוצות תחומי עניין ב-worklet של Shared Storage
הוספת שיטת interestGroups() ל-worklet של האחסון השיתופי, כדי להחזיר את קבוצות תחומי העניין של הקהל המוגן שמשויכות לבעלים של המקור של האחסון השיתופי, עם כמה מטא-נתונים נוספים.
ה-API הזה מספק לקונה של Protected Audience תמונה טובה יותר של מה שקורה עם המשתמשים שלו, ומאפשר לקבל דוחות על צבירת נתונים פרטית.
תכונה של דיווח על שיוך (Attribution): הסרת המגבלה על דוחות שאפשר לצבור כשמזהה ההקשר של הטריגר הוא לא null
השינוי הזה מבוסס על משוב ממפעילי ה-API ועל הצורך למדוד מספר גבוה יותר של אירועי המרה בתהליכי שימוש מסוימים.
נכון לעכשיו, ב-API יש מגבלה שמאפשרת ליצור עד 20 דוחות שאפשר לצבור לכל רישום של מקור. המגבלה הזו מגבילה תרחישי שימוש שבהם תהליך הרכישה של המשתמש עשוי להיות ארוך יותר. בעקבות השינוי הזה, לא תהיה הגבלה על מספר הדוחות שאפשר לצבור כשמזהה הקשר של הטריגר מסופק כחלק מהרישום. הסרת המגבלה הזו מוגבלת רק למקרים שבהם מצוין מזהה ההקשר של הטריגר, כי כאשר הוא מצוין, ה-API מחיל שיעור גבוה יותר של דוחות null, שעוזר להגן מפני זליגת מידע בין אתרים דרך ספירת הדוחות.
בנוסף, דוחות שאפשר לצבור עדיין יהיו כפופים למגבלות אחרות שמגבילות את כמות המידע הכוללת שניתן למדוד, כמו תקציב התרומה ברמה L1 (65,536) לכל מקור ומגבלת שיעור השיוך.
הקלות במעקב אחר עזיבה מהדף הראשון במטמון HTTP
ההקלות במעקב אחר עזיבה מהדף הראשון במטמון ה-HTTP הן תוספת להתנהגות הקיימת למניעת מעקב אחר עזיבה מהדף הראשון. העדכון מבטל את הדרישה שלפיה אתר חשוד למעקב חייב לבצע גישה לאחסון כדי להפעיל את הפתרונות לצמצום המעקב אחר נטישות.
הפתרון הראשוני של Chrome לצמצום מעקב אחר נטישות מופעל כשאתר נכנס לאחסון הדפדפן (לדוגמה, בקובצי cookie) במהלך תהליך הפניה אוטומטית. עם זאת, מעקב אחר נטישות יכול לעקוף באופן שיטתי את הפתרונות האלה באמצעות שימוש במטמון ה-HTTP כדי לשמור נתונים. אם נמתין את תנאי ההפעלה של הפחתת ההשפעה של מעקב אחר נטישות, הדפדפן יוכל לזהות מכשירי מעקב אחר נטישות באמצעות מטמון ה-HTTP.
מעקב אחרי באג מס' 40264244 | הרשומה ב-ChromeStatus.com | מפרט
זיהוי התראות פוגעניות במכשירי Android באמצעות LLM במכשיר
מטרת ההשקה הזו היא להסתיר את התוכן של התראות שיש חשד שהן פוגעות. לאחר מכן, למשתמש תהיה אפשרות לסגור את ההתראה, להציג אותה או לבטל את ההרשמה למקור. הזיהוי הזה יתבצע באמצעות מודל במכשיר.
OffscreenCanvas getContextAttributes
מוסיפים את הממשק getContextAttributes מ-CanvasRenderingContext2D אל OffscreenCanvasRenderingContext2D.
מעקב אחרי באג מס' 388437261 | רשומה ב-ChromeStatus.com | מפרט
Private Aggregation API: מגבלות על תרומות לפי הקשר למבצעים של קריאות ל-Shared Storage
מאפשרת למפעילים של אחסון משותף להתאים אישית את מספר התרומות לכל דוח צבירה פרטי.
התכונה הזו מאפשרת למפעילים של אחסון משותף להגדיר מגבלות על תרומות לפי הקשר באמצעות שדה חדש, maxContributions. מבצעי הקריאה מגדירים את השדה הזה כדי לשנות את מספר ברירת המחדל של התרומות לכל דוח. אפשר להגדיר מספרים גדולים יותר וקטנים יותר. Chrome יקבל ערכים של maxContributions בין 1 ל-1,000, כולל. ערכים גדולים יותר יתפרשו כ-1,000.
בגלל הוספת ה-padding, גודל המטען הייעודי של כל דוח יהיה יחסי באופן גס למספר התרומות שנבחרו לכל דוח. אנחנו צופים שהצטרפות לדוחות גדולים יותר תגדיל את עלות הפעלת שירות הצבירה.
התכונה הזו לא תשפיע על מבצעי קריאה (callers) של קהלים מוגנים. עם זאת, אנחנו מתכננים להוסיף תמיכה בהתאמה אישית של מספר התרומות בדוחות של קהלים מוגנים בתכונות עתידיות.
מעקב אחרי באג מס' 376707230 | הרשומה ב-ChromeStatus.com | מפרט
תמיכה ב-Web Locks API ב-Shared Storage
שילוב של Web Locks API באחסון משותף. כך אפשר למנוע תרחישים שבהם מדידת פוטנציאל החשיפה באתרים שונים עלולה לגרום לדיווח כפול, בגלל תנאי מרוץ פוטנציאליים בלוגיקה של get() ו-set().
השינוי הזה:
- הצגת
navigator.locks.requestבסביבת ה-worklet. - הוספת האפשרות
{ withLock: <resource>}לכל שיטות המשתנים. - הוספה של שיטת שינוי באצווה:
sharedStorage.batchUpdate(methods, options). השיטה הזו, עם האפשרותwithLock, מאפשרת להריץ כמה שיטות של מודיפיקרים באופן אטומי, ומתאימה לתרחישים לדוגמה שבהם אתר צריך לשמור על עקביות בזמן עדכון נתונים שמאורגנים בכמה מפתחות.
מעקב אחרי באג מס' 373899210 | הרשומה ב-ChromeStatus.com
רינדור וגרפיקה
תמיכה ב-ImageSmoothingQuality ב-PaintCanvas
הוספת תמיכה במאפיין imageSmoothingQuality ב-Paint Canvas.
כך תוכלו לבחור בין איכות לבין ביצועים כשמשנים את הגודל של התמונות.
יש שלוש אפשרויות בסך הכול עבור imageSmoothingQuality: low, medium ו-high.
מעקב אחרי באג מס' None | רשומה ב-ChromeStatus.com | מפרט
קבוצות משנה של WebGPU
הוספת פונקציונליות של קבוצות משנה ל-WebGPU. פעולות של קבוצות משנה מבצעות פעולות SIMT כדי לספק תקשורת יעילה ושיתוף נתונים בין קבוצות של קריאות. אפשר להשתמש בפעולות האלה כדי להאיץ אפליקציות על ידי צמצום התקורה העודפת של הזיכרון שנובעת מתקשורת בין קריאות.
הרשומה ב-ChromeStatus.com | מפרט
גרסאות מקור לניסיון
Digital Credential API
כיום, אתרים יכולים לקבל פרטי כניסה מאפליקציות של ארנקים לנייד באמצעות מגוון מנגנונים, למשל, מנהלי כתובות URL מותאמים אישית וסריקת קודי QR. התכונה הזו מאפשרת לאתרים לבקש פרטי זהות מארנקים באמצעות מערכת IdentityCredential CredMan של Android. אפשר להרחיב אותו כדי לתמוך במספר פורמטים של פרטי כניסה (לדוגמה, ISO mDoc ופרטי כניסה מאומתים של W3C), ומאפשר להשתמש בכמה אפליקציות ארנק. אנחנו מוסיפים מנגנונים שיעזרו לצמצם את הסיכון לניצול לרעה של זהות בעולם האמיתי ברמת הסביבה העסקית.
במהלך תקופת הניסיון במקור, החל מגרסה 134 של Chrome, תהיה תמיכה ב-API הזה בפלטפורמת המחשב. במהלך תקופת הניסיון, Chrome במחשב יתקשר באופן מאובטח עם הארנק הדיגיטלי בטלפון Android כדי לאחזר את פרטי הכניסה המבוקשים.
גרסת Origin | באג במעקב מס' 40257092 | הרשומה ב-ChromeStatus.com | מפרט
תקופת ניסיון לתכונה שהוצאה משימוש עבור SelectParserRelaxation
זוהי תקופת ניסיון להוצאה משימוש, שבה המערכת מפעילה מחדש את התנהגות המנתח הישנה לניתוח תגי <select>. לפי ההתנהגות הישנה, תוכן לא נתמך מושלך ללא הודעה ולא נכלל בתוכן ה-DOM שמתחת ל-<select>. אפשר להשתמש בגרסת הניסיון הזו אם ההתנהגות החדשה שמופעלת מ-Chrome 135 גורמת לשיבושים באתר.
גרסת Origin לניסיון | הרשומה ב-ChromeStatus.com
הוצאה משימוש והסרות
הסרה של אילוצים לא סטנדרטיים של אודיו ב-getUserMedia
Blink תומך במספר אילוצים לא סטנדרטיים עם קידומת goog ל-getUserMedia, מהתקופה שבה האילוצים לא היו סטנדרטיים.
השימוש ירד באופן משמעותי ל-0.000001% עד 0.0009% (בהתאם למגבלה), וחלק מהן אפילו לא משפיעות בגלל שינויים ב-stack של הקלטת האודיו ב-Chromium. בקרוב לא תהיה לאף אחד מהם השפעה בגלל שינויים אחרים שצפויים בקרוב.
אנחנו לא צופים שיהיו נסיגות משמעותיות בעקבות השינוי הזה. אפליקציות שמשתמשות באילוצים האלה ימשיכו לפעול, אבל יקבלו אודיו עם הגדרות ברירת המחדל (כאילו לא הועברו אילוצים). הם יכולים לבחור לעבור לאילוצים רגילים.
מעקב אחרי באג מס' 377131184 | רשומה ב-ChromeStatus.com | מפרט