It sounds like the better option for your situation would be using the WebsiteFilter Firefox policy to block all URLs except for the ones that you want your employees to have access to.

This would be the preferred method of achieving what it appears you are trying to achieve. Hiding the address bar completely may have undesirable side-effects.

You could simply block everything and then add approved content as an exception. For example:

{
  "policies": {
    "WebsiteFilter": {
      "Block": ["<all_urls>"],
      "Exceptions": ["http://example.org/*"]
    }
  }
}

Firefox policies may also have a number of other useful restrictions that you may wish to implement. For more information on using Firefox policies, please refer to Customizing Firefox Using policies.json.

Hope this helps.

It strikes me that FF must be rather poorly implemented inside, if there isn't a way to separate UI elements from its internal functionality. I consider it poor UI design if the UI is cluttered with elements that are _not_ functional. Things, in our case, like search history, predictive suggestions, configuration knobs, etc. The sheer complexity of what has been revealed to me in my research, just for doing what seems to me like very simple and common operations, bodes ill for getting the desired result using this browser as an implementation engine for our site.

The userChrome.css gives you a way to hide things, once you finally discover the correct name, but that affects _other_ elements that shouldn't be tied together. I don't want somebody to be able to _type_ an address, why does turning off this collection box render the whole concept of history null and void?

This particular site is not for employees, but the general walk-up public. Not all of them are all that savvy. Not all of them are friendly. We want it pretty constrained. And yet attractive.

I really don't want a separate firewall type of patch, because the marketing department, who creates our site, does not have access to the firewall list that would be associated with it. I would be spending an inordinate amount of _my_ time chasing _them_, and it would be _my_ fault any time I didn't get it exactly right.

jcathey said

I've spent much time trying to craft a userChrome.css, and it never works right. Every time I get close, something else is badly broken. For example, I _finally_ got the address box turned off, so they can't type in addresses, but now the Back button is non-functional.

So in what environment are we talking here? This sounds more like a IT initiative in which the browser is installed as Admin and then the Standard user account is restricted as to what it can and can't do. In a Browser environment if you can type in it they will go to it.

Here's are some other options.

How to Block Web Browsers at the Router Level https://smallbusiness.chron.com/block-browsers-router-level-50407.html

How To Restrict Internet Access Using Group Policy (GPO) https://thesysadminchannel.com/how-to-restrict-internet-access-using-group-policy-gpo/

What your trying doesn't sound like that will work.

jcathey said

This particular site is not for employees, but the general walk-up public. Not all of them are all that savvy. Not all of them are friendly. We want it pretty constrained. And yet attractive.

In that case, you definitely want something more restrictive than what you are attempting to do.

You're not going to get the desired behaviour from your userChrome.css because hiding the address bar stops Firefox's ability to accurately determine the history for the back and forward navigation buttons.

Can you post the content of your userChrome.css file because it sound that your selected aren't specific enough? See also:

• https://developer.mozilla.org/en-US/Tools/Browser_Toolbox

cor-el said

Can you post the content of your userChrome.css file because it sound that your selected aren't specific enough?

My assumption is that the OP is attempting to use the following code:

#urlbar {
     display:none !important;
}

This breaks the history navigation buttons because Firefox loses access to the address bar. I can confirm that this is the case, as I have tested in my installation of Firefox.

It might be better to use {visibility:collapse !important} in such a case to keep the toolbar in the DOM.

Add code to the userChrome.css file below the default @namespace line.

• http://kb.mozillazine.org/userChrome.css

@namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"); /* only needed once */

#urlbar-container {visibility:collapse !important}

I believe I have it working as desired now, using

#urlbar {visibility:collapse !important;}

in addition to my other changes in the CSS file. Thanks to all for the pointers! Speaking as a layman, things like "display:none" and "visibility:collapse" are semantically equivalent. In no way does the former indicate that there are more side-effects than just not displaying something. I think FF pretty much solidly violates the "principle of least astonishment" in this area.

The kiosk rules are described very simply:

• Anything that marketing puts on the site should be reachable, even including external links to various associated businesses-du-jour;
• Users should not be able to get to anything else via any means whatsoever, be it as innocuous as Facebook or as offensive as kiddie porn. The kiosk is there for a specific purpose, and that is not internet-by-the-hour;
• Users should be able to navigate the entire site, going backwards and forwards easily;
• Users should not be able to damage the kiosk in any way short of a hammer, so no configuration changes, modes, preferences, etc. We run FF in private browsing mode, so no permanent cookies, etc.

So, anything fire-wally just doesn't cut it, especially since I would have to tree-walk the entire site daily in order to ensure the firewall was up to date.

I spent days on this, researching and experimenting, and finally asking for help. In no way should it have been this hard, FF was in practice nearly unusable for the purpose, and I was already experimenting with other browsers. FF is still not my ideal choice, because nowadays it refuses to run correctly without an X Window Manager, which the kiosk otherwise does not want or need. (Finding a simple-enough one of those was another major project, driven only by FF.) FF cannot seem to collect text box information without a WM.