Closed
Bug 666896
Opened 14 years ago
Closed 13 years ago
Unresponsive/Hanging script warning while trying to install Lightning 1.0b4 in Thunderbird 5.0b2
Categories
(Toolkit :: Add-ons Manager, defect)
Tracking
()
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
"
Comment 1•14 years ago
|
||
I can't reproduce this on a clean profile on windows 7. Is this reproducible for you on 5.0b2?
Reporter | ||
Comment 2•14 years ago
|
||
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.
Comment 3•14 years ago
|
||
(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.
Comment 4•14 years ago
|
||
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?
Comment 5•14 years ago
|
||
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
Reporter | ||
Comment 6•13 years ago
|
||
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.
Comment 7•13 years ago
|
||
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
Reporter | ||
Comment 8•13 years ago
|
||
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
Comment 9•13 years ago
|
||
Exactly. The timeout is not disabled for chrome scripts by default. I also have hit this with our Mozmill Crowd extension.
Comment 10•13 years ago
|
||
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.
Comment 11•13 years ago
|
||
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...
Comment 12•13 years ago
|
||
... 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.
Comment 13•13 years ago
|
||
... 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.
Comment 14•13 years ago
|
||
...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).
Comment 15•13 years ago
|
||
(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?
Comment 16•13 years ago
|
||
(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
Comment 17•13 years ago
|
||
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
Reporter | ||
Comment 18•13 years ago
|
||
(In reply to comment #15)
> Does everyone seeing this have their profile files encrypted?
No. So duping against bug 562674?
Comment 19•13 years ago
|
||
(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.
Reporter | ||
Comment 20•13 years ago
|
||
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.
Comment 22•13 years ago
|
||
With Lightning 1.0b4 TB5 takes some 5+ minutes to start.
W/out Lightning - around 20 sec
Comment 23•13 years ago
|
||
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.
Comment 24•13 years ago
|
||
(for 1.0b5 of course, see addons.mozilla.org)
Comment 25•13 years ago
|
||
(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.
Comment 26•13 years ago
|
||
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: 13 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•