Боль багов в WebView-рантайме

Распространение вайб-кодинга ведёт к деградации индустрии. Эксперты отмечают два главных риска:

снижение квалификации: формируется слой «разработчиков», неспособных писать код самостоятельно и понимать логику программы.

технические угрозы: рынок наполняется низкокачественным ПО с критическими уязвимостями, что ставит под удар безопасность данных и стабильность бизнеса.

Вы абсолютно правы, Спасибо за уточнение!

Попробуй flutter, может получше будет

Спасибо!

формируется слой «разработчиков»

Это правда

технические угрозы: рынок наполняется низкокачественным ПО с критическими уязвимостями, что ставит под удар безопасность данных и стабильность бизнеса.

Не надо себе льстить. С этим «разработчики» и даже Разработчики справляются много лет и без вайбкода неплохо.

Странный выбор… Бери go+react+TypeScript. Будь как все вайбкодеры. Выбирай простые технологии, где меньше кода писать.

Просто полтора часа убито

Ой, беда-беда, на один баг полтора часа ушло!

Вайбкодю

/thread

Правда в том, что он даже свою мысль не мог выразить, а скопировал ответ у той же нейросети?) Или это «другое»? Чистое лицемерие

Но мне очень нравится гибкость html

превью-панель 288px, картинка 480 px; после резолва src становится renderer://

Ты сам-то понял, что делаешь?

По делу:

1. разбей всё это безобразие на маленькие блоки, ИИ их лучше сделает.

2. Не знаю, как у тебя с чистым web, мне нравится результат Flutter с агентом в Android Studio. Глюков вёрстки не замечал, работает в apk и в web (и на десктопе) соответственно замыслам. Самое главное - максимально скрывает всю эту дичь с HTML и CSS.

Да, этот подход тоже добавил к себе на вооружение. Спасибо.

А так если кому интересно, агент в итоге объяснил причины бага:

Конфликт между ProseMirror (PM) и DOM (MutationObserver) внутри WebView — это классическая проблема при разработке мобильных текстовых редакторов. Война наблюдателей возникает из-за фундаментального противоречия: ProseMirror требует полного контроля над DOM на основе своего внутреннего состояния (State), в то время как WebView (особенно на Android/iOS) и сторонние системные утилиты вмешиваются в этот DOM напрямую. Ниже подробно разобраны причины конфликта и методы борьбы с потерей маркировки.

1. Почему возникает «Война Observer» ProseMirror использует встроенный класс DOMObserver (на базе MutationObserver) для отслеживания изменений, которые пользователь вносит через ввод. Схема конфликта выглядит так:

   1. Внешнее вмешательство: Сторонняя библиотека, системная функция WebView (например, автоперевод, автозаполнение, проверка орфографии) или кастомный плагин модифицируют DOM-дерево (меняют теги, добавляют атрибуты, сбрасывают стили).
   2. Реакция ProseMirror: DOMObserver перехватывает эти мутации. Так как эти изменения не были инициированы через транзакции PM (dispatchTransaction), ProseMirror считает, что DOM «поврежден» (vandalized).
   3. Агрессивный рендеринг: PM пытается синхронизировать отображение и принудительно перерисовывает (reconcile/re-render) измененный участок дерева.
   4. Зацикливание: Если внешняя система (или ваш собственный Observer) снова реагирует на эту перерисовку и пытается вернуть свои изменения, возникает бесконечный цикл мутаций — «война наблюдателей», которая намертво вешает поток WebView.

2. Причины потери маркировки (Marks & Decorations) Потеря виртуальной маркировки (выделений, подсветки синтаксиса, комментариев, кастомных стилей (Marks/Inline Decorations)) происходит из-за особенностей нормализации DOM в WebView: • Асинхронность мутаций в Safari/Chromium: В WebView на мобильных устройствах события ввода, автозаполнения и MutationObserver могут срабатывать в непредсказуемом порядке (например, мутация прилетает до compositionend). PM не успевает сопоставить изменения с текущими координатами текстовых маркеров. • Деструктивное перестроение текстовых узлов: WebView при вводе текста на некоторых азиатских клавиатурах (IME) или при работе автоисправления может заменить элемент с вашей маркировкой на связку или несколько TextNode. Для PM этот узел становится dirty. Во время нормализации ProseMirror заменяет его «чистой» копией из стейта, полностью стирая кастомные обертки и маркеры.

В итоге стратегия по устранению разработана агентом, обобщена и в дальнейшем целый класс ошибок будет практически исключён.

Это плохая стратегия. Единственно верный путь для web приложений класса редакторов - это рисовать ВСЁ в canvas, как это сделано в VSCode.

Поддерживаю. Но надо готовиться к большой боли, у canvas надо делать обработку мышки и простых событий на кнопках там нет…

Ну, я не знаю, я когда несложный виджет на canvas с тачем и кликом делал, умвр.