Last Comment Bug 394713 - SeaMonkey 1.1.4 takes much longer to start without administrator privileges than with
: SeaMonkey 1.1.4 takes much longer to start without administrator privileges t...
Status: RESOLVED FIXED
: fixed-seamonkey1.1.7
Product: SeaMonkey
Classification: Client Software
Component: General (show other bugs)
: SeaMonkey 1.1 Branch
: x86 Windows XP
: -- normal (vote)
: ---
Assigned To: general
:
Mentors:
Depends on: 389136 402460
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-03 00:42 PDT by Tilman Schmidt
Modified: 2007-11-26 10:42 PST (History)
4 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments

Description Tilman Schmidt 2007-09-03 00:42:40 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 Mnenhy/0.7.5.666
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de-AT; rv:1.8.1.6) Gecko/20070802 SeaMonkey/1.1.4 Mnenhy/0.7.5.666

If I start SeaMonkey 1.1.4 from a regular Windows account without administrator rights, it takes four (4) minutes from the display of the splash screen until the browser window appears. During that time, CPU usage stays solidly at 100%.
If I grant the Windows account membership in the local Administrators group, log out and in again, the delay is just a few seconds.
If I remove the Administrator privileges again, the delay reappears.
SeaMonkey 1.1.2 started equally fast with or without administrative rights on the same machine and with the same profile.

Reproducible: Always

Steps to Reproduce:
1. log in without administrative rights
2. start SeaMonkey
Actual Results:  
4 minutes wait at 100% CPU between splash screen and actual SeaMonkey window appearing

Expected Results:  
startup as fast as with administrator rights
Comment 1 Frank Wein [:mcsmurf] 2007-09-03 02:52:45 PDT
Do you have any extensions other than Mnenhy installed?
Comment 2 Tilman Schmidt 2007-09-03 03:51:54 PDT
The following extensions are installed:

- in application directory:

extuninstall.xpi
adblock_plus-0.7.5.1-fx+tb+sm+fl.xpi
enigmail-0.95.3-tb+sm.xpi
enigmail-de-0.9x.xpi
messageid-finder-2.0.0-mz+tb.xpi
mnenhy-0.7.5.666-fx+mz+zm+tb.xpi
noscript-1.1.6.16-fx+mz+sm+fl.xpi

- in profile:

extuninstallapi.xpi
duplicate_tab-0.9-fx+mz+zm.xpi
ie_view-1.3.3-fx+mz+ns+fl-win.xpi
image_zoom-0.3-fx+mz+tb+ns+sm+fl.xpi

Differences to the previous installation of SeaMonkey 1.1.2 (which didn't exhibit the problem):
- enigmail updated from 0.95.1 to 0.95.3
- noscript updated from 1.1.4.9 to 1.1.6.16
- adblock_filterset.g_updater not installed anymore
Comment 3 Worcester12345 2007-09-03 09:32:54 PDT
See Bug 394190 – seamonkey/thunderbird not starting up due to CRT/manifest issues in components (https://bugzilla.mozilla.org/show_bug.cgi?id=394190)
Comment 4 Tilman Schmidt 2007-09-03 11:04:46 PDT
I have looked at bug 394190 but cannot see any similarity between the symptoms described there and those I am experiencing.
Comment 5 Frank Wein [:mcsmurf] 2007-09-03 12:16:20 PDT
@Worcester12345: Bug 394190 is about trunk, not about branch...
Comment 6 Frank Wein [:mcsmurf] 2007-09-03 12:21:03 PDT
Reporter: Did you delete the SeaMonkey 1.1.2 folder before installing 1.1.4 and/or install into a new folder (or uninstall 1.1.2 before)?
Comment 7 Tilman Schmidt 2007-09-04 02:14:21 PDT
I uninstalled SeaMonkey 1.1.2 through the Windows Control Panel - Software control and answered "yes" to the question whether to remove the folder. I did not remove the SeaMonkey user profile.

Then I installed SeaMonkey 1.1.4 from seamonkey-1.1.4.en-US.win32.installer.exe, added seamonkey-1.1.4.de-AT.langpack.xpi, extuninstall.xpi, extuninstallapi.xpi and then the others in roughly alphabetical order, restarting SeaMonkey after every one. On the first test the German "OpenPGP Settings" dialog showed the usual red error message, so I removed Enigmail and its language pack with extuninstall and installed them again without a restart between them, which fixed the problem.
Comment 8 Frank Wein [:mcsmurf] 2007-09-07 02:49:26 PDT
And the problem started after installing the last extension or when did this start?
Comment 9 Tilman Schmidt 2007-09-07 03:53:10 PDT
I cannot tell precisely when the problem started, or indeed whether it would already have existed without any extensions, because I didn't even try to start SeaMonkey from a regular account before all extensions were installed.

Startup time was still normal when I started SeaMonkey as Administrator one last time after installing the last extension to check whether everything was working properly.

The problem became apparent when, after that, I logged out from the administrator account, logged in to my regular user account, and started SeaMonkey from there.

It disappeared when I gave that regular account administrative privileges by making it a member of the local Administrators group, and reappeared when I revoked those privileges again.

Hope that clarifies it.
Comment 10 WADA 2007-09-27 15:54:18 PDT
Bug 389136 Comment #25 can probably explain phenomenon in your environment.
When program directory is not write-permitted, and if chrome\chrome.rdf already exists(i.e. admin user used this program directory in the past), Seamonkey seems to try to write chrome-1.rdf to chrome-1700.rdf.
Will "deletion of chrome\chrome.rdf from program directory" be a workaround?
Comment 11 Tilman Schmidt 2007-10-11 00:53:12 PDT
After I renamed %ProgramFiles\mozilla.org\SeaMonkey\chrome\chrome.rdf to ~.rdf-DELETED, SeaMonkey's startup time went back to the normal few seconds.
Comment 12 Tilman Schmidt 2007-10-11 01:01:16 PDT
A side effect of the deletion of chrome.rdf is that the German localization no longer works.
Comment 13 WADA 2007-10-11 01:50:18 PDT
(In reply to comment #12)
> A side effect of the deletion of chrome.rdf is that the German localization no longer works.

Following 2 files in program directory written by administrator also affects on behavior of Seamonkey under non-administrator-privilege user(no write permission of program directory of Seamonkey in your case). See Bug 389136 Comment #16.
  components\compreg.dat (not found in profile)
  components\xpti.dat    (not found in profile)
Will "Rename to ....dat-DELETED" alter phenomenon?
Comment 14 Tilman Schmidt 2007-10-12 00:58:48 PDT
Nope, didn't help.

I have now renamed, below %ProgramFiles\mozilla.org\SeaMonkey, all of
chrome\chrome.rdf
components\compreg.dat
components\xpti.dat
to ~-DELETED, and also checked that none of these files have been recreated.
Startup time stays normal, but the German localization remains absent.
In Preferences category Appearance-Languages, only "English(US)" is listed.
The GUI elements belonging to Enigmail are still appearing in German, though.

Background info: I have installed seamonkey-1.1.4.en-US.win32.installer.exe and then installed seamonkey-1.1.4.de-AT.langpack.xpi into the program directory, as Administrator. When I ran SeaMonkey as a regular user before renaming those files, German localization was available. It disappeared after renaming chrome\chrome.rdf and did not reappear after renaming components\{compreg,xpti}.dat.
Comment 15 WADA 2007-10-12 01:27:01 PDT
(In reply to comment #14)
> Startup time stays normal, but the German localization remains absent.

> Background info: I have installed seamonkey-1.1.4.en-US.win32.installer.exe and
> then installed seamonkey-1.1.4.de-AT.langpack.xpi into the program directory,
> as Administrator.

Can langpack be installed in profile directory?
Sorry but I always use Seamonky without langpack, and I have no experience of Seamonkey with Japanese langpack.
No other workaround than "write permission of program directory" if install of langpack is required?
Comment 16 Tilman Schmidt 2007-10-12 01:48:21 PDT
I think the language pack can be installed in the profile (I don't know how to actually check, short of reinstalling SeaMonkey) but I'd rather not because it complicates upgrading to a new version of SeaMonkey very much.

Adding write permission to the %ProgramFiles%\mozilla.org\SeaMonkey\chrome directory for all users seems to be sufficient to work around the bug. I have now renamed all -DELETED files back to their original name, startup time is still normal, and the "Deutsch(AT)" entry is available again in Preferences category Appearance-Languages. The first time I selected it the GUI became a mix of English and German, but that was easily cleared up by the usual procedure of setting it back to en-US and then to de-AT again.

Interestingly, SeaMonkey doesn't seem to actually change anything in %ProgramFiles%\mozilla.org\SeaMonkey\chrome. The modification date of the directory itself is updated each time I start SeaMonkey, but no files are added, removed, or modified. So it doesn't look as if SeaMonkey actually needed write access there.
Comment 17 neil@parkwaycc.co.uk 2007-11-13 16:21:46 PST
I have just checked in the fix for bug 402460 to the branch for SeaMonkey 1.1.7, please can you try one of the next nightlies to verify the fix. They should be available here in about seven hours:

http://ftp.mozilla.org/pub/mozilla.org/seamonkey/nightly/latest-mozilla1.8/
Comment 18 Tilman Schmidt 2007-11-20 07:11:18 PST
As far as I can tell from a quick check with a bare installation of today's 1.1.7pre without any plugins, the problem is indeed fixed. Thanks!
Comment 19 Robert Kaiser (not working on stability any more) 2007-11-21 06:14:43 PST
So, can we mark this FIXED or actually a dupe of bug 402460?
Comment 20 neil@parkwaycc.co.uk 2007-11-22 08:29:08 PST
Fixed by checkin of bug 402460.
Comment 21 WADA 2007-11-24 18:32:09 PST
(In reply to comment #18)
> 1.1.7pre without any plugins, the problem is indeed fixed.

To Tilman Schmidt(bug opener):
Is it true too when language pack is used? (1.1.7pre/1.1.8pre is for en-US only)
As seen in Bug 389136, chrome.rdf/chrome-N.rdf case has been apparently resolved.
  When chrome.rdf exists(generated by admin-user), 
  Sm tries to write chrome-1.rdf only(not chrome-1.rdf to chrome-9999.rdf),
  and write failure(ACCESS DENIED) of chrome-1.rdf won't produce any error.  
But I don't know about your components\{compreg and/or xpti}.dat case.   
Comment 22 WADA 2007-11-24 19:06:46 PST
It seems that no problem even when lauguage pack is involved.
Lang-Pack & Semonkey : Japanese Lang-pack, seamonkey-1.1.8pre(2007/11/24 build)
(case1) Install Lang-Pack in profile (by Read-only user)
        => No problem
(case2) Install Lang-Pack in program directory by admin-user.
        Use it by Read-only user.
        => Language pack is usable. No performance down in startup was observed

 
Comment 23 Tilman Schmidt 2007-11-26 02:02:26 PST
(In reply to comment #21)

> > 1.1.7pre without any plugins, the problem is indeed fixed.
> 
> Is it true too when language pack is used? (1.1.7pre/1.1.8pre is for en-US
> only)

Not sure where I would find a German language pack for nightly builds.
Comment 24 Robert Kaiser (not working on stability any more) 2007-11-26 05:07:53 PST
All 1.1.x language packs work fine with all 1.1.x versions, so just use the langpack for the latest release version, it works nicely for nightlies as well.
Comment 25 WADA 2007-11-26 10:42:57 PST
Addtional test result.
(case3) After case2 of comment #22(install Lang-pack in Program directory),
        rename chrome\chrome.rdf/components\{compreg & xpti}.dat to *-DELETED
        => Lang-pack can be used normaly,
           although slightly slower start-up time due to no compreg.dat etc.
No side-effect on lang-pack was observed.

Note You need to log in before you can comment on or make changes to this bug.