mirror of
https://github.com/netblue30/firejail.git
synced 2026-05-15 14:16:14 -06:00
[GH-ISSUE #1947] Firefox exit code question #1305
Labels
No labels
LTS merge
LTS merge
bug
bug
converted-to-discussion
doc-todo
documentation
duplicate
enhancement
file-transfer
firecfg
firejail-in-firejail
firetools
graphics
help wanted
information_old
installation
invalid
modif
moved
needinfo
networking
notabug
notourbug
old-version
overlayfs
packaging
profile-request
pull-request
question
question_old
removal
runtime-permissions
sandbox-ipc
security
stale
wiki
wiki
wontfix
wordpress
workaround
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: github-starred/firejail#1305
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @reinerh on GitHub (May 17, 2018).
Original GitHub issue: https://github.com/netblue30/firejail/issues/1947
A Debian user of firejail reported that since 0.9.54 he observes a different exit status (1 instead of 0) when opening new tabs in Firefox (ESR 52) with
firejail --name=firefox firefox-esr $url(when an instance is already running).As I can't reproduce that behavior on my machine, I'm curious if other users are seeing this issue too.
Could someone please try it out as well?
@SkewedZeppelin commented on GitHub (May 17, 2018):
fwiw I was unable to reproduce under the following
Firefox 60 on Arch
Firefox ESR 60.0.1 on Arch
Firefox 60 on Fedora 28
Icecat 52.7.3 on Fedora 28
and I did indeed test by first launching an instance and then passing a URL the second time
@netblue30 commented on GitHub (May 19, 2018):
I'm not seeing it on my computers also.
@chiraag-nataraj commented on GitHub (May 30, 2018):
Huh, I'm actually seeing this (just tested it). With an instance of firefox already running:
@reinerh commented on GitHub (May 30, 2018):
@chiraag-nataraj that is interesting. when you run it the second time without firejail, does it then exit with 0 or also with 1?
@chiraag-nataraj commented on GitHub (May 30, 2018):
It repeatedly gives me 0 no matter how many times I run it or how I interleave it with
firejailruns (thefirejailruns similarly give me 1 no matter how many times I run it or how I interleave it with regular runs).@reinerh commented on GitHub (May 30, 2018):
@chiraag-nataraj which distribution are you using? is
which firefoxa binary or a shell script that is starting firefox?@chiraag-nataraj commented on GitHub (May 30, 2018):
I'm on Debian Sid.
which firefoxis/usr/bin/firefox, which is a symlink to/usr/lib/firefox/firefox, which is a binary.@reinerh commented on GitHub (Jun 3, 2018):
@chiraag-nataraj could you please try to bisect the commit that "broke" that behavior?
In the git repo you can call "git bisect start 0.9.54 0.9.52" (as we know it's broken in 0.9.54 for you, and working in 0.9.52). It will then start a binary search for the commit causing the issue.
Each time you recompile/reinstall firejail and try to reproduce the issue. If it's still there you call "git bisect bad" (when it's exiting with 1), and "git bisect good" if it's working as expected (exiting with 0).
Sorry to bother you again, but you seem to be the only one here who is able to reproduce it.
@chiraag-nataraj commented on GitHub (Jun 3, 2018):
@reinerh I'll experiment and report back 😊
@chiraag-nataraj commented on GitHub (Jun 3, 2018):
Wait, what the hell. I'm now getting 0 as expected. This is really bizarre.
@chiraag-nataraj commented on GitHub (Jun 3, 2018):
I suspect this may have to do with the fact that I upgraded firefox in the interim. Going to check some things and report back.
@chiraag-nataraj commented on GitHub (Jun 3, 2018):
Okay, I give up. This had nothing to do with the firefox upgrade and I'm now consistently getting 0 as the return value no matter what I do... ❓❓❓
@reinerh commented on GitHub (Jun 3, 2018):
@chiraag-nataraj okay, interesting.
thanks for trying it!
@chiraag-nataraj commented on GitHub (Oct 3, 2018):
I think we're not going to be able to solve this, since none of us are able to replicate. I'm going to close this for now. If it comes up again, we can re-open.