גרסת בטא של 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: החלפת רכיבים של טקסטורה

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

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

הספרייה לתמיכה ב-Unicode‏ ICU (International Components for 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 מכיל את אותם נתונים שהיו זמינים במהלך האירוע 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 for Isolated Web Apps

זמין רק באפליקציות אינטרנט מבודדות (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 בפלטפורמת האינטרנט ולהסיר אותה. ארגון WHATWG החליט להקדים את הוצאת XSLT משימוש.

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