עכשיו קל יותר לנפות באגים בבעיות שקשורות לגלילה בעזרת תג הגלילה החדש של DevTools. בפוסט הזה נסביר מהם רכיבים שאפשר לגלול בהם, למה יכול להיות שקשה למצוא אותם ואיך התכונה החדשה עוזרת לכם לאתר אותם במהירות. בנוסף, ניקח אתכם אל מאחורי הקלעים כדי לראות איך פיתחנו את תג הגלילה.
מהו רכיב שניתן לגלילה?
אם אפשר לגלול בתוכן בתוך אלמנט, זהו אלמנט שניתן לגלילה (או קונטיינר לגלילה). לא משנה אם יש בו סרגל גלילה או לא.
למה קשה למצוא את הרכיב שאפשר לגלול בו?
קשה לנפות באגים בבעיות שקשורות לגלילה. בלי כלי שמוצג בו בבירור הרכיב שאפשר לגלול בו, קל ללכת לאיבוד, במיוחד בדפים מורכבים שבהם אין סרגל גלילה.
חיפוש ידני של הרכיב שגורם לגלילה יכול להיות תהליך מייגע של ניסוי וטעייה:
- בוחרים רכיב ומשמנים את הסגנונות שלו.
- האם סרגל הגלילה נעלם? אם לא, חוזרים על התהליך.
חדש: תג גלילה
בגרסה 130 של Chrome, אתם יכולים להשתמש בתג הגלילה החדש בחלונית הרכיבים כדי לאתר את הרכיבים שאפשר לגלול.
לדוגמה, אפשר לנסות למצוא את הרכיב שגורם לסרגלי הגלילה להופיע בדוגמה הבאה באמצעות תג הגלילה החדש.
הטמעה טכנית של תג הגלילה החדש
מאחורי הקלעים, ההטמעה מחולקת לשני חלקים:
- זיהוי אלמנטים שאפשר לגלול בהם. משתמשים באותות
Blink’s(מנוע העיבוד של Chrome) כדי לזהות רכיבים שניתן לגלול או שניתן לגלול בהם בעקבות שינוי בדף. - הצגת תג הגלילה. כשאנחנו מקבלים את האותות, אנחנו משלבים תג חדש (בדומה לתגים הקיימים של הרשת) לצד הרכיבים שאפשר לגלול בהם בחלונית רכיבים.
זיהוי רכיבים שניתן לגלול
כדי לזהות רכיבים שאפשר לגלול בהם, השתמשנו בשיטה IsUserScrollable ב-Blink. השיטה הזו קובעת אם אפשר לגלול בצומת על ידי בדיקה אם הוא חורג מעבר לציר X או Y, כלומר אם התוכן חורג ממימדי המארז ואפשר לגלול בו. אנחנו קוראים לשיטה הזו בכל פעם שרכיב חדש נטען בכלי הפיתוח, כדי לזהות קונטיינרים שניתנים לגלילה.
כדי לעדכן באופן דינמי את מצב יכולת הגלילה של רכיבים שכבר נטענו, נאלצנו לצלול לעומק של בסיס הקוד של מנוע העיבוד של Blink, כדי לבדוק איפה אפשר להוסיף או להסיר את האזור הניתן לגלילה עבור צומת.
חריגת הטיפול בלוגיקת הליבה מנוהלת על ידי הרכיב PaintLayerScrollableArea. באופן ספציפי, השיטה UpdateScrollableAreaSet אחראית לזהות מתי קיימת חריגה או מתי נפתרה הבעיה.
המידע הזה מועבר לקצה העורפי של כלי הפיתוח על ידי שליחת ההפניה של הצומת ששינתה את ה-ScrollableArea שלו.
לאחר מכן, הקצה העורפי בודק מחדש את הצומת באמצעות השיטה IsUserScrollable כדי לקבל את המצב החדש שלו. אחרי אימות האפשרות לגלילה, נשלח אות לקצה הקדמי באמצעות Chrome DevTools Protocol, כדי לוודא שממשק המשתמש משקף במדויק שינויים בתוכן שניתן לגלילה.
הצגת תג הגלילה
כדי להוסיף את התג החדש בחזית של DevTools, יצרנו שיטת טיפול באירוע ב-ElementsTreeOutline שקיבלה את nodeId של הרכיב ששינה את סטטוס הגלילה שלו באמצעות אירוע.
בטיפול הזה אנחנו מאחזרים את האובייקט ElementsTreeElement באמצעות nodeId ומנחים אותו לעדכן את תג הגלילה שלו.
כדי לעדכן את תג הגלילה, צריך לבדוק אם אפשר לגלול ברכיב ואם כבר יש לו תג גלילה. על סמך התנאים האלה, מתבצעות הפעולות הבאות:
- אם ניתן לגלול את הרכיב ועדיין אין לו תג גלילה, נוסף אחד כזה.
- אם לא ניתן לגלול ברכיב אבל יש לו תג גלילה, התג הקיים יוסר.
הלוגיקה המיוחדת לטיפול במסמך ברמה העליונה שניתן לגלילה
כשניתן לגלול את המסמך ברמה העליונה, יש לנו מקרה מיוחד כי אנחנו לא מציגים את הרכיב #document עבור המסמך הראשי, רק עבור iframe. כתוצאה מכך, אנחנו לא יכולים להציג את התג ישירות על רכיבי #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.
מעבר לגלילה: חדש: תג האפשרויות הנוספות
נוסף על כך, אנחנו עובדים על תג חדש של עומס יתר כדי לזהות את הגורם לגלילה. התג הזה יופיע לצד רכיבים שחורגים מעבר לקונטיינר שלהם, וכך יעזור לכם לאבחן במהירות בעיות בפריסה.
כך זה יפעל:
- ניפוי באפליקציה באופן אינטראקטיבי. לוחצים על תג הגלילה כדי להפעיל פקודה של פרוטוקול כלי הפיתוח שמזהה רכיבי צאצא גולשים.
- תצוגה חזותית של חריגה ממלאי אנחנו נתעד את גבולות הרכיבים בתוך המאגר שניתן לגלילה כדי לזהות כל זליגה.
- הדגשת הגורם. תג האפשרויות הנוספות יסמן את הרכיבים הנוספים האלה, ולחיצה עליו תדגיש אותם ישירות ב-DOM.
כך מפתחים מקבלים כלי חדש ויעיל שיעזור להם להבין ולתקן בעיות פריסה שנגרמות מגלישה בתוכן. אנחנו מאמינים שרמת הניתוח העמוקה הזו תשפר באופן משמעותי את תהליך ניפוי הבאגים.