תחקיר אחרי שבלגנתי בבת אחת את מצב ההתחברות וההרחבות ב‑Chrome: אל תעשו remote debugging על Profile אמיתי

AIDO ניפוי באגים
, ,
1

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

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

עובדות שאישרתי ב-session המקומי

  • קודם בוצעה פקודה לסיום בכפייה של Chrome — בפועל זה כמו פשוט להרוג את תהליך הדפדפן שרץ.
  • לאחר מכן הופעל מחדש Chrome האמיתי, ובאופן ישיר כוון ל-Profile ברירת המחדל שבתיקיית המשתמש האמיתית.
  • בפרמטרי ההפעלה היו גם פורט ניפוי באגים מרחוק, וגם --disable-sync.
  • דף היעד היה עמוד ההגדרות של ההרחבה ב-All API Hub.
  • בקוד ה-helper המקומי במקור הייתה הגנה של “אם Chrome כבר רץ — לצאת”, אבל לפני הפעולה הרגתי את Chrome בכוח, כלומר עקפתי בפועל את שכבת ההגנה הזו.

למה זה עשה בעיות

מצב ההתחברות של Chrome, רישום ההרחבות, מצב הסנכרון וחלק מהעדפות — כולם קשורים חזק לתיקיית המשתמש האמיתית.
כשעל ה-Profile האמיתי עשיתי בו־זמנית את הדברים הבאים:

  • הרג בכפייה Chrome שרץ
  • השתלטות על ה-Profile האמיתי דרך ניפוי באגים מרחוק
  • הוספת --disable-sync על ה-Profile האמיתי

התוצאה הייתה ערבוב בין “מצב הדפדפן שאני משתמש בו ביום־יום” לבין “פעולת אוטומציה זמנית”.
פעולות כאלה לא בהכרח מוחקות את הדאטה הבסיסי עד הסוף, אבל הן מאוד בקלות יוצרות שיבוש במצב החיצוני, למשל:

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

איך השחזור הלך הפעם

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

תוצאות בדיקת session-ים היסטוריים

הלכתי לחפש בארכיון המקומי.
המסקנה היא:

  • 2026-04-25: במקרה הזה יש שרשרת ראיות מלאה וברורה.
  • האם בעבר קרתה “אותה תאונה של הרג בכפייה של Chrome + השתלטות על Default Profile האמיתי” — כרגע לא מצאתי בארכיון המקומי ראיות באותה רמת ודאות. אפשר רק להגיד שבעבר אולי הייתה תחושה דומה, אבל זו הפעם הראשונה שאפשר לקבע בוודאות.

כללי ברזל להמשך

מכאן והלאה, כל מה שנוגע לאוטומציה של Chrome — חייב לעמוד בכללים הבאים:

  1. לא עושים אוטומציה על ה-Profile האמיתי של Chrome לשימוש יום־יומי.
  2. לא מחסלים בכפייה Chrome שרץ רק כדי להשתלט על הדפדפן.
  3. לא משתמשים על ה-Profile האמיתי ב---disable-sync, ניפוי באגים מרחוק, או פרמטרים ניסיוניים זמניים.
  4. כשצריך לדבג תוסף — עובדים רק עם user-data-dir זמני נפרד או Profile בדיקה ייעודי.
  5. כשצריך לכתוב נתוני חשבון של ההרחבה — מעדיפים ייבוא/ייצוא, כתיבה לשכבת האחסון או API ייעודי, ולא חוטפים סשן דפדפן אמיתי.
  6. לפני כל ניסוי ברמת הדפדפן — קודם לגבות את Local State, Preferences, Secure Preferences, Sessions.

המהות של הסיפור הזה אינה ש-Chrome לא יציב, אלא שאני השתמשתי ב"סביבת פרודקשן" בתור “סביבת ניסוי”.
לכתוב את זה כדי לא לחזור על זה פעם נוספת.