Closed Bug 394713 Opened 17 years ago Closed 17 years ago

SeaMonkey 1.1.4 takes much longer to start without administrator privileges than with

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Version:
SeaMonkey 1.1 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: tilman, Unassigned)

References

Details

(Keywords: fixed-seamonkey1.1.7) 

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
Do you have any extensions other than Mnenhy installed?
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

See Bug 394190 – seamonkey/thunderbird not starting up due to CRT/manifest issues in components (https://bugzilla.mozilla.org/show_bug.cgi?id=394190)
I have looked at bug 394190 but cannot see any similarity between the symptoms described there and those I am experiencing.
@Worcester12345: Bug 394190 is about trunk, not about branch...
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)?
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.

And the problem started after installing the last extension or when did this start?
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.
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?
After I renamed %ProgramFiles\mozilla.org\SeaMonkey\chrome\chrome.rdf to ~.rdf-DELETED, SeaMonkey's startup time went back to the normal few seconds.

A side effect of the deletion of chrome.rdf is that the German localization no longer works.
(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?

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.
(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?
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.
Depends on: 402460
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/
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!

So, can we mark this FIXED or actually a dupe of bug 402460?
Fixed by checkin of bug 402460.
Status: UNCONFIRMED → RESOLVED
Closed: 17 years ago
Keywords: fixed-seamonkey1.1.7
Resolution: --- → FIXED
Version: unspecified → SeaMonkey 1.1 Branch
(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.   
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

 

(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.
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.
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.
You need to log in before you can comment on or make changes to this bug.