Firefox в полноэкранном режиме

Иксы еще окно не отрисовали (или еще какая хрень не догрузилась), а ты его уже телипаешь на фулскрин. Задержку в несколько сек точно ставил, увеличивал? Возможно перед запуском фф тоже нужна.

Это возможно?

Если твой WM не умеет (а какой у тебя WM?), то попробуй поставить devilspie. Напиши правило в ~/.devilspie/firefox.ds:

(if 
  (is (application_name) "firefox")		
  (begin
    (fullscreen)
  )
)

(я надеюсь, что в правиле не ошибся - писал вслепую)

какой WM ? В моем bspwm это можно местными средствами делать, при этом firefox все валидно подхватывает

Нет, всё бодро грузится, открывается бразер, но не разворачивается на полный экран. Задержку увеличивал до 9 секунд. Никакого эффекта. Т

Unity. Ubuntu 14.04.5.

А перед запуском фф задержку ставить пробовал?

Тогда, может, поставить Compiz Config Settings Manager? Там есть подобные настройки для каждого приложения в разделе Window Management -> Window Rules + Place Windows

Да, пробовал.

Всем ещё раз спасибо за идеи!

Всем ещё раз спасибо за идеи!

Ну а как решил задачу в итоге?

В теле темы всегда пишу, чтобы люди долго не листали переписку).

В теле темы всегда пишу, чтобы люди долго не листали переписку).

Ну, если честно, то решение с xdotool странное. Для твоей задачи инструмент хоть и рабочий, но такое решение — кривой костыль. Какие-то паузы выжидать. Зачем? 11 секунд! В иксах есть механизмы присвоения окнам свойств в момент их появления. Окно еще не отобразилось, а WM уже будет знать, как его отображать. То есть это либо оконные менеджеры умеют сами, либо сторонние средства типа devilspie (а в случае Unity — CCSM).

https://askubuntu.com/questions/428850/open-windows-maximized

К тому же, твое решение некорректное. Ты хоть понимаешь, куда посылается F11? Оно посылается не конкретно окну firefox, а окну, которое на момент срабатывания xdotool будет иметь input focus. Если кто-то перехватит фокус за твои 7 секунд (что-то вскочило на экране), то F11 firefox не получит.

Исправил код. Замечание верное. Фокус реально сбивался).

Задержка нужна, т.к. глючный Wi-Fi адаптер долго подсоединяется к сетке. Если он не соединится вовремя, браузер раскроется на весь экран со страницей ошибки. В итоге, время задержки было увеличено аж до 27 секунд (!). Это киоск, фэйлы с незагруженными страничками - крайне не желательны. А так, да, если коннект быстрый, смысла ставить такое долгое время нет.

У огнелиса есть расширения для режима киоска.

Создай отдельный профиль firefox --ProfileManager и установи туда расширения необходимые. Потом стартуй по firefox -P <имя_профиля>.

И запускать через N секунд после старта тоже некорректно. Скриптом проверяй поднялась ли сеть, а потом стартуй огнелис.

Исправил код. Замечание верное. Фокус реально сбивался).

xdotool search --name 'Firefox' && xdotool key "F11"

Ты его странно исправил, это мягко говоря. :) Твой код ничего не делает. То, что ты написал, не делает ничего. Надо хотя бы так (classname, class, name можно посмотреть в xprop, например):

$ xdotool search --classname "Navigator" windowactivate --sync key "F11"

Это киоск, фэйлы с незагруженными страничками - крайне не желательны

А для чего киоск вообще нужен? Пользователь имеет доступ к клавиатуре? Он может нажать F11 и вывести FF из полноэкранного режима? Может, тебе вообще оконный менеджер не нужен в принципе, если компьютер будет без доступа к клавиатуре и выполнять только одну задачу серфинга по интернету.

Пользователь имеет доступ к виртуальной клавиатуре, на которой отсутствуют функциональные клавиши и клавиша Ctrl. Сама система нужна для настройки некоторых устройств и сервисов.

C чего ты взял, что он ничего не делает? У меня он делает следующее: открыто для теста окно хрома, окно терминала, из которого выполняю этот скрипт. В итоге, открывается Firefox и разворачивает на полный экран, окна хрома и терминала остаются прежними. Всё работает.

Unity

Зачем это вообще на киоске?
Я когда-то делал для цати штук по районам, ничего кроме X не использовалось, никаких вм итп.
firefox --display=:0 -P /настроенный/профиль
Домашняя директория в чистом tmpfs с профилем воссоздается из тарбола перед каждым запуском фф, во избежание. По вкусу можно использовать tmpfs+overlay
Экранная клава, емнип, была в виде дополнения к фф.
Стартовало все мгновенно и ничего не ломалось.

Нет, не делает. Что эта строчка делает? Она в первой части просто запрашивает XID окон, которые подходят под критерий "-name 'firefox' и выводит их в stdout, а потом выполняет xdotool key "F11", где <F11> снова достается окну, у которого фокус ввода. Если перед FF что-то перехватит фокус, то ему <F11> не достанется. Об этом я, кажется, выше сказал. Хочешь проверить? Пожалуйста. Открой FF, открой терминал перед FF. Терминал имеет фокус ввода. Теперь в терминале введи свою строчку.

$ xdotool search --name 'Firefox' && xdotool key "F11"

Что ты получаешь? Первая часть просто выведет номер, вторая передаст <F11> терминалу, а Firefox так и станется в своем состоянии, ничего не получит. То есть то, что ты пытался исправить после моего замечания, не исправлено. А теперь попоробуй мою строчку из такого же состояния.

Аналогично. Надо было поставить на ЦЭВМ торгового автомата браузер, так как интерфейс у них был написан на HTML. Вкатил FF (тогда еще был xulrunner). Но надо было, чтобы в приложении была только область рендера и никаких там менюшек, кнопок, табов, строки статуса и пр. Написал тривиальный XUL, в котором осталась только область отображения нужного размера (тег <browser>, вертикальный экран 1440x900). Все стартовало со стартовой странички в атрибуте «src». Никаких там WM, ничего, только голые Иксы.

vmrunner/chrome/content/vmrunner.xul:

<?xml version="1.0"?>
<?xml-stylesheet href="chrome://global/skin/" type="text/css"?>

<window xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
        id="vmrunner"
        windowtype="vmrunner:main"
        width="900" height="1440"
        title="VMRunner"
        sizemode="maximized"
        onunload="shutdownApplication(false)">

  <browser id="main-browser" flex="1" type="content" src="http://localhost/~vm/"/>
</window>

Прошли те времена ...

Когда я запускаю в скрипте, то всё выводится нормально. Если выполнить отдельно команду, то да, раскрывается терминал.

А теперь попоробуй мою строчку из такого же состояния.

Попробовал. На экране появился браузер Firefox. Раскрытия на весь экран не было.

Попробовал. На экране появился браузер Firefox. Раскрытия на весь экран не было.

Этого не может быть. Какую строчку ты попробовал? У меня все раскрывается после того, как FF выдвигается вперед.

Вот эту команду ввёл в терминале при раскрытом сзади Firefox'e:

$ xdotool search --classname "Navigator" windowactivate --sync key "F11"

А FF поднимается поверх терминала после выполнения этой строчки?

Да, фокус переключается на Firefox.

Да, фокус переключается на Firefox.

Не знаю. Должно работать. У меня работает из любого положения - пусть даже FF похоронен по десятью окнами. Он должен поднять окно FF, дождаться конца этой операции и только после этого переслать F11. Не знаю, в чем может быть дело у тебя. Попробуй добавить delay:

xdotool search --classname "Navigator" windowactivate --sync key --delay 200 "F11"

если команду написать так:

xdotool search --classname "Navigator" windowactivate --sync; xdotool key "F11"

Я на федоре пробую. Не знаю, наверное, не имеет значения.

ТЫ делаешь то же самое, что и делал. xdotool передает F11 окну, которое имеет фокус, а не конкретному окну. Но у меня есть предположение, почему так происходит. Подчеркну, что это предположение. У меня FF еще старый, так как я хочу подзадержаться на GTK2. FF на GTK3 меня выбешивает, а у тебя наверняка все наоборот.

Ситуация такая. Когда в параметрах xdotool указывается конкретное окно, то он использует для передачи сообщения F11 клиентское сообщение SendEvent, а если окно не указывается (то, как ты сделал), то используется расширение XTEST, которое посылает кнопку тому, кто владеет фокусом. Есть одна фишка, что некоторые тулкиты или отдельные приложения могут фильтровать сообщения SendEvent и поэтому никак не реагировать. Этот момент много где описан и также в xdotool:

SENDEVENT NOTES
       If you are trying to send key input to a specific window, and it does
       not appear to be working, then it's likely your application is ignoring
       the events xdotool is generating. This is fairly common.

       Sending keystrokes to a specific window uses a different API than
       simply typing to the active window. If you specify 'xdotool type
       --window 12345 hello' xdotool will generate key events and send them
       directly to window 12345.  However, X11 servers will set a special flag
       on all events generated in this way (see XEvent.xany.send_event in
       X11's manual). Many programs observe this flag and reject these events.

       It is important to note that for key and mouse events, we only use
       XSendEvent when a specific window is targeted. Otherwise, we use XTEST.

       Some programs can be configured to accept events even if they are
       generated by xdotool. Seek the documentation of your application for
       help.

       Specific application notes (from the author's testing): * Firefox 3
       seems to ignore all input when it does not have focus.  * xterm can be
       configured while running with ctrl+leftclick, 'Allow SendEvents' *
       gnome-terminal appears to accept generated input by default.

FF на GTK2 реагирует, а вот на GTK3 может не реагировать. Тогда выходя нет - поднимать окно и тут же второй командой через XTEST долбить F11.

... вот только откуда этот «навигатор»?

А я же выше написал. Из xprop например.

xprop | grep "WM_CLASS"

Интересная инфа. Спасибо!

Ну, да. В общем, я тут проверил на Evince, который GTK3. Игнорирует он сообщения, отправленные ему напрямую. При этом если фокус имеет, то сообщения через XTEST нормально отрабатывает. Чудится мне, что это политика уже на уровне GTK3 сделана. Возможно, что из каких-то своих соображений безопасности. О таких соображениях, например, в xterm говорится:

       allowSendEvents (class AllowSendEvents)
               Specifies whether or not synthetic key and button events
               (generated using the X protocol SendEvent request) should be
               interpreted or discarded.  The default is “false” meaning they
               are discarded.  Note that allowing such events would create a
               very large security hole, therefore enabling this resource
               forcefully disables the allowXXXOps resources.  The default is
               “false”.

То есть твой последний вариант с отдельным xdotool после поднятия окна наверх единственный рабочий вариант (поднятием окна заведует WM, а не приложение, поэтому оно-то срабатывает).