Created attachment 484941 [details] test xpi, this extension changes text color of the browser UI Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101020 Firefox/4.0b8pre ID:20101020120347 If the browser start with new profile, Style is not applied, after install xpi and restart Browser. And the Style is applied when I restart browser once again. It happens only in case of browser started with newly created profile. And the xpi uses "style" in chrome.manifest Reproducible: Always Steps to Reproduce: 1. Start Minefield with -P option 2. Create a new profile. and start browser with the new profile. 3. Exit browser and start browser eith the profile again 4. Install xpi and restart browser. Actual Results: Style is not applied. Restart browser once again. then style is applied. Expected Results: Style should be not applied.
Corrected > 3. Exit browser and start browser eith the profile again 3. Exit browser and start browser with the profile again
Regression window: Works: http://hg.mozilla.org/mozilla-central/rev/fd1592c0dae1 Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100714 Minefield/4.0b2pre ID:20100714111119 Fails: http://hg.mozilla.org/mozilla-central/rev/0391518a24b5 Mozilla/5.0 (Windows; Windows NT 6.1; WOW64; en-US; rv:2.0b2pre) Gecko/20100714 Minefield/4.0b2pre ID:20100714115823 Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=fd1592c0dae1&tochange=0391518a24b5 Candidate bug:(from cghangeset no) Bug 576553 - Don't restart for extension installation any more (No EM restart) NOTE Maybe Annotation of the changeset is wrong. c7df4612f8e Dave Townsend — Bug 376553: Don't restart during startup affor extension and app changes. r=robstring, r=bsmedberg
Oops in comment #2 s/c7df4612f8e/8c7df4612f8e/
Sorry, too much spelling miss... >Expected Results: > Style should be not applied. Expected Results: Style should be applied.
This also happens on Linux. Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101020 Firefox/4.0b8pre ID:20101020104642
Seems the startup cache isn't getting invalidated properly, digging in now
Actually I guess it is the XUL cache that is stale, not surprisingly since we don't flush it anywhere
I had thought that bug 592943 was already fixed. I guess at this point we need to figure out an alternate method for clearing the fastload cache at runtime. It looks like we do this early enough that it doesn't yet exist so I guess one quick hack would be to delete the files
Sending the "startupcache-invalidate" notification should clear out the xulprototypecache and remove the backing fastload file as well. See code around: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/XPIProvider.jsm#2185 Sorry, don't have a working build environment to try this out at the moment.
(In reply to comment #9) > Sending the "startupcache-invalidate" notification should clear out the > xulprototypecache and remove the backing fastload file as well. See code > around: > http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/extensions/XPIProvider.jsm#2185 Yeah I know that code, it doesn't seem to work though. I haven't debugged into AbortFastLoads yet but it looks to me like if the fast load service hasn't been used yet in the session (likely since no XUL windows will have displayed by this point) then the fast load file won't get removed.
Argh, yeah, you're right. The gFastloadFile in xulprototypecache won't be set if StartFastLoad() hasn't been called. One thing to do could be to change nsXULPrototypeCache::AbortFastLoads() to get a proper reference to that file if it doesn't exist.
Created attachment 485925 [details] [diff] [review] patch rev 1 Two issues here. Firstly as mentioned AbortFastLoads doesn't actually clear the fast load cache if the fast load service hasn't yet been used. Secondly AbortFastLoads isn't actually called because the observer service registration was missed. I made AbortFastLoads get the fast load service if it hasn't yet been started. This seems to be side-effect free and the rest of the method will just proceed with the output and input streams as null. Added some tests that verify that the fastload file gets deleted as expected. This isn't a full test of the fast load cache but I think it is a useful one for this case.
Dave tells me that this is needed for people who'll be using beta7 as the base for add-on compatibility. Compelling!