ההקלדה אינה מחשבת סגנון לכל המסמך בכל תו: כלל הבאנר בלי :has()

[Nathaniel-260]

מה קרה

„כשאני מקליד, לוקח כמה שניות עד שהתו מופיע.”

נמדד ב-Chrome על ה-dist הארוז, במסמך אמיתי של חמישה עמודים: על כל הקשה הדפדפן חישב סגנון מחדש (UpdateLayoutTree) לכל עץ המסמך — 2,748 אלמנטים, 60–115ms לחישוב — 42 פעמים ב-50 הקשות, עם 53 long tasks. במסמך ריק זה לא קרה. על מכונה עמוסה ובתוך ה-WebView של אוצריא זה מה שמצטבר ל„כמה שניות”.

סיבת השורש

לא הקוד שרץ בהקלדה (פחות מאחוז מהזמן היה של התוסף) אלא כלל CSS יחיד ב-src/styles/engine-chrome.css: ההסתרה של באנר edit-rejected של המנוע נכתבה כ-

.superdoc__mutation-status:has([data-superdoc-v2-edit-rejected]) { display: none; }

:has() שהעוגן שלו יושב בתוך .superdoc גורם ל-Blink לסמן את .superdoc כמושפע מ-:has(), ומאותו רגע כל הוספה או הסרה של צומת במסמך — כל תו — מתזמנת חישוב סגנון של תת-העץ כולו. ב-trace עם invalidationTracking: „Affected by :has()” על DIV.superdoc, „Invalidation set invalidates subtree”.

ההכרעה הייתה ניסוי מבוקר על אותו מסמך, בזמן ריצה, לפני ההקלדה:

מה נמחק מהגיליון	חישובי סגנון של כל המסמך (50 הקשות)	long tasks
כלום (בסיס)	42	53
כלל אקראי (.editor-stack__host--pending)	40	64
ה-:has() שברצועה	44	52
כלל הבאנר	0	3

התיקון

הכלל מסתיר את ה-<p> שנושא את התכונה כילד ישיר של העוטף, בלי :has():

.superdoc__mutation-status > [data-superdoc-v2-edit-rejected] { display: none; }

העוטף (SuperDoc.vue) הוא height: 0 בלי ריפוד ורקע, ולכן אין הבדל נראה. העיגון הסמנטי בתכונה נשמר.

מה מונע חזרה

• סטטי — tests/unit/css-hygiene.test.ts: כל :has() בגיליונות ובבלוקי <style> חייב להופיע ברשימה מאושרת עם נימוק. הרשימה מחזיקה כלל אחד (ברצועה, מחוץ לעץ המסמך — נמדד כבלתי מזיק), והבדיקה נופלת גם אם כלל מאושר נעלם.
• דינמי — npm run check:typing-recalc (scripts/qa/typing-style-recalc-qa.mjs): בונה מסמך של ארבעה עמודים דרך ה-Document API, מקליד 40 תווים תחת trace של ה-renderer (חיבור CDP שני, כי Tracing.dataCollected הוא אירוע), וסופר חישובי סגנון של ≥1,000 אלמנטים. מוטציה נמדדה: על ה-dist הישן — 112 חישובים כאלה (1,716ms) → אדום; אחרי התיקון — 0 → ירוק. נוסף ל-verify:qa.
• חוזה — tests/contract/engine-edit-rejected-banner.test.ts נועל את הצורה: בלי :has(), > בין העוטף לתכונה, וה-<p> אכן ילד ישיר באריזה.

כלי אבחון

scripts/typing-latency-probe.mjs: זמן מלחיצה עד ציור, long tasks, הודעות קונסולה וקריאות למאחז לכל הקשה; --docx, --tab, --drop-css <regex> (הניסוי שלמעלה), --trace, ו---attach <port> לתוסף שרץ בתוך אוצריא (אחרי הרצה עם WEBVIEW2_ADDITIONAL_BROWSER_ARGUMENTS=--remote-debugging-port=<port>). מתועד ב-README, „איטיות בהקלדה”.

מה לא נשלח למעלה

גיליון המנוע (@superdoc/docx-engine, קנייני) גם משתמש ב-:has(), וזה מה שהופך :has() בצד המארח למסוכן. בלי הכלל שלנו התופעה אינה מופיעה, ולכן ההגנה כאן. הרישיון של המנוע אוסר לפרסם מדידות שלו; נרשם איכותית ב-docs/engine-gaps.md.

בדיקות שרצו

• npm run typecheck — עבר
• npm test — 185 קבצים, 3,903 בדיקות, כולן עברו
• npm run build + npm run check:dist — עבר
• npm run check:typing-recalc — ירוק על הבנייה הזאת, אדום על הבנייה שלפני התיקון
• scripts/typing-latency-probe.mjs על המסמך שדווח: long tasks בזמן הקלדה 53 → 2

[Nathaniel-260]

אימות על מסמך גדול (165 עמודים, ‏193 אלף מילים, נוצר לבדיקה): אחרי שהפריסה הראשונית נחה, ההקלדה על הבנייה המתוקנת נותנת חציון 55–75ms מלחיצה עד ציור, p90 כ-100ms, ו-4 long tasks ב-60 הקשות — כמו במסמך של חמישה עמודים — ואפס חישובי סגנון של כל המסמך. הקומיט הנוסף משפר את scripts/typing-latency-probe.mjs לבדיקות כאלה (‎--open-wait, ‎--settle, ‎--trace-light, ‎--profile-interval).

[Nathaniel-260]

אימות בתוך אוצריא, עם הקשות אמיתיות (8c0ae81)

נמדד על התוסף כשהוא רץ בתוך ה‑WebView של אוצריא (WebView2 עם --remote-debugging-port), על מסמך אמיתי של חמישה עמודים בשני טורים עם הערות שוליים, בהקשות אמיתיות של מערכת ההפעלה (SendInput) אחרי לחיצת עכבר אמיתית במסמך:

• ההקשה מגיעה לדף תוך מילישניות בודדות; בזמן ההקלדה אפס long tasks ואפס חישובי סגנון של המסמך כולו. כך גם בהקלדה חופשית של המשתמש עצמו שנרשמה ברקע.
• מה שנשאר מורגש הוא שלב המארח, לא הדף: הפיקסלים מופיעים על המסך כ‑150ms אחרי שה‑renderer צייר אותם (WebView2 → Windows.Graphics.Capture → טקסטורת Flutter → raster, בבניית Debug של אוצריא). זה מחוץ לתוסף ולא נראה במדידה דרך CDP בלבד.
• שני מצבים נראים כ„הקלדה איטית” ואינם כאלה: חלון ממוזער, או WebView שאוצריא השהתה — הדף hidden, rAF לא רץ. הכלי מזהה ומדפיס זאת לפני שהוא מתחיל.

הקומיט מוסיף את scripts/typing-latency-inapp.mjs שמודד את השרשרת כולה (הקשה → keydown → ציור → פיקסלים, --screen), ומתקן ב‑typing-latency-probe.mjs --attach לחיצה סינתטית שנחתה ברצועה כשהחלון צר. פירוט ב‑README, „איטיות בהקלדה”.

[Nathaniel-260]

המארח: PR לפורק של flutter_inappwebview

מה שנשאר אחרי התיקון כאן — כ‑150ms מהציור ב‑renderer ועד הפיקסלים על המסך — נחקר בצד המארח: Windows.Graphics.Capture מספק פריים בכל טיק של הקומפוזיטור גם כשה‑WebView סטטי, ו‑Flutter צייר ~60fps כל הזמן שתוסף על המסך (~430 ציורים ב‑5 שניות, otzaria.exe ~20% CPU בשקט). התיקון — השוואת הפריים על ה‑GPU ו‑notify ל‑Flutter רק כשפיקסל השתנה — ב‑Otzaria/flutter_inappwebview#19: 18 ציורים ב‑5 שניות (הבהוב הסמן), 0 כשאין שינוי, CPU ~4%. ההשהיה עד המסך לא השתנתה (ספירת ההופים זהה), אבל המכונה כבר לא מבזבזת ליבה על WebView דומם.

המדידות נעשו עם scripts/typing-latency-inapp.mjs (cc366f9 בענף הזה).

[Nathaniel-260]

עוד קומיט על הענף (8a74521): scripts/typing-latency-inapp.mjs מודד עכשיו את הגעת התו ל‑DOM ולא את המוטציה הראשונה אחרי ההקשה — זו שכבת הסמן, והיא מקדימה את התו בעשרות מילישניות, כך שהמדד הקודם דיווח „מהר” גם כשהתו איחר. הרישום הוא סדרה ומשויך לפי סדר, ולכן הוא תקף גם בהקלדה מהירה, ומודפס „ההקשה האחרונה → התו האחרון ב‑DOM”: המדד שמרגישים כשמקלידים מהר. --target בוחר איפה להקליד (כותרת ברוחב העמוד, טור שמאלי/ימני, שורה לפי טקסט).

מה שנמצא איתו, על המסמך המקורי של הדיווח: התחושה „בטורים זה איטי” לא אושרה — פסקה עם ריצת עיצוב אחת בתוך הטורים מקלידה כמו הכותרת גם בקצב מהיר. מה שכן איטי הוא פסקה עם ריצות עיצוב רבות, שהמנוע מסווג paragraph-complex-inline ומשליך מחדש בכל הקשה; ומכיוון שהקשות מעובדות אחת‑אחת בלי איחוד, הקלדה מהירה בפסקה כזאת נערמת לתור. זה במנוע, לא בתוסף ולא במארח, ומספריו אינם מתפרסמים. פירוט ב‑README תחת „בתוך אוצריא”.

[Nathaniel-260]

החלק של המנוע דווח ל-SuperDoc: superdoc/docx-editor#3984 — פסקה עם br/tab/הפניה להערת שוליים בתוך הפסקה כבדה פי שניים להקשה, וההקשות אינן מאוחדות. איכותי בלבד, עם מחולל מסמכי שחזור סינתטיים (gist). החלק של המארח נשאר לסבב הבא.

[github-actions]

תוצאות בדיקת תוספי אוצריא

מקור מפרט ה-API: GitHub (זמן אמת)

תוסף	שגיאות	אזהרות	עיצוב	סטטוס
וורד לאוצריא (com.otzaria_word_editor.superdoc)	0	0	0	✅

הרצה מלאה

[Nathaniel-260]

תיקון (da9be97): המסקנה „המארח מייקר את ההקשה” נמדדה בזמן שסשן אחר בנה את אוצריא והריץ חבילת בדיקות על אותו מחשב (שתי ליבות). על מחשב שקט — אותה בנייה, אותו מסמך, אותה שורה — העורך עומד בקצב גם בפסקה עם br/tab, כמו ב-Chrome וב-Edge באותו רגע. README עודכן בהתאם (הטריגר: br/tab/הפניה להערת שוליים, לא מספר ריצות), ו-typing-latency-inapp.mjs מדפיס עכשיו את ה-CPU של שאר התהליכים בזמן הפרץ ומזהיר על עומס זר. תגובת תיקון מקבילה נוספה ב-superdoc/docx-editor#3984.