The roads I take...

One of the last legacy modules SeaMonkey currently is still importing from old CVS is extensions/typeaheadfind. This modules drives the suite's "Find as you type" feature in browser and even mailnews message content areas and is invoked by just typing some text to be found, possibly prefixed by / or ' to specify searching in any text or just links, and giving UI feedback on those actions in the status bar. While this is quite convenient for the power user, it's hardly discoverable for people who don't know it.
Because of that, Firefox developers have forked that code into the toolkit, reworked it a bit and developed the "findbar" UI that appears at the bottom of browser windows based on it, merging it with the "find in page" feature that was/is an annoying separate dialog in the suite and making it much better discoverable.

Now, SeaMonkey supporters have basically had two problems with that approach for quite some time:

1. Even for an advanced user, there's no possibility to get rid of needing an additional UI element, reducing screen estate more than those users want
2. Having this find bar at the bottom of the window conflicts with usual user workflow that is top-to-bottom - that's why every window that constantly shows a search bar has that bar above the searched content.

The former probably could be addressed with a pref and some coding if wanted, the latter was actually an intentional decision: If the bar would open at the top of the content part of the window, Firefox devs said it would push content down, and moving content is a bad experience. Now they did implement moving content with notification bars, but even there it's suboptimal. A look at Safari shows how a solution for such issues could look like UI-wise: We could just open such a bar more or less over the top part of the content, just adjusting the scrollbar so one could scroll up to the now hidden top of the content, leaving the page itself completely in place. That only works well when a scrollbar is already shown, but then, I think people mostly use such a findbar on pages that already show a scrollbar.
In any case, any of those solutions would need someone to work on, and actually, the "find as you type" feature works well enough for most SeaMonkey devs not to think about this and not pick up such work.

Now enter today: Benjamin Smedberg checked in a "deCOMtamination" patch that breaks suite typeaheadfind, and it's hard to just fix this as the code still lives in CVS and is shared with 1.9.0-based Camino. There are multiple reasons why I tried very hard to keep things this way and not move the code to suite/ in comm-central:

• The code is unmaintained. Nobody touches it unless it breaks and then only small bustage fixes are applied.
• This module duplicates functionality the toolkit code in mozilla-central provides in the before mentioned findbar code.
• The current code does not build on frozen interfaces and so would break in a conversion of SeaMonkey to XULRunner, probably even on the road to using libxul, and actually it even breaks compilation of static SeaMonkey builds, which we should look into for releases
• As mentioned above, the UI is not ideal, does not deal with other "find in page" and doesn't work well with IMEs as used in Asian countries.

So, how to fix the breakage introduced by this deCOM patch, when it can't be done in CVS but importing into suite/ is a bad idea as well? For now, I think the best idea is removing the whole module from the SeaMonkey build. Yes, that means we won't have a "find as you type" feature at all for the moment - but perhaps exactly that is a reason for someone to step in and finally hack on something that builds on toolkit code, is maintained, and really does what it should do. I'm very interested in how this works out.

Oh, and if you can help here, we'd very much appreciate it!