Closed
Bug 606076
Opened 14 years ago
Closed 14 years ago
XUL Prototype cache is not invalidated immediately after a new extension is installed
Categories
(Core :: XPCOM, defect)
Tracking
()
RESOLVED
FIXED
mozilla2.0b7
Tracking | Status | |
---|---|---|
blocking2.0 | --- | beta7+ |
People
(Reporter: alice0775, Assigned: mossop)
References
Details
(Keywords: regression)
Attachments
(2 files)
(deleted),
application/x-xpinstall
|
Details | |
(deleted),
patch
|
benjamin
:
review+
|
Details | Diff | Splinter Review |
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•14 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•14 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
Reporter | ||
Comment 3•14 years ago
|
||
Oops in comment #2
s/c7df4612f8e/8c7df4612f8e/
Reporter | ||
Comment 4•14 years ago
|
||
Sorry, too much spelling miss...
>Expected Results:
> Style should be not applied.
Expected Results:
Style should be applied.
Reporter | ||
Comment 5•14 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•14 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•14 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•14 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
Comment 9•14 years ago
|
||
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•14 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.
Comment 11•14 years ago
|
||
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•14 years ago
|
||
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•14 years ago
|
Whiteboard: [has patch][needs review bsmedberg]
Updated•14 years ago
|
Attachment #485925 -
Flags: review?(benjamin) → review+
Assignee | ||
Updated•14 years ago
|
Whiteboard: [has patch][needs review bsmedberg]
Comment 13•14 years ago
|
||
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•14 years ago
|
||
Status: NEW → RESOLVED
Closed: 14 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.
Description
•