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

Status: RESOLVED WONTFIX

(Firefox :: General, enhancement)

Description

[Nathan O'Brennan]

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

Comment 1

[Myk Melez [:myk] [@mykmelez]]

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.)?

Comment 2

[Nathan O'Brennan]

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!

Comment 3

[Jan Fader]

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.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

(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.

Comment 5

[Jan Fader]

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.

Comment 6

[Jan Fader]

(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.

Comment 7

[Myk Melez [:myk] [@mykmelez]]

(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).

Comment 8

[Jeff Griffiths (:canuckistani) (:⚡︎)]

(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

Comment 9

[Jeff Griffiths (:canuckistani) (:⚡︎)]

Sorry, that is instead https://bugzilla.mozilla.org/show_bug.cgi?id=1203059

Comment 10

[J]

> 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.

Comment 11

[freeman]

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.

Comment 12

[Nathan O'Brennan]

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.

Comment 13

[Myk Melez [:myk] [@mykmelez]]

(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?

Comment 14

[freeman]

(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.

Comment 15

[freeman]

Well I guess that means Chrome remains our company's browser.

Comment 16

[pawel.preczynski]

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.

Comment 17

[Daniel Stensnes]

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.

Comment 18

[mikolajp]

This is becoming such a fundamental feature with modern web applications approaching usability of the desktop. 
I thought this was in the works actually, but seeing this thread I am switching back to chrome/brave duo. It is simply strange for such future lay dormant for 2 years and for people from mozilla give half-baked replies that it is not needed. 

As a comparison, here is similar thread for brave: https://github.com/brave/browser-laptop/issues/534 and https://github.com/brave/browser-laptop/issues/8101

Comment 19

[pawel.preczynski]

Hi, 

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

Best,
Paweł.

Comment 20

[dreadnaut]

(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

Comment 22

[Maverick]

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!!!

Comment 23

[per]

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.

Comment 25

[Patrick L Archibald (PLA)]

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.

Comment 26

[Jolleyboy]

+1

Comment 27

[therealplato]

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.

Comment 28

[JRL]

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!

Comment 29

[Maverick]

I think this is a perfect fit for https://bugzilla.mozilla.org/show_bug.cgi?id=720362

Comment 30

[pawel.preczynski]

(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!

Comment 31

[Maverick]

(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 ;)

Comment 32

[Dan Mosedale (:dmosedale, :dmose)]

I suspect mkaply is managing that dependency tree, giving him in a needinfo to see if he thinks it fits there.

Comment 33

[Mike Kaply [:mkaply]]

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.

Comment 34

[Maverick]

(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?

Comment 35

[Maverick]

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.

Comment 36

[per]

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.

Comment 37

[Maverick]

(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.

Comment 38

[[e-mail]]

As to reasons for wanting this, outside of enterprise usage, I tend to use "chrome apps" for web-based desktop app replacements like email, chat, controlling my nest, home-assistant, invoicing, calendar, etc.  Even though I have firefox set as my default browser, whenever I click links in those "apps", a new tab is opened in chrome.  That makes sense since I am essentially already in the chrome browser.  

I'd really rather have all of the above run in firefox, in that it's by browser of choice.  This functionality works great on android, when I save apps to my home-screen.  I want that same functionality for my desktop.  Also having the choice of a new profile per app would be pretty fantastic, and a welcome improvement over chrome desktop "apps", but not absolutely essential.

Comment 39

[Victor Magalhães]

I would really love to see Firefox tackle issues like this one, or making it easy to embed Gecko for Electron-like Gecko-based apps to thrive, or yet stuff like SpiderNode (https://github.com/mozilla/spidernode). By becoming infrastructure, an ecosystem could grow around it that, together with Firefox itself, could enable a positive feedback cycle and network effects that would help it to thrive, even if in a niche. Also, it does already have a foothold among developers, specially those privacy-minded, and those lack alternatives to Chromium, Electron, and V8, and would probably happily make the switch if there were (those very same developers could be the ones submitting patches and collaborating in Firefox development).

It would be a lot of work, of course, and I'm not even implying its currently feasible. That said, as much as I want to see Firefox and Mozilla growing (and I do), I don't see that happening any time soon by means of Firefox-the-product. Maybe Firefox-the-ecosystem would be around as popular, but it would be better equipped to survive in a smaller scale and organically grow.

So that's the unrequested speculative rant from someone not that well informed who hasn't (yet, I hope) contributed with Mozilla in any significant way other than spreading the word, but who deeply want to see the open web and Mozilla thrive. That's probably not the place to talk about this, anyway.

Comment 40

[Kristian Klausen]

(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?

Comment 41

[Mike Kaply [:mkaply]]

Could this work or is there a better approach?

That could theoretically work.

Comment 42

[Maverick]

(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)?

Comment 43

[Kristian Klausen]

(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.

Comment 44

[Tim Retout]

(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.

Comment 45

[Kevin]

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.

Comment 46

[kmichael.aye]

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.

Comment 47

[Tim Retout]

(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?

Comment 48

[Tim Retout]

Attachment: Add --ssb command-line arg; does not work with earlyBlankFirstPaint

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.

Comment 49

[Maverick]

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

Comment 50

[Tim Retout]

(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.

Comment 51

[Maverick]

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 :)

Comment 52

[djoerd]

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.

Comment 53

[badle]

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.

Comment 54

[sagudev [:samson]]

Attachment: wapp.diff

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.

Comment 55

[sagudev [:samson]]

Attachment: Bug 1283670 - wapp option to run web applications in "app mode" Feature Request

Comment 56

[Mike Kaply [:mkaply]]

NIing Mossop who is working on some similar things.

Comment 57

[sagudev [:samson]]

Who is reviewer for this bug?

Comment 58

[Dave Townsend [:mossop]]

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).

Comment 59

[Maverick]

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

This is really missing around here!

Comment 60

[Sylvestre Ledru [:Sylvestre]]

FYI, the kiosk mode landed https://bugzilla.mozilla.org/show_bug.cgi?id=158968

Comment 61

[sagudev [:samson]]

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.

Comment 62

[sagudev [:samson]]

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.

Comment 63

[Mike Kaply [:mkaply]]

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

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

Comment 64

[sagudev [:samson]]

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

Comment 65

[sagudev [:samson]]

(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.

Comment 66

[Mike Kaply [:mkaply]]

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.

Comment 67

[sagudev [:samson]]

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."

Comment 68

[Maverick]

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.

Comment 69

[sagudev [:samson]]

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?

Comment 70

[Mike Kaply [:mkaply]]

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

Comment 71

[sagudev [:samson]]

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.

Comment 72

[Maverick]

@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?

Comment 73

[Dave Townsend [:mossop]]

(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.

Comment 74

[Dave Townsend [:mossop]]

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.

Comment 75

[Maverick]

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 :)

Comment 76

[Dave Townsend [:mossop]]

(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.

Comment 77

[per]

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.

Comment 78

[Nathan O'Brennan]

(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?

Comment 79

[Dave Townsend [:mossop]]

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?

Comment 80

[per]

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.

Comment 81

[Dave Townsend [:mossop]]

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.

Comment 82

[per]

"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.

Comment 83

[Dave Townsend [:mossop]]

(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.

Comment 84

[per]

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.

Comment 85

[Dave Townsend [:mossop]]

(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.

Comment 86

[per]

"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.

Comment 87

[ExE Boss]

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

Comment 88

[eoli3n]

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

Comment 89

[eoli3n]

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

Comment 91

[per]

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?

Comment 92

[Maverick]

Ain't this a duplicate of bug 1602168 ?

Comment 93

[per]

(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?

Comment 94

[merith.tk]

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?

Comment 95

[Maverick]

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?

Comment 96

[Kevin Daudt]

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?

Comment 97

[Sylvestre Ledru [:Sylvestre]]

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

Comment 98

[Maverick]

(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

Comment 99

[Rik]

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!

Comment 100

[Sorin Sbarnea]

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.

Comment 101

[Justin D'Arcangelo [:justindarc]]

(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

Comment 102

[tomblygupgup]

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.

Comment 103

[rswat09]

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.

Comment 104

[Tom Hindle]

@rswat09 - I've created an issue to see what people think of specifying a manifest file on the command line. (so one could control title, icons and various other things)
https://bugzilla.mozilla.org/show_bug.cgi?id=1679575

Comment 105

[Dave Townsend [:mossop]]

As per bug 1682593 we do not intend to support this feature at this time.

Comment 106

[Vic Mortelmans]

As a partial workaround, check out these nice add-ons:
https://github.com/ettoolong/PopupWindow
https://github.com/ettoolong/WebAppMode
The only problem that remains to be solved for me, is that I'm not able to maximize the separate window (in Windows).

Comment 107

[dconner.pro]

(In reply to Dave Townsend [:mossop] from comment #105)

As per bug 1682593 we do not intend to support this feature at this time.

The change in direction for SSB's in Firefox is infuriating.

This only further reinforces my suspicion that a lack of support for SSB's is some kind of spooky NSA/Google conspiracy to prop up the "surveillability" of the web by:

• limiting the number of sets of various identity-markers (particularly cookies, but also other browser signals)
• limiting the complexity of those sets of signals (by lumping almost all of them into one giant subset of cookies, sessions, dns configurations, etc)
• relegating attempts to automate/manage configuration of SSB's to shit like "Peppermint Linux"
• creating a name for something completely unrelated (i.e. some shit like "secure scuttlebutt") to pollute "ssb electron" results, in case someone was like "fuck it i will literally script the creation of dumb electron apps" .... (halfway joking here)
• and about 1,000 other things that I don't want to list, including greatly expanding the possible attack surface that techniques like XSS offer hackers...

SSB's should have been a first-class citizen and available as APPS to any major operating system: for global shortcut key's, etc, etc. This is what seems to have inspired Chrome's "Webapp as App" functionality , which eventually became diluted and bastardized into shortcuts because i wonder why (nsa)... Which means any user automation (like scripting the creation of these or backing up simple declarative configs in dotfiles) is just out of the question. That people can't use operating systems that support them is infuriating!!! (e.g. so we can do OS-level task management stuff with webapps......)

So fuck you mozilla for not going all the way with this feature ... and again enabling the NSA to abort yet another well-meaning attempt to simply UI/UX so that it's not agonizing to use the web (e.g. when you have neurological issues that require keeping track of tabs in various specific ways).

Instead, your Firefox browser has its "container" functionality for cookie storage", which actually makes Firefox use various design patterns that are natural for SSB's done properly. It would seem like SSB's would be the natural end result of some recent traction in Firefox UI/UX developments.

But making it hard to track users for ads (or surveil them: same thing) is a big no-no for Silicon Valley and the NSA .... and any time in technology when "we can't have nice things" you'll find it has something to do with a monopoly's business model or the nsa.

Comment 108

[Maverick]

There is also this very nice addon (with the same limitations regarding auto-maximization on windows, as Vic mentioned):

https://addons.mozilla.org/en-US/firefox/addon/popup/

its a real shame we can't have auto-maximization - but that's a MS-Windows specific problem. In Linux, for example, it works like a charm!

Comment 109

[Tomas Sandven]

Well this is extremely disappointing. I was in the process of switching my default browser from Chrome to Firefox, since I noticed that Firefox has way better Wayland support.

However, one of the main things I do with Chrome is open up a bunch of chat applications in "app" mode (chrome --app=https://...) and tile them in a dedicated desktop. If I do this with Firefox as separate full browser windows, I'll be wasting a huge chunk of the screen on pointless toolbars.

Additionally, I have multiple desktop shortcuts for media applications I use often, like Twitch, Youtube, Netflix, Crunchyroll and so on. Using browser tabs for these applications is super annoying, as I often have to spend time trying to find the right tab when I want to pause a video. I also like to pin these windows to a corner of the screen while I work. This also doesn't work with Firefox since toolbars take up most of the space in the little window.

In short, there's absolutely no way I can use Firefox as a primary browser without some kind of support for launching websites without toolbars from the command line. I personally don't care about the other parts of an "app mode" like support for otherwise occupied keyboard shortcuts or separate taskbar icons, I just want to be able to use web applications in separate windows without toolbars.

Comment 110

[Tomas Sandven]

Adding to my previous comment,

If Firefox had a launch option / command line flag that would launch the browser in "full screen mode", but without actually being full screened, that would solve my issues. When I full screen a browser window, all toolbars disappears. In X11, I could simply do this, then "un-fullscreen" the Window directly in X and the window would remain in full-screen mode, but in a regular window.

This workaround is no longer possible in Wayland for some reason, as the window is apparently informed when Wayland leaves full-screen mode and the toolbars come back.

This feature seems like it should be little effort to add, since all the functionality is already in the browser. You would just have to add a command line flag that forces this mode to always be enabled for the launched window, even though the window isn't full screened.

Comment 111

[Maverick]

(In reply to Tomas Sandven from comment #110)

This feature seems like it should be little effort to add, since all the functionality is already in the browser. You would just have to add a command line flag that forces this mode to always be enabled for the launched window, even though the window isn't full screened.

Well, it's truly a shame this got dropped. I too needed this at enterprise level!
but it does seem to have many more "details"/problems that come with it. So, while for most of us is just a "create a popup with no toolbars", for devs there are many more problems that come from it...

Still... having a easy way to set a desktop shortcut with no chrome toolbars would be gold.

the best i can recommend, as a workaround, is this addon:

https://addons.mozilla.org/en-US/firefox/addon/popup/

You'll have to configure it and it won't work amazingly on windows - in Linux it works like a charm, however...
(The fault is actually on windows that does not allow total-fullscreen from a popup... you have to set dimensions manually)

(yeah yeah... go ahead and mark it as advocacy - i honestly don't care anymore!)