3341 - Kiosk mode (similiar to fullscreen but blocks access to certain features)

Status: RESOLVED WONTFIX

(SeaMonkey :: UI Design, enhancement)

Description

[rw263]

On the Navigation Toolbar, how about an option for full screen view?

Comment 1

[Paul MacQuiddy]

Assigning to marketing guru

Comment 2

[Michael La Guardia]

Considering....

Comment 3

[Matthew Tuck [:CodeMachine]]

How would this work with "open in new window"?  Do all mailer/browser/composer
windows get this, and you have to use the menus to switch?  What about
modeless dialogs/windows like bookmarks, history, find and address book, can
they still overlay the screen?

Comment 4

[Matt Schmitt]

What about doing this for Macs as well. Instead of a full screen view button, why
not just have it fill the entire screen on the Mac window. Completely hide the
background and make it an option to make the window smaller and make the desktop
viewable.

Comment 5

[MenTaLguY]

Shouldn't this be for all platforms, rather than just MacOS?  Granted, the

approaches on different platforms will probably need to be subtly different, but...



It may be useful to look at how IE handles this feature; it seems relatively

natural in this case.  Namely, open new window from a full-screened window

creates another full-screen window, but full-screen does not otherwise apply to

other kinds of windows.



In IE, fullscreen mode always hides the titlebar, so there really need not be

any differences in behavior between platforms with common titlebars and those

without.

Comment 6

[Joseph Elwell]

Changing OS from Mac to All, as I would also like to see this enhancement on
Windows and Linux.

Comment 7

[leger]

Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.

Comment 8

[Richard Zach]

*** Bug 28554 has been marked as a duplicate of this bug. ***

Comment 9

[Joseph Elwell]

I'm assinging this bug to myself. I actually already did some work on Win98 -
nothing to holler about and documentation for windows programming was hard to
find. So I'm going to tackle programming the full screen view in for Linux first. :)

If anyone cares to interject just shout.

Comment 10

[Joseph Elwell]

I wasn't able to implement full Screen on Linux, however I made some notes that
I think with a little help from a Mozilla developer we could get this working.
Here's the code that I think this needs to be added to an XPIDL interface:
/* save current window size and location */
gdk_window_get_origin (GTK_WINDOW(mShell), &x, &y);
gdk_window_get_size (GTK_WINDOW(mShell), &w, &h);
/* resize window to full size */
gdk_window_move_resize (GTK_WINDOW(mShell), 0, 0, gdk_screen_width(), gdk_s
creen_height());
/* This sets the Screen to unchangeable size. */
gtk_window_set_policy(GTK_WINDOW(mShell), PR_FALSE, PR_FALSE, PR_FALSE);
/* set borderstyle to eBorderStyle_none */

/* resize window and replace window back from whence it came */
gdk_window_move_resize (GTK_WINDOW(mShell), x, y, w, h);

With all that, I really couldn't figure out if fullscreen mode could be done in
Javascript without adding any new XPIDL. The only thing I was successful in
doing was adding a FullScreen option into the "View" menu just under Page
Source. like so:
add to mozilla/xpfe/browser/resources/locale/en-US/navigator.dtd
 <!ENTITY fullScreenCmd.label "Full Screen">
add to mozilla/xpfe/browser/resources/content/navigatorOverlay.xul
 <menuitem value="&fullScreenCmd.label;" oncommand="BrowserFullScreen();"/>
add to mozilla/xpfe/browser/resources/content/navigator.js
 function BrowserFullScreen()
 {
 }

Comment 11

[shuang (gone)]

assign to don and see whether he can find someone from browser group ater to 
review the code. I don't think this is a  high priority feature at this point, 
though. 

Comment 12

[Simon Lucy]

Perhaps not to Netscape, but it is to other implementors.

Comment 13

[Matthew T (active 1999-2002)]

UI suggestions:

* Full-Screen Mode has an item in the View menu, but does not have a navigation
  toolbar button by default. (It won't be used often enough to warrant it.)

* In Full-Screen Mode on all platforms, there is a menu bar and a status bar, and
  nothing else by default. Other toolbars can be shown and hidden, and their
  persistent states are stored separately from the persistent states for
  non-full-screen mode.

* Back, Forward, Reload, Stop, and Full-Screen Mode buttons appear (in that
  order) at the right end of the status bar when Full-Screen Mode is active,
  regardless of whether the navigation toolbar is currently open. For the
  moment, these could just be buttons which are hidden when not in Full Screen
  Mode. But eventually, once horizontally adjacent toolbars become possible, this
  could become a Mini-Navigation Toolbar which could be moved around, and used
  even when not in Full-Screen Mode.

Comment 14

[Joseph Elwell]

UI decisions aside. I think the important part is getting the backend code to
support javascript's ability to move the browser into full-screen mode. Once
that is done packages and skins (chrome) can be used to decide the look and feel.

Comment 15

[Henri Sivonen (:hsivonen)]

I think it would be nice to have a full screen mode for presentations, 
but a site should *not* be able to enable the full screen mode via 
JavaScript. (Script access should be only allowed from chrome.)
Imagine all the Web designers who want to have absolute 
control of your user experience hijacking the entire screen all of a 
sudden.

An item in the View menu is the right way to go.

Comment 16

[Simon Lucy]

So long as moveTo and resizeTo are supported any script can go to full screen.
Actually, the simplest method I've found for full screen is to move the origin 
of the screen up and then resize it to the full screen size, that way you 
needn't muck about with changing Window props or the WindowClass on the fly.

Comment 17

[Eli Goldberg]

QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs 
to Matthew Thomas ([e-mail]).

Matthew Thomas is now the QA owner for the User Interface: Design Feedback 
component. (Bugs that involve UI issues in the Netscape-branded Mozilla browser 
should continue be QA assigned to [e-mail].)

Comment 18

[Blake Ross]

*** Bug 38108 has been marked as a duplicate of this bug. ***

Comment 19

[Karl Ove Hufthammer]

Have you seen what Opera 4 (beta 3) does with its full screen mode?

Try <URL: http://homepages.tig.com.au/~mcgarry/opera/styledemo/index.html > in O4b3 and press F11. Opera uses the media specific 'projection' style sheet (if it exists) for full screen mode, including support for 'page-break-before/-after'.

If full screen ever gets implemented in Mozilla, it should IMHO do the same thing. If a page hasn't specified a 'projection' style sheet, everything will get rendered as usual (just like printing a web page which doesn't have a printer style sheet), but if it *has* specified a 'projection' style sheets, this will get used (in addition to 'screen' and 'all' style sheets).

Comment 20

[James "Kovu" Russell]

I'd like to note that this is the one feature that IE has over Netscape, at 
least as far as I know about IE. When arguing with a friend about whether or not 
Netscape is better, that's the ONE thing you cannot argue against: IE can give 
you a display that's nothing but Web and Netscape can't.

Comment 21

[Matthew Brealey]

This is important: the existence of a ($10) product for Netscape 4.* to do this 
shows that. I also frequently see a lot of mentions of how useful the IE 
version is. In fact, the only reason I use Opera 3.6 is because of this feature, 
and (one of) the reasons I deleted v4 was that the feature wasn't as good.

Here's how it should work (basically the way that Opera 3.6 implements it, with 
an amendment):

F11 - Full-screen mode - no title bar, address bar, toolbar no nothing. [This is 
implemented by IE and Opera]
[These keystrokes are used by Opera 3.6, but disabled in v4, with the addition 
of Shift+F11):
Ctrl+F11 - toggle menu bar on and off
Alt/Cmd+F11 - toggle address bar on and off
Shift+F11 - toggle everything else (these can be grouped, since they aren't very 
useful)

For example, I like to surf with just the address bar.

Comment 22

[Jeremy Wrinkle]

Attachment: This is a fullscreen mode patch that works in the current nightlies. The fullscreen mode is in the view menu.

Comment 23

[Jeremy Wrinkle]

woops, I forgot to mention, if u have a toolbar hidden when u hit fullscreen 
mode, it will come back. Tjis patch basically allows you to toggle all the 
toolbars at once.

Comment 24

[Tim Larson]

I'd like this to be a 3-way toggle.  
1.  Normal window, sized how you like it.
2.  Window unchanged horiz., but using the max available screen height.
3.  Full-screen, hiding unnecessary chrome, etc.
The reason that I suggest this is that I use a Mac, where I actually find my 
desktop useful.  I need to get to it easily at all times.  But I'd still like my 
browser window to use "all" of the available space, once I've set the window 
width to comfortable reading size.  Netscape 4.x bothers me because new windows 
waste vertical space.
An option of how you'd like new windows opened (for "open link in new window" 
and such) would be good.  With choices of the 3 above, and a 4th for "whatever 
current window is."

Comment 25

[Daniel Bratell]

*** Bug 47157 has been marked as a duplicate of this bug. ***

Comment 26

[Blake Ross]

*** Bug 23208 has been marked as a duplicate of this bug. ***

Comment 27

[Adrian]

FullScreen mode would be usefull.

Comment 28

[Eugene Savitsky]

Any milestone suggestion?

Comment 29

[timeless]

Yes: please don't spam bugs. Lecture: timeless don't spam people's bugs. 
Response: Jeremy Wrinkle if you want my help with this bug I can (for now i'm 
taking it off don's hands). As the owner it is ok for me to spam this bug.

Marking helpwanted, mozilla0.9, patch. also adding review, hopefully Blake or I 
will review and work on getting this a fix onto the patch.

To all: feel free to silently add yourself as cc or to vote for this bug. I 
don't care about either of those, nor does anyone else. By participating in 
bugzilla we accept that. As a developer/contributor I want the bug comments to 
be relevant to the work I will do or would need to do to get something done, I 
should not need to read people apologizing for spamming a bug, that's more spam 
than I see when I get bugmail.

Comment 30

[Blake Ross]

Please attach new, TIP-updated patches in standard cvs diff -u form.  I can't 
review entire files.

Comment 31

[Matthew T (active 1999-2002)]

--> XPApps/GUI (will need cross-platform QA when it's done).

Comment 32

[timeless]

Exotrip's patch will only do the chrome work. We still need the back end 
support.

Blake: can we find someone who can work on that?

I suspect that this will not be completed until after mozilla0.9 I do have 
exotrip's code almost written well enough for blake to review.

Comment 33

[Zach Lipton [:zach]]

I talked to timeless and I am going to take this bug. I cannot really do the 
full screen view, but that can come in a little while. What I will do to start off 
is create a "kiosk" mode that hides features and creates something that 
can be used for a kiosk. I am working on this and I will post updates to 
this bug.

Comment 34

[Robin Lionheart]

Opera 5.0 does something very clever in full-screen mode, it goes into
projection mode (what it calls "OperaShow").

It reloads style sheets using the media type "projection" instead of "screen".
Then it splits the current document into pages (using the CSS2 style
descriptions like page-break-before:). The PgUp and PgDn keys then flip through
the pages like a slideshow.

See Opera's website for more details (http://www.opera.com/opera5/operashow.html).

Comment 35

[Zach Lipton [:zach]]

This is no slideshow mode, but you can get the point. I am attaching 
patches to do the following:

1. Make the mac build system build this
2. Add a 'kiosk' package to mozilla that will hide most UI elements. 

What is not done:

1. Menubar slimdown
2. Building on unix and windows (I don't understand the system, can 
someone HELP?)

This is a 'prerelease' of this. Don't expect it to work, but if it doesn't please 
let me know.

Note: The 'kiosk' directory goes in extentions and the mac build patches 
should be applied to allow things to copy over into place.

Comment 36

[Zach Lipton [:zach]]

Attachment: Patches to the mac build system for kiosk mode

Comment 37

[Zach Lipton [:zach]]

Attachment: Kiosk directory in extentions where the magic happens

Comment 38

[Zach Lipton [:zach]]

Attachment: file in mozilla/xpfe/bootstrap that puts the kiosk mode choice in the bin directory.

Comment 39

[Zach Lipton [:zach]]

Attachment: file in mozilla/xpfe/bootstrap that puts the kiosk mode choice in the bin directory.

Comment 40

[Zach Lipton [:zach]]

Sorry. I attached the bootstrap file twice there. Just ignore one of them.

Comment 41

[Zach Lipton [:zach]]

Attachment: screenshot

Comment 42

[Brian 'netdragon' Bober]

You need a windows person? Hmmmm.... where is a windows person. Oh yeah, I know 
a lot about windows, can I help? :)

I'll see what I can do.

Comment 43

[Matthew T (active 1999-2002)]

Full-screen mode and kiosk mode are not the same thing. A user shouldn't have to 
cripple her browser in order to get full-screen mode; and she shouldn't have to 
go into full-screen mode in order to set up a kiosk for her children.

Since this bug is now mainly about kiosk mode, resummarizing and split off bug 
68136 for full-screen mode.

Zach, here's the dialog I told you about on IRC today:

  +--------------------------------------------+
  | Kiosk Mode ::::::::::::::::::::::::::::::::|
  +--------------------------------------------+
  | You can use Kiosk Mode to restrict access  |
  | to features and settings in Navigator.     |
  |                                            |
  | [/] Block _printing                        |
  | [/] Block access to _History               |
  | [ ] Block _saving of files                 |
  | [/] Automatically _return to home page     |
  |     if inactive _for: [5 minutes       :^] |
  |                                            |
  | Password: [                              ] |
  |                                            |
  | /!\ To exit Kiosk Mode, choose "End Kiosk  |
  |     Mode" from the "Tools" menu, and enter |
  |     the password again. You cannot exit    |
  |     Kiosk Mode by restarting Navigator.    |
  |                                            |
  |                     ( Cancel ) (( Start )) |
  +--------------------------------------------+

Comment 44

[timeless]

[This list is a tree, and should probably only show X rows, all rows that I 
could think of now are shown]
Allow:
/--------------+-\
|-local        |^|
|  Open        | |
|  Printing    | |
|  Saving      | |
|-chrome       | |
|  Prefs       | |
|  History     | |
|  Mail        | |
|  Editor      | |
|  <Add>       | |
|-protocols    | |
|  http        | |
|  https       | |
|  gopher      | |
|  file        | |
|  about       | |
|  telnet      | |
|  javascript  | |
|  data        | |
|  <Add>       | |
|-mime         | |
|  all plugins | |
|  inline helper applications
|  spawned applications
| +List        |v|
\--------------+-/
[          |v] automatically return to homepage 
/---------------\
|Do not         |
|after 5 minutes|
...
\---------------/
Password: [                              ]

There is definitely enough stuff here for a preferences pane.

Comment 45

[Joseph Elwell]

Mathew Thomas: you just invalidated all the votes for this bug. This bug has
always been about Full Screen mode, and a reduced UI.

Comment 46

[timeless]

The indentation in 24728 is off [1666,1677] :-(, can you mention the mime types 
for these files? [i'll work on improving bugzilla later]

Comment 47

[Matthew T (active 1999-2002)]

Joseph: Sorry, blame Zach. The patches here are for Kiosk mode. I consider 
patches to be slightly more important than votes.

Timeless: I started thinking of it as a prefs panel, until I realized that doing 
that would be an effective way of making sure that the people who would be most 
likely to want to use the feature (parents, grandparents, etc) would not be able 
to understand it. Providing the bewildering number of options you suggested would 
be an excellent way of doing that, too.

Comment 48

[timeless]

grandparents aren't likely to use kiosk mode, and i expect beonex or 
someone else will offer default kiosk settings [we could create the panel, but 
imo that customization is beyond our scope].

Filed bug 68470 and bug 68471 for a preferences interface.
Filed bug 68473 and bug 68474 for a kiosk warning dialog and a menu item to 
leave kiosk mode.

Comment 49

[Alan S. Jones]

I not sure where this comment should live, but it might be nice to have Kios 
mode prevent a user from browsing a local drive like C:\ and seeing to much :)

Also I added this next comment in 68474 but wanted to mention it here as this 
seems to be main bug.
==
I am confused/concerned about a menu item to leave kiosk.
Kiosk mode i have heard talked about would not let a person do anything but 
browse the web and lock the rest of the computer down (even ctrl-alt-del for 
windows users).  

Having a menu item to exit is fine, but it sounds like it should be password 
protected so just anyone can't exit.
===

Comment 50

[timeless]

Filed bug 68501 for the password dialog.

Comment 51

[Zach Lipton [:zach]]

Ok. To clarify EVERYTHING. This bug is for KIOSK mode. This is for 
stores and things that want to restrict a user to their own site and not be 
able to access most nav features. 68136 is for FULL SCREEN mode. 
This is for home users and such who want a simple interface that filles 
the whole screen. Hope this clears things up.

Comment 52

[Alan S. Jones]

As far as Kiosk mode goes, after seeing so much debate and talk i decided I 
should add a few things.  

In my opinion the first thing is to get the back end of Kiosk Mode working.
The associated prefs (and more) that timeless mentioned on 2-8-01 @ 8:09.  First 
roll out does not need a UI to configure it.  Let people edit all.js or some 
other pref's file to turn on/off every Kiosk setting.  

Let people beat up on Kiosk mode itself before adding a front end.  Most 
corporate people can edit a preferences file by hand and copy it to other 
machines as needed.  

Kiosk mode should also include 2 options.  One that allows free browsing to and 
accepted web site, or only allowing browsing to specific domains.  Restricting 
to specific domains could be useful if you only wanted to brows a corporate site 
and several related sites.

Lock down and control to turn as much on and off as possible should be a big 
key.

After Kiosk mode is done right all we should have to do is lock a PC in a 
cabinet so a user can touch only the keyboard and mouse.  Then depending on what 
is allowed restricts the user.  No access to the rest of the system.

Comment 53

[Hixie (not reading bugmail)]

(Note that Kiosk mode should not need to worry about locking down other aspects
of the OS, only aspects of the browser. So we don't need to block Ctrl+Alt+Del
or Ctrl+Alt+Backspace or Cmd+Power or whatever. That's up to the OS to do.)

Comment 54

[Oliver Klee]

*** Bug 69219 has been marked as a duplicate of this bug. ***

Comment 55

[Chris Charabaruk]

Adding self to cc.
Any other word on just plain vanilla full-screen, a la IE4/5?

Comment 56

[Zach Lipton [:zach]]

Timeless: the mimetype for 24728 is text/plain, diffs. 24729 is a zip file.

Comment 57

[Robin Lionheart]

Well, we could reopen bug 28554 if we want a separate entry for plain vanilla full-screen mode.

Comment 58

[Chris Charabaruk]

Robin, the fullscreen bug is, as it's been said on here so many times, bug 68136.

And for those who are concerned on kiosk mode, would following links from an
allowed site to one that's neither set up as allowed or disallowed work? And
what would one see if he tried to access a site that is disallowed? Lastly, how
about a way to get a list of allowed and disallowed sites from another computer?

Comment 59

[timeless]

the restrictions should be covered in bug 68470 and bug 68471

Comment 60

[Zach Lipton [:zach]]

As I sit here in the 0.9 targeting zarro boogs meeting, I realize this isn't 
going to get in. bumping ahead.

Comment 61

[R.K.Aa.]

*** Bug 81547 has been marked as a duplicate of this bug. ***

Comment 62

[Jason Chambers]

I was wondering if this kiosk mode will be configurable on how it will work. IE, lock 
out prefereneces etc. yet allow for find, search documents and print. Have some 
type of administration password so you can modify the configuration settings.

Or should I file a new bug for this to be requested.

Comment 63

[Chris Charabaruk]

Is there a metabug for kiosk mode? Or is this it? And if this is it, why isn't
it marked so?

Comment 64

[Zach Lipton [:zach]]

Fine, it's a metabug :)

Comment 65

[Jason Chambers]

I was wondering if bug 104389 should depend on this, because i think that bug
would be implemented in kiosk mode would it not?

Comment 66

[timeless]

no because someone might pick that up separately

Comment 67

[Nicolas Combelles]

I'm new here and doesn't want to interferebut :

>>------- Additional Comment #57 From Robin Lionheart 2001-02-27 20:57 -------
>>Well, we could reopen bug 28554 if we want a separate entry for plain vanilla 
>>full-screen mode.

Seems to be a good idea. 
Here we have the kiosk mode (seems to be about security)
The user-setting fullscreen mode

And I've seen some people talking about the scripting (webmaster setting) 
fullscreen mode for window.open (some calls it vanilla ???)

I don't really know how this work .. could someone tell me :

- If that question is already answered as  NO ?
- If we could debate it bug 28554 (reopening it)

Sorry if i'm not clear it's not my natural language ;)

On french webmaster's forums I see at least one or two people each week who ask 
how it works for IE ( window.open('page.htm','','fullscreen')
And all those peoples are making IE-only sites when they see NS/MOZ doesn't 
support it.

So i think this should really be implemented in Moz. Implementing Iframe, 
innerHTML, and MozOpacity are going this way. I mean webmasters plebiscite 
those smart usefull and easy to learn functionalities. 

Well i'm not going to tell more if nobody wants to discuss that point (and i 
know there are much who are against it) but i know much people are interested 
so ... 

Can someone a bit more experimented do something ? (sorry if i made too much 
reading :> ) 

Comment 68

[Brian 'netdragon' Bober]

Nicolas:

What I think this bug is about is a "kiosk" mode that hides features and creates
something that can be used for a kiosk. It will limit what the user could do so
Mozilla could be used for things like searching for a book in a library or
bookstore without the user using it to go to their favorite sports site.

Bug 68136 is about full-screen mode (I changed which bug this depends on from
bug 109603 to bug 68136). It is about a user-controlled full-screen mode , not
making a window maximized when its opened. The user would click F11 and the
window would take up the entire screen.

It is not about a site being able to open a page full-screen (which I think
personally is a very bad feature). I entered javascript:
window.open('page.htm','','fullscreen') in Internet Explorer and it made a
fullscreen window without any UI (just the web page) and I had no way of closing
it but end-tasking it (which is a terrible feature imho). Although, that feature
might be OK if the user does it himself by pressing some key, and has a way to
exit it by right clicking on the context menu or pressing another key. To make a
web page able to open itself fullscreen would just be a bad idea in my humble
opinion.

If you want that to be possible, I recommend reading bug 68136's comments and
saying you want an ability to hide all UI in full-screen mode, because basically
what IE does. I doubt, though, you will get someone to implement the feature
where a web page has the ability force itself or a popup window fullscreen.
Internet Explorer has this problem where it lets a web page control too much of
the user's system. We don't want to copy that in Mozilla.

As you can see by going to it, bug 28554 is a duplicate of bug 3341 (which is
incorrect in my opinion) - I think it should be a duplicate of bug 68136. What I
think you are looking for is bug 68136. Therefore, we would not reopen bug 28554.

Comment 69

[Amaury Jacquot]

I think that both full screen and kiosk should be available.
However, there should also be a "full screen kiosk mode" that should be
available which could be used to create touch screen devices (read, multimedia
public things, like local tourist info thingies, public transportation tickets
dispensing...).
The mode should be only available with a command-line option and there should be
a way to deactivate it with a javascript call (that would show a password dialog
box).

Comment 70

[Matthew T (active 1999-2002)]

Nicolas, Amaury: This bug is about kiosk mode. If you want to write irrelevant 
comments about full-screen mode, don't spam this bug with them. Instead, write 
them on a piece of paper, then throw the paper in the nearest trashcan.

Comment 71

[Mark Bitterling]

Shouldn't kiosk mode depend on
<http://bugzilla.mozilla.org/show_bug.cgi?id=55181> and/or
<http://bugzilla.mozilla.org/show_bug.cgi?id=68409> to provide the kiosk user a
means to clear out the stored authentications?

I would hate to use a kiosk that did not allow me to manually logout of all
websites that I might have authenticated to before I walked away from the kiosk.
 The timeout suggested by the W3C spec may also be of interest, but I personally
think that some UI is needed because I would not want to count on it to time our
before another person used the kiosk.

Comment 72

[Mark Bitterling]

Bug 65212 talks about calling
nsIProfile::ShutDownCurrentProfile(SHUTDOWN_CLEANSE) followed by
nsIProfile::SetCurrentProfile("guest") in order to reset a kiosk user's profile
which I assume would clear out all stored authentication.  Is it agreed that
this is a satisfactory solution for user logout for kiosk mode?  

If so, then it should be fairly simple to create the UI to make those calls, but
if it is hardcoded to the "guest" profile then I am not sure that the same UI
would be useful for bug 55181 or bug 68409 since they woud require more flexibility.

Comment 73

[Zach Lipton [:zach]]

Personally, I'm not convinced that this is something that mozilla needs to 
do. Rather than try to trim things out of mozilla and build in all sorts of 
special cases, why not have an embeding product to do this?

I no longer want this bug -> nobody

Comment 74

[Chris Casciano]

Mark, I'd argue that no it shouldn't have those dependencies. I just read
through all the comments and everything indication is that this kiosk mode is
for use in a retail or display envrionment where the focus is on repeated
displaying a small subset of the web (like one website, or folder on a local
file system).

It does /not/ sound to me like "kiosk mode" is intended in an envrionment like a
web cafe where folks will be doing seriuos web surfing and need to clear out
their amazon cookies or log out of their corporations super secret http based
autenticated web site.

As I see it, the way this "kiosk mode" is inteded is that if there's something
like purchacing/credit card use or information gathering going on in the display
kiosks all the privacy/security concerns should be handled via smart development
on the web server's end along with perhaps the disabling of back/forward
mechanisms on the browser end.

So what I'd envision in a kiosk is essentially the combination of:
  - a full screen/chromeless mode
  - a way to disable keyboard commands
  - a way to disable mouse driven contextual menus

  - a method to enter kiosk mode with a default start page (preferably
automated, via command line to allow a script to activate it on reboot)
  - a secured method to exit kiosk mode.

And I'm kinda on the fence re: comment 53, as I would always need to lock out
things like CTRL-ALT-DEL if there is a full keyboard available to users of the
kiosk. 

But over all I say let the content drive the navigation here.

Comment 75

[amutch]

While it appears that this bug has been abandoned, it should be noted that
Netscape 4.x provided a kiosk mode which was called from the command-line with
the "-k" switch. Also, later version of Netscape/Communicator 4.x provided the
"super" kiosk mode that was called from the command-line with the "-sk" switch.
The primary difference between the two modes was that the "super" kiosk mode ran
a in a frameless border that occupied the entire screen. It was the perfect mode
for kiosk applications. 

The point is that this bug is over 3 years old and the lack of kiosk modes from
Mozilla 1.0 will represent the absence of Netscape 4.x functionality that should
have been included.  Also, Internet Explorer provides a kiosk mode.

Comment 76

[Alex Hosking]

This sounds like a great idea
Espesialy comment 43

Comment 77

[Alex Hosking]

isnt this the same as bug 68136 ?

Comment 78

[Chris Charabaruk]

Re comment #77:

No, no it is not. Kiosk mode != full screen mode. IIRC, they were attached
sometime in the past, but this has always been about a kiosk mode for places
like libraries, stores, etc. as far as I could ever tell.

Comment 79

[Jessica Blanco]

Attachment: Patch for kiosk mode

I used what had been done for fullscreen mode to get kiosk mode working. With
this patch, just a browser window will display fullscreen with no menubars,
statusbar, sidebar. The context menu, shortcut keys, and accesskeys will not
work (F7, F5, Alt+<-, Alt+Home, Alt+->, and Alt+A do work). You can copy and
paste in text fields. If a user clicks on an email link, the Composer window
will come up. But if someone's using kiosk mode, there shouldn't be any email
links. When using kiosk mode a user would only be browsing the site given and
could navigate and submit info through the site's links/buttons. I looked at
this on OS/2 and Windows. You would need to close the browser by Ctrl+Alt+Del.
This works by setting a Preference in prefs.js.

user_pref("browser.kiosk_mode", true);

Comment 80

[amutch]

i just tested the patch with 1.2 beta and it just needs a minor update:

this line in fullScreen.js needs to be changed from:

+            els[i].setAttribute("moz-collapsed", "true");

to 

+            els[i].setAttribute("collapsed", "true");

Otherwise, it works like a charm! 

Anyone in Mozillaland willing to take this patch in for a review?

Comment 81

[amutch]

With the noted correction, this patch also works in Mozilla 1.2.1.

Just as a note, while most of the shortcut keys are disabled, you can use 
ALT+F4 to close the kiosk window.

Comment 82

[Christian :Biesinger (don't email me, ping me on IRC)]

Comment on attachment 94247 [details] [diff] [review]
Patch for kiosk mode

requesting review on behalf of comment 80
(patch is not by me)

Comment 83

[amutch]

The patch, with the correction I posted, works in Mozilla 1.3 alpha. Can we 
reset the target milestone to 1.3??  Once this is checked in or concurrent 
with this approval process, I would like to see a command-line switch, like -
k, that would also start in this mode.

Comment 84

[Brant Gurganus]

Anybody want to updated the Target Milestone since 1.1a is out.

Comment 85

[Alex Hosking]

Moving 
BUT ONLY BECAUSE 1.1a IS PAST NOT BECAUSE I'M GOING TO FIX IT.

Comment 86

[Jessica Blanco]

Attachment: updated patch for kiosk mode

With changes from bug 176640, the browser would no longer open in kiosk mode
with the above patch(94247). Using the code from the previous patch, I now set
the size and location when setting the browser to full screen in
nsGlobalWindow.cpp(this code use to be there). Because the browser gets the
persisted sizes when opening a new window, it needs those sizes set before
opening a new window in kiosk mode. I also modified nsXulWindow.cpp to no
longer constrain the size and position of a window if in kiosk mode so it can
take up the whole screen.

Comment 87

[jag (Peter Annema)]

Comment on attachment 114226 [details] [diff] [review]
updated patch for kiosk mode

Asking danm for r=, hewitt for sr=. I'm not sure if sizing the window to the
screen's width and height is the right approach here.

Comment 88

[Jessica Blanco]

I set the size of the kiosk mode equal to the width and height of the screen
because when a user uses the browser in this mode, they shouldn't have access to
other windows such as the start bar on Windows. 

Comment 89

[Dan M]

Sizing to the screen seems like the thing to do, if you can hide the Windows
taskbar. Forgive me, I've been studiously ignoring this bug, and I don't see the
answer to this question anywhere recent. Why do you have to size the window
twice, once in widget and then once again immediately afterward in GlobalWindow?
The move/size in widget should reset all the persistent size information. If not
I think we have another bug.

Comment 90

[Brian 'netdragon' Bober]

In Windows, sizing to fullscreen != going fullscreen. Examples of true
full-screen applications are games like those that use DirectX (Quake3,
Counterstrike). Do you want to totally bar the user from getting at anything on
the computer? If so, there might be a way to get around a simple resize.

Comment 91

[Dan M]

Granted. But why is this not taken care of in the specialized widget method for
doing just that

+++ dom/src/base/nsGlobalWindow.cpp	12 Feb 2003 16:49:04 -0000
@@ -1975,6 +1975,20 @@
   if (widget)
     widget->MakeFullScreen(aFullScreen); <--------- HERE
 
+  // Set screen size when going into full screen.
+  // Needs to be done when opening browser in kiosk mode
+  // because browser gets the persisted sizes when opening windows
+  if (aFullScreen) {

? Why does it need to be done a second time, immediately afterward,
...
+    MoveTo(0,0);  <-------- HERE
+    ResizeTo(width, height);

Maybe I'm missing something important, but to my eye one of these two
implementations has to go.

Comment 92

[Brian 'netdragon' Bober]

danm: Take a look in function MakeFullscreen
http://lxr.mozilla.org/seamonkey/source/widget/src/xpwidgets/nsBaseWidget.cpp#4
99

and especially: 
http://lxr.mozilla.org/seamonkey/source/widget/src/xpwidgets/nsBaseWidget.cpp#5
17

Would placing the following before the call to MakeFullScreen help?:

+  if (aFullScreen) {
+    nsCOMPtr<nsIDOMScreen> screen;
+    GetScreen(getter_AddRefs(screen));
+    PRInt32 width, height;
+    screen->GetWidth(&width);
+    screen->GetHeight(&height);

Comment 93

[Dan M]

Yeah... that's what I'm looking at. I'm still not seeing it any better. It's not
the order I care about, it's the duplication. The patch seems fine to me except
for the modification no nsGlobalWindow.cpp. Why the redundancy? Can no one
explain why the window has to be sized twice? Why must
  Resize(0, 0, screenWidth, screenHeight, PR_TRUE);
be immediately followed, or preceeded, or accompanied in any way, by
  MoveTo(0,0);
  ResizeTo(width, height);
does the window have no widget? Are the sizes different? Is two simply better
than one? Did it come to somebody in a dream? Does it make ferrets squeal with
delight? What?

  And then, the good reason whatever it is implies something's amiss with the
widget method. What's the underlying bug?

Comment 94

[Jessica Blanco]

The reason I added MoveTo() and SizeTo() functions in nsGlobalWindow.cpp is
because it calls SetSizeAndPosition in nsXulWindow.cpp, which sets the size and
position of a window (info that is stored in localstore.rdf). This code use to
be in this file before MakeFullScreen() was created. The two functions (MoveTo
and SizeTo) were no longer needed after MakeFullScreen() was added because
MakeFullScreen calls other functions to set the browser's size and position for
full screen, and the browser doesn't start in full screen. Full screen gets set
while the browser is already up and running so an existing window is getting
resized and repositioned.

With Kiosk mode, I wanted to make the browser open full screen minus the title
bar, toolbars, status bar...  When the browser opens a window for the first
time, it gets the last size and position saved when the browser closed or from a
current open browser window - info that's found in localstore.rdf. Using the
full screen code to run kiosk mode, I can't just let it go through
MakeFullScreen to Resize and Reposition a window that doesn't exist yet. I also
needed to Set the size and position so when the window opens it takes those
values and uses them. That is why I updated the previous patch to get this code
back in. It did once work before that code was removed.

I was trying to look at different ways to do this and chose to set the size and
position in this location in nsGlobalWindow.cpp. 

Comment 95

[Dan M]

Alright I just spent a lot of time on this. What platform are you working with?
I'm on Windows. Here's what's happening there. With the patch under
consideration the code goes:

GlobalWindow::SetFullScreen(true)
  Widget::MakeFullScreen(true)
    SetSizeMode(normal)
    Resize(0,0,w,h)
      [nsWebShellWindow::PersistPositionAndSize(size,mode)] (indirectly)
    FullScreen::HideAllOSChrome
  MoveTo(0,0)
    nsWebShellWindow::PersistPositionAndSize(position)
  ResizeTo(w,h)
    nsWebShellWindow::PersistPositionAndSize(size,mode)

The subtle distinction is that Widget::Resize persists only its size, not its
position. This is because the WM_WINDOWPOSCHANGED case in
nsWindow::ProcessMessage persists size only. There's even a comment in there
that we expect a friendly WM_MOVE to come along and take care of position
persistence. But that doesn't happen in this case. So the ResizeTo in
GlobalWindow *is* redundant, but the MoveTo in GlobalWindow does finally cause
position to be saved.

If I were you, I'd look into calling OnMove from the WM_WINDOWPOSCHANGED case of
nsWindow::ProcessMessage to fix the underlying bug. Then that redundant-looking
code in GlobalWindow should truly be redundant. And there may be similar bugs on
other platforms.

Be certain that this doesn't cause nsWebShellWindow::PersistPositionAndSize to
be called an extra time even in the normal case when a WM_MOVE does come through
as expected, since that's a *very* expensive method. But this shouldn't happen.
That's what the timer is for.

That said, I'm not real keen on this code in general. It seems very scattered.
Knowledge of the nsIFullScreen service seems more widespread than it could have
been. It seems to require a lot of cooperation to actually get a window into
full-screen mode. At least I think I've been able to stomp the requirement for
redundant sizing.

I wonder if things would have been cleaner with a fourth window size state:
(normal, minimized, maximized, fullscreen). This at least should have obviated
any need to worry about fullscreen mode window size/position persistence. I
can't say for sure that this could have been done more cleanly. It's easy to
pontificate from a position of hindsight and incomplete analysis. I'm not going
to push for a rewrite. But I do want to register a grumble.

If it turns out you really do need redundant window positioning in
GlobalWindow::SetFullScreen, please at least go heavy on the comments. It
confused the heck out of me.

Comment 96

[Christian :Biesinger (don't email me, ping me on IRC)]

*** Bug 15324 has been marked as a duplicate of this bug. ***

Comment 97

[Michael Hendy (Hendikins)]

*** Bug 199387 has been marked as a duplicate of this bug. ***

Comment 98

[Linards Ticmanis]

Alright, this seems to be a lot harder than I, the naive non-coder wiseguy,
expected when I filed Bug 199387. How hard would it be to have an option to just
hide the location bar and scrollbars (until you touch the mouse to the screen
borders) in the already-existing fullscreen mode? The point of this is of course
not setting up a Kiosk but simply allowing 100% of the screen pixels to be
dedicated to content, which is what fullscreen is all about IMHO.

Comment 99

[amutch]

FWIW, I don't think your bug should be duped against this one. It's a 
fullscreen issue, not a kiosk issue. I'm not really clear on the purpose of it 
except for some really unique setups, like someone displaying Flash, where you 
can know that there is no need for scrollbars. Otherwise, I don't see what's 
gained by having them not display in some percentage of situations. But that's 
for another bug, not this one.

Comment 100

[Brian 'netdragon' Bober]

Linards, there is a bug about what you are talking about, but its not this 
bug. This is a kiosk mode that might be used, for example, as a graphical web-
based search system for the catalog that keeps the user from doing anything 
but what its meant for.

Comment 101

[Dave Miller [:justdave]]

[e-mail] is about to go on a long vacation to the bit bucket

Comment 102

[timeless]

.

Comment 103

[Travis Chase]

Im confused, whats wrong with just pressing F11 and going to full screen that way?

Comment 104

[Brian 'netdragon' Bober]

Look at comment #43, comment #49

F11 is for fullscreen mode, which isn't kiosk mode.

Comment 105

[jag (Peter Annema)]

Comment on attachment 114226 [details] [diff] [review]
updated patch for kiosk mode

Anyone here interested in resurrecting this patch? Based on danm's comments it
looks like this needs some work still.

Comment 106

[amutch]

Yes, I'm still interested in seeing this happen. I'll touch base with Jessica to
review the comments. But it sounds like Dan M was talking about a major addition
or rewrite to the Fullscreen code which is way outside the scope of this bug. If
that's going to happen separately, we can make this bug dependent on it. But I
didn't have the impression that was what was going to happen. 

Comment 107

[Dan M]

I could take another look at this, if folks still want to get it checked in. It
does still need some work. My main objection in comment 89-95 was that this
patch seems to include a workaround for an underlying bug. I'd rather see that
fixed than worked around. I could take a look at that underlying bug if you want
to get the rest of this patch in order.

That said, I did have other objections in comment 95. I don't recommend any
major rewrites to the fullscreen code, but I did wonder if this kiosk code would
have been more direct if done another way. Don't know; haven't tried writing it,
myself. There's not that much of it so I guess I'd let it go as is, with a huff.

I have additional concerns. Obviously the patch will need to be updated to
current base versions of the affected files. The patch to nsGlobalWindow (which
I think I'd like to see removed anyway, with the aforementioned underlying bug
fixed) assumes the top left corner of the screen is positioned at (0,0), which
of course won't always be true. You'll need to do something about window.moveTo,
moveBy, resizeTo and resizeBy. What about window.open?

Comment 108

[alanjstr]

Would it be better to target this for a full-screen Firefox now?  

Comment 109

[amutch]

DanM: If you can work on the underlying bug, I can work on getting the patch 
revamped to the current code. If you want to file a separate bug on that and 
set dependency here, that works for me. 

As far as making this a part of Firefox, I requested this before and was 
told "No". 

Comment 110

[Brian 'netdragon' Bober]

alan: Afaik, this is almost entirely a back-end fix. Most back-end fixes are
still targeted to Seamonkey.

Comment 111

[Dan M]

Once a major milestone or so I remember this bug...

Brian: there's front-end code involved, too. It's just that Firefox seems not to
want the functionality. Something like it already exists as an extension, anyway.

amutch: My apologies for blocking this bug for so long. It's still not my
favourite patch ever. But my main objection, that it seemed to need to do more
work than necessary, is an overreaction. Stepping on this patch until an
underlying problem is fixed, one for which a reasonable workaround exists,
hardly seems cricket.

You'll want to update the patch and get Jag to approve it. I'll stop stonewalling.

Comment 112

[Brian King [:kinger]]

For reference, some Kiosk extensions available.

Firefox:
https://addons.mozilla.org/extensions/showlist.php?application=firefox&category=Kiosk%20Browsing

Seamonkey:
https://addons.mozilla.org/extensions/showlist.php?application=mozilla&category=Kiosk%20Browsing

Comment 113

[Alex Hosking]

Isn't Mozilla a Business now, and isn't this sort of behavior important if FF/Mozilla is to be adopted by Businesses?

Comment 114

[Worcester12345]

Our local library is STILL using an ancient version of PWB (Personal Web Browser) on public PC's.

It does what they want, kiosk-wise. Their staff uses Firefox. It would be great if they could use a Firefox in kiosk mode.

Comment 115

[Kathleen :Brade]

Worcester12345 (comment 114) -- it is possible to run Firefox in kiosk mode with the right extension(s).  VisualAutomation.com has a product called iLock that your library might use (which is available for Firefox 3 although the web site doesn't reflect that today).  If that isn't the right solution, you might search on AMO (see comment 112) to find other extensions to bundle with Firefox for a kiosk setup.

Comment 116

[Worcester12345]

The links in comment 112 no longer work. Meanwhile, PWB continues to provide a moving target: http://www.teamsoftwaresolutions.com/

Comment 117

[Philip Chee]

The SeaMonkey team will not devote any resources to this. If you want to provide a patch and drive this into the tree please file a NEW bug thanks.

Comment 118

[Worcester12345]

(In reply to Worcester12345 from comment #116)
> The links in comment 112 no longer work. Meanwhile, PWB continues to provide
> a moving target: http://www.teamsoftwaresolutions.com/

Would it be possible to reconsider this bug?