yup
Я в chrome_debugger_profile никаких новых стилей не жду. Мне бы свой нормально загрузить.

Это может оказаться неосмотрительным. То, что выглядит как единое окно отладчика (в смысле - Инструменты разработки и Инструменты браузера), на самом деле - куча отдельных компонентов, это можно легко увидеть с помощью самого этого отладчика. Каждый из этих компонентов загружается из своего собственного файла при первом переходе на соответствующую вкладку, и этот файл вполне может тянуть за собой какие-то стилевые файлы. (На предмет этого я отладчик не изучал.)

Вот и получается, что сначала будут загружены стили из userChrome (или те, которые скрипт назначит) и только после них те, которые вкладка с собой притащила. А у последних, как известно, приоритет перед всеми предыдущими.

(Там ещё, конечно, идёт градация по AUTHOR_SHEET, AGENT_SHEET, USER_SHEET, но смотреть, в какую категорию попадают стили из userChrome, у меня как-то повода никогда не было.)

Отредактировано yup (24-05-2025 04:17:06)

Где-то здесь на форуме Dumby писал, что стили из userChrome.css проходят как USER_SHEET.
Впрочем, сейчас это не сильно важно - ведь при втором открытии окна стили применяются.

Для окон Инструменты разработки и Инструменты браузера используются одни и те же файлы - и .xhtml, и .css. Поэтому интересно, наблюдается ли та же проблема с окном Инструменты разработки.

Добавлено 24-05-2025 18:49:28
И ещё: у меня, конечно, версия Firefox другая, но есть к ней серьёзнейшие претензии именно по части Инструментов: то в дереве DOM не показывает элемент, который вот он, перед глазами, то в Отладчике не показывает скрипты, используемые документом. Я уже вычислил, что самый надёжный способ увидеть скрипты это перейти на вкладку Консоль, закрыть окно Инструментов, открыть его заново (при этом Консоль будет текущей) и только потом перейти в Отладчик. Хотя казалось бы - какая разница?

Отредактировано yup (24-05-2025 18:52:04)

как и стили из userContent.css

_zt
проблема со стилями с первым заходом в инстр разраба будет наблюдаться в релизе 139 или лучше сразу качать 141 альфа?

В общем вот и @-moz-document можно отбросить. Скрипт работает только в chrome_debugger_profile. Напомню, тем кто весь тред не читал, это для config.js - применение внешнего файла стилей из заданного файла в profile\chrome к profile\chrome_debugger_profile, т.е. к "chrome://devtools".

(async () => {
    var file = Services.dirsvc.get("ProfD", Ci.nsIFile);
    if (file.leafName !== "chrome_debugger_profile") return;
    file = file.parent;
    file.append("chrome");
    file.append("userChrome_Agent.css");
    if (!file.exists() || !file.isFile()) return;
    Cc["@mozilla.org/content/style-sheet-service;1"].getService(Ci.nsIStyleSheetService)
    .loadAndRegisterSheet(Services.io.newFileURI(file), 0);
})();

Отредактировано _zt (24-05-2025 23:00:36)

Этот скрипт работает, или этот тот, который работает со второго раза?

Но диск-то, на котором браузер стоит, скорее всего, отформатирован в NTFS. Можно же просто создать вторую ссылку на файл, и будет физически один и тот же файл лежать одновременно в двух профилях, и скрипт этот не понадобится, и не нужно будет одинаковые правки в два файла вносить. Нужно только будет файл редактировать программой , которая новый текст перезаписывает поверх старого, а не новый файл создаёт (FAR-ом, например).

То окно, которое для веб-страниц (Инструменты разработки), - тоже "chrome://devtools".
Для обоих окон Инструментов используются физически одни и те же файлы из omni.ja, соответственно и все URL-ы у них одинаковые.

Но  ведь scrollbar это XUL. Или его в новейших оттуда уже в HTML "импортировали"?

На тему USER_SHEET/AGENT_SHEET:

Когда я в том браузере, который у меня проходит как "не очень новый Firefox", с помощью Инструментов браузера изучаю scrollbar, то там в списке стилей, которые применяются к этому элементу, перед именами тех файлов CSS, которые что-то назначают именно элементу scrollbar, в скобочках написано (user sheet). Перед именами файлов, из которых scrollbar берёт что-то неявно (наследованием от родительских элементов) никакой приписки нет.

При этом все эти .CSS-ы внутрибраузерные (из omni.ja) и ни по своему содержимому, ни по расположению внутри omni.ja ничем особым друг от друга не отличаются.

Такая вот загадка.

Отредактировано yup (Вчера 01:23:13)

Сравнивал 140 альфу, которую качал пару недель назад и от 24 мая. Различия значительные в omni.ja. Последнюю качал по этой ссылке

Отредактировано dinn (Вчера 10:01:04)

Сравнил его с исходным вариантом. Различий всего два:

1. Исходный работает в обоих профилях, этот - только в chrome_debugger_profile. (Если видит, что запущен не в chrome_debugger_profile, не делает ничего. Значит, это изменение никак не могло повлиять на успех.)
   
2. Код исходного записан как function(), а код этого как async function(). И получается, что это и есть то решающее изменение, которое помогло.

Да, конечно, асинхронная функция запускается чуть позже синхронной, но это не должно было влиять на то, какой профиль будет в ProfD. И тем более не объясняет, почему при втором запуске всё работало.

Может, это в браузере в ходе переделок ошибка новая завелась, и надо на багзилле жалобу накатать?

А почему нет? Место на диске сэкономить? Так этот профиль 15 МБ занимает, из которых 3 МБ - startupCache, а остальное - places и прочие .sqlite (абсолютно пустые). Ужать эти .sqlite-ы до суммарного размера в несколько сот КБ, и от исходных 15 МБ только startupCache и останется.

Я помню, с чего началось. Сейчас даже процитирую с прошлой страницы: "при первом запуске инструментов браузера, после удаления chrome_debugger_profile, стили перестали применятся".
Как видите, там не говорилось, что chrome_debugger_profile постоянно удаляется.

Понятно. Просто я фразу: "+ html| (например, html|div....) для элементов списков и scrollbar-ов" - понял как: "нужно писать html|scrollbar".

А то, что "в данном случае без html| не пашет" объясняется очень легко: наверняка в файле стилей пространством имён по умолчанию объявлено XUL-ное, и, соответственно, звёздочка без "html|" означает только XUL-ные элементы, а полосы прокрутки-то в нынешних отладчиках уже являются частью HTML-ных элементов (div-ов и пр.).

Из каких моих слов можно сделать такой вывод?

Я всего лишь увидел, что скрипт задействует некий стилевой файл из одного профиля для "боевой раскраски" другого. Задействует целиком. А тот же эффект можно получить, уложив во второй профиль ссылку на файл из первого.

Отредактировано yup (Вчера 13:46:17)

Изначально о наличии @-moz-document в файле стилей ничего не говорилось. А когда, наконец, оно было упомянуто, я ответил, что у всех файлов Инструментов url-prefix равен "chrome://devtools". То есть, в том файле @-moz-document url-prefix("chrome://devtools") является заведомо излишним и может быть спокойно удалено даже при использовании старого скрипта.
А если одно только это удаление не помогает, значит, добавление async тоже важно, но тогда нельзя утверждать, что "новый скрипт позволил удалить @-moz-document из стиля", т.к. и старый такому удалению никак не препятствовал.

Рабочий профиль у меня занимает 3,5 ГБ. Мог бы быть и намного больше, но я регулярно удаляю всё ненужное.

Но ужать профиль отладчика до 3-4 МБ (практически до размера startupCache) особого труда не составляет. А если вместо отдельных файлов использовать ссылки на файлы из другого профиля, то они вообще места занимать не будут.

У меня для четырёх разных браузеров используется физически один и тот же каталог chrome. И благодаря этому все вносимые туда изменения одновременно действуют на все браузеры.

Видел. Но из слов: "при первом запуске инструментов браузера, после удаления chrome_debugger_profile, стили перестали применятся" - никак не видно, что это удаление происходит регулярно. Удаление, на котором проблема обнаружилась, вполне могло быть разовым действием, выполненным из-за какой-то сиюминутной надобности.

Но это же не значит, что в том файле содержатся все-все стили. Это во-первых.

А во-вторых, скрипт (в обеих своих версиях) берёт тот файл и загружает его в браузер целиком, со всеми-всеми стилями, которые в нём имеются.
Условно говоря, я предложил вместо действия useFile("..\file") создать в текущем каталоге ссылку на файл и использовать действие useFile("file").

Отредактировано yup (Вчера 17:09:39)

Для Инструментов браузера - да, читается. Увидеть это очень просто - например, с помощью ProcMon.

Я даже больше скажу - он при этом и обязан читаться. Когда я открываю Инструменты браузера в заведомо однопроцессном Firefox 53, то у меня не просто новое окно на экране появляется, а ещё и в Диспетчере задач появляется второй процесс firefox.exe!

Однако поскольку Инструменты браузера - процесс совершенно отдельный (автономный), то для него это чтение config.js не повторное, а первое.
А когда открывается окно Инструменты разработки, файл config.js повторно не читается.

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

И ещё в документации одно интересное примечание есть:

(Это я так, к слову.)

Отредактировано yup (Вчера 20:00:54)