165398 - More perf improvements for typeaheadfind

Status: VERIFIED WONTFIX

(SeaMonkey :: Find In Page, defect)

Description

[Aaron Leventhal]

It turns out that the recent checkin for bug 161960 seems to fix the page load
problem, afaict. However, we should look at other potential perf issues, such as
startup time and typing speed.

Possibility #1 - startup fix
Right now typeaheadfind is a component that registers it with
nsIAppStartupNotifier. This makes the .dll get loaded no matter what, even when
the pref is off. Perhaps the typeaheadfind service should only be loaded after
the first keystroke has been pressed (in content).

Possibility #2 - keystroke fix
Rather than having to check whether keystrokes that come in aren't in an
editor/mailnews window or in an edit field or selecti control, we could hook in
where the browser already deals with keystrokes aimed at content. For example,
nsDOMWindowControler::DoCommand() already knows that we're not in an edit field
or in a select, or in the editor. The problem with this is that
nsDOMWindowController::DoCommand() doesn't know what the keystroke was; that
info doesn't get passed in. Therefore I don't think this is necessarily a good idea.

Possibility #3
Finally, as bzbarsky said in bug 161960:
+  nsCOMPtr<nsISelectElement> selectEl(do_QueryInterface(domEventTarget));
+  if (selectEl) {

> It may be faster to QI domEventTarget to nsIContent, check that it's an HTML
> content (using IsContentOfType) and if it is getting the tag and comparing to
> nsHTMLAtoms::select.  That involves a succeeding QI (which is much faster than 
> a failing QI, which is what this code would usually encounter) and some very 
> cheap getters/comparisons.

Comment 1

[Aaron Leventhal]

Perf issues are resolved. We can't find any bad numbers to fix.

Comment 2

[sairuh (rarely reading bugmail)]

mass-verifying Wontfix bugs.

mail filter string for bugspam: Tursiopstruncatus