Open Bug 1636168 Opened 5 years ago Updated 1 month ago

Firefox sometimes doesn't launch in kiosk mode under openbox when kiosk flag is specified

Categories

(Core :: Widget: Gtk, defect, P5)

Product:
Core
Component:
Widget: Gtk
Type:
defect

Tracking

()

Status:
ASSIGNED

People

(Reporter: aritz, Assigned: jhorak)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

kiosk-log.txt
5.25 KB, text/plain
Details
Bug 1636168 Ensure switch to fullscreen when it fails in GTK; r=stransky
48 bytes, text/x-phabricator-request
Details | Review

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:76.0) Gecko/20100101 Firefox/76.0

Steps to reproduce:

Run Firefox in a barebones openbox session in Ubuntu 20.04 (Started with startx), opened up xterm, then typed in "while true; do firefox -kiosk; done", then kept pressing ALT+F4 to re-start Firefox. Also tried with different flags, such as --new-window and --private-window.

Actual results:

Firefox would sometimes not start in kiosk mode, but instead its normal mode as if -kiosk mode wasn't specified.

Expected results:

Firefox should launch in kiosk mode 100% of the time. Unsure if this is a bug in firefox or openbox. Chrome appears launch in its kiosk mode 100% of the time in my tests, but Firefox doesn't exhibit this behavior in KDE.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Component: Untriaged → Startup and Profile System
Product: Firefox → Toolkit
Component: Startup and Profile System → Untriaged
Product: Toolkit → Firefox

Is it possible Firefox was already running somewhere?

This issue occurs whether or not the firefox launched in xterm was the only firefox process or not.

If anyone would like to reproduce this issue, they can grab the latest version of lubuntu at https://lubuntu.me . That uses openbox, and I've been able to confirm that the issue happens there, too.

Component: Untriaged → Enterprise Policies

Because this bug's Severity is normal and has not been changed, and this bug's priority is -- (none,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Severity: normal → --

confirming, but I have no explanation as why. It seems pretty random.

Severity: -- → S3
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P5

Same issue with jwm on Debian Buster

Is it some kind of race-condition?

Looking at the code I did notice that FullScreen.init() (line 2055) is called before window.fullScreen = true (line 2113). If I move FullScreen.init() to line 2116 it seems to work better (the navigation bar is only shown shortly but the title bar is still shown).

Tested with Firefox 78.0b7 and manual "patching" like so:

cd /opt/firefox
mkdir tmp
cd tmp
nano chrome/browser/content/browser/browser.js
unzip ../browser/omni.ja
zip -qr9XD ../browser/omni.ja *

Fullscreen init should just be initing the fullscreen service and then window.fullscreen is the thing that makes it fullscreen. still researching.

@mkalpy: Did your research reveal anything new?

Unfortunately not. I'm still looking. Sorry.

This bug also affect xfwm and icewm.
Can be easily reproduced by using a docker container (bug occurs every second time).

Honestly, I'm not a Linux user and so I just haven't had time/resources to look at this.

We're received a bugreport regarding issue lately. I'm able to reproduce it only with upstream binaries and sway and not with Fedora binaries - which make debugging quite difficult. I've noticed the command line parameters are processed from there:
https://searchfox.org/mozilla-central/source/toolkit/xre/nsAppRunner.cpp#5251
It looks like it's called after the final-ui-startup observers are notified. Could not its observers run some code asynchronously and be faster before the gKiosk is set? I wish I could reproduce it with the debugbuild or custom build, but so far no luck.

Hm, will try the "manual patching" Kristian suggested.

Thanks. I just haven't had a chance to look at it.

Attached file kiosk-log.txt —

According to stacktraces which triggers on getting gKiosk value it looks like when the kiosk fails the "fullscreen" event is not triggered for the browser-fullScreenAndPointerLock. Not sure why ATM.

Looks like problem with nsWindow::MakeFullScreen (gtk implementation). I'll work on it next day.

Sometimes the window is not switched to fullscreen after call of MakeFullscreen because
other window mode change arrive too with later time. Gtk then ignores the fullscreen
request which breaks the kiosk mode and window stays maximized instead of fullscreen.
This patch resend the fullscreen request if it failed before.

Assignee: nobody → jhorak
Status: NEW → ASSIGNED

I'm glad this has moved forward since I've reported it almost a year ago, though @stransky mentioned with in the phabricator comments, "I'd rather remove the toplevel window state restoration at session manager than hacking the fullscreen/restore race condition here."

Which finally gives the reason why as to Firefox sometimes doesn't start in kiosk mode... because it's attempting to position itself while restoring a previous session, even though kiosk mode is activated. With that in mind, I have come up with this workaround for starting kiosk mode in Linux, it's surprisingly simple: start in private mode while specifying the location and the dimensions of the window:

firefox --new-instance --kiosk --private-window https://duckduckgo.com --top 10 --left 10 --width 400 --height 400

I'm running this in the same infinite loop as before, and so far it has never failed to start in kiosk mode!

(In reply to Martin Stránský [:stransky] (ni? me) from comment #21)

Dupe of Bug 1727815 ?

No, that particular bug specifically has to do with Wayland, this issue appears to be caused by a race condition between window placement of a previous session and starting kiosk/full-screen mode.

Since I commented last, I found that if one does not want to use a private window, (i.e., keep cookies and such) this issue can be worked around by setting the following preferences to false.
browser.sessionstore.restore_on_demand
browser.sessionstore.restore_tabs_lazily

Sorry, there was a problem with the detection of inactive users. I'm reverting the change.

Assignee: nobody → jhorak
Status: NEW → ASSIGNED

ARitz, is it still an issue for you or can we close it?
Thanks.

Flags: needinfo?(aritz)
Blocks: wayland
Component: Enterprise Policies → Widget: Gtk
Product: Firefox → Core
Version: 76 Branch → unspecified

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Flags: needinfo?(aritz)

(In reply to Martin Stránský [:stransky] (ni? me) from comment #25)

ARitz, is it still an issue for you or can we close it?
Thanks.

Launching kiosk mode still requires the workarounds I mentioned

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: