165100 - typeaheadfind.dll loads too early

Status: RESOLVED WONTFIX

(SeaMonkey :: Find In Page, defect)

Description

[Daniel Bratell]

typeaheadfind.dll loads very early when Mozilla is started. Even before 
necko.dll. The load should be delayed until typeaheadfind is used to save both 
startup time and footprint.

Comment 1

[Aaron Leventhal]

The only way I know to do this would be hacky. When/where do you think it should
be loaded? It needs to attach it's listeners right away so that when a keystroke
comes in, it's ready for it.

Comment 2

[Daniel Bratell]

I don't know enough about how the DLL:s are loaded to tell. There are other
dll:s that are loaded on demand after the first window has opened and the
solution they uses might be used here too.

Comment 3

[Hixie (not reading bugmail)]

this should definitely not be loaded until _after_ we have loaded a page in the
content area, otherwise it will be hitting both startup and page load times for
no reason (since the user can't use this that early anyway).

Comment 4

[Aaron Leventhal]

Right now I get initialized because of this line in nsTypeAheadFindRegistration.cpp

    rv = categoryManager->AddCategoryEntry(APPSTARTUP_CATEGORY,
                                           "Type Ahead Find", 
                                           "service,"
                                           NS_TYPEAHEADFIND_CONTRACTID,
                                           PR_TRUE, PR_TRUE, nsnull);

Comment 5

[Aaron Leventhal]

After talking with Johnny Stenback and John Morrison, it sounds like what we're
doing now is fine. It's such a small .dll that it doesn't appear to affect
startup time at all.

Since typeaheadfind is needed right away to set up keystroke handlers, and since
there is no apparent performance problem, and since we can't think of any other
clean non-hacky way to load it on demand, we're going to leave it as is.

Comment 6

[Aaron Leventhal]

I should have also mentioned that since it appears typeaheadfind is going to be
turned on by default in all of our builds, we wouldnt' be saving on footprint
either.

Comment 7

[John Morrison]

Actually, I still think this should stay open but 'for later'. I don't have a 
smoking gun although conceptually I believe we should delay-load as many DLLs
as possible (as has been done for a variety of other page-oriented features).

Remember: "It's not the last cookie that makes you fat" :-)

Comment 8

[John Morrison]

Or, to be clear, I said I was fine with not fixing this now. But I should have 
said that we should do this someday (unless it's architecturally impractical
but I don't think that's the case. Icky and messy, sure, but still doable :-)

Comment 9

[Johnny Stenback (:jst)]

There comes a point where "Icky and messy" weighs quite a lot compared to
eagerly loading a library that'll be loaded anyway though. I'm fine with
delaying loading of this library, but I doubt it'll be pretty...

Comment 10

[Serge Gautherie (:sgautherie)]

This dll still exists in SM v1.1.13 and existed in v1.5a,
but it doesn't exist anymore in current v2.0a2pre:
R.WontFix

Reopen if I missed something.