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)

enhancement
Not set
normal

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?
Assignee: ebina → michaell
Component: Browser Hooks → UE/UI
Product: MozillaClassic → Browser
Assigning to marketing guru
Status: NEW → ASSIGNED
Considering....
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?
OS: Windows 98 → Mac System 8.6
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.
OS: Mac System 8.6 → All
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
*** Bug 28554 has been marked as a duplicate of this bug. ***
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.
Assignee: jelwell → shuang
QA Contact: claudius → elig
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() { }
Whiteboard: will update on 03/13 with Linux status. → Have some code - need help implementing.
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
Perhaps not to Netscape, but it is to other implementors.
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.
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.
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.
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
*** Bug 38108 has been marked as a duplicate of this bug. ***
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).
Target Milestone: --- → Future
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.
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.
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.
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."
*** Bug 47157 has been marked as a duplicate of this bug. ***
*** Bug 23208 has been marked as a duplicate of this bug. ***
FullScreen mode would be usefull.
Any milestone suggestion?
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
Please attach new, TIP-updated patches in standard cvs diff -u form. I can't review entire files.
--> XPApps/GUI (will need cross-platform QA when it's done).
Component: User Interface: Design Feedback → XP Apps: GUI Features
QA Contact: mpt → sairuh
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
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.
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).
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.
Status: NEW → ASSIGNED
Sorry. I attached the bootstrap file twice there. Just ignore one of them.
Attached image screenshot (deleted) —
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.
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
[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.
QA Contact: sairuh → claudius
Mathew Thomas: you just invalidated all the votes for this bug. This bug has always been about Full Screen mode, and a reduced UI.
The indentation in 24728 is off [1666,1677] :-(, can you mention the mime types for these files? [i'll work on improving bugzilla later]
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.
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.
Depends on: 68470, 68471, 68473, 68474
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. ===
Filed bug 68501 for the password dialog.
Depends on: 68501
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.
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.
Blocks: 15324
Depends on: 65212
No longer depends on: 68471
(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.)
*** Bug 69219 has been marked as a duplicate of this bug. ***
Adding self to cc. Any other word on just plain vanilla full-screen, a la IE4/5?
Timeless: the mimetype for 24728 is text/plain, diffs. 24729 is a zip file.
Well, we could reopen bug 28554 if we want a separate entry for plain vanilla full-screen mode.
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?
the restrictions should be covered in bug 68470 and bug 68471
As I sit here in the 0.9 targeting zarro boogs meeting, I realize this isn't going to get in. bumping ahead.
Target Milestone: mozilla0.9 → mozilla1.1
*** Bug 81547 has been marked as a duplicate of this bug. ***
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.
Is there a metabug for kiosk mode? Or is this it? And if this is it, why isn't it marked so?
Fine, it's a metabug :)
Keywords: meta
I was wondering if bug 104389 should depend on this, because i think that bug would be implemented in kiosk mode would it not?
no because someone might pick that up separately
Depends on: 109603
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 :> )
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.
Depends on: 68136
No longer depends on: 109603
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).
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
Depends on: 126685
No longer depends on: 126685
Depends on: 126685
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.
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.
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
Assignee: zach → nobody
Status: ASSIGNED → NEW
Keywords: helpwanted
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.
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.
Keywords: 4xp
This sounds like a great idea Espesialy comment 43
isnt this the same as bug 68136 ?
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.
Blocks: 157731
No longer blocks: 157731
Attached patch Patch for kiosk mode (obsolete) (deleted) — Splinter Review
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);
Depends on: 164421
Blocks: 164421
No longer depends on: 164421
Keywords: mozilla1.2
Depends on: 159135
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?
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 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)
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.
Depends on: 152080
Anybody want to updated the Target Milestone since 1.1a is out.
Moving BUT ONLY BECAUSE 1.1a IS PAST NOT BECAUSE I'M GOING TO FIX IT.
Target Milestone: mozilla1.1alpha → mozilla1.5alpha
Attached patch updated patch for kiosk mode (deleted) — Splinter Review
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
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)
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.
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.
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.
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.
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);
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?
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.
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.
*** Bug 15324 has been marked as a duplicate of this bug. ***
*** Bug 199387 has been marked as a duplicate of this bug. ***
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.
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.
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.
Blocks: 129472
nobody@netscape.com is about to go on a long vacation to the bit bucket
Assignee: nobody → nobody
.
No longer blocks: 129472
Attachment #94247 - Flags: review?(jaggernaut)
Im confused, whats wrong with just pressing F11 and going to full screen that way?
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
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)
Target Milestone: mozilla1.5alpha → ---
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.
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?
Would it be better to target this for a full-screen Firefox now?
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".
alan: Afaik, this is almost entirely a back-end fix. Most back-end fixes are still targeted to Seamonkey.
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.
Product: Core → Mozilla Application Suite
Depends on: 305179
Isn't Mozilla a Business now, and isn't this sort of behavior important if FF/Mozilla is to be adopted by Businesses?
QA Contact: claudius → guifeatures
Component: XP Apps: GUI Features → UI Design
Assignee: nobody → jag
Priority: P2 → --
QA Contact: guifeatures
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.
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.
The links in comment 112 no longer work. Meanwhile, PWB continues to provide a moving target: http://www.teamsoftwaresolutions.com/
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
(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.

Attachment

General

Creator:
Created:
Updated:
Size: