Open Bug 1283670 Opened 4 years ago Updated 4 days ago

--app option to run web applications in "app mode" Feature Request

Categories

(Firefox :: General, enhancement)

enhancement
Not set
normal

Tracking

()

Tracking Status
firefox57 --- wontfix

People

(Reporter: nathan, Unassigned)

References

(Blocks 2 open bugs)

Details

(Keywords: feature)

Attachments

(3 files)

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36

Steps to reproduce:

I want to use Firefox to run desktop web apps similar to Google's Chrome --app functionality. When running firefox --app='myurl.tld' the browser should open to a specified url without toolbars.


Actual results:

Feature Request


Expected results:

Feature Request
Severity: normal → enhancement
Component: Untriaged → Startup and Profile System
Product: Firefox → Toolkit
Component: Startup and Profile System → DOM: Apps
Product: Toolkit → Core
I'm not so sure this is a "Core" request.  After all, Firefox command-line flags are features of Firefox (even if some of them are provided by Gecko code).  And presumably a feature like this would require Firefox's cooperation.  It wouldn't be possibly to simply add it to Gecko and advertise it as a platform feature that happens to be accessible via Firefox.

Regardless, I'm interested in understanding the use case better.

Nathan: are you interested in using a feature like this to create a site-specific browser <https://en.wikipedia.org/wiki/Site-specific_browser>?  And would it be for your own personal use, or do you want to distribute an application that starts Firefox in this mode to other users (f.e. so they can use your website via a site-specific browser)?  Lastly, how would you expect to start Firefox in this mode (via a Windows shortcut, by starting another application that starts Firefox, by manually entering its path on a command line, etc.)?
I have a computer at home that my kids use for some school and entertainment. I found Chrome's --app feature useful because I created specific icons for my younger kids to click on which take them directly to Netflix or Wikipedia or several other sites and the benefit is they do not have bookmarks shown or the address bar. Rather than a web browser it makes it more like an interface and simplifies it for my young kids. (this is all in Fedora KDE). 

I also do this with my own desktop as I use Roundcube for email and I created a chrome --app to access it, along with several other sites, which focuses the use to that specific site.

Along the same lines, at work I realized I could create an icon and share it around the office for users to access some internally developed web applications. In this respect it is really just a neato factor, though it does psychologically affect some people because they no longer look at the web app as a web app but as a real application worthy of consideration.

I appreciate your interest in my use cases, thank you!
After the latest upgrade of Firefox from 47 to 48 some keyboard shortcuts in our web-based erp-application doesn't work any longer. These are essentiell to our customers. For example our users can press CTRL-N to create a new object in the application. Other webapplications are also suffering from this problem.

The same problem exists in newer versions of Chrome but Google provides the application mode (starting chrome.exe with --app) and all our keyboard shortcuts works there. In addition there is a really great interface and a application based icon in the task-bar (based on the favicon of the server).

We welcome the idea of having an app mode in firefox because it will solve our problem.
(In reply to Jan Fader from comment #3)
> After the latest upgrade of Firefox from 47 to 48 some keyboard shortcuts in
> our web-based erp-application doesn't work any longer. These are essentiell
> to our customers. For example our users can press CTRL-N to create a new
> object in the application. Other webapplications are also suffering from
> this problem.

Hmm, I reviewed the Firefox 48 release notes <https://www.mozilla.org/en-US/firefox/48.0/releasenotes/< and I don't see a reference to a change that broke keyboard shortcuts in web applications. (I would have expected to see something related to key events, or possibly something about the behavior of Event.preventDefault/stopPropagation.)

Also, bug 380637 suggests that apps can still override browser shortcuts, although the bug is ambiguous, so it isn't clear whether it refers to keyboard shortcuts generally or Ctrl+S specifically.  Hearing that other apps are experiencing the same problem suggests that it isn't a bug in the apps themselves (unless they share a dependency that does event handling).

Have you tried filing a bug report on the problem?  If you file one with a reduced test case (i.e. the simplest possible web page that registers an event handler for the key event in question and demonstrates the difference in behavior between versions of Firefox), it'd be possible to determine whether or not the change is a regression or an intentional change.


> The same problem exists in newer versions of Chrome but Google provides the
> application mode (starting chrome.exe with --app) and all our keyboard
> shortcuts works there. In addition there is a really great interface and a
> application based icon in the task-bar (based on the favicon of the server).
> 
> We welcome the idea of having an app mode in firefox because it will solve
> our problem.

That's useful information, and it might be the case that an app mode is the only/best way to ensure reliable support for arbitrary keyboard shortcuts.  But I'd still confirm that the change in Firefox 48 is actually intentional, as it might be a regression.
Based on the feedback in the new bug (based on a reduced test case on jsfiddle) https://bugzilla.mozilla.org/show_bug.cgi?id=1301476 the change is intended behavior.
(In reply to Myk Melez [:myk] [@mykmelez] from comment #4)
> That's useful information, and it might be the case that an app mode is the
> only/best way to ensure reliable support for arbitrary keyboard shortcuts.

Our development team can confirm that an app mode works great for them (tested with Chrome) and all keyboard shortcuts (including CTRL-N) works as expected.
 
> But I'd still confirm that the change in Firefox 48 is actually intentional,
> as it might be a regression.

The new bug report with a minimal example (https://bugzilla.mozilla.org/show_bug.cgi?id=1301476) states that this change in the behavior is intentional.

Do Mozilla already have any further plans about the implementation of an app mode? We need a forecast for our customers and their users.

We don't want to change our recommended browser to Chrome but based on the feedback of Mozilla we will discuss this step internally.
(In reply to Jan Fader from comment #6)
> Do Mozilla already have any further plans about the implementation of an app
> mode? We need a forecast for our customers and their users.

I'm not aware of such a plan, but I've set the "productwanted" keyword and am requesting needinfo from a Firefox product manager who should be able to answer that question authoritatively (or redirect the request to another product manager who can do so).
Status: UNCONFIRMED → NEW
Component: DOM: Apps → General
Ever confirmed: true
Flags: needinfo?(jgriffiths)
Keywords: productwanted
Product: Core → Firefox
(In reply to Myk Melez [:myk] [@mykmelez] from comment #7)
> (In reply to Jan Fader from comment #6)
> > Do Mozilla already have any further plans about the implementation of an app
> > mode? We need a forecast for our customers and their users.
> 
> I'm not aware of such a plan, but I've set the "productwanted" keyword and
> am requesting needinfo from a Firefox product manager who should be able to
> answer that question authoritatively (or redirect the request to another
> product manager who can do so).

We currently have no plan to implement Chrome's app mode. Firefox as-is does prevent some keybindings including Cltr+N, on par with other browsers ( including chrome when not in app mode ).

See also bug 1164954
Flags: needinfo?(jgriffiths)
See Also: → 1164954
> We currently have no plan to implement Chrome's app mode. Firefox as-is does
> prevent some keybindings including Cltr+N, on par with other browsers (
> including chrome when not in app mode ).
> 
> See also bug 1164954

Wait, this only addresses keybindings use-case but not main use-case, in Comment #2, which I also have. There was this Standalone add-on ( https://addons.mozilla.org/pt-br/firefox/addon/standalone/ ) that used to do part of that (it missed some functionality but at least did the basic) but it no longer works because something it relied on was taken away, so apparently not even an add-on is an option anymore.
The app mode feature really needs to be added to Firefox. Badly. Just google it and see how many people are requesting it. It is the number one reason our entire organization is not switching from Chrome to Firefox. This feature is becoming standard protocol for companies that have web apps. It's important to simply have an icon on your desktop or task bar that you can click and use a web app just like any other first class desktop app.
I originally wanted this for personal use at home with my kids... Now it is becoming exceedingly important at work. I have developed numerous web applications that we use Chrome with, simply because the higher-ups want a slick icon on the desktop to launch the program.
(In reply to freeman from comment #11)
> Just google it and see how many people are requesting it.

I googled for "firefox app mode" and saw these three people asking about it in the first ten search results:

https://superuser.com/questions/468580/create-application-shortcut-chromes-feature-in-firefox
https://askubuntu.com/questions/487936/how-do-i-open-fixed-window-in-firefox-like-chrome-app-mode
https://www.reddit.com/r/firefox/comments/5wrnsj/is_there_a_app_mode_in_firefox/

I'm unsure how to extrapolate from those numbers to the broader community of potential Firefox users, however.


> It is the number one reason our entire organization is not switching from Chrome to Firefox.

What are the other reasons, and how significant are they relative to this one?


> It's important to simply have an icon on your desktop or task bar that you can
> click and use a web app just like any other first class desktop app.

Is it important for this feature to be built into Firefox, or would it be sufficient for it to be provided by a separate product?

If there was a product that enabled your organization to create distributable desktop/task bar icons that launched a web app in a separate Firefox window, would that product satisfy your organization's needs?  Or is it important for users to be able to create their own icons for any given web app?
(In reply to Myk Melez [:myk] [@mykmelez] from comment #13)
> (In reply to freeman from comment #11)
> > Just google it and see how many people are requesting it.
> 
> I googled for "firefox app mode" and saw these three people asking about it
> in the first ten search results:
> 
> https://superuser.com/questions/468580/create-application-shortcut-chromes-
> feature-in-firefox
> https://askubuntu.com/questions/487936/how-do-i-open-fixed-window-in-firefox-
> like-chrome-app-mode
> https://www.reddit.com/r/firefox/comments/5wrnsj/
> is_there_a_app_mode_in_firefox/
> 
> I'm unsure how to extrapolate from those numbers to the broader community of
> potential Firefox users, however.
> 
> 
> > It is the number one reason our entire organization is not switching from Chrome to Firefox.
> 
> What are the other reasons, and how significant are they relative to this
> one?
> 
The previous most significant issue was not having the security.enterprise_roots.enabled option.
> 
> > It's important to simply have an icon on your desktop or task bar that you can
> > click and use a web app just like any other first class desktop app.
> 
> Is it important for this feature to be built into Firefox, or would it be
> sufficient for it to be provided by a separate product?
> 
> If there was a product that enabled your organization to create
> distributable desktop/task bar icons that launched a web app in a separate
> Firefox window, would that product satisfy your organization's needs?  Or is
> it important for users to be able to create their own icons for any given
> web app?

In a separate window without any other toolbars/extensions etc. Just like Chrome's app mode. That might work...I have been completely unable to find any such app though.
Well I guess that means Chrome remains our company's browser.
Missing of this feature makes me use Chrome. I really want to use Firefox.
It's just opening page without menus, address bar, in new window from console.
I have found a workaround. I make a separate profile directory for the instance like this:
  PROFILENAME="netflix"
  PROFILEPATH="$HOME/.firefox-profiles/$PROFILENAME"
  mkdir -p "$PROFILEPATH/chrome"
  chmod og-rwx -R "$PROFILEPATH"
  echo '#TabsToolbar,#nav-bar { visibility: collapse !important; }'>"${PROFILEPATH}/chrome/userChrome.css"

That last "echo" line adds a chrome/userChrome.css file that hides the toolbar and nav-bar. To start it i use a shell script like this:
  #! /bin/sh
  exec firefox -profile "$HOME/.firefox-profiles/netflix" -no-remote 'https://www.netflix.com/'

It's not perfect though, as I can still create tabs and such via shortcuts (e.g. Ctrl-t) and changing between them with Ctrl-Tab. Hitting the Alt button once also makes the menu bar appear, giving access to a lot of functions like preferences, addons etc, so this isn't perfect as a kiosk mode, but it solves my usecase which was Netflix without all the clutter, since that has all the navigation needed built in to the user interface. I also use it for slack, google calendar, google mail, and internal server monitoring tools. As an added benefit, every profile only needs to be logged in to one website/webapp. The only annoying thing is that I have to copy&paste all the URLs i receive on slack over to my "real" firefox browser, because clicking them would open them as a new tab in my slack profile, and I have hidden all the navigation&tabs.
Hi, 

There is a workaround that allow to make own browser/app using Firefox:
https://github.com/precz/wpaana

Best,
Paweł.
(In reply to pawel.preczynski from comment #19)
> There is a workaround that allow to make own browser/app using Firefox:
> https://github.com/precz/wpaana

On Windows I use a similar system, manually creating separate `application.ini` and Firefox shortcuts to load them. I use these to open separate application-like websites: To-do, Slack, Google Calendar, Trello, Box, IcoMoon, etc.  The only issue with the method, beyond the manual set-up for each shortcut, is that the window takes the default firefox icon (although the taskbar icon uses the shortcut icon correctly.

I see two use cases: fast in-out tools which I open, use, close (To-do, Calendar, Box) and long running application (Trello, Slack) which stay open for longer but are easier to switch to when they live in a separate windows, with a separate taskbar entry.

The closest alternative is the "pinned website" in IE11, which however share cookies and other data with the main IE profile. And being IE, it probably does not have a future.

A `--app` option which open a chromeless window would be a great addition to Firefox. Additional requirements could be:

- open the website in its own context
- open all off-domain links in the default browser
- use the website favicon/manifest icon as application icon
- show a separate taskbar entry
Blocks: 1459977
Duplicate of this bug: 1459663
I would like to manifest that this is an important feature for the company i work to as well!!!

Like i mentioned on bug 1459663: We do not want any kiosk-like limitations. 
We just want a way so we can maximize the usable space for the software we're using (think, for example, OpenERP or solutions that, like that one, are web based). In other words we do want (and need)  page titles and window controls, but we do not need any of the browser specific UI/toolbars and we do not want the browser to start in complete full-screen.

This being able to be applied just to certain shortcuts is also needed because we do need a regular browser to browse the web. So, please, bring back that --app option again!!!
An -app option would be an alternative to some Electron-style applications.

Specifically, the DomTerm terminal emulator (https://domterm.org/) has a server backend written C and a UI front-end written in JavaScript that can run in any "modern" browser.  The current preferred "browsers" re either a small Electron wrapper or a Qt wrapper, because they replace the menubar and other chrome clutter with ones more appropriate to a terminal emulator.  However, using google-chrome -app is *almost* as good as Electron: It removes the chrome clutter and default key-bindings.  (A DomTerm-specific menubar and context menu could be added with JavaScript. (There is also a chrome --app bug in that --window-size is not handled properly.)

In other words: if Firefox could have a working --app (along with --window-size or --geometry) options, it would enable a good UI for some applications (including DomTerm) with less overhead than Electron.
Duplicate of this bug: 1467343
An -app option would be great for Intranet applications at work. We have several web apps that work well in the Chrome "Create shortcut, open as window" environment. Having no URL bar and remembering size and position of the window would be ace. In addition  to remembering size and position being able to set size and position via --geometry would also be ace.
I have several web applications that I want to start at boot, in dedicated windows, with maximum screen real estate. Without this feature I'm forced to use Chrome for this, losing Firefox's privacy protections and requiring manual copy/pasting of URL's from Chrome into Firefox.

I'd be fine with a secondary binary that, when invoked with a URL, resulted in a Firefox window of that URL with no menu or top bars.

I wouldn't object to keeping the bottom statusbar on link mouseover as it does not decrease screen real estate.

IMO clicking a link in this hypothetical app window should respect my OS's configured MIME types if any, opening in another window and potentially a different browser entirely.
Please add this feature.  I want to watch <insert name of video streaming service> on my laptop while I'm working, in a small window in the corner of my screen.  Browser tabs and the address bar take up too much space in a small browser window on a small screen.  Google-chrome's `--app` flag is the perfect solutions, except...I want to use Firefox!
Blocks: desktop-pwa
No longer blocks: 1459977
I think this is a perfect fit for https://bugzilla.mozilla.org/show_bug.cgi?id=720362
(In reply to Maverick from comment #29)
> I think this is a perfect fit for
> https://bugzilla.mozilla.org/show_bug.cgi?id=720362

definitely!
(In reply to pawel.preczynski from comment #30)
> (In reply to Maverick from comment #29)
> > I think this is a perfect fit for
> > https://bugzilla.mozilla.org/show_bug.cgi?id=720362
> 
> definitely!

(i don't have a clue on how to set the "depend on" tag, however ;)
I suspect mkaply is managing that dependency tree, giving him in a needinfo to see if he thinks it fits there.
Flags: needinfo?(mozilla)
Yeah, it probably does. It has come up before.

Chrome's "app" mode is actually pretty straightforward. It only removes the chrome around the browser. Everything else still works (keyboard shortcuts for instance).

So it could just be a matter of creating a slimmed down browser.xul that we load in some cases and figuring out profiles.
Depends on: fx-enterprise
Flags: needinfo?(mozilla)
(In reply to Mike Kaply [:mkaply] from comment #33)
> Yeah, it probably does. It has come up before.
> 
> Chrome's "app" mode is actually pretty straightforward. It only removes the
> chrome around the browser. Everything else still works (keyboard shortcuts
> for instance).
> 
> So it could just be a matter of creating a slimmed down browser.xul that we
> load in some cases and figuring out profiles.

Shouldn't this be the other way around? 
I mean, this bug blocks bug 720362, right?
Flags: needinfo?(mozilla)
No longer depends on: fx-enterprise
Flags: needinfo?(mozilla)
For our use the default profile would be just fine (but then again, any profile would be ok, even a private one).

I suppose this would not require much work - removing all the browser's chrome and opening the url in the default profile
(dealing with more specific cases later, in case any comes up)

This would help a lot around here and for sure enable migrations from Chrome in many cases.
It would also be helpful to have a simple way to give the "app" some extra permissions without requiring an explicit installation by user.  While one can implement menus with JavaScript, they aren't quite as nice as the browser menus - for one the latter can extend outside the browser window.  Clipboard access would be nice.  Etc.
(In reply to per from comment #36)
> It would also be helpful to have a simple way to give the "app" some extra
> permissions without requiring an explicit installation by user.  While one
> can implement menus with JavaScript, they aren't quite as nice as the
> browser menus - for one the latter can extend outside the browser window. 
> Clipboard access would be nice.  Etc.

Agree, but i think that could be left for a second stage of implementation.

A first stage, imho, would basically be just a regular Firefox window without any chrome. Everything just like you would have if you open a normal firefox instance, but with no chrome.

This would bring the vast majority of features needed. Then, in subsequent stages, more specific (and also important) cases like that one mentioned could be studied.

(In reply to Mike Kaply [:mkaply] from comment #33)

Yeah, it probably does. It has come up before.

Chrome's "app" mode is actually pretty straightforward. It only removes the
chrome around the browser. Everything else still works (keyboard shortcuts
for instance).

So it could just be a matter of creating a slimmed down browser.xul that we
load in some cases and figuring out profiles.

So add a new arg to toolkit/xre/nsAppRunner.cpp, modify xpcom/components/nsComponentManager.cpp to load a different manifest file if that arg is specified, slightly modify the files from https://github.com/precz/wpaana and add them?

Could this work or is there a better approach?

Could this work or is there a better approach?

That could theoretically work.

(In reply to Mike Kaply [:mkaply] from comment #41)

Could this work or is there a better approach?

That could theoretically work.

Does this mean we get a change to (finally) see this implemented and solve a few workarounds we have to use in enterprise (and ditch Chrome as well)?

(In reply to Maverick from comment #42)

(In reply to Mike Kaply [:mkaply] from comment #41)

Could this work or is there a better approach?

That could theoretically work.

Does this mean we get a change to (finally) see this implemented and solve a few workarounds we have to use in enterprise (and ditch Chrome as well)?

I did spend a little time looking a try, but I'm not familiar with the Gecko code base.
I'm not sure how to pass the arg from xpcom/components/nsComponentManager.cpp to toolkit/xre/nsAppRunner.cpp and the chrome.manifest/browser.xul seems to be generated (?) somewhere, and I haven't got the time to figure out where.

(In reply to Kristian Klausen from comment #40)

So add a new arg to toolkit/xre/nsAppRunner.cpp, modify xpcom/components/nsComponentManager.cpp to load a different manifest file if that arg is specified, slightly modify the files from https://github.com/precz/wpaana and add them?

Could this work or is there a better approach?

I'm also not familiar with the code. However, from looking this evening, I'd suggest sticking within Firefox rather than XULRunner:

  • first of all, note that the "--app" argument is taken already for running different XUL apps (browser/app/nsBrowserApp.cpp); perhaps "--ssb <url>" would be acceptable for site-specific browser windows?
  • browser/components/nsBrowserContentHandler.js parses the "new-tab" and "new-window" arguments - I'd suggest extending this argument parsing.
  • "new-window" calls openBrowserWindow, which contains a chromeURL variable:

https://searchfox.org/mozilla-central/source/browser/components/nsBrowserContentHandler.js#185

One option is therefore to add a new flag to openBrowserWindow, add a new XUL file, and completely swap out the UI. However, I haven't ruled out the possibility of retaining browser.xul and just disabling the toolbars.

Just to say I'm looking to switch entire family from Chrome to Firefox (although I do like Chrome's print preview and printer options page) and I too need an --app kiosk window option (not full-screen) before I can ditch Chrome. Hoping coming very soon. Thank too.

Heavy Jupyter notebook user here. For maximizing work space, I'd also appreciate an --app mode for Firefox, where all toolbars are switched off. Chrome one works fine, but I'd like to switch to Firefox.

(In reply to Tim Retout from comment #44)

  • browser/components/nsBrowserContentHandler.js parses the "new-tab" and "new-window" arguments - I'd suggest extending this argument parsing.

I tried this, combined with editing the window features to remove the toolbars, and it does work - but interacts with earlyBlankFirstPaint() in nsBrowserGlue.js, which sets the features for the initial window. (So the second and subsequent windows could be opened without menubars etc., but not the first window.)

I think the missing step might be to disable earlyBlankFirstPaint if --ssb mode is requested... but this means parsing the arguments earlier?

This is a fairly ugly way to add an --ssb argument, but it keeps the patch in one place. It might work out neater to add an argument to openWindow?

The patch does not work if earlyBlankFirstPaint is enabled. (Disable it by setting browser.startup.blankWindow to false.)

I'm not sure how to get an argument through to earlyBlankFirstPaint; the argument passing could instead be done as early as nsBrowserApp, but then that needs feeding through to the JavaScript somehow.

Please clarify me of one thing: instead of using --app after a desktop shortcut url we would be using --ssb, is that it?

(In reply to Maverick from comment #49)

Please clarify me of one thing: instead of using --app after a desktop shortcut url we would be using --ssb, is that it?

In the first draft I wrote, yes. It's not impossible to make --app do this, but currently it's used for XULRunner apps. It's also possible to choose a different flag altogether.

Nice! Would be great to have it implemented!

Its a feature that would be of most value to us!

Since it would be used for ProgressiveWebApps how about --pwa ? Or is that taken already?

Just a suggestion :)

I whole-heartedly support this option: Running web applications like native apps is the vision that made me love FirefoxOS. I am now using Chromium's --app mode on desktop, as well as Chrome's app mode on Android to get a similar experience. I would love to use Firefox instead.

Really Really wish this feature was back in Firefox. The only thing that keeps chrome on my computer is enjoying my separate web apps. Seems like every 6 months I search this to see if there has been any updates & improvements. Hell i'd build it if I had any clue where to start. :P lol but it would be sweet to have this back, even if its low priority. With web apps becoming more & more popular I could see this being used much more frequently.

Attached patch wapp.diffSplinter Review

As --app is taken I used --wapp to implement function. So you need to call firefox with --wapp https://google.si
And it doesn't care if earlyBlankFirstPaint is enabled or not.

Attachment #9082982 - Flags: review+

NIing Mossop who is working on some similar things.

Flags: needinfo?(dtownsend)

Who is reviewer for this bug?

Flags: needinfo?(samo.golez)

We're in the process of planning out a feature similar to this. We likely wouldn't accept a patch here until we're done with the current investigations (mostly at the research stage right now).

Flags: needinfo?(dtownsend)

Hum... i just hope that "planning" process won't take another "x years", plus some others to implement.

This is really missing around here!

If I understand correctly kiosk mode is always full-screen but for app mode window should be resizable and not full-screen only. But it is good starting point.

Flags: needinfo?(samo.golez)

After a bit of additional researching I found out that when opening kiosk window a blank window with toolbar is shown. And also kiosk window is not private so we see all it's history in normal Firefox mode. So I will try to use principles from kiosk for rewriting my previous patch to make it more cleaner.

If you want a private kiosk window, you would pass -private.

But it definitely doesn't have a toolbar. What platform are you on?

When you start kiosk mode it is shown for 0.5s probably due to earlyBlankFirstPaint. Look at Tim Retout comments in this bug.

(In reply to Mike Kaply [:mkaply] from comment #63)

But it definitely doesn't have a toolbar. What platform are you on?
Oh I forgot to mention I am on Ubuntu.

Yes, you see flash of the toolbar. In my scenario, it's not that big a deal, but I'll check into what I can do about that. I'll open a separate bug.

I found another issue. If you run Firefox and then run another instance in kiosk mode you get: "Firefox is already running, but is not responding. To open a new window, you must first close the existing Firefox process, or restart your system."

Just my 2cents: I have to manifest that i agree with sagudev -> fullscreen, while a good starting point, is not what we need!

We really need a --wapp like mode! Something that starts maximized, just with a titlebar, but that can be minimized, closed, restored, resized (the normal operations on a window), but with no additional toolbars.

As much as we, as a company, would prefer to use firefox (for his privacy), we really can't use it for that particular case unless something like sagudev described is available.

I'm currently working on it. I also want to make this app mode good starting point for pwa.
@mkaply could you be reviewer for this bug?

Flags: needinfo?(mozilla)

I'm not the right person for this. See Mossop's early comment about our work around this.

Flags: needinfo?(mozilla)

Wait. Kiosk isn't Mossop's "feature similar to this"? Oh, I thought Kiosk was end of his investigation. My bad.
Waiting for @mossop to finish research.

@mossop How's the investigation on this?

Is there something on the horizon from mozilla or can we get @sagudev 's take on it for the time being?

Flags: needinfo?(dtownsend)

(In reply to Maverick from comment #72)

@mossop How's the investigation on this?

Is there something on the horizon from mozilla or can we get @sagudev 's take on it for the time being?

We completed some user research interviews last week. We haven't completed the analysis on that yet so I can't actually say what the conclusions are at the moment. How and whether we move forward with this depends a lot on those results but the hope is that if all looks well to have something testable in nightly before the end of the year.

Flags: needinfo?(dtownsend)

To give an update here, we've started landing some experimental pieces here. See bug 1602117 for a tracking bug for what is going to land initially. Some things I'd like to ask:

  • Don't file bugs or feature requests for the new feature yet. We know the current behaviour is not likely to be the final behaviour and at least for now it is going to be easier to work through some things before we get wider feedback which we'll likely ask for early in the year.
  • Don't assume that what is landing is what is going to ship (or even that it is going to ship!), this is an experiment, preffed off by default for a reason. We still don't have full results from the user research and we're certainly going to learn more as folks play around with the feature.

Great news!!!

A few questions: can we play with the feature already or do you prefer to keep it "internal" for a bit more?

if we can already take a look,
Can you share with us what's the value to be changed in about:config (if there is one)?
Also, does this have any "--app" option command?

Thanks for the update :)

(In reply to Maverick from comment #75)

Great news!!!

A few questions: can we play with the feature already or do you prefer to keep it "internal" for a bit more?

if we can already take a look,
Can you share with us what's the value to be changed in about:config (if there is one)?
Also, does this have any "--app" option command?

Thanks for the update :)

It's landing in Nightly, so not really internal at this point! That said only about half of the patches for the initial experiment have landed, it's probably worth waiting until they are all in. I did just get in this morning to find that all but one patch has been accepted so it will probably only be a day or two until it's all landed.

The pref is browser.ssb.enabled and the command line argument is -ssb. Both might end up changing depending on what we end up calling the feature.

I got DomTerm more-or-less working with nightly.

However, one big problem: It seems to require https, rather than http, even for localhost.
For applications that basically just want to use SBB as a GUI platform for a local application, it would make things a lot smoother and easier if we didn't have to deal with certificates. I'm OK if http is restricted to localhost. Could this be changed?

I was able to get DomTerm minimally-working using ssl, but it was klunky (certificate warnings) and there are some problems.

I know you wanted to hold off on bug-reports, so I'm just mentioning this informally for now.

(In reply to per from comment #77)

I got DomTerm more-or-less working with nightly.

However, one big problem: It seems to require https, rather than http, even for localhost.
For applications that basically just want to use SBB as a GUI platform for a local application, it would make things a lot smoother and easier if we didn't have to deal with certificates. I'm OK if http is restricted to localhost. Could this be changed?

I was able to get DomTerm minimally-working using ssl, but it was klunky (certificate warnings) and there are some problems.

I know you wanted to hold off on bug-reports, so I'm just mentioning this informally for now.

I would like to use this on several local applications, but they are not available via localhost, though they are contained within my private network. Is it possible to restrict http to localhost and private ips?

disclaimer: Not promising anything, experimental, blah blah blah.

Rather than special casing localhost (my understanding is that there are potential ways to make localhost point elsewhere) or needing to do what could be a costly DNS lookup) would it be reasonable to instead add a way to whitelist certain domains from the https restriction or are you expecting users of these apps to be working on machines you have no control over?

Being able to whitelist domains is fine for me.

However, I hope to avoid the user having to accept or install anything. I.e. the whitelist should be on the command line or in a file whose name is specified on the command line.

My goal is for the user to be to start an application (in my case 'domterm') like they would start any application that creates a new window: xterm, gnome-terminal, emacs: The application should not require setup or enabling of permissions before it starts, assuming it has been installed in the PATH, and that it can find the firefox executable.

Similarly, enabling/disabling permissions (for example clipboard access) should be possible from the command line without user interaction.

Being able to whitelist domains in the same command line that you're launching with doesn't really help. It would likely need to be an additional action from the user or something configured in the Firefox install such as default preferences or enterprise policy.

"Being able to whitelist domains in the same command line that you're launching with doesn't really help."

True. Firefox can just as easily infer that if you explicitly ask for a url on the command line, it should be allowed.

"It would likely need to be an additional action from the user or something configured in the Firefox install such as default preferences or enterprise policy."

Why? What are you trying to protect against by disallowing http://localhost:PORT ? If we can't use SBB without "additional action from the user" or configuring an "enterprise policy" that makes the whole exercise much less useful. Chrome's -app works without those steps. Electron works without those steps.

(In reply to per from comment #82)

Why? What are you trying to protect against by disallowing http://localhost:PORT ? If we can't use SBB without "additional action from the user" or configuring an "enterprise policy" that makes the whole exercise much less useful. Chrome's -app works without those steps. Electron works without those steps.

We're showing a website with (currently) no surrounding UI so the user gets no security indicators to let them know whether what they can trust what they're seeing and not something masquerading as what they expect. Requiring SSL helps with this a lot though it's possible it may not be enough. We haven't spoken with the security team yet so it is possible we may need to add further restrictions.

There are no security indicators, but there is no location bar either. So I don't see how https can make a difference if the concern is a malicious site masquerading as some other site. (I'm not a security guy, so I might be missing something.)

It's not that requiring https is inherently a show-stopper. However, I don't know how to do that in a way that doesn't require root access or cause scary warnings or extra manual setup stages. (That just means I personally don't know, not that it isn't possible.) Regardless, it seems a needless and useless (?) requirement, one not required by chrome --app or Electron or Qt or other browsers or browser-embeddings I've tried.

For my use-case (basically using a browser as the GUI for a desktop application - like Electron) it would be ok to require https when the port is 80 (domterm runs a server as the user invoking the command, hence uses a non-system port) - but comment #78 suggests other use-cases.

(In reply to per from comment #84)

There are no security indicators, but there is no location bar either. So I don't see how https can make a difference if the concern is a malicious site masquerading as some other site. (I'm not a security guy, so I might be missing something.)

Exactly why the security team may require more here. But the idea is that if you open a window for foo.com then we want to make sure the only content shown is from foo.com. https mostly ensures this, http does not.

It's not that requiring https is inherently a show-stopper. However, I don't know how to do that in a way that doesn't require root access or cause scary warnings or extra manual setup stages. (That just means I personally don't know, not that it isn't possible.) Regardless, it seems a needless and useless (?) requirement, one not required by chrome --app or Electron or Qt or other browsers or browser-embeddings I've tried.

Electron lets you do it, but they're pretty explicit that you shouldn't (https://electronjs.org/docs/tutorial/security#security-native-capabilities-and-your-responsibility, https://electronjs.org/docs/tutorial/security#1-only-load-secure-content).

Anyway this is all going too deep for now.

"Electron [is] explicit that you shouldn't [load http]"

There a 3 reasons listed in "Why?" at https://electronjs.org/docs/tutorial/security#1-only-load-secure-content.
None seem to be relevant when using localhost, with the server and browser and browser running as the same non-root user on the same host.

I agree this is getting into the details. When you get a chance, it might be help to see what goals and use-cases you're trying to address. The "site-specific browser" concept and use-cases may be very different than the "app mode" feature request, which seems much simpler: A browser window with minimal chrome.

We could probably re‑use the rules for determining secure context‑ness for whether the scheme is allowed for app mode.

It's sad to see that it needs 4 years to start active work on a basic, no offense.
I'm a chrome user since 3 years because of that miss.

--kiosk is great, and near --app mode. Let us tweak it behaviour in about:config.

browser.kiosk.window : maximized|minimized
browser.kiosk.tabs : false|true
browser.kiosk.external_links : default_browser|newtab
browser.kiosk.contextual_menu : true

https://bugzilla.mozilla.org/show_bug.cgi?id=1606245#c5

I tried -ssb on nightly with gmail

firefox-nightly -private --ssb "https://gmail.com"

Just clic on "connexion" then it opens a new firefox instance, not what i expected.
Maybe its related to this : https://gitlab.gnome.org/GNOME/epiphany/issues/597

Duplicate of this bug: 1606245

The suggestion in comment #87 to use the rules fro "secure contexts" seems reasonable and I think it would work for me.

If this change is acceptable, then the sooner we can get it in, the sooner I will be able to test this mode. Is there a bug for this issue?

Ain't this a duplicate of bug 1602168 ?

(In reply to Maverick from comment #92)

Ain't this a duplicate of bug 1602168 ?

See comment #74 - bug 1602168 is one part of the tracking bug 1602117.

Alas - progress seems to have stopped on this. Any hope it might resume?

a agree that i want to see this progress be resumed, the choice to block http://localhost at the very least seems quite stubborn.

Where it is right now, it does show a Title Bar
https://i.imgur.com/uzwMEeS.png

why not make this say "[INSECURE]" or something like that in big bold letters when on a non https:// domain?

I've probably found a bug:

If one uses a desktop icon to fireup a SSB site, that site only loads if we have a "normal" Firefox window already (previously) open.

If Firefox is closed and we fireup a SSB site from desktop, the window/instance opened will remain without ever loading the desired website.

Anyone else experiencing this?

I have been long waiting for this feature, so nice to see it's is finally there, but I noticed a couple of things:

  • Seems like extensions (like ublock) are not active for these windows?
  • Right click seems to be disabled (possible to support kiosks). Is it possible to enable that?

@Maverik @Kevin please open new bugs for potential defects and feature request!
thanks

(In reply to Sylvestre Ledru [:Sylvestre] from comment #97)

@Maverik @Kevin please open new bugs for potential defects and feature request!
thanks

Upon a more detailed investigation my report is definitely related to bug 1604424.
Creating a new profile without ublock (or ghostery or adblock, as all 3 cause the issue) solves the problem

I will elaborate more on 1604424

PS about --app
Visual Studio Code is one of the most used editors in the world. It's all JS, front/back end. It's based on Electron and Electron uses Chromium as a window to show the GUI. Could have been Firefox, but Firefox lack the main option to do that: --app
The same thing Electron does, could be done with a different stack like:
php+nginx (or PHP as a standalone server) + Firefox -app to show the JS GUI.
... unfortunately Firefox has not --app option so must be used Chromium for webapps on desktop.
I think it's a huge gap!

At least on MacOS the App Mode does not create an app link and and is not visible in system Launcher, making almost impossible to use it as a real application.

Chrome does that but it comes with a high price: it forces you to use Chrome when you open links from these apps, ignoring system browser preference. I raised this with them at https://support.google.com/chrome/thread/57952461?hl=en but I really doubt they have any interest in addressing it.

My hopes is that Firefox will address this issue, which is critical for apps that you want to be isolated from the browser windows like chat and video conferencing ones.

(In reply to Sorin Sbarnea from comment #100)

At least on MacOS the App Mode does not create an app link and and is not visible in system Launcher, making almost impossible to use it as a real application.

Chrome does that but it comes with a high price: it forces you to use Chrome when you open links from these apps, ignoring system browser preference. I raised this with them at https://support.google.com/chrome/thread/57952461?hl=en but I really doubt they have any interest in addressing it.

My hopes is that Firefox will address this issue, which is critical for apps that you want to be isolated from the browser windows like chat and video conferencing ones.

Chrome seems to accomplish this by literally generating a "launcher" app that is a real macOS ".app" bundle that they configure to open the web app in its own window that gets treated by the OS as a real app:

https://source.chromium.org/chromium/chromium/src/+/master:chrome/browser/web_applications/components/web_app_shortcut_mac.mm

I find the Web App feature from Chrome to be hugely useful for accessibility to both my children & my parents.
I currently have both firefox & chrome installed on all devices. Firefox for basically everything, then Chrome for media streaming.
to have this option in firefox would mean I could remove chrome.

In Ubuntu, the title in --ssb does not pick up the website's title. For example, DuckDuckGo should show DuckDuckGo - Privacy, simplified, not duckduckgo.com. If it is impossible to get the title from the website opened, it would great if a CLI option is provided to set the title, like --title in gnome-terminal. Also, file:// URIs do not work.

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