Ещё анимашки

[Feodor2]

          > А для всего того, что позже скачивается скриптами, никакой индикации нет. А хочется. И как реализовать, я предложил.

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

XMLHttpRequest отслеживать не нужно - через него скачивают только мелкий файлик (обычно JSON или XML), содержащий информацию о тех объектах, которые нужно показать на пустом месте страницы. А дальше скрипт ничего не скачивает, а создаёт и добавляет на страницу новые объекты. Если объект - картинка, скрипт прописывает ей атрибут src. И дальше уже сам браузер отправляет на сайт свой обычный запрос. (В Мониторе сети эти запросы идут в разделе HTML, а не XHR).

И значит, отслеживать и индицировать нужно наличие именно таких запросов - точно так же, как при начальной загрузке страницы.

Originally posted by @zanud in #549 (comment)

[Feodor2]

Я думаю первое что нужно сделать найти где и по какому сигналу это включаеться и выключается, начинай именно с самой анимашки.

[zanud]

Я уже знаю, как включать и выключать анимацию - это элементарно просто.
Я нашёл место в исходниках, где включается и выключается штатная анимация загрузки страницы. Но там отслеживается только начало и конец загрузки страницы в целом, вместе со всеми её компонентами. Однако вполне возможно, что там же легко организовать и отслеживание загрузки новых компонентов, добавляемых после получения страницы.

Но тут всплыли технические проблемы.

• Во всём семействе 68.14.* не работает отладчик.

• В 68.13 отладчик работает, но дефектно:

  1. Ставлю точку прерывания внутри того обработчика событий, который запускает-останавливает анимацию.
  2. Перезагружаю страницу.
  3. Происходит основ на точке прерывания.
  4. Ничего в отладчике не делая, жму Run, чтобы продолжить выполнение.
  5. Анимация запускается и... не заканчивается.
     Кнопка Reload/Stop находится в состоянии Stop (крестик) и не нажимается.
     Единственное, что в этом состоянии можно сделать - закрыть страницу.

Придётся медленно и печально разбираться в происходящем с помощью отладочного вывода в консоль. Но это же каждый раз omni.ja пересобирать надо.

Я знаю, как отлаживать дополнения в исходном виде, без их упаковки в .xpi. А для omni.ja такая возможность есть?

[zanud]

Что-то у меня и с отладочным выводом не получается.

В разных местах браузера вывод в консоль осуществляется разными методами.
Файл, который терзаю (https://github.com/Feodor2/Mypal68/blob/main/browser/base/content/tabbrowser.js) изначально содержит кучу вызовов console.log() и console.error().

Натыкал в него свои console.log(), но ничего никуда не выводится. Вообще. В консоли полная тишина. Хотя отладчиком (Mypal 68.13) пошагово эти строки прохожу нормально, никакой ругани на неизвестные функции нет.

[zanud]

Разобрался я, почему console.log() ничего не выводит.

Оказывается, при самом первом запуске браузера (точнее, при создании профиля пользователя) откомпилированное содержимое omni.ja кешируется и в дальнейшем берётся именно из этого кеша, даже несмотря на то, что дата и размер исходного файла изменились.

Если кеш грохнуть, файл закешируется заново уже в изменённом состоянии.

И нужно не забывать так делать после любых изменений.

[zanud]

После того, как удалось победить вывод в консоль, обнаружилось, что что-то неладно в датском королевстве.

За процессом загрузки вкладки следит некий WebProgressListener, который получает извещения о разных событиях, происходящих в процессе загрузки документа. Нас в первую очередь интересуют два класса событий: StateChange и StatusChange.
StateChange связан только с загрузкой страницы в целом, поэтому не так сильно интересен. А вот StatusChange извещает об изменении в состоянии каждого http-запроса в отдельности.

Заголовок функции, которая принимает извещения, выглядит так:
void onStatusChange(in nsIWebProgress aWebProgress, in nsIRequest aRequest, in nsresult aStatus, in wstring aMessage);

Первые два параметра - объекты, позволяющие определить, кто породил пришедшее событие. Третий - числовой код состояния запроса ("a numeric value that indicates the current status of the request"). Четвёртый - словесное описание состояния (это именно то, что мелькает в строке статуса в процессе загрузки страницы).

Из всего этого добра интересует именно код состояния, потому что на описание ориентироваться нельзя - оно локализуемое: нет пакета локализации - описания на английском; поставил я себе русский перевод - всё, описания уже на русском.

Я вставил в самое начало этого обработчика такие строки:

console.log('onStatusChange():');
console.log('  Status: ' + aStatus);
console.log('  Message: ' + aMessage);

И вот что оно мне пишет:

onStatusChange():
  Status: 0
  Message: Поиск devdoc.net…

onStatusChange():
  Status: 0
  Message: Соединение с devdoc.net…

onStatusChange():
  Status: 0
  Message: Выполнение TLS-рукопожатия с devdoc.net…

onStatusChange():
  Status: 0
  Message: Ожидание ответа от devdoc.net…

onStatusChange():
  Status: 0
  Message: Прочитано devdoc.net

Как видим, события в функцию приходят разные, но код у них всё время один и тот же - 0.

Как такое может быть? Это не ошибка в браузере, случаем?

[zanud]

Решил посмотреть, что полезного можно выжать из объекта в параметре aRequest.

По документации у него есть два информационных поля:

name | AUTF8String | The name of the request. Often this is the URI of the request.
status | nsresult | The error status associated with the request

Но на практике оказывается, что никакого объекта функция не получает вообще - значение параметра aRequest всегда null.

И параметр aWebProgress тоже всегда null 🤨

[Feodor2]

Думаю не там ищеш, ну и omni.ja это зип, я обычно там делаю всё внутри фаром. Распаковать тоже можно, но как праильно не знаю, смотреть как что в исходн

[zanud]

Думаю не там ищеш, ну и omni.ja это зип, я обычно там делаю всё внутри фаром.

Так и я FAR-ом делаю. Всё равно это далеко не так удобно, как сразу с распакованным файлом работать.
И как-то трудно представить, что разработчики Firefox предусмотрели такую возможность для посторонних мужиков (создателей дополнений), но не предусмотрели её для самих себя и в процессе своих "улучшений" каждые несколько минут пересоздают архив и чистят кеш.

И что мешало при старте сравнивать дату и размер закешированного файла с его текущим состоянием? Может, как раз тот факт, что они с архивированием не парятся, а работают с распакованными файлами?

Ну да ладно, это проблемы технические. Сейчас главное выяснить, почему события StatusChange приходят такими кастрированными: из четырёх их параметров те три, с которыми можно работать программно, просто обнулены, а четвёртый годится только чтобы его пользователю показать.
(При том, что события StateChange приходят полноценными.)

[Feodor2]

В распакованном тоже нужо чистить (purgecahes)

[zanud]

То есть, распакованный omni.ja Mypal подхватывать умеет? Как?

А кеш чистить это ерунда. В том же FAR-e - полсекунды дела.

[Feodor2]

Собирать из исходников или распаковать правильно, смотреть как там omni.ja пакуются и сделать обратную процедуру

[zanud]

У меня нет проблем с упаковыванием omni.ja. Но это бессмысленные затраты времени.

Для дополнений же (xpi которых тоже zip) есть способ устанавливать их в браузер и отлаживать прямо на дереве исходных текстов, не тратя времени на создание архива.

Вполне логично предположить, что и для omni.ja должен быть подобный способ. И когда ты написал: "В распакованном тоже нужо чистить" - я решил, что ты этот способ знаешь.

[zanud]

Проследил цепочку вызовов вверх по стеку до функции onStatusChange(aWebProgress, aRequest, aStatus, aMessage) { ... } (файл RemoteWebProgress.jsm, строка 126).

Те нули вместо осмысленных значений она получает откуда-то извне, от того, кто её вызвал.

Но стек вызовов на ней заканчивается. То есть, она вызывается откуда-то из сишного кода, и JS-отладчик тут бессилен.

Найти место её вызова анализом исходников не получилось. Так что теперь вся надежда на автора с нормальным отладчиком.