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)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: dietrich, Assigned: asaf)

Details

(Whiteboard: [ts])

Attachments

(1 file)

Attached patch push backSplinter Review
Is there a reason why this can't be loaded on demand?
Whiteboard: [ts]
Assignee: nobody → dietrich
Attachment #421765 - Attachment is patch: true
Attachment #421765 - Attachment mime type: application/octet-stream → text/plain
ran the xpcshell, mochitest-plain and mochitest-chrome tests in /feeds against this patch, and everything passed.
Attachment #421765 - Flags: review?(mano)
Comment on attachment 421765 [details] [diff] [review]
push back

will remove the commented out code if we go ahead w/ this.
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-
Ok, thanks. Can you recommend where we should make the change to load this on first-need instead of app startup?
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.
i.e. browserglue...
Or you could move the registration to nsBrowserGlue and use it from this service.
Assignee: dietrich → mano
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.
Whiteboard: [ts] → [ts][wontfix?]
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
Whiteboard: [ts][wontfix?] → [ts]
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: