606076 - XUL Prototype cache is not invalidated immediately after a new extension is installed

Status: RESOLVED FIXED

(Core :: XPCOM, defect)

Description

[Alice0775 White]

Attachment: 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.

Comment 1

[Alice0775 White]

Corrected
> 3. Exit browser and start browser eith the profile again
3. Exit browser and start browser with the profile again

Comment 2

[Alice0775 White]

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

Comment 3

[Alice0775 White]

Oops in comment #2

s/c7df4612f8e/8c7df4612f8e/

Comment 4

[Alice0775 White]

Sorry, too much spelling miss...
>Expected Results:
> Style should be not applied.

Expected Results:
  Style should be applied.

Comment 5

[Alice0775 White]

This also happens on Linux.
Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101020 Firefox/4.0b8pre ID:20101020104642

Comment 6

[Dave Townsend [:mossop]]

Seems the startup cache isn't getting invalidated properly, digging in now

Comment 7

[Dave Townsend [:mossop]]

Actually I guess it is the XUL cache that is stale, not surprisingly since we don't flush it anywhere

Comment 8

[Dave Townsend [:mossop]]

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

Comment 9

[Benedict Hsieh [:benedict]]

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.

Comment 10

[Dave Townsend [:mossop]]

(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.

Comment 11

[Benedict Hsieh [:benedict]]

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.

Comment 12

[Dave Townsend [:mossop]]

Attachment: 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.

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

Dave tells me that this is needed for people who'll be using beta7 as the base for add-on compatibility. Compelling!

Comment 14

[Dave Townsend [:mossop]]

Landed: http://hg.mozilla.org/mozilla-central/rev/18db490056aa