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

RESOLVED FIXED in mozilla2.0b7

Status

()

Core
XPCOM
RESOLVED FIXED
7 years ago
7 years ago

People

(Reporter: Alice0775 White, Assigned: mossop)

Tracking

({regression})

Trunk
mozilla2.0b7
x86
All
regression
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite +
in-litmus -

Firefox Tracking Flags

(blocking2.0 beta7+)

Details

Attachments

(2 attachments)

(Reporter)

Description

7 years ago
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.
(Reporter)

Comment 1

7 years ago
Corrected
> 3. Exit browser and start browser eith the profile again
3. Exit browser and start browser with the profile again
(Reporter)

Comment 2

7 years ago
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
Blocks: 576553
blocking2.0: --- → ?
Keywords: regression
(Reporter)

Comment 3

7 years ago
Oops in comment #2

s/c7df4612f8e/8c7df4612f8e/
(Reporter)

Comment 4

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

Expected Results:
  Style should be applied.
(Reporter)

Comment 5

7 years ago
This also happens on Linux.
Mozilla/5.0 (X11; Linux i686; rv:2.0b8pre) Gecko/20101020 Firefox/4.0b8pre ID:20101020104642
OS: Windows 7 → All
(Assignee)

Comment 6

7 years ago
Seems the startup cache isn't getting invalidated properly, digging in now
blocking2.0: ? → beta8+
Component: Add-ons Manager → XPCOM
Product: Toolkit → Core
QA Contact: add-ons.manager → xpcom
(Assignee)

Comment 7

7 years ago
Actually I guess it is the XUL cache that is stale, not surprisingly since we don't flush it anywhere
Assignee: nobody → dtownsend
(Assignee)

Comment 8

7 years ago
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
Depends on: 592943
Summary: Style is not applied, after install xpi and restart Browser → XUL Prototype cache is not invalidated immediately after a new extension is installed
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.
(Assignee)

Comment 10

7 years ago
(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.
(Assignee)

Comment 12

7 years ago
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.
Attachment #485925 - Flags: review?(benjamin)
(Assignee)

Updated

7 years ago
Whiteboard: [has patch][needs review bsmedberg]
Attachment #485925 - Flags: review?(benjamin) → review+
(Assignee)

Updated

7 years ago
Whiteboard: [has patch][needs review bsmedberg]
Dave tells me that this is needed for people who'll be using beta7 as the base for add-on compatibility. Compelling!
blocking2.0: beta8+ → beta7+
(Assignee)

Comment 14

7 years ago
Landed: http://hg.mozilla.org/mozilla-central/rev/18db490056aa
Status: NEW → RESOLVED
Last Resolved: 7 years ago
Flags: in-testsuite+
Flags: in-litmus-
Resolution: --- → FIXED
Target Milestone: mozilla2.0 → mozilla2.0b7
You need to log in before you can comment on or make changes to this bug.