19 lines
1.6 KiB
JavaScript
19 lines
1.6 KiB
JavaScript
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.
|