Closed Bug 666896 Opened 13 years ago Closed 12 years ago

Unresponsive/Hanging script warning while trying to install Lightning 1.0b4 in Thunderbird 5.0b2

Categories

(Toolkit :: Add-ons Manager, defect)

Product:
Toolkit
Component:
Add-ons Manager
Version:
5 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED DUPLICATE of bug 562674

People

(Reporter: aryx, Unassigned)

References

Details

(Keywords: perf) 

Windows XP SP 3 32-bit, Thunderbird 5.0b2

There is a hanging script warning while trying to install Lightning 1.0b4 in Thunderbird 5.0b2. Seen in used and new profile. Not seen when I tried to reproduce with Thunderbird nightly and Lightning nightly.

Steps to reproduce:
1. Open the add-ons manager.
2. Open the extensions pane.
3. Open http://releases.mozilla.org/pub/mozilla.org/calendar/lightning/releases/1.0b4rc1/win32/ in the browser.
4. Drag and drop the lightning.xpi to the extensions pane.
5. Wait for the download to finish and the install prompt to show up. Confirm it.

Actual result:
Unresponsive script warning:

"
A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.

Script: resource://gre/modules/XPIProvider.jsm:862
"
I can't reproduce this on a clean profile on windows 7. Is this reproducible for you on 5.0b2?
Tested again, two tries, got the warning both times. After clicking the 'Install' confirmation button, the application gets unresponsive and I see much disk activity. The message is shown immediately after Thunderbird gets again responsive and Lightning is shown in the add-ons manager as 'Installing' with the progress bar minimally filled on the left.
(In reply to comment #0)
> Script: resource://gre/modules/XPIProvider.jsm:862

Please more details. Copy and paste the code and mark the line of the code.
That'd be http://mxr.mozilla.org/mozilla-beta/source/toolkit/mozapps/extensions/XPIProvider.jsm#862

Could it be that a Background running App (AV, Anti-Malware etc.) does some Realtime Scanning on the Extension Archive File against your TB 5.0 Installation?
Actually http://mxr.mozilla.org/mozilla-beta/source/toolkit/mozapps/extensions/XPIProvider.jsm#898

It does suggest it is taking a long time to extract the xpi, which would be strange
I switched to Microsoft Security Essentials a few weeks ago.

Security Essentials-Version: 2.0.657.0
Antischadsoftwareclient-Version: 3.0.8107.0
Modulversion: 1.1.7000.0
Virendefinition: 1.107.355.0
Spywaredefinition: 1.107.355.0

Even with its runtime protection disabled, I still see the unresponsive script warning.
All that small files in Lightning trash the extraction performance, extracting with 7-zip manages to write only 1 MB/s.
The Lightning nightly likely causes no problems because it en-US only, while the 1.0b4 contains all its localizations.
If it's really just a long running extraction then I don't know why the slow script warning is displaying, it's meant to be disabled for chrome
As far as I know dom.max_chrome_script_run_time controls this [1] and is set to show the hanging script warning after 20 seconds (the same value for Firefox 5.0 and Thunderbird 5.0b2).

[1]: http://kb.mozillazine.org/Dom.max_chrome_script_run_time
Exactly. The timeout is not disabled for chrome scripts by default. I also have hit this with our Mozmill Crowd extension.
confirming same bug here, it's been driving me mad for the last hour or so, it's a no go, hanging install process and then script not responding message.

ps: this is with lightning 1.0b4 on Thb5.0b2 on W7/64

...also wanted to mention, I could manage an install or lightning 1.0b4 to run on a clean thb profile using default location in app data. Clean profile or not, it's a no go as soon as I use a relocated (to a folder and partition of my choice) profile.
yeah an extraction with 7Zip takes about 55s here. But if I wait for the script to respond when attempting to install in thb, it just never ends...
... okay I think I got it, works at least here: the extension refuses to install if the profile is EFS encrypted. Decryption, install of 1.0b4 and then re-encryption is fine.
... just noting that after re-encryption, some compatible extensions got marked as incompatible, got solved after checking for updates... actually nothing got updated, just got the message that the extensions in question would be re-enabled after a restart.

 ... my guess is that Thb5.0b2 might have some general access right (privilege) issues with Windows EFS.
...still stranger, AB+ 1.3.8 is considered compatible while the profile folder is not encrypted, as soon as it is, 1.3.9 (experimental build) becomes mandatory. So there must be something broken with compatibility check as well in the first place, as 1.3.8 should never have been "accepted" (I don't have compatibility check disabled).
(In reply to comment #13)
> ... just noting that after re-encryption, some compatible extensions got
> marked as incompatible, got solved after checking for updates... actually
> nothing got updated, just got the message that the extensions in question
> would be re-enabled after a restart.

This is expected if that process involved changing the modification times of the extensions' files.

(In reply to comment #12)
> ... okay I think I got it, works at least here: the extension refuses to
> install if the profile is EFS encrypted. Decryption, install of 1.0b4 and
> then re-encryption is fine.

Does everyone seeing this have their profile files encrypted?
(In reply to comment #15)
> (In reply to comment #12)
> > ... okay I think I got it, works at least here: the extension refuses to
> > install if the profile is EFS encrypted. Decryption, install of 1.0b4 and
> > then re-encryption is fine.
> 
> Does everyone seeing this have their profile files encrypted?

Ok, with EFS on I can see the install taking longer than normal, I have a very fast machine so it doesn't timeout for me, but at least it's something to go on
Looking at the process monitor logs during this I'm not seeing anything obviously stupid going on. I've known for a while that a long running installation could freeze the UI as we aren't doing it asynchronously right now, using EFS compounds the problem because in my timings it takes a little more than twice as long to extract the files as without. I think the only way to solve this is to fix bug 562674, not investigated how difficult that would be yet.
Depends on: 562674
(In reply to comment #15)
> Does everyone seeing this have their profile files encrypted?

No. So duping against bug 562674?
(In reply to comment #18)
> (In reply to comment #15)
> > Does everyone seeing this have their profile files encrypted?
> 
> No. So duping against bug 562674?

Depends if we either think there is something more strange going on with your profile, or if we want to leave this open for a potential lightning fix. They could f.e. support installing their extension as a packed XPI. That removes the extraction step and so would make installation near instant. Tbh it's likely to be quicker for them to do that than for us to get full async extraction of all XPIs done.
AFAIK, there are two problems blocking packed XPI install:
- windows icons
- binary components (they have at least one DLL)
But packaging folders into jars should be an alternative.
With Lightning 1.0b4 TB5 takes some 5+ minutes to start. 
W/out Lightning - around 20 sec
Severity: normal → major
Keywords: perf
I've tried to work around this bug by packaging the locales as .jar files instead of flat inside the xpi. This reduces the file size by about 1MB, maybe thats enough to work around this issue.
(for 1.0b5 of course, see addons.mozilla.org)
(In reply to comment #23)
> I've tried to work around this bug by packaging the locales as .jar files
> instead of flat inside the xpi. This reduces the file size by about 1MB,
> maybe thats enough to work around this issue.

I think the fewer files in the xpi the better. If all of the locales and chrome were in one jar for example then I suspect this problem would go away, maybe also with each locale in its own jar.
Lightning works now with the workaround noted in comment 23 and I could possibly further reduce this with comment 25.

I think the rest can be taken care of in bug:
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.