עכשיו קל יותר לנפות באגים בבעיות שקשורות לגלילה בעזרת תג הגלילה החדש של DevTools. בפוסט הזה נסביר מהם רכיבים שאפשר לגלול בהם, למה יכול להיות שקשה למצוא אותם ואיך התכונה החדשה עוזרת לכם לאתר אותם במהירות. בנוסף, ניקח אתכם אל מאחורי הקלעים כדי להראות איך פיתחנו את תג הגלילה.
מהו רכיב שניתן לגלילה?
אם אפשר לגלול בתוכן בתוך אלמנט, זהו אלמנט שניתן לגלילה (או קונטיינר לגלילה). לא משנה אם יש בו סרגל גלילה או לא.
למה קשה למצוא את הרכיב שאפשר לגלול בו?
קשה לנפות באגים בבעיות שקשורות לגלילה. בלי כלי שמוצג בו בבירור הרכיב שאפשר לגלול בו, קל ללכת לאיבוד, במיוחד בדפים מורכבים שבהם אין סרגל גלילה.
חיפוש ידני של הרכיב שגורם לגלילה יכול להיות תהליך מייגע של ניסוי וטעייה:
- בוחרים רכיב ומשמנים את הסגנונות שלו.
- האם סרגל הגלילה נעלם? אם לא, חוזרים על התהליך.
חדש: תג גלילה
ב-Chrome 130, אתם יכולים להשתמש בתג הגלילה החדש בחלונית רכיבים כדי לאתר את הרכיבים שאפשר לגלול בהם.
לדוגמה, אפשר לנסות למצוא את הרכיב שגורם לסרגלי הגלילה להופיע בדוגמה הבאה באמצעות תג הגלילה החדש.
הטמעה טכנית של תג הגלילה החדש
מאחורי הקלעים, ההטמעה מחולקת לשני חלקים:
- זיהוי אלמנטים שאפשר לגלול בהם. משתמשים באותות של
Blink’s
(מנוע הרינדור של Chrome) כדי לזהות רכיבים שאפשר לגלול בהם או שהפכו לגלילים עקב שינוי בדף. - הצגת תג הגלילה. כשאנחנו מקבלים את האותות, אנחנו משלבים תג חדש (בדומה לתגים הקיימים של הרשת) לצד הרכיבים שאפשר לגלול בהם בחלונית רכיבים.
זיהוי רכיבים שאפשר לגלול בהם
כדי לזהות רכיבים שאפשר לגלול בהם, השתמשנו בשיטה IsUserScrollable
ב-Blink. השיטה הזו קובעת אם אפשר לגלול בצומת על ידי בדיקה אם הוא חורג מעבר לציר X או Y, כלומר אם התוכן חורג ממימדי המארז ואפשר לגלול בו. אנחנו קוראים לשיטה הזו בכל פעם שמתבצעת טעינה של רכיב חדש בכלי הפיתוח, כדי לזהות קונטיינרים שאפשר לגלול בהם.
כדי לעדכן באופן דינמי את מצב הגלילה של רכיבים שכבר נטענו, נאלצנו להתעמק בקוד של מנוע הרינדור של Blink כדי לעקוב אחרי המיקום שבו השטח שאפשר לגלול בו בנוי או מוסר בצומת.
הרכיב PaintLayerScrollableArea
מנהל את הלוגיקה של הליבה לטיפול בחריגה ממלאי. באופן ספציפי, השיטה UpdateScrollableAreaSet
אחראית לזיהוי מתי התרחשה חריגה ממלאי או שהיא טופלה.
המידע הזה מועבר לקצה העורפי של DevTools על ידי שליחת ההפניה לצומת ששינה את ScrollableArea
שלו.
לאחר מכן, הקצה העורפי בודק מחדש את הצומת באמצעות השיטה IsUserScrollable
כדי לקבל את המצב החדש שלו. אחרי אימות האפשרות לגלילה, נשלח אות לקצה הקדמי באמצעות Chrome DevTools Protocol
, כדי לוודא שממשק המשתמש משקף במדויק שינויים בתוכן שניתן לגלילה.
הצגת תג הגלילה
כדי להוסיף את התג החדש בחזית של DevTools, יצרנו שיטת טיפול באירוע ב-ElementsTreeOutline
שקיבלה את nodeId של הרכיב ששינה את סטטוס הגלילה שלו באמצעות אירוע.
בטיפול הזה אנחנו מאחזרים את האובייקט ElementsTreeElement
באמצעות nodeId
ומנחים אותו לעדכן את תג הגלילה שלו.
כדי לעדכן את תג הגלילה, צריך לבדוק אם אפשר לגלול ברכיב ואם כבר יש לו תג גלילה. על סמך התנאים האלה, מתבצעות הפעולות הבאות:
- אם אפשר לגלול ברכיב והוא עדיין לא כולל תג גלילה, תתבצע הוספה של תג כזה.
- אם לא ניתן לגלול ברכיב אבל יש לו תג גלילה, התג הקיים יוסר.
הלוגיקה המיוחדת לטיפול במסמך ברמה העליונה שניתן לגלילה
כשאפשר לגלול במסמך ברמה העליונה, מדובר במקרה מיוחד כי אנחנו לא מציגים את הרכיב #document
במסמך הראשי – רק ב-iframes. כתוצאה מכך, אנחנו לא יכולים להציג את התג ישירות על רכיבי #document
החלטנו להציג את תג הגלילה במקום זאת ברכיב </html>
, כולל ברכיבים ב-Quirks mode
שבהם document.scrollingElement()
מחזיר את הערך <body>
או null
. ההחלטה הזו מונעת בלבול בין מסמכים שאפשר לגלול בהם לבין אלמנטים של גוף הדף שאפשר לגלול בהם, במיוחד בדפים שבהם אפשר לגלול בגוף הדף בנפרד.
זו הדרך הכי ברורה להראות למפתחים אילו רכיבים אפשר לגלול.
שינויים בפרוטוקול של כלי הפיתוח ל-Chrome (CDP)
כדי לשלב את תג הגלילה החדש, נדרשו שינויים ב-Chrome DevTools Protocol (CDP)
. CDP משמש כפרוטוקול תקשורת בין DevTools לבין Chrome.
נאלצנו לשנות את הפרוטוקול כדי לכלול את שני המקרים:
- האם אפשר לגלול בצומת הזה כשהוא נטען בכלי הפיתוח?
- האם הצומת הזה עדכן את המצב שלו לגבי גלילה?
האם אפשר לגלול בצומת הזה כשהוא נטען בכלי הפיתוח?
הוספנו מאפיין חדש בשם isScrollable
לסוג הנתונים DOM.Node
שנשלח בכל פעם שנטען צומת חדש בחזית של DevTools.
כדי להימנע מעומס נתונים מיותר, החלטנו לאכלס את המאפיין הזה רק כשהערך שלו הוא True. לכן, אם המאפיין לא נשלח, אנחנו מניחים שהרכיב לא ניתן לגלילה.
האם הצומת הזה עדכן את המצב שלו לגבי גלילה?
כדי לזהות אם הצומת עדכן את מצב הגלילה שלו, הוספנו אירוע חדש scrollableFlagUpdated
ב-CDP שמופעל בכל פעם שרכיב מקבל או מאבד אזור גלילה. לאירוע יש את המבנה הבא:
# Fired when a node's scrollability state changes.
experimental event scrollableFlagUpdated
parameters
# The id of the node.
DOM.NodeId nodeId
# If the node is scrollable.
boolean isScrollable
טיפ למומחים: בדיקת השינויים החדשים ב-CDP בדפדפן
רוצים לדעת איך Chrome מתקשר עם DevTools? יש דרך פשוטה לבדוק את זה.
בחלונית Protocol Monitor אפשר לראות אירועים שמתרחשים בזמן אמת בין Chrome לבין DevTools, כולל האירוע החדש שנוסף לתג הגלילה. לדוגמה, כשמשנים את הסגנון של רכיב שמשפיע על היכולת לגלול בו, אפשר לראות באופן מיידי את אירועי ה-CDP הקשורים בזמן שהם מתרחשים.
מדריך מפורט יותר זמין במאמר Protocol monitor: View and send CDP requests
.
מעבר לגלילה: חדש: תג האפשרויות הנוספות
יתרה מכך, אנחנו עובדים על תג חדש של חריגה ממלאי השטח כדי לזהות את הגורם לגלילה הזו. התג הזה יופיע לצד רכיבים שחורגים מעבר לקונטיינר שלהם, וכך יעזור לכם לאבחן במהירות בעיות בפריסה.
כך זה יפעל:
- ניפוי באפליקציה באופן אינטראקטיבי. לוחצים על תג הגלילה כדי להפעיל פקודה של DevTools Protocol שמזהה אלמנטים צאצאים שחורגים מהרוחב.
- תצוגה חזותית של חריגה ממלאי. אנחנו נתעד את גבולות האלמנטים בתוך המאגר שניתן לגלילה כדי לזהות כל זליגה.
- הדגשת הגורם. תג ה-overflow יסמן את הרכיבים האלה שחורגים מהמגבלה, ולחיצה עליו תדגיש אותם ישירות ב-DOM.
כך המפתחים יקבלו כלי חדש ויעיל להבנה ולפתרון בעיות פריסה שנובעות מתוכן שחורג מהמסגרת. אנחנו מאמינים שרמת הניתוח העמוקה הזו תשפר באופן משמעותי את תהליך ניפוי הבאגים.