Closed
Bug 539869
Opened 14 years ago
Closed 14 years ago
move WebContentConverter out of the startup path
Categories
(Firefox Graveyard :: RSS Discovery and Preview, defect)
Firefox Graveyard
RSS Discovery and Preview
Tracking
(Not tracked)
RESOLVED
WONTFIX
People
(Reporter: dietrich, Assigned: asaf)
Details
(Whiteboard: [ts])
Attachments
(1 file)
2.21 KB,
patch
|
asaf
:
review-
|
Details | Diff | Splinter Review |
Is there a reason why this can't be loaded on demand?
Reporter | ||
Updated•14 years ago
|
Whiteboard: [ts]
Reporter | ||
Updated•14 years ago
|
Assignee: nobody → dietrich
Updated•14 years ago
|
Attachment #421765 -
Attachment is patch: true
Attachment #421765 -
Attachment mime type: application/octet-stream → text/plain
Reporter | ||
Comment 1•14 years ago
|
||
ran the xpcshell, mochitest-plain and mochitest-chrome tests in /feeds against this patch, and everything passed.
Reporter | ||
Updated•14 years ago
|
Attachment #421765 -
Flags: review?(mano)
Reporter | ||
Comment 2•14 years ago
|
||
Comment on attachment 421765 [details] [diff] [review] push back will remove the commented out code if we go ahead w/ this.
Assignee | ||
Comment 3•14 years ago
|
||
Comment on attachment 421765 [details] [diff] [review] push back With this change, the service would be initialized only once registerContentHandler (the DOM one, in nsGlobalWindow) is called. That may seem OK if you think the only thing service does is saving preference, but actually it also uses them ;) See _updateContentTypeHandlerMap (in particular, the call to registerFactory).
Attachment #421765 -
Flags: review?(mano) → review-
Reporter | ||
Comment 4•14 years ago
|
||
Ok, thanks. Can you recommend where we should make the change to load this on first-need instead of app startup?
Assignee | ||
Comment 5•14 years ago
|
||
nsStreamConverterService is the component the uses the handlers (See the long comment in http://mxr.mozilla.org/mozilla-central/source/netwerk/streamconv/public/nsIStreamConverter.idl). However, I don't think we can win much by adding it there (it's like changing IO.newURI...). The only thing you could do, I think, is to copy over some of this code to browser.js or to some other service that is loaded on startup.
Assignee | ||
Comment 6•14 years ago
|
||
i.e. browserglue...
Assignee | ||
Comment 7•14 years ago
|
||
Or you could move the registration to nsBrowserGlue and use it from this service.
Assignee | ||
Updated•14 years ago
|
Assignee: dietrich → mano
Assignee | ||
Comment 8•14 years ago
|
||
Hey Dietrich, I investigated this today a little bit. It seems that the only thing we can do is to merge this service with BrowserGlue. That will save the component registration time, but we'll still register the factory for each content type on startup. I don't think it's worth it unless we know for sure that component registration is as expensive.
Assignee | ||
Updated•14 years ago
|
Whiteboard: [ts] → [ts][wontfix?]
Reporter | ||
Comment 9•14 years ago
|
||
talked w/ mano on irc. given that the architecture won't allow us to easily register the content types on demand, going to WONTFIX.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WONTFIX
Reporter | ||
Updated•14 years ago
|
Whiteboard: [ts][wontfix?] → [ts]
Updated•5 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•