Сейчас вы снова убедитесь, что знание языка С сопоставимо с навыками самообороны, поскольку в современном мире мега-корпораций и победившего киберпанка на простых пользователей всем и давно наплевать.
Отдыхаем хорошо
Как и все нормальные люди, я временами смотрю фильмы, сериалы и длинные видео на ноутбуке и чтобы тот случайно не ушел в сон во время просмотра — включаю на нем «режим презентации».
Поскольку за последние годы все кино переместилось в веб, большую часть времени теперь используется не программа-видеоплеер, а обычный браузер Chrome/Chromium.
После одного из обновлений, стал замечать, что браузер-то оборзел научился самостоятельно перехватывать засыпание ноутбука, блокировку экрана и запуск скринсейвера во время просмотра видео, без всяких «режимов презентации».
Затем такое поведение появилось и на обычных сайтах — без видимого видео или аудио-контента.
Без каких-либо сообщений, запросов и подтверждений на подобные действия.
Затем ноутбук впервые разрядился в ноль, будучи оставленным с открытой страницей какого-то левого сайта, ни suspend ни hibernate внезапно не сработали.
После пятой по счету подставы с перехватом управления, автор окончально огорчился с такой наглости, достал любимый топор компилятор и стал изучать проблему в деталях.
Изучение проблемы
Первым делом я полез в поисковик, убедиться что проблема — не результат осеннего обострения или моего специфического окружения, в котором половина системы это разнообразные компиляторы и средства разработки, а другая — горы исходного кода.
Оказалось что сия дичь действительно массовая и хорошо известная:
Хотя в статье речь пойдет о Xfce, аналогичным обазом ведут себя все «большие» окружения — KDE, Gnome, Cinnamon и так далее:
Отдельная «шутка юмора» — попытка втащить поддержку такого поведения в.. Sway:
Monitor dbus and inhibit swayidle when Firefox or Chromium request it
Хотя любители тайловых менеджеров — особая раса сверхлюдей, понять мотивы которых обывателю не дано, так что не буду даже пытаться.
Разумеется по этой проблеме есть давно заведенный тикет в трекере, с длиннющей перепиской, с приложенными дампами памяти и техническими деталями, открытый уже 11 лет:
Помимо означенного тикета в публичном трекере Ubuntu, где тусуются в основном простые пользователи, нашелся еще один, не менее эпичный тикет в трекере самого Chromium, висящий там аж с 2013 года:
Если прокрутить в самый низ страницы, можно заметить статус «Fixed» и битую ссылку на коммит (поскольку трекер переехал), суть которого — легализация специального API для управления блокировкой экрана и засыпанием.. прямо из кода на странице!
Примерно такого:
// The wake lock sentinel.
let wakeLock = null;
// Function that attempts to request a screen wake lock.
const requestWakeLock = async () => {
try {
wakeLock = await navigator.wakeLock.request();
wakeLock.addEventListener('release', () => {
console.log('Screen Wake Lock released:', wakeLock.released);
});
console.log('Screen Wake Lock released:', wakeLock.released);
} catch (err) {
console.error(`${err.name}, ${err.message}`);
}
};
// Request a screen wake lock…
await requestWakeLock();
// …and release it again after 5s.
window.setTimeout(() => {
wakeLock.release();
wakeLock = null;
}, 5000);Как тебе такое, Илон Маск?
Повторяю для тех, кто еще не понял и не осознал:
любая веб-макака, верстающая на полставки
порносайты, ныне может с помощью специального кода на странице заставить браузер Chrome заблокировать засыпание вашего ноутбука.
И защитить от такого может лишь знание языка С и эта замечательная статья.
Механизм работы
Прежде чем «карать и патчить» очередную оборзевшую программу, стоит рассказать широкой аудитории как вся эта кухня вообще работает, хотя‑бы для осознания печальных реалий.
Есть одна неведомая штука в Linux-системах, под названием systemd:
systemd is a suite of basic building blocks for a Linux system. It provides a system and service manager that runs as PID 1 and starts the rest of the system.
Описание, взятое с официального сайта, столь расплывчато не потому, что это перевод с языка рептилоидов, как могло показаться. Просто такого рода системные сервисы крайне непросто описать простыми словами, доступными обывателю.
Для примера, вот так выглядит набор системных сервисов Windows:
У замечательного systemd с недавних пор появился абсолютно «сказочный» функционал, созданный для перехвата управления процессами засыпания и выключения системы:
systemd 183 and newer include a logic to inhibit system shutdowns and sleep states. This is implemented as part of systemd-logind.daemon(8)
Отключаемый, разумеется.
Но только с последствиями, вроде сломанного процесса автоматического засыпания из менеджеров управления питанием.
И риском загнуть систему целиком при обновлении, поскольку например менеджеры пакетов выставляют подобную блокировку при установке пакета.
Можете конечно попробовать заблокировать механизм
inhibitв systemd, но все последствия — на вас и вашей совести.
Мы же пойдем немного другим, менее радикальным путем.
Менеджер управления питанием Xfce
Этой командой можно посмотреть список запущенных перехватчиков:
systemd-inhibit --listВ моей системе (Linux Manjaro) вывод выглядит следующим образом:
Обратите внимание, что самого браузера Chrome в списке нет, зато есть xfce4-power-manager — менеджер управления питанием из Xfce, который принимает входящие запросы на перехват и решает что делать дальше.
Остальные сервисы обрабатывают только события засыпания (sleep).
Так что наша цель это xfce4-power-manager , именно туда мы сейчас и залезем, для нанесения правок.
xfce4-power-manager — по большей части фоновое приложение, автоматически запускаемое при старте среды Xfce. Но в отличие от прошлого поциента, тут есть некоторый интерфейс и взаимодействие с пользователем, которое происходит с помощью иконки в трее:
По нажатию правой кнопки мыши, появится меню со списком дерзких приложений, которые в данный момент перехватывают управление питанием:
Так что ответственный за весь этот электронный беспредел был наконец четко определен.
Кровавый патчинг
Исходный код менеджера управления питанием находится в основном репозитории Xfce, исправляемая версия должна совпадать с установленной локально, чтобы не словить феерические проблемы совместимости.
Автор использовал версию 4.20, установленную на момент написания статьи.
Место предстоящей правки — файл xfpm-inhibit.c, в который вынесена вся логика по обработке перехватов (inhibit).
Нас интересует метод
xfpm_inhibit_inhibit,строка 370, где начинается обработка входящего запроса на перехват управления.
Код метода небольшой, поэтому привожу его целиком:
static gboolean
xfpm_inhibit_inhibit (XfpmInhibit *inhibit,
GDBusMethodInvocation *invocation,
const gchar *IN_appname,
const gchar *IN_reason,
gpointer user_data)
{
const gchar *sender;
guint cookie;
if (IN_appname == NULL || IN_reason == NULL)
{
g_dbus_method_invocation_return_error (invocation,
XFPM_ERROR,
XFPM_ERROR_INVALID_ARGUMENTS,
_("Invalid arguments"));
return TRUE;
}
sender = g_dbus_method_invocation_get_sender (invocation);
cookie = xfpm_inhibit_add_application (inhibit, IN_appname, sender);
XFPM_DEBUG ("Inhibit send application name=%s reason=%s sender=%s",
IN_appname, IN_reason, sender);
xfpm_inhibit_has_inhibit_changed (inhibit);
xfpm_dbus_monitor_add_unique_name (inhibit->priv->monitor,
G_BUS_TYPE_SESSION, sender);
xfpm_power_management_inhibit_complete_inhibit (user_data,
invocation, cookie);
return TRUE;
}Обратите внимание на вызов метода XFPM_DEBUG, содержащего текст отладочного сообщения. Все подобные сообщения становятся видны только если запустить xfce4-power-manager с ключом --debug.
Именно так и было найдено место будущей правки, после сообщения в консоли:
xfpm_inhibit_inhibit(): Inhibit send application name=/usr/lib/chromium/chromium reason=Video Wake Lock sender=:1.459
Что мы имеем в итоге:
есть единственная точка входа (метод) в менеджере управления питанием, с которой начинается регистрация перехватчика управления;
метод принимает на вход название приложения (полный путь), посягнувшего на такой перехват.
Думаю не надо иметь высшее техническое образование, чтобы догадаться как будет выглядеть финальное решение:
if (strstr(IN_appname,"chrom") != NULL ) {
XFPM_DEBUG ("Chrome уходи!");
return TRUE;
}Для не знающих и не владеющих:
метод strstr проверяет на входжение слова «chrom» в названии дерзкого приложения, которое отправило запрос на перехват управления питанием, если оно там есть — происходит немедленный выход из этого метода, а запрос игнорируется.
Вот так, всего лишь 4 строчки на С, вставленные в нужном месте, сразу после проверки на пустоту обламывают рога оборзевшему браузеру, созданному мировой корпорацией, которая решила, что «мы знаем как лучше».
Так это выглядит в действии после наложения моего «кровавого» патча:
Сборка
Теперь поговорим о печальном — о сборке всего этого цирка с конями.
Проект xfce4-power-manager это уже существенная часть Xfce, чтобы собрать его из исходников и заставить работать — придется постараться.
Во-первых, не стоит забирать исходники непосредственно из репозитория, поскольку в проекте используется кодогенерация и в этом случае придется заниматься еще и ей, устанавливая дополнительные пакеты в систему.
Куда проще скачать готовый архив со специально подготовленными исходниками релизной версии.
Напоминаю что мы патчим версию 4.20.
Во-вторых, придется установить в систему довольно много библиотек и утилит для разработки:
-
Gtk+ and Glib headers, in some distributions called the -devel packages
-
Xfce 4.20 requires Gtk+ 3.24 and Glib-2.0 >= 2.72 (See also: 4.20 dependencies)
Same version for gmodule-2.0, gobject-2.0, gthread-2.0, gio-2.0 and gdbus
gdk-pixbuf-2.0 >= 2.42.8
gobject-introspection >= 1.72
gtk-layer-shell 0.7.0
pkgconfig
-
Это не весь список, тут внизу страницы находится специальная таблица с описанием зависимостей между компонентами Xfce, часть из которых также придется установить.
Таков путь джедая, что поделать.
Распаковываем скачанный архив с исходниками и запускаем скрипт configure:
tar xvjf ~/Downloads/xfce4-power-manager-4.20.0.tar.bz2
cd fce4-power-manager-4.20.0
./configure --disable-waylandПоскольку автор не использует Wayland — тут отключена зависимость от него при сборке, но если вам оно актуально, придется установить дополнительные библиотеки:
wayland 1.20
wayland-protocols 1.25
Добавляем описанный выше блок в файл src/xfpm-inhibit.c и наконец запускаем сборку:
makeЕсли сборка завершится успешно, в каталоге src будет готовый бинарник с патчем, проверить который можно так:
pkill -f xfce4-power-manager
./src/xfce4-power-manager --debugДальше открываем в Chrome любую страницу с видео и смотрим выдаваемые сообщения:
Разумеется, после такого патча вам придется вручную включать и отключать режим презентации (Presentation mode) при просмотре длинных роликов в браузере, зато процесс будет полностью контролируемым.
Также подобным образом можно «обламывать рога» и другим интересным приложениям, дерзнувшим покуситься на управление питанием — с недавних пор за подобным неблаговидным делом был замечен и Firefox.
Эпилог
Грустно наблюдать (в который уж раз), как некогда хороший софт, по мере роста популярности скатывается в полное УГ отрицание пользовательского опыта и начинает считать своих пользователей полными идиотами:
неотключаемые опции, неизменяемое поведение и просто наглая ложь — все это стало, к великому сожалению, постоянными спутниками самого популярного браузера на планете.
И лишь владение языком С и навыки системного программирования все еще позволяют ставить на место оборзевшие программы — изучайте же инженерное дело настоящим образом!
В одной из следующих статей расскажу о патчах для самого браузера Chrome: «как убрать detach вкладок при таскании», «как вернуть пустую страницу для новой вкладки» и многое другое — следите за анонсами на нашем канале.
Менее цензурный оригинал статьи как обычно в нашем блоге.
Комментарии (42)
DSolodukhin
30.11.2025 20:33А можно раскрыть, в чем проблема? Вы хотите, чтобы комп засыпал, пока вы кино смотрите?
alex0x08 Автор
30.11.2025 20:33Проблема в том, что "дырку для кино" стали использовать все подряд, например чтобы сделать блокирование перехода в спящий режим все время пока открыта страница сайта.
В качестве "фишки".
Соотвественно теперь возможно такое, что если оставляете включенным ноутбук с открытым сайтом в браузере, он легко может и не заснуть, полностью разрядив батарею.
DSolodukhin
30.11.2025 20:33Да, интересно, не сталкивался сам, если честно.
А не смотрели, что приходит в reason? Может там можно различть как-то когда сам браузер запрашивает или это шаловливые ручки сайтописателя?
alex0x08 Автор
30.11.2025 20:33На скриншотах же видно сообщение "Playing audio", так что оно достаточно общее, хотя и обязательное (судя по коду).
На самом деле сам факт программной инициации из JS столь системного действа как управление питанием - лишь половина проблемы, есть и вторая:
задумайтесь, что произойдет если браузер отправит сообщение через dbus на запрос перехвата и оно будет принято, а затем браузер упадет.
спойлер:
блокировка засыпания останется висеть и убрать ее не получится, тк таймаут обрабатывается на стороне браузера, но не в менеджере питания.
Цирк короче.
AcckiyGerman
30.11.2025 20:33Извините за критику, но это не решение, а временный костыль.
if (strstr(IN_appname,"chrom") != NULL ) {А если пользователь откроет Brave|Firefox|Opera|любой другой браузер?
А не перезапишется ли патч при обновлении? А если не перезапишется, а у XFCE API для менеджера управления питанием поменялось?
А что насчёт других DE?
Суть проблемы не решена. При просмотре одного видео (фильма) ноут засыпать не должен, а при просмотре другого (рекламы) - должен. Но с точки зрения браузера разницы никакой нет!
Проблема злоупотребления полезной технологией не нова. С уведомлениями на сайтах тоже самое - полезно для условного Gmail, но маркетологи начали злоупотреблять, браузеры начали запрашивать разрешения и теперь на каждом втором сайте нужно отклонять "разрешите показывать вам уведомления".
Я думаю, что с этой проблемой случится то же самое - если злоупотребление станет массовым, то блокировку засыпания просто добавят в список разрешений, требующих одобрения пользователя, как доступ к микрофону, камере, уведомлениям сейчас.
Ну а пока можно просто закрывать крышку ноутбука, отправляя его в сон принудительно.
alex0x08 Автор
30.11.2025 20:33А если пользователь откроет Brave|Firefox|Opera|любой другой браузер?
Тогда он быстренько изучает С и добавляет условие для этого браузера.
А не перезапишется ли патч при обновлении?
Обязательно перезапишется и придется заново повторять процесс. Теперь понимаете ценность source-based дистрибутивов?
А если не перезапишется, а у XFCE API для менеджера управления питанием поменялось?
Если будет любое расхождение версий - все немедленно сломается. И придется повторять все шаги для новой версии. Зато сможете на себе ощутить роль ментейнера пакета, всю боль и страдания при обновлениях апстрима.
Суть проблемы не решена.
Это к Минобороны, только они смогут жахнуть по штаб-квартире Гугла, или где там сидит центр разработки Хрома.
Ну а пока можно просто закрывать крышку ноутбука, отправляя его в сон принудительно.
Вы не поняли глубину пробемы )
Браузер заблокирует засыпание, даже если вы закроете крышку ноутбука (если она управляется через менеджер питания). В статье есть скриншот с сообщением пользователя, который как раз очень огорчился, когда ноутбук не заснул после закрытия крышки.
Теперь понятен смысл статьи?
squns
30.11.2025 20:33Браузер заблокирует засыпание, даже если вы закроете крышку ноутбука (если она управляется через менеджер питания).
Я не настоящий линуксоид, но похоже на проблему приоритетов. Неужели в systemd нет что-то похожего?
R0bur
30.11.2025 20:33Теперь понимаете ценность source-based дистрибутивов?
А на source-based дистрибутивах энергопотребление на пересборку программ при обновлениях не перекрывает проблему энергопотребления из-за бессонницы браузера?
event1
30.11.2025 20:33Извините за критику, но это не решение, а временный костыль.
Это вполне решение, но подходит оно очень ограниченному кругу пользователей.
kma21
30.11.2025 20:33Вот так и получаются новые дистрибутивы или форки софта. Когда авторы делают какую-то несусветную дичь. По крайней мере, по мнению автора форка.
Интересно, а насколько глубоко мейнтейнеры дистрибутива могут лазить руками в код и менять его? Вот можно выпилить данную функцию из XFCE и положить в репозитории своего БолгенОС?
Я не про лицензию или про технические возможности. Я про логику и некую политику - где граница возможностей мейнтейнера дистрибутива. Когда он становится уже разработчиком?alex0x08 Автор
30.11.2025 20:33а насколько глубоко мейнтейнеры дистрибутива могут лазить руками в код и менять его?
Очень глубоко, примерно по локоть :) В качестве примера так выглядит список патчей для Хрома от команды FreeBSD.
Когда он становится уже разработчиком?
Сразу с рождения ) На самом деле это достаточно абстрактные вещи, как и самоопределение программистов.
Grigo52
30.11.2025 20:33Гляньте список патчей, которые Debian или Red Hat накладывают на ядро Linux или на тот же Firefox, там могут быть сотни исправлений, так что технически мейнтейнер может выпилить эту функцию, да, но политически вряд ли. Будет слишком сильное расхождение с апстримом, которое потом будет больно поддерживать.
baalmef
30.11.2025 20:33Хотя в статье речь пойдет о Xfce, аналогичным обазом ведут себя все «большие» окружения — KDE, Gnome, Cinnamon и так далее
Немного подушню, но вообще именно Xfce4 по всем параметрам входит в тройку "больших" окружений вместе с Кедами и гномощелью. Cinnamon, увы, пока лишь в числе стремящихся.
alex0x08 Автор
30.11.2025 20:33Xfce4 по всем параметрам входит в тройку "больших" окружений
Ну вот, а когда-то считался "легковесной заменой KDE".
Stanislavvv
30.11.2025 20:33Если правильно помню, можно запретить управление питанием через политики dbus при помощи конфига в недрах /etc/dbus-1.
Правда, не помню, с какой точностью это можно запретить, то есть, можно ли это запретить только для приложения.
alex0x08 Автор
30.11.2025 20:33Конечно можно, но прежде чем запрещать, стоит осознать
сущность бытиямеханизм работы:Хром посылает сообщение о перехвате, DBus его пропускает в специальный обработчик inhibit, которым является xfce4-power-manager, который решает что с этим делать.
Если xfce4-power-manager решает что можно - посылает еще один сигнал через DBus уже к systemd для реализации этой самой блокировки.
Если запретить механизм inhibit - менеджер управления питанием не сможет работать, поскольку он точно также лишь "отсылает сигналы".
И абсолютно все участники этой сложной схемы просто хотели как лучше, разумеется.
Stanislavvv
30.11.2025 20:33Раз per-app не получится... Остаётся вариант написания фильтрующего dbus-proxy и подмены им dbus для избранных. Всё равно, часть софта через firejail идёт.
Grigo52
30.11.2025 20:33Патчить системные компоненты вручную это конечно круто и по хакерски, но это путь воина-одиночки
Как верно заметили в комментариях, после первого же apt upgrade весь ваш патч улетит в трубу. Более системное решение это либо PR в апстрим, либо создание своего пакета с патчем для своего дистрибутива, либо как предложили, настройка политик dbus
Fromych
30.11.2025 20:33Можно, да. Только проблема в том что апстрим это чинить не спешит, тикеты там годами висят. Поэтому пока дойдёт до фикса, проще собрать свой маленький пакет с патчем и обновлять его вместе с системой
dbus-политики вариант норм, но иногда режут и нужные вещи. Тут уже каждый выбирает что ему больнее: жить с багом или подправить поведение под себя
event1
30.11.2025 20:33Хотя любители тайловых менеджеров — особая раса
сверхлюдей, понять мотивы которых обывателю не дано, так что не буду даже пытаться.Ничего сложного. Если у вас все окна всегда открыты на весь экран и повышенные требования к производительности и повышенная толерантность к сыроватому софту и повышенные требования к настраиваемости, то тайловые менеджеры — для вас.
В остальном, статья хорошая, но решение, мягко выражаясь, очень спорное. В первую очередь — конкретным приложениям не место в сердце управления питанием. Потому что завтра вы поменяете хромиум на бромиум и вся конструкция развалится. Не говоря о том, что вам теперь поддерживать этот патч.
Если приложение не умеет само отключать нужный функционал (кстати, хороший броузер умеет), то можно как-то отфильтровать такие вызовы на dbus.
alex0x08 Автор
30.11.2025 20:33Если приложение не умеет само отключать нужный функционал (кстати, хороший броузер умеет), то можно как-то отфильтровать такие вызовы на dbus.
Тогда вопрос архитектурному гуру: что будет когда ваш "хороший браузер" обновится и утеряет важную настройку, отвечающую за вопрос с питанием?
А это постоянно происходит и с хорошими браузерами и с плохими и даже с самими systemd и DBus, по той простой причине, что серьезная поддержка миграций конфигурации стоит чудовищных затрат и является проблемой даже в коммерческом софте, например в Windows.
Так что ваш совет безусловно идеологически правильный (можете вставить в резюме), но увы не жизнеспособный.
event1
30.11.2025 20:33что будет когда ваш "хороший браузер" обновится и утеряет важную настройку, отвечающую за вопрос с питанием?
Тогда придётся фильтровать dbus вызовы. В любом случае эта странная конфигурация останется на этой странной машине
krendelbok
30.11.2025 20:33Так что ваш совет безусловно идеологически правильный (можете вставить в резюме), но увы не жизнеспособный.
Потеряв голову по волосам не плачут (с). Это ваш костыль ужасно выглядит и никому больше не подойдет. Говорю как чувак, что патчил 2 месяца ollama, чтобы она поддерживала мою видюху. Надоело очень быстро и выкинул её в топку решением, которое делает это из коробки.
ogogoggogog
30.11.2025 20:33Перепись оверинженегров. Просто в кроне проверяем заряд батареи и на Х% говорим shutdown +1
ganzmavag
30.11.2025 20:33Надеюсь для мобильных версий они до такой штуки не додумались? По крайней мере, если браузер в фоне, а не на первом плане.
killbond
30.11.2025 20:33У меня была похожая проблема где-то в начале лета.
ChatGPTЭлектронный болван посоветовал отслеживать статус воспроизведения видео/аудио через Wire Plumber. Идея была проверена и доведена до рабочего решения в виде такого bash скрипта:#!/bin/bash IDLE_LIMIT_MS=900000 # 15 minutes while true; do idle_ms=$(xprintidle) # if wpctl status | awk '/Streams:/,/Video/ {print}' | grep -B1 'playback_' | grep -q '\[active\]'; then if wpctl status | grep 'playback' | grep '\[active\]'; then echo "$(date): Audio playing, skip suspend" sleep 60 continue fi if [ "$idle_ms" -gt "$IDLE_LIMIT_MS" ]; then echo "$(date): Idle and no audio — suspending..." systemctl suspend fi sleep 60 doneЕще понадобится
xprintidle- он выводит число миллисекунд без активности пользователя. Раньшеwpctlумел и видео отслеживать, но с каким-то апдейтом он то ли перестал это делать, то ли мне было лень разбираться, почему сломалось, поэтому я его закомментировал.Получается, каждую минуту смотрим
wpctl status, если проигрывается аудио, то ждем минуту и возвращаемся в начало цикла. Если аудио нет и выводxprintidleбольше чем 15 минут, то отправляем систему в сон, иначе ждем минуту, все.Кладем этот скрипт, например, куда-нибудь в
~/.local/bin, добавляем в автозагрузку, да хоть в том же xfce при логине пользователя и пользуемся. Не надо ничего патчить и перекомпилировать, нет проблем с апдейтами, после окончания фильма сам уснет через 15 мин.
AlexSky
30.11.2025 20:33Может, я не уловил, в чем проблема, но почему просто не зайти на chrome://settings/content/idleDetection и не отключить эту опцию по умолчанию? Или это только в Chromium есть?
alex0x08 Автор
30.11.2025 20:33Во-первых как уже неоднократно упоминал: настройки часто слетают при обновлении,
во-вторых может быть запрос на самом сайте из серии "для продолжения работы пожалуйста включите опцию", как это происходит с веб-камерой и микрофоном.
Плюс такое поведение не у одного только Хрома и отучать все приложения - рука устанет.
AlexSky
30.11.2025 20:331) Поискал по тексту статьи и комментам - все упоминания про проблемы при обновлении относятся к правкам в менеджере питания XFCE. При чем тут настройки Хрома, которые ну никак не должны слетать при обновлении?
2) Про это вообще не было разговора. Приведите пример такого сайта.
3) Сколькими браузерами вы постоянно пользуетесь на одном компьюетере? Я не знаю ни одного человека, кто использовал бы больше одного (фронтендщики на своих сайтах не в счет). Ну и даже отключение в 10 браузерах быстрее, чем то, что описано в статье. И не слетает при обновлениях.
CoolCmd
а не проще сделать простенькое расширение браузера (одна строка js), меняющее
navigator.wakeLock.requestна заглушку? бонус: расширение будет работать не только в chrome, но и в firefox и safari.alex0x08 Автор
Это системная функция браузера, не факт что сработает.
Ну и Хром такой не один, как только в systemd сделали дырку для управления питанием — понеслось, теперь и плееры и видеоредакторы
и калькуляторылезут блокировать засыпание.CoolCmd
js на страницах блокировать сон не сможет, вы же этого хотите. можно указать отдельные сайты.
сам браузер блокировать сможет, например во время просмотра видео.
aborouhin
В Firefox оно, вроде, штатно отключается через about:config (dom.screenwakelock.enabled и media.video-wakelock, не вникал детально, в чём разница в этих двух параметрах)
А по поводу того, как проще - тогда уж надо бы PR в XFCE оформлять, который добавляет настройку "Allow apps to request wakelock", лучше ещё и с выбором приложений, которым можно или нельзя. Иначе пересобирать со своим патчем при каждом обновлении будет, хм... утомительно.
alex0x08 Автор
Это еще один невозможный с точки зрения технических специалистов PR, уже проходили с открытием диалога.