63092 - Ability to lock session

Status: RESOLVED WONTFIX

(SeaMonkey :: Startup & Profiles, enhancement)

Description

[Brian 'netdragon' Bober]

I thought that along with password protection, the user could lock up their 
session with the press of a button, and they would have to type their password 
again to continue the session. Everything would return intact when they re-
entered the password. This would keep people from messing with the web sites 
they were using while they are away. This wouldn't lock people out of the 
computer, just out of the browser.

Comment 1

[R.K.Aa.]

Hmm. I fail to see how a feature like this can have any practical "protection"
function at all. It sounds like the functionality better covered with password
protected screensavers and/or real multiuser environments. Locking only the
browser would allow anyone with access to the computer to modify or even delete
browser-related user-files, for instance.

Comment 2

[R.K.Aa.]

Btw.. there is a vaguely resemblant RFE you might want to be aware of:
bug 16489 "[RFE] Password Protection of Profiles"

Comment 3

[Brian 'netdragon' Bober]

RKE - as you can see, this bug does already depend on 16489, as it would only 
be viable with passwords. I am also adding now a depends on 63094 (which I just 
created) and a blocker of bug 63093. This doesn't lock the browser (which is 
still usable via another profile), this saves the session information, and 
makes it so they can reopen it. The difference with this and bug 63094 is that 
it would hide all the windows and allow quick reaccess to the session, and the 
session would only be saved until reuse. But it does depend on bug 63094.

This would not stop another user from logging on with a different profile name 
while the account is locked out. 

Bug 63094 calls for the ability to save a session. Locking up a session would 
save the session in the person's profile for later use - as 
mmddyyyy_24hrtime.??? ( whatever the session data file's extension is). All 
windows would hide and a dialog (not modal) would come up that gives them the 
ability to reopen the session (quickly) or use profile manager. If they logged 
back onto their profile any time before mozilla was closed, they would be asked 
if they wanted to continue the previous session. Of course, the session would 
only be saved until it was reopened (as compared to normal saved sessions that 
are saved forever)

Comment 4

[Brian 'netdragon' Bober]

Sorry, R.K.Aa, not RKE.

Comment 5

[Brian 'netdragon' Bober]

Please note this has nothing to do with locking out someone from the operating 
system or trying to act as an operating system or Mozilla becoming an operating 
system. It simply has to do with locking out people from a profile. 

Comment 6

[Keyser Sose]

Marking NEW to get it off the unconfirmed radar. 

Comment 7

[Samir Gehani]

-> profiles?

Comment 8

[Ben Goodger (use ben at mozilla dot org for email)]

helpwanted, [e-mail]. Another add-on type thing. 

Comment 9

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 10

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 11

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 12

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 13

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 14

[Robert Kaiser]

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 16

[Robert Kaiser]

The SeaMonkey team will not specifically work on this.