update at 2026-03-04 13:25:26

pxterm/scripts/archive/cjs_tools/patch_revert_pointer.cjs

@@ -0,0 +1,18 @@
+const fs = require('fs');
+let code = fs.readFileSync('src/components/TerminalPanel.vue', 'utf8');
+
+// The issue: "手指一直滑动,但屏幕没有滚动. 似乎无效的事件并没有被捕捉到"
+// AND we only saw ONE touchmove! 
+// WAIT! "🟠 POINTER UP" fired immediately!
+// This means the OS literally cancelled the touch gesture because it thinks it became a native scrolling gesture!!
+// In iOS Safari, if you don't call preventDefault() on BOTH `touchstart` AND `touchmove` IMMEDIATELY, the browser takes over the touch payload, makes it a pan/scroll gesture, sending a `pointercancel` or `pointerup`, and STOPS firing `touchmove` to JS!
+// But wait, `touchstart` is marked as { passive: true }. iOS is seizing the pan gesture.
+
+// What if we try to switch back to letting xterm do its own DOM scroll but with proper CSS config? 
+// No, the user explicitly asked NOT to use xterm's code and that xterm hijacked it.
+// Let's modify touchstart to be non-passive, or at least understand why pointerUp happened. 
+// "POINTER UP" fired instead of "POINTER CANCEL". If it was a system pan, it would be pointerCancel or touchCancel. pointerUp means physical lift? But user says "手指一直滑动". So maybe user slid, but the touch tracker ended? 
+// Actually, no, if it's long press native selection, pointerUp.
+// Wait! `absDy > TOUCH_KEYBOARD_TAP_MAX_MOVE_PX` -> `event.stopImmediatePropagation()` on pointermove!
+// Oh! Does our `pointermove` prevent `touchmove` from firing if pointer events are capturing it?
+// No, DOM standard dictates both fire. But in Safari, touch and pointer events interact weirdly.