Status

enhancement
RESOLVED WONTFIX
19 years ago
9 years ago

People

(Reporter: netdragon, Unassigned)

Tracking

({helpwanted})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

19 years ago
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.
Reporter

Updated

19 years ago
Depends on: profile-password

Comment 1

19 years ago
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

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

Reporter

Comment 3

19 years ago
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)
Blocks: 63093
Depends on: 63094
Reporter

Comment 4

19 years ago
Sorry, R.K.Aa, not RKE.
Reporter

Comment 5

19 years ago
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

19 years ago
Marking NEW to get it off the unconfirmed radar. 
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 7

18 years ago
-> profiles?
Assignee: matt → ben
Component: Preferences → Profile Manager FrontEnd
QA Contact: sairuh → ktrina
helpwanted, nobody@mozilla.org. Another add-on type thing. 
Assignee: ben → nobody
Keywords: helpwanted

Updated

18 years ago
Summary: [RFE]Ability to lock up session → [RFE]Ability to lock session

Updated

18 years ago
Whiteboard: [Aufbau-Pf]

Updated

18 years ago
Whiteboard: [Aufbau-Pf]

Updated

17 years ago
Summary: [RFE]Ability to lock session → Ability to lock session

Updated

16 years ago
No longer depends on: 63094
Product: Browser → Seamonkey
QA Contact: ktrina → profile-manager

Comment 9

10 years ago
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
Status: NEW → UNCONFIRMED

Comment 10

10 years ago
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

10 years ago
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

10 years ago
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

10 years ago
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

10 years ago
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 15

9 years ago
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 16

9 years ago
The SeaMonkey team will not specifically work on this.
Status: NEW → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.