גרסת בטא של Chrome 143

Rachel Andrew

פורסם: 29 באוקטובר 2025

אלא אם צוין אחרת, השינויים האלה חלים על גרסת הבטא של Chrome 143 ל-Android, ל-ChromeOS, ל-Linux, ל-macOS ול-Windows. מידע נוסף על התכונות האלה זמין בקישורים שבהמשך או באתר ChromeStatus.com. אפשר להוריד את Chrome 143 beta מ-Google.com למחשב או מחנות Google Play ב-Android.

CSS וממשק משתמש

שאילתות CSS חלופיות מוצמדות לקונטיינר

התכונה הזו מציגה את @container anchored(fallback) כדי לעצב צאצאים של רכיבים עם מיקום עוגן על סמך הערך של position-try-fallbacks שמוחל.

לדוגמה, אפשר להשתמש בשאילתות כאלה כדי להגדיר את הסגנון של נקודת העגינה של רכיב מעוגן או של האנימציות שלו, בהתאם למיקום של נקודת העגינה והרכיב המעוגן ביחס אחד לשני.

דוגמה:

#anchored {
 position-try-options: flip-block;
 container-type: anchored;
}

@container anchored(fallback: flip-block) {
  #anchored > .arrow {
    --arrow-rotation: 180deg;
   }
}

מידע נוסף זמין במאמר Detect fallback positions with anchored container queries from Chrome 143.

EditContext: TextFormat underlineStyle ו-underlineThickness

ב-Chromium הושק EditContext API עם באג שבו אובייקט TextFormat, שסופק על ידי EditContext/textformatupdate_event, מספק ערכים שגויים למאפיינים underlineStyle ו-underlineThickness. ב-Chromium, הערכים האפשריים הם None, ‏ Solid, ‏ Dotted,‏ Dashed, ‏ Squiggle ו-None, ‏ Thin, ‏ Thick. עם זאת, לפי המפרט של EditContext ‎, הערכים צריכים להיות none, ‏ solid, ‏ dotted, ‏ dashed, ‏ wavy ו-none, ‏ thin,‏ thick.

Web APIs

אפשר להשתמש ביותר תווים בממשקי JavaScript DOM API

מנתח ה-HTML תמיד (או במשך זמן רב) אפשר לאלמנטים ולמאפיינים להכיל מגוון רחב של תווים ושמות תקינים, אבל ממשקי ה-API של JavaScript DOM ליצירת אותם אלמנטים ומאפיינים הם מחמירים יותר ולא תואמים למנתח.

השינוי הזה מרחיב את האימות של JavaScript DOM APIs כך שיתאים ל-HTML parser.

הקשר נוסף זמין כאן: github.com/whatwg/dom/issues/849

לא צפויות בעיות תאימות בעקבות השינוי הזה, כי כל השמות של הרכיבים והמאפיינים שהיו מותרים קודם עדיין תקפים עם ההתנהגות החדשה.

כללי ספקולציות: שיפורים בטעינה המוקדמת בנייד

בנייד, כללי הניחוש של טעינה מראש ועיבוד מראש של 'eager' מופעלים עכשיו כשאלמנטים של עוגן HTML נמצאים באזור התצוגה למשך זמן קצר.

בעבר, טעינה מראש ועיבוד מראש התחילו מוקדם ככל האפשר, שזה היה שווה ל 'מיידי'. ההתנהגות המעודכנת הזו שימושית יותר כי היא משקפת טוב יותר את הכוונה של המחבר להיות נלהב יותר מ'בינוני' ופחות נלהב מ'מיידי'.

הטמעה של מאפיין CSS font-language-override

התכונה הזו מוסיפה תמיכה במאפיין font-language-override CSS ב-Chromium. המאפיין מאפשר למפתחים לבטל את שפת המערכת שמשמשת להחלפת גליפים ב-OpenType, על ידי ציון תג שפה בן ארבעה תווים ישירות ב-CSS.

האפשרות הזו מאפשרת שליטה מדויקת בטיפוגרפיה, ושימושית לתוכן רב-לשוני או לגופנים עם וריאציות של גליפים שספציפיות לשפה.

‫WebGPU: ערבוב רכיבי טקסטורה

החלפת רכיבי טקסטורה מאפשרת GPUTextureViews לסדר מחדש או להחליף את רכיבי הצבע מערוצי האדום, הירוק, הכחול או האלפא של טקסטורה, כש-Shader ניגש אליהם.

‫ICU 77 (תמיכה ב-Unicode 16)

הספרייה ICU (רכיבים בינלאומיים ל-Unicode) שכוללת תמיכה ב-Unicode משודרגת מגרסה 74.2 לגרסה 77.1, ונוספת לה תמיכה ב-Unicode 16. בנוסף, מתבצע עדכון של נתוני הלוקאל. שני שינויים עלולים להוות סיכון לאפליקציות אינטרנט שמניחות פורמט ספציפי מממשקי ה-API של Intl JavaScript:

• בפורמט המספרים האיטלקי שמוגדר כברירת מחדל, מפריד האלפים מושמט עכשיו ממספרים בני 4 ספרות. לדוגמה, הפונקציה new Intl.NumberFormat("it").format(1234) מחזירה את הערך '1234' במקום '1.234'. אפשר להשיג את ההתנהגות הקודמת באמצעות הפרמטר useGrouping של ה-constructor‏ Intl.NumberFormat.
• במקומות מסוימים שבהם משתמשים באנגלית (לדוגמה, en-AU,‏ en-GB ו-en-IN), נוסף פסיק אחרי שם היום המלא, כך שהתאריך "Saturday 30 April 2011" הפך ל-"Saturday, 30 April 2011". אפליקציות אינטרנט לא יכולות להסתמך על פורמט מדויק של תאריכים.
• ‫Intl ו-RegExp‏ (V8): הרבה שינויים קטנים. השינוי בפורמט המספרים באיטליה הוא בעל הסיכון הגבוה ביותר, ויש לו דגל ייעודי.
• ‫IDNA: השדרוג הזה בדרך כלל מאפשר יותר פעולות ומשפר את התוצאות הכוללות של הבדיקה ב-WPT.
• פילוח טקסט: השינוי הבולט ביותר הוא שיפור של מעברי השורה ביפנית כשמשתמשים ב-word-break: auto-phrase. השינוי הזה קשור לכתובת https://chromestatus.com/feature/5133892532568064.

מאפיין DataTransfer עבור אירועי קלט של insertFromPaste, insertFromDrop ו-insertReplacementText

התכונה הזו מאכלסת את המאפיין dataTransfer באירועי קלט עם inputType של insertFromPaste, insertFromDrop ו-insertReplacementText. ההרשאה הזו מאפשרת גישה לנתונים בלוח העריכה ולנתוני גרירה ושחרור במהלך פעולות עריכה ברכיבי contenteditable.

האובייקט dataTransfer מכיל את אותם נתונים שהיו זמינים במהלך האירוע beforeinput.

התכונה הזו חלה רק על רכיבי contenteditable. בפקדי טופס (textarea, input), ההתנהגות נשארת ללא שינוי – המאפיין data מכיל את הטקסט שהוזן ו-dataTransfer נשאר null. התכונה הזו כבר נתמכת ב-Safari וב-Firefox. הטמעה של התכונה הזו ב-Chrome משפרת את יכולת הפעולה ההדדית בין דפדפנים, ומספקת חוויה עקבית יותר למפתחי אתרים.

FedCM—Support Structured JSON Responses from IdPs

התכונה הזו מאפשרת לספקי זהויות (IdPs) להחזיר אובייקטים מובנים של JSON במקום מחרוזות פשוטות לצדדים מסתמכים (RPs) דרך id_assertion_endpoint.

השינוי הזה מפשט את השילוב למפתחים, כי הוא מבטל את הצורך בסריאליזציה ובניתוח ידניים של מחרוזות JSON. היא מספקת תהליכי אימות דינמיים וגמישים יותר, ומאפשרת לצדדים מסתמכים לפרש תגובות מורכבות ישירות ולתמוך בפרוטוקולים שונים כמו OAuth2,‏ OIDC או IndieAuth בלי הסכמים מחוץ לתחום.

משא ומתן על פרוטוקול אפליקציה ב-WebTransport

המשא ומתן על פרוטוקול האפליקציה WebTransport מאפשר לנהל משא ומתן על הפרוטוקול שבו משתמשת אפליקציית האינטרנט במסגרת לחיצת היד של WebTransport.

אפליקציית אינטרנט יכולה לציין רשימה של פרוטוקולי אפליקציה כשיוצרים אובייקט WebTransport. הפרוטוקולים האלה מועברים לשרת באמצעות כותרות HTTP. אם השרת בוחר באחד מהפרוטוקולים האלה, הוא יכול לציין זאת בכותרות התגובה, והתגובה הזו זמינה באובייקט WebTransport.

Web Smart Card API לאפליקציות אינטרנט מבודדות

זמין רק באפליקציות אינטרנט מבודדות (IWA). התכונה הזו מאפשרת לאפליקציות של כרטיסים חכמים (PC/SC) לעבור לפלטפורמת האינטרנט. היא מעניקה להם גישה להטמעה של PC/SC (ולדרייברים של קורא הכרטיסים) שזמינים במערכת ההפעלה של המארח.

אדמינים יכולים לקבוע את הזמינות של ה-API הזה בשתי דרכים:

• באופן גלובלי – באמצעות מדיניות DefaultSmartCardConnectSetting
• לכל אפליקציה – באמצעות כללי המדיניות SmartCardConnectAllowedForUrls ו-SmartCardConnectBlockedForUrls

מניפסט של אפליקציית אינטרנט: ציון הזכאות לעדכון, כתובות ה-URL של הסמלים הן Cache-Control: immutable

מפרט המניפסט כולל עכשיו אלגוריתם של זכאות לעדכון. כך תהליך העדכון יהיה יותר דטרמיניסטי וצפוי, המפתחים יוכלו לשלוט יותר במועד שבו העדכונים יחולו על התקנות קיימות, והמשתמשים יוכלו לבחור מה לעשות עם העדכון, למשל להתעלם ממנו אם הם רוצים. היא גם מאפשרת להסיר את 'הגבלת הבדיקה של העדכון' שסוכני משתמשים מטמיעים כדי למנוע בזבוז של משאבי רשת.

התערבות בנוגע למודעות כבדות: דוחות שנשלחים למסגרת ההטמעה

דוחות על התערבות בהצגת מודעות נשלחים עכשיו למסגרת ההטמעה של המודעה, בנוסף למסגרת המודעה עצמה. הדוח שנשלח למסגרת ההטמעה יכיל את מזהה ה-iframe של המודעה ואת כתובת ה-URL של המסגרת לפני ההפניה האוטומטית, שהוסרה מתוך שדה ההודעה של גוף הדוח. השינוי הזה מאפשר להקשר של ההטמעה לזהות ספקי מודעות בעייתיים ולטפל במודעות שפוגעות בחוויית המשתמש.

גרסאות מקור לניסיון בתהליך

ב-Chrome 143, אפשר להצטרף לניסויים חדשים של מקורות.

Digital Credentials API (תמיכה בהנפקה)

התכונה הזו מאפשרת לאתרים מנפיקים (לדוגמה, אוניברסיטה, סוכנות ממשלתית או בנק) להתחיל בצורה מאובטחת את תהליך ההקצאה (הנפקה) של פרטי כניסה דיגיטליים ישירות לאפליקציית הארנק הדיגיטלי של המשתמש. ב-Android, היכולת הזו מבוססת על מערכת CredMan (Credential Manager) של Android IdentityCredential. במחשב, נעשה שימוש בגישות חוצות-מכשירים עם פרוטוקול CTAP, בדומה לתהליך הצגת פרטי כניסה דיגיטליים במכשירים שונים.

הקצאה אקראית של מגבלת מאגר שקעי TCP

באמצעות ניצול של מגבלות בגודל מאגר החיבורים ב-Chrome, אפשר לקבל מידע על מצב חוצה-אתרים שאחרת לא היה נגיש. באופן ספציפי, אתם יכולים (עם מידה מסוימת של ודאות סטטיסטית) להעריך את מצב הכניסה, את היסטוריית הביקורים או אפילו משהו ספציפי יותר, כמו אם יש בתיבת הדואר הנכנס של Gmail הודעות בהמתנה.

כדי לצמצם את הסיכון הזה, נוסף רכיב אקראי לאופן שבו מאגרי שקעי TCP מוגבלים, כך שאתר שצופה לא יכול להסיק את המידע הזה בוודאות גבוהה.

הוצאה משימוש והסרה

בגרסה הזו של Chrome מוצגות ההוצאות משימוש וההסרות שמפורטות בקטעים הבאים. באתר ChromeStatus.com אפשר למצוא רשימות של הוצאות משימוש מתוכננות, הוצאות משימוש נוכחיות והסרות קודמות.

בגרסה הזו של Chrome הוצאו משימוש שתי תכונות

הוצאה משימוש של פונקציות getter של Intl Locale Info

‫Intl Locale Info API הוא הצעה ברמה 3 של ECMAScript TC39 לשיפור האובייקט Intl.Locale על ידי חשיפת מידע על הלוקאל, כמו נתוני שבוע (היום הראשון בשבוע, היום שבו מתחיל סוף השבוע, היום שבו מסתיים סוף השבוע, היום המינימלי בשבוע הראשון) ומחזור השעות של כיוון הטקסט שמשמש בלוקאל.

ההטמעה נשלחה ב-Chrome 99. עם זאת, ההצעה השתנתה בהמשך בשלב 3, וכמה פונקציות getter הועברו לפונקציות. צריך להסיר את פונקציות ה-getter שהוצאו משימוש ולהשיק מחדש את הפונקציות ששמן שונה.

הוצאה משימוש של XSLT

‫XSLT v1.0, שכל הדפדפנים פועלים לפיו, עבר סטנדרטיזציה בשנת 1999. בינתיים, XSLT התפתחה לגרסאות 2.0 ו-3.0, נוספו לה תכונות והיא שונה מהגרסה שהוטמעה בדפדפנים. הקיפאון הזה, יחד עם העלייה בשימוש בספריות ובמסגרות של JavaScript שמציעות מניפולציה גמישה ועוצמתית של DOM, הובילו לירידה משמעותית בשימוש ב-XSLT בצד הלקוח. טכנולוגיות מבוססות JavaScript, כמו JSON ו-React, החליפו במידה רבה את התפקיד שלה בדפדפן האינטרנט.

‫Chromium משתמש בספריית libxslt כדי לעבד את השינויים האלה, אבל לא בוצעו עדכונים ב-libxslt במשך כשישה חודשים בשנת 2025. ‫Libxslt הוא בסיס קוד מורכב בשפת C, שנוצר לפני זמן רב ורגיש לנקודות תורפה שקשורות לבטיחות הזיכרון, כמו גלישת חוצץ, שעלולה להוביל להרצת קוד שרירותי. מכיוון ש-XSLT בצד הלקוח הוא עכשיו תכונה נישתית שמשתמשים בה לעיתים רחוקות, הספריות האלה מקבלות פחות תחזוקה ובדיקות אבטחה מאשר מנועי JavaScript ליבה. עם זאת, הם מייצגים שטח תקיפה ישיר לעיבוד תוכן אינטרנט לא מהימן. למעשה, XSLT הוא המקור לכמה ניצולי פרצות אבטחה בולטים מהזמן האחרון, שממשיכים לסכן את המשתמשים בדפדפנים.

מסיבות אלה, אנחנו מתכננים להוציא משימוש את XSLT בפלטפורמת האינטרנט ולהסיר אותו מ-Chromium. ארגון WHATWG החליט להמשיך בתהליך ההוצאה משימוש של XSLT.

פרטים נוספים על ההוצאה משימוש ומידע על הפעולות שצריך לבצע אם אתם מסתמכים על XSLT מופיעים במאמר הסרת XSLT כדי להפוך את הדפדפן למאובטח יותר.