Closed
Bug 3341
Opened 26 years ago
Closed 14 years ago
Kiosk mode (similiar to fullscreen but blocks access to certain features)
Categories
(SeaMonkey :: UI Design, enhancement)
SeaMonkey
UI Design
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: rw263, Assigned: jag+mozilla)
References
(Depends on 5 open bugs)
Details
(Keywords: helpwanted, meta, Whiteboard: Kiosk mode isn't fullscreen mode - see Comment #43, Comment #49)
Attachments
(7 files, 1 obsolete file)
On the Navigation Toolbar, how about an option for full screen view?
Updated•26 years ago
|
Assignee: ebina → michaell
Component: Browser Hooks → UE/UI
Product: MozillaClassic → Browser
Comment 1•26 years ago
|
||
Assigning to marketing guru
Updated•26 years ago
|
Status: NEW → ASSIGNED
Comment 2•26 years ago
|
||
Considering....
Comment 3•25 years ago
|
||
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?
Updated•25 years ago
|
OS: Windows 98 → Mac System 8.6
Comment 4•25 years ago
|
||
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.
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.
Updated•25 years ago
|
OS: Mac System 8.6 → All
Comment 6•25 years ago
|
||
Changing OS from Mac to All, as I would also like to see this enhancement on
Windows and Linux.
Moving all UE/UI bugs to new component: User Interface: Design Feedback
UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
Comment 9•25 years ago
|
||
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.
Assignee: michaell → jelwell
Status: ASSIGNED → NEW
Whiteboard: will update on 03/13 with Linux status.
Updated•25 years ago
|
Assignee: jelwell → shuang
QA Contact: claudius → elig
Comment 10•25 years ago
|
||
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()
{
}
Updated•25 years ago
|
Whiteboard: will update on 03/13 with Linux status. → Have some code - need help implementing.
Comment 11•25 years ago
|
||
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.
Assignee: shuang → don
Comment 12•25 years ago
|
||
Perhaps not to Netscape, but it is to other implementors.
Comment 13•25 years ago
|
||
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•25 years ago
|
||
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.
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•24 years ago
|
||
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•24 years ago
|
||
QA Assigning non-confidential New/Assigned User Interface: Design Feedback bugs
to Matthew Thomas (mpt@mailandnews.com).
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 elig@netscape.com.)
QA Contact: elig → mpt
Comment 18•24 years ago
|
||
*** Bug 38108 has been marked as a duplicate of this bug. ***
Comment 19•24 years ago
|
||
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).
Updated•24 years ago
|
Target Milestone: --- → Future
Comment 20•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
Comment 23•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
*** Bug 47157 has been marked as a duplicate of this bug. ***
Comment 26•24 years ago
|
||
*** Bug 23208 has been marked as a duplicate of this bug. ***
Comment 27•24 years ago
|
||
FullScreen mode would be usefull.
Comment 28•24 years ago
|
||
Any milestone suggestion?
Comment 29•24 years ago
|
||
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.
Assignee: don → timeless
Target Milestone: Future → mozilla0.9
Comment 30•24 years ago
|
||
Please attach new, TIP-updated patches in standard cvs diff -u form. I can't
review entire files.
Comment 31•24 years ago
|
||
--> XPApps/GUI (will need cross-platform QA when it's done).
Component: User Interface: Design Feedback → XP Apps: GUI Features
QA Contact: mpt → sairuh
Comment 32•24 years ago
|
||
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.
Status: NEW → ASSIGNED
Comment 33•24 years ago
|
||
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.
Assignee: timeless → zach
Status: ASSIGNED → NEW
Keywords: helpwanted,
patch,
review
Summary: Full Screen View → Full Screen View/kiosk mode
Whiteboard: Have some code - need help implementing.
Comment 34•24 years ago
|
||
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•24 years ago
|
||
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.
Updated•24 years ago
|
Status: NEW → ASSIGNED
Comment 36•24 years ago
|
||
Comment 37•24 years ago
|
||
Comment 38•24 years ago
|
||
Comment 39•24 years ago
|
||
Comment 40•24 years ago
|
||
Sorry. I attached the bootstrap file twice there. Just ignore one of them.
Comment 41•24 years ago
|
||
Comment 42•24 years ago
|
||
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•24 years ago
|
||
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 )) |
+--------------------------------------------+
Summary: Full Screen View/kiosk mode → Kiosk mode
Comment 44•24 years ago
|
||
[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.
Updated•24 years ago
|
QA Contact: sairuh → claudius
Comment 45•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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 51•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
(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•24 years ago
|
||
*** Bug 69219 has been marked as a duplicate of this bug. ***
Comment 55•24 years ago
|
||
Adding self to cc.
Any other word on just plain vanilla full-screen, a la IE4/5?
Comment 56•24 years ago
|
||
Timeless: the mimetype for 24728 is text/plain, diffs. 24729 is a zip file.
Comment 57•24 years ago
|
||
Well, we could reopen bug 28554 if we want a separate entry for plain vanilla full-screen mode.
Comment 58•24 years ago
|
||
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•24 years ago
|
||
Comment 60•23 years ago
|
||
As I sit here in the 0.9 targeting zarro boogs meeting, I realize this isn't
going to get in. bumping ahead.
Keywords: mozilla0.9,
mozilla1.0
Target Milestone: mozilla0.9 → mozilla1.1
Comment 61•23 years ago
|
||
*** Bug 81547 has been marked as a duplicate of this bug. ***
Comment 62•23 years ago
|
||
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•23 years ago
|
||
Is there a metabug for kiosk mode? Or is this it? And if this is it, why isn't
it marked so?
Comment 65•23 years ago
|
||
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•23 years ago
|
||
no because someone might pick that up separately
Comment 67•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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.
No longer depends on: 68136
Comment 71•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
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•22 years ago
|
||
This sounds like a great idea
Espesialy comment 43
Comment 77•22 years ago
|
||
isnt this the same as bug 68136 ?
Comment 78•22 years ago
|
||
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•22 years ago
|
||
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);
Updated•22 years ago
|
Updated•22 years ago
|
Keywords: mozilla1.2
Comment 80•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
Comment on attachment 94247 [details] [diff] [review]
Patch for kiosk mode
requesting review on behalf of comment 80
(patch is not by me)
Attachment #94247 -
Flags: review?(jaggernaut)
Comment 83•22 years ago
|
||
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•22 years ago
|
||
Anybody want to updated the Target Milestone since 1.1a is out.
Comment 85•22 years ago
|
||
Moving
BUT ONLY BECAUSE 1.1a IS PAST NOT BECAUSE I'M GOING TO FIX IT.
Target Milestone: mozilla1.1alpha → mozilla1.5alpha
Comment 86•22 years ago
|
||
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.
Attachment #94247 -
Attachment is obsolete: true
Assignee | ||
Comment 87•22 years ago
|
||
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.
Attachment #114226 -
Flags: superreview?(hewitt)
Attachment #114226 -
Flags: review?(danm)
Comment 88•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
*** Bug 15324 has been marked as a duplicate of this bug. ***
Comment 97•22 years ago
|
||
*** Bug 199387 has been marked as a duplicate of this bug. ***
Comment 98•22 years ago
|
||
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•22 years ago
|
||
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•22 years ago
|
||
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•21 years ago
|
||
nobody@netscape.com is about to go on a long vacation to the bit bucket
Assignee: nobody → nobody
Comment 102•21 years ago
|
||
.
Updated•21 years ago
|
Attachment #94247 -
Flags: review?(jaggernaut)
Comment 103•21 years ago
|
||
Im confused, whats wrong with just pressing F11 and going to full screen that way?
Comment 104•21 years ago
|
||
Look at comment #43, comment #49
F11 is for fullscreen mode, which isn't kiosk mode.
Summary: Kiosk mode → Kiosk mode (similiar to fullscreen but blocks access to certain features)
Whiteboard: Kiosk mode isn't fullscreen mode - see Comment #43, Comment #49
Assignee | ||
Comment 105•21 years ago
|
||
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.
Attachment #114226 -
Flags: superreview?(hewitt)
Attachment #114226 -
Flags: review?(danm-moz)
Updated•21 years ago
|
Target Milestone: mozilla1.5alpha → ---
Comment 106•21 years ago
|
||
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•21 years ago
|
||
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•21 years ago
|
||
Would it be better to target this for a full-screen Firefox now?
Comment 109•21 years ago
|
||
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•21 years ago
|
||
alan: Afaik, this is almost entirely a back-end fix. Most back-end fixes are
still targeted to Seamonkey.
Comment 111•20 years ago
|
||
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.
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 112•19 years ago
|
||
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•18 years ago
|
||
Isn't Mozilla a Business now, and isn't this sort of behavior important if FF/Mozilla is to be adopted by Businesses?
Updated•16 years ago
|
QA Contact: claudius → guifeatures
Updated•16 years ago
|
Assignee: nobody → jag
Priority: P2 → --
QA Contact: guifeatures
Comment 114•16 years ago
|
||
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•16 years ago
|
||
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•15 years ago
|
||
The links in comment 112 no longer work. Meanwhile, PWB continues to provide a moving target: http://www.teamsoftwaresolutions.com/
Comment 117•14 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Comment 118•7 years ago
|
||
(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?
You need to log in
before you can comment on or make changes to this bug.
Description
•