Closed Bug 58417 Opened 24 years ago Closed 24 years ago

Unable to Encrypt Sensitive Info.

Categories

(Core Graveyard :: Security: UI, defect, P1)

Product:
Core Graveyard
Component:
Security: UI
Version:
1.0 Branch
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME

People

(Reporter: skasinathan, Assigned: javi)

References

Details

(Keywords: hang, platform-parity, regression, Whiteboard: [rtm-] relnote-user)

Steps: 1. One on the mail basic functionality test is to encrypt the stored mail passwords. Goto Tasks | Privacy and Security | Password Manager | Encrypt Sensitive info. After you select this, no window pops up. It FREEZES the browser. Platform and build: 2000-10-28-09-MN6 on Linux and Mac. Hoping the same on Windows (no windows build to test). PS: Please change the component, if you think so.
nominating for rtm.
Keywords: regression, rtm
COnsole window displays the foll. Document http://home.netscape.com/ loaded successfully we don't handle eBorderStyle_close yet... please fix me Setting content window *** Pulling out the charset in SetSecurityButton
I just tried this on a windows mozilla branch build and it works-for-me. Will try it on a windows commercial branch build in a few moments (after my build finishes). I started with a fresh profile which means that there was no data to encrypt. That is what the above steps implied.
I just tried it on a commercial branch build and again it works-for-me. I also tried it after first saving some single-signon data. In that case I got the dialog asking me to create a master password (no such dialog appears when there is no data to encyrpt).
Morse, I tried again using the same Linux branch commercial build (2000-10-28-09-MN6). I tried couple of ways. I. a) Created a new profile. Created a new IMAP account and checked save password in the password dialog. b) I quit the app, launch again using the same profile. Tried to encrypt the saved password. NO, it doesn't bring up the master password (Private key) dialog. I should get this dialog, right? and it freezes the browser. II. a) Same steps as above, but didn't quit the app in step b. The only difference I see is that you tried on Windows and I tried on Linux and Mac!
suresh, could you try this on windows and see what you get?
Morse, YES! It works fine on Windows. I can see the Master PAssword dialog. Builds tested: 2000102916MN6 windows branch commercial build on Win NT 4.0.
SingleSignon, I think. Please reassign if I'm wrong.
Assignee: mstoltz → morse
Component: Security: General → Single Signon
QA Contact: czhang → tpreston
Sounds like this is WORKSFORME.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Mitchell Stoltz, This DOESN'T workforme. I said it works fine only in Windows. It doesn't work on linux and Mac.
Status: RESOLVED → REOPENED
Component: Single Signon → Security: General
QA Contact: tpreston → czhang
Resolution: WORKSFORME → ---
It is waaaaay to late to be finding this. It's marked "regression" -- when was the last time it worked? Maybe we can find the guilty check-in. Suresh: how did you install the Mac and Linux builds. If you use the tarballs instead of the the installers it is possible you did not get PSM. Do secure sites work for you? Even if no PSM you shouldn't hang, of course.
Whiteboard: [rtm need info]
dveditz, I marked this as "regression" because I know for sure that this use to work before. It was working on 10/16 Linux build (Not sure about mac, but I do know that Mac brings up an empty dialog before. bug 57081). I did a Full Install(using the installer) on linux. I downloaded the tarball (netscape*.sea.bin) on Mac. Yes, PSM works fine on both Mac and Linux.
*** Bug 57081 has been marked as a duplicate of this bug. ***
Just to reiterate, This problem occurs only on Linux and Mac. It works fine on Windows. Morse, did you get a chance to look at this problem on Linux/Mac? Thanks!
I'm confused by Suresh's comment on on 10/30 about bug 57081. I believe that bug was fixed on Friday the 27th. Can you verify what the problem is on the mac here? I'm copying Pavlov to try to get additional input on the Linux situation for this bug ('cause he hates when Linux lags behind windows!) Can we have an update for the two platforms (Mac and Linux)?
OK, I'm able to reproduce this on linux. And I agree -- this is quite serious. When did this regression start? We are hung inside of cartman. Here's a stack trace at the time of the hang: #0 0x4038258b in __sigsuspend (set=0xbefffbe4) at ../sysdeps/unix/sysv/linux/sigsuspend.c:48 #1 0x402d1211 in __pthread_lock (lock=0x83fbf94, self=0xbefffe60) at restart.h:32 #2 0x402ce99a in __pthread_mutex_lock (mutex=0x83fbf84) at mutex.c:84 #3 0x402ababb in PR_Lock (lock=0x83fbf84) at ptsynch.c:167 #4 0x402ac8ac in PR_EnterMonitor (mon=0x83fbf80) at ptsynch.c:492 #5 0x4224c93b in nsPSMMutexLock (p=0x4227ce18) at nsPSMMutex.c:56 #6 0x41df2b76 in CMT_ProcessEvent (cm_control=0x84f1638) at cmtevent.c:232 #7 0x41df2c59 in CMT_EventLoop (cm_control=0x84f1638) at cmtevent.c:262 #8 0x42251801 in CARTMAN_UIEventLoop (data=0x84f1638) at nsPSMUICallbacks.cpp:206 #9 0x402b39fb in _pt_root (arg=0x84f1810) at ptthread.c:198 #10 0x402cdeca in pthread_start_thread (arg=0xbefffe60) at manager.c:213
Assignee: morse → ddrinan
Status: REOPENED → NEW
Thanks Morse for looking into the problem!! Jar, let me clear your confusion. The bug 57081 is a Mac only bug. It was reported using 10/16 build. Using this build on Mac when you launch Single signon window, the window is EMPTY. There was nothing inside the window. Javi attached a patch to that bug, but I'm not sure whether it was checked into the tree. Looking at the bug activity junruh@netscape.com marked that bug as fixed and verified. Yesterday I reopened that bug coz we are still seeing the problem on Mac and Linux (Note that Mac doen't even brings up the empty window). I marked bug 57081 as a dup of this one as per discussion with Lisa and Esther yesterday! Hope this clears things up!
Adding nitinp to the cc-list.
QA > junruh
Component: Security: General → Security: Crypto
QA Contact: czhang → junruh
I am able to reproduce it with the 20001030 branch build of linux. It was working before , must have crept in sometime. Today's build are useless so will try to reproduce the bug tomorrow or whenever a working build is available
so in the morning I thought I will try and trace the beginning of this supposed bug. I could find only 2000-10-26-09-MN6 as the earliest branch build. I installed that build on linux. The encript sensitive data works fine. I tried all combinations possible. Changed edit|preferences , Obscured data and then encrypted data. Then I jumped onto the 2000-10-30-09-MN6. In fact I deleted the dirs in .mozilla to start over again. So I migrated the nova profile again and setup new db password and everything works fine. I haven't tested on the 2000-10-31 builds since they had some test stopper bugs in them. I will try again with today's branch builds. But in short it WORKSFORME.
nitinp, I didn't understand your previous two comments. Your comment on 2000-10-31 16:20 says "I am able to reproduce it with the 20001030 branch build of linux." Your comment on 2000-11-01 09:11 says "Then I jumped onto the 2000-10-30-09-MN6. In fact I deleted the dirs in .mozilla to start over again. So I migrated the nova profile again and setup new db password and everything works fine." Does the builds you are referring in the above comments refer to the same build? If yes, you are saying that you were able to reproduce yesterday but not today. right? Am I missing something here? Thanks!!
I did reproduce it for the 20001030 branch build. But that was with an old profile. But then today I removed all the files in .mozilla and restarted netscape6 which migrated my nova profile and since then I cannot reproduce the bug. In fact I just installed the 2000-10-31-14-MN6 and tried to reproduce the bug , but cannot reproduce it.
Based on preceding comment, I deleted all my old profiles and removed everything from the .mozilla directory. Then tried this test again and I am still able to reproduce the problem.
which build are you testing?
Using the latest MN6 builds from 10/31. Still reproducible on Mac and linux. Win98 and WinNT is OK. Just create a new profile, enter your name and password at mail.yahoo.com, save it, then immediately encrypt the data. To setup new profiles: For Linux, type ./netscape -ProfileManager (./netscape -h for help) For Mac, drag the file Netscape Profile Manager onto the Netscape 6 file.
Is a workaround acceptable? My hunch is that if you got to Tasks->Privacy and Security->Password Manager->Change Personal Security Password and set the Personal Security Password first. Then setting the option to encrypt should "just work(TM)."
but does this happen only if the password is not set or it happens even if the password is set. The fact that a new profile is being created means you have a new db. But I tested it after I set the password from the security advisor. I assumed that the password is already set. So suresh - when you created a new profile did activate SDR from the prefs dialog? or you went to IMAP account ,clicked OK on the big box and tried to encrypt it. The bug then will be that the new password window does not come up and freezes the browser when trying to encrypt sensitive data , because it works for a new profile with a password set for the profile.
nitinp, I removed .mozilla, created a new profile, created a imap account and while logging in I checked the box to remember password. Then tried to encrypt the password. Hangs. And also tried using 2000-11-01-09-MN6 build. Same result (Hangs).
without setting up the password the new profile does freeze up when I try to encrypt a data I just saved. When I restart netscape6 with that profile and set the password from the tasks|privacy and security|password manager|personal security password it works fine after that.
....so any new updates on this bug? Thanks!
Here is a mac stack trace (CurStackBase does not seem to apply...dumping 4K.) Return addresses on the stack Stack Addr Frame Addr ISA Caller 09BEC3C4 PPC 00690070 09BEC326 PPC 0068FFFC 09BEC1EC 68K 0000000A 09BEC014 PPC 00690070 09BEBD5C PPC 1AC2E010 PR_GetThreadPrivate+004F4 09BEBCC6 68K 00D7FFFA 09BEBCA6 68K 03280346 09BEBBD8 09BEBBD0 PPC 1AC2FAA8 PRP_TryLock+00994 09BEBB86 68K 09C5FFFE 09BEBB78 09BEBB70 PPC 1AC2DFF4 PR_GetThreadPrivate+004D8 09BEBB28 09BEBB20 PPC 1AC34644 PR_GetPrimaryThread+002A0 09BEBB18 09BEBB10 PPC 1AC2E4A0 _PR_GetPrimordialCPU+0045C 09BEBAE8 68K FFD61FDA WaitNextEvent+0002A 09BEBA68 09BEBA60 PPC 1AC3518C PR_LocalTimeParameters+0019C 09BEBA34 09BEBA30 68K 0007189E 09BEB9C8 PPC 0036F11C EmToNatEndMoveParams+00014 09BEB978 09BEB970 PPC 001E79E4 MPSecondaryInitializeAPI+001EC 09BEB93E 68K 092C092A 09BEB938 09BEB930 PPC 001E97FC MPGetPoolStatistics+002A4 09BEB928 09BEB920 PPC 00952A98 09BEB850 09BEB84C 68K 002E119C 'scod BFAF 0002'+01EEC 09BEB840 09BEB83C 68K 002E5566 'scod BFAF 0002'+062B6 09BEB830 09BEB82C 68K 002F0D88 'scod BFAF 0002'+11AD8 09BEB80C 68K 002F0E2C 'scod BFAF 0002'+11B7C 09BEB808 PPC 0036F11C EmToNatEndMoveParams+00014 09BEB7E8 09BEB7E4 68K 002E558E 'scod BFAF 0002'+062DE 09BEB7C8 09BEB7C0 PPC 001E7A60 MPSecondaryInitializeAPI+00268 09BEB7A0 68K 002F2B56 'scod BFAF 0002'+138A6 09BEB790 09BEB78C 68K FFC416A2 _LoadScrap+00E10 09BEB788 09BEB780 PPC 001E97FC MPGetPoolStatistics+002A4 09BEB778 09BEB770 PPC 00951684 09BEB756 68K 038FFFFE 09BEB750 68K 002E119C 'scod BFAF 0002'+01EEC 09BEB6F8 09BEB6F0 PPC 1C8229B4 InitFloatingWindows+00A18 09BEB6C8 09BEB6C0 PPC 1C822924 InitFloatingWindows+00988 09BEB6A0 68K 002F2B56 'scod BFAF 0002'+138A6 09BEB690 09BEB68C 68K 0077D2A6 09BEB688 PPC 1C816998 DeactivateFloatingWindows+001C8 09BEB650 09BEB64C 68K 005358D4 09BEB63E 09BEB63A 68K 002E1220 'scod BFAF 0002'+01F70 09BEB62E 68K 0042E29E 09BEB618 68K FFC41782 _LoadScrap+00EF0 09BEB5E6 09BEB5E2 68K 002EA036 'scod BFAF 0002'+0AD86 09BEB5BE 09BEB5BA 68K 002EA606 'scod BFAF 0002'+0B356 09BEB580 09BEB57C 68K 002F0A8E 'scod BFAF 0002'+117DE 09BEB56C 09BEB568 68K 002F097C 'scod BFAF 0002'+116CC 09BEB54E 68K 002F0886 'scod BFAF 0002'+115D6 09BEB54A 68K 00420960
I'm getting progressively more desperate... we really need some traction on this from the Mac or Unix folks. On the Mac, the best helpers should probably be Gordon or Patrick. I'm not sure who on Unix should step forward... but I see no progress, and this may either be a ship stopper, or a major problem at a minimum. It appears there is a deadlock on the two platforms. That may be a hint that we are calling into PSM twice, and each call is trying to hold some locks (but I am guessing with no basis in fact, never having looked at the code :-( ). Steve: Do you understand the general area of the code enough to *assure* that we aren't making two parallel calls into PSM?
I suspect that this is yet another occurance of the SDR/PSM/UI deadlock that we keep seeing and fixing. Let me try to explain the sequence of events that occurs: 1. The password manager code calls the SDR encrypt function in the psm-glue layer. This is a synchronous call, it doesn't return until the encrypted data is created (or an error occurs). 2. The psm-glue sends the request to PSM. It then waits for the response. The response can be delivered as the first return packet, or there can be one or more packets that are *events* that need to be handled. 3. PSM processes the encryption request. In the problem case, it discovers that a password needs to be set on the key database before progress can be made. It sends a UI request back to the application (psm-glue). It then waits for the response; 4. The code in psm-glue reads the UI request. Here there may be some variation: either the original request thread (Mozilla thread?) or a special event thread may pick up the response. I don't think it matters. The handling thread calls various Mozilla APIs to find a window, create a new window and feed it a URL to use for fetching the data to display. Buttons on the new UI window cause the result to be sent back to PSM and the whole thing unwinds (if it's working!) The problem: apparently displaying the new UI usually depends on the Mozilla (main?) thread being able to process operations. However in this case it is blocked in the psm-glue component waiting for a response from the SDR encrypt. The result is typically an empty frame w/ NO content (this is for Windows). Solution:The way we fixed this (several times) is to make the new UI window "modal". This seems to be a way to force the current thread to do event processing, and allows the contents of the window to be displayed correctly. This solution has been removed occasionally by people who didn't understand the sensitivity of this code path. I discussed this solution with several people back in May 2000. I was worried at that time that it seemed to be a "kludge", but I got general agreement that it would work, and it does solve the problem. In the future, we need to outline a better architecture for this sort of flow (it apply to more than just PSM) There's the info: it may be that modal handling on Linux and Mac does not work any more, or something else could be wrong :)
To understand better what is happening, I instrumented the win32 build to see when the locks are getting set and unset. Here are the locks that I observed, starting from the time that the tasks->privacy->password-manager->encrypt menu item is selected: 1. LOCK called from: CMT_SendMessage CMT_Hello nsPSMComponent::GetControlConnection nsSecretDecoderRing::Logout wallet_ReencryptAll ... 2. UNLOCK for 1 above 3. LOCK called from: CMT_SendMessage CMT_PassAllPrefs nsPSMComponent::PassPrefs nsPSMComponent::GetControlConnection nsSecretDecoderRing::Logout wallet_ReencryptAll ... 4. LOCK called from: CMT_ReferenceControlConnection CMT_EventLoop CARTMAN_UIEventLoop _PR_NativeRunThread _threadstartex KERNEL32! 77f04f3e() 5. UNLOCK for 3 above 6. LOCK called for: CMT_SendMessage CMT_LogoutAllTokens nsSecretDecoderRing::Logout wallet_ReencryptAll ... 7. UNLOCK for 6 above 8. LOCK called for: CMT_SendMessage tmp_SendMessage CMT_SDREncrypt nsSecretDecoderRing::Encrypt nsSecretDecoderRing::EncryptString EncryptString Wallet_Encrypt ... and then the PSM screen for entering the "Personal Security Password" appears. Now comparing this to the stack trace that I reported earlier for linux, it's clear that the hang is occuring at step 4 -- in the cartman UI event loop. At this time the lock has been set from cartman's PassAllPrefs (step 3) and not yet released (it will be released in step 5). The fact that the lock is already set doesn't bother windows but it does block linux.
Had a mid-air collision with thayes' comment above. I think we are saying the same thing but I'm not sure.
Terry, please attach the solution that you referred (or cite a reference to it) so I can try it out and see if it solves the current problem.
The linux psm is no longer modal.We removed the modal behavior for PR3 because there was a bug which hd rendered the Security Advisor useless. Making it non-modal solved the problem. In fact we were sceptic that this may create problems for SDR. Looks like it did. john- is the mac psm modal to netscape6 ?
Nope. I can close the main window, and leave PSM still running.
So, what patch must be applied to make the dialog modal again on Mac & Linux?
Since window modality is being brought into this fray... I'm adding DanM to the CC list. It does sound like we're closing in. Nintip: Do you have a reference to the exact bug being repaired, or the exact patch (or even file) that was changed in the PR3 "repair?"
jar: the bug no is 46253. it was verified on 10/19. So I correct myself , it was not fixed for PR3 , but was a post PR3 fix. javi: I could not see the patch for this on the bug report.
So let me ask a dumb question. If I'm understanding Terry's comment, the sequence of events is as follows: 1. PSM-glue receives an encryption request 2. PSM-glue passes that request on to PSM 3. PSM sets a lock before continuing with the encryption 4. PSM determines that user never set password so it does a callback to PSM-glue 5. PSM-glue sets a lock and then puts up the UI for collecting a password So suppose that PSM-glue tests for the presence of a password first. If there is none, then PSM-glue puts up theUI to collect the password. After that completes, it passes the encryption request on to PSM.
The deadlock is not on any lock in the PSM/psm-glue code. The deadlock is caused by having the main thread wait for UI to be displayed and processed, which depends on the main thread for those services. Using modal windows breaks this dependency by allowing a second thread to process UI, or allowing the main thread to do the UI stuff immediately (depending on which thread invokes the UI) Testing whether a password is required is not currently available, and would require changes to PSM and the PSM protocol (I think). Even if it could be done, the same issue occurs. The main thread must put up UI (in psm-glue) to ask for the password values. This must block waiting for the response, which leads to the original deadlock. The solution (again) is to make the UI modal.
making the UI modal , might render the Security Advisor useless. please conisder that while coming up with a solution.
Here's a comment from danm that appears in bug 46253. I think we need to make the security window nonmodal, or stop opening nonmodal browser windows on top of it. Is there any chance that can be the solution to this bug? So making the UI modal involves making two windows modal. The problem before was that only one of the UI windows were modal. Is that correct?
Terry is right. I'm 90% certain that if we add the modal flag back to psm-glue's handler for UI events, this problem goes away. But in doing so, we will probably break Security Advisor and SSL dialogs along the way.
After swimming through the linkage of chained bug reports starting from 46253, I think I might have found the patch that caused this problem. It's in bug 54860. I'm going to try backing this out to see if that was the culprit.
It was almost certainly bug 54860 that caused the problem. Modal windows have a lot of disadvantages. The one I was referring to just above is the one where they hog the UI. You have to be careful what you do next while you have a modal window up. The security UI is full of links that open nonmodal browser windows, which argues for making it nonmodal. The one good feature of modal windows is that they know how to unstall I/O processing. I suppose it's no coincidence that this bug isn't a problem only on Windows, and that it's only on Windows that the PSM UI is modal, since Oct 16? You could leave the window nonmodal and try the same trick modal windows use to unstall I/O (push/pop a new event queue), if there's a good place to do that. Or I could implement that thing I was going to try in bug 56677, forcing new windows spawned from modal ones to be modal themselves, regardless of whether they were specified modal. Then you could make the PSM UI modal again on all platforms, without the consequent UI problems it was causing. Though that does open up an interesting open potential for the user to keep stacking modal windows up until -- I think if they get 50 deep they'll stall your car.
Javier is working on a fix for this, so I'm re-assigning to him.
Assignee: ddrinan → javi
Dan's proposal for bug 56677 would be exactly the right thing. The security advisor would open modal windows if it could, but the Javascript open() call doesn't let it (because of security concerns?). Making windows opened by modal windows also be modal would solve this problem Dan also identifies the key advantage of modal windows that we are using - event processing. While we could work around this ourselves in the psm-glue layer by push/pop of a new event queue, I'd rather leave such details to other parts of the code. Currently we do this by specifying "modal" in the window options. If there was another option that provided this benefit without other "bad" features of modal windows (if there are any) then we would use that. Our propose patch (in the works) is a "fix-the-symptom" workaround. It isn't the correct solution, and if implemented needs to be replaced ASAP with a real fix. The 56677 patch is such a fix. I vote for doing it now.
There's a patch attached to bug 56677 that might help. Though I don't see it making it into the branch. It doesn't seem to be quite perfect -- see the notes in that bug. But it will probably solve your problem here by allowing you to make the PSM UI window modal on all platforms again. Yeesh. Sorry I've been pushing to make that window unmodal. I wasn't expecting its modality to actually be a benefit.
I did some work adding the modal flag back to the window->Open call, and that didn't seem to work. If someone has a Linux tree they can reliably work with, try reverting mozilla/extensions/psm-glue/src/nsPSMUICallbacks.cpp to -r 1.23, and see if that fixes this for them. I'll keep working independently to see if I can fix this.
Javi: We are really running out of time here... so any comments need to be focused on specific folks. This bug won't get fixed without such pressure at this point. Danm: Can you test the patch you suggested against linux, and report evil side effects (if any)? If problematic, can you also try Javi's suggestion: "try reverting mozilla/extensions/psm-glue/src/nsPSMUICallbacks.cpp to -r 1.23" Beard: Can you test the above two items against Mac and report any problems? Thanks in advance to all participants in this activity, Jim
Bottom line: What I thought would fix this, didn't work. I'm back to square one in terms of investiagting what went wrong. :(
Hmm. I've had better luck. On my Linux build, reverting nsPSMUICallbacks.cpp keeps "Encrypt Sensitive Info" from hanging the browser -- I suddenly start getting the "pick your password" window. And further, with my patch from bug 56677 included in the mix, windows opened from it seem OK and modal (except for parts of the UI, and I think I know what's wrong there too, now.) I think this will work.
There's a better patch in bug 56677 now, so I can amend my comment above to state simply that the combination of these two changes is, as near as I can tell, working. At least on Linux.
Javi: So Danm says you should be done... Does this work on Mac as well? If so, can you get this reviewed and approved asap? ...or can you list the problems?
For danm, I would add one more test (unfortunately, you have to be inside the Netscape firewall to get to this site). On Linux, goto https://javi.red.iplanet.com:8080 You should see a dialog pop up warning you that the site isn't trusted (it's cert was issued by a test CA) and that the names don't match (the cert was issued for javi.mcom.com). If you are able to click through this dialog and children window of the security advisor can still receive mouse clicks, then I say this fix is good. (Linux and Mac were the 2 platforms most susceptible to this problem.)
I get no response from http://javi.red.iplanet.com:8080 with either Mozilla or Navigator 4.7 (both spin for a bit and shrug; Navigator kindly tells me the document contained no data.) More notes: fess up time; I've been testing this on the trunk. With the above changes in my Linux Mozilla trunk build, attempting to "encrypt sensitive information" seems to work. (I get the "pick a password dialog," anyway. After 15 seconds' wait.) With those same changes in my Linux RTM branch Netscape commercial build, I don't get the dialog; it just goes straight to the "Unable to convert stored data" alert, as if I had seen the dialog and cancelled. Has this stuff by any chance been disconnected in the RTM branch because of this bug?
Using build 2000-05-23 on mac and linux the work around works: Here is what I did to test the work around: Create a new profile, Select Change Personal SecurityPassword (even though you don't have a PS password to change), you will get a window for entering a NEW PS password. Give the password and close. Add a new mail account and check the box for saving password. You will get the Alert (as they should) that the password should be encrypted to password protect stored information. You are told to select the Encrypt option in the menu. OK this dialog and their mail loads. After closing app then relaunching mail the password is obsure and still needs to be encrypted. You can now select Encrypt from the menu without hanging the system. The user will get the Password dialog for entering the previously recorded encrypted password. So yes the work around works! Basically do a Change Personal Security Password first then chose Encrypt. We will try on existing Profiles too.
This should be release noted. Adding relnoteRTM.
Keywords: relnoteRTM
Whiteboard: [rtm need info] → [rtm need info] relnote-user
..and it works fine on existing profile also. Thanks esther for testing this!!
It should be pointed out that this work-around is far from desirable. It means that the user has to kow in advance that he is going to want to encrypt his information. If he doesn't, and saves any information at all and then decides later that he wants to encrypt it, he is out of luck.
rtm-, in lieu of a patch, we have to live with the workaround and release note.
Whiteboard: [rtm need info] relnote-user → [rtm-] relnote-user
Release note: "Mac and Linux. To avoid a crash before encrypting your stored passwords for the first time (Tasks>Privacy and Security>Password Manager>Encrypt Sensitive Information), select Tasks>Privacy and Security>Password Manager>Change Personal Security Password and setup a new password.
*** Bug 60854 has been marked as a duplicate of this bug. ***
Release noted. Removing myself from list of cc's.
*** Bug 61680 has been marked as a duplicate of this bug. ***
I claim that all you need to do to fix this bug is remove the Mac-'n-Linux code which makes the window nonmodal. Patch below. To retrofit this to the Netscape 6.0 branch, you would also want to copy the fix for bug 56677. RCS file: /cvsroot/mozilla/extensions/psm-glue/src/nsPSMUICallbacks.cpp,v retrieving revision 1.24 diff -r1.24 nsPSMUICallbacks.cpp 109d108 < #ifdef WIN32 111,113d109 < #else < (modal && win) ? "menubar=no,height=%d,width=%d,dependent" < #endif 122,129d117 < #ifdef WIN32 < if (modal && win) { < parentWindow->OpenDialog(jsContext, argv, 3, &newWindow); < } else { < parentWindow->Open(jsContext, argv, 3, &newWindow); < } < newWindow->ResizeTo(width, height); < #else 131d118 < #endif
Oops. I'm rescinding my claim above. Found a more complex case that misbehaves. Javier's internal test case mentioned further above, 11-03-2000, horks under my patch. Symptoms make it seem as if the patchwork of stalled and active event queues created by the resulting modal window festival are to blame.
*** Bug 62036 has been marked as a duplicate of this bug. ***
Raising priority.
Priority: P3 → P1
What happened with the idea of sniffing the "password" token out of the URL? Is there a patch that can go on the trunk RSN?
*** Bug 63680 has been marked as a duplicate of this bug. ***
*** Bug 63680 has been marked as a duplicate of this bug. ***
danm: Whatever became of the work you were doing for this bug?
Uf. Haven't looked at it recently. I recall we'd decided there were scary event processing issues standing in the way of a general solution, and so it would probably be harmless and beneficial to hack nsPSMUICallbacks.cpp to switch on the URL, opening this one instance of the PSM window modally on all systems, while leaving it nonmodal for every other case (but leave it modal in all cases on Windows). I guess we didn't decide who got to implement that, but I nominate Javier, who knows the most about the URL situation. This should work fine on the (Mozilla) trunk. We were also talking about doing the same thing on the Netscape 6 branch. This won't work without the fix for bug 56677, which is currently missing from that branch. I can take care of that part if we decide to go ahead with this. But last I heard, this little project never made it to the approval stage.
*** Bug 64323 has been marked as a duplicate of this bug. ***
Adding keywords hang since problem is still occurring on 01-24-13-Mtest build...
Keywords: hang
I'm surprised that nobody has nominated this one for nsbeta1 yet. So I'll do so now.
Keywords: nsbeta1
Adding pp on the keywords since problem is only occurring on Linux & Mac 9.04 platforms.......
Keywords: pp
*** Bug 69049 has been marked as a duplicate of this bug. ***
We see this same problem on Solaris Sparc as well. Margaret
Is this going to be fixed for beta1?
john, Does this still happen w/ PSM 2?
Worksforme on Linux, Win32 and Mac.
Status: NEW → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → WORKSFORME
Verified.
Status: RESOLVED → VERIFIED
*** Bug 76514 has been marked as a duplicate of this bug. ***
Mass changing Security:Crypto to PSM
Component: Security: Crypto → Client Library
Product: Browser → PSM
Version: other → 2.1
Mass changing Security:Crypto to PSM
Product: PSM → Core
Version: psm2.1 → 1.0 Branch
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.