Now that bug 399740 has landed, FAYT works again. However, we don't show any information in the status bar. I think this is a separate ("Camino-only") regression from the actual breaking of FAYT, since the SeaMonkey builds I checked when finding the regression range in 399740 had the status text even when they wouldn't find. We should see where this is broken and request blocking if it's in Core.

This was already broken in 10/10/07 build, which is before FAYT broke entirely, so it's definitely separate. We should try to get a regression range for this.

Fails: Version 2007051205 (2.0a1pre) Works: Version 2007051102 (2.0a1pre) http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2007-05-11+01%3A00%3A00&maxdate=2007-05-12+05%3A00%3A00&cvsroot=%2Fcvsroot a couple of Camino checkins in there: bug 376871, bug 374623, but also bug 377801 (move suite's typeaheadfind locale file so that it works with 'source L10n')

(In reply to comment #2) > but also bug 377801 (move suite's typeaheadfind locale file so that it works > with 'source L10n') Yeah, that's going to be it. The file's no longer being packaged because it's not somewhere we build. Probably our best option is to land a copy of the file in embed-replacements in the new correct location. That way we don't disrupt Suite localization, and we could also fix the "--" in those strings that smfr hates so much - bug 244175 comment 23.

So, the file reference moved from "chrome://global/locale/typeaheadfind.properties" aka embed.jar!locale/en-US/global/typeaheadfind.properties to "chrome://communicator/locale/typeaheadfind.properties" I filed a copy of it in embed-replacements such that it ended up as the corresponding embed.jar!locale/en-US/communicator/typeaheadfind.properties, but that didn't get us strings (and chrome://communicator/locale/typeaheadfind.properties brings up an error page, whereas chrome://global/locale/typeaheadfind.properties on the branch shows the file content). Something else is still broken here :/

So the issue turned out to be we had the communicator locale package registered (from embed.jar, I think), but we also needed a contents.rdf in locale/en-US/communicator/ to make the chrome registry know we actually had that package :P There's not one in the tree that we can just pull over, so this stuffs one in embed-replacements. It's mildly fragile, but those version numbers don't seem to matter; other contents.rdf files are also still "1.9a1". Hopefully this means that by the time the number needs to change we'll no longer be using this chrome style. I also fixed the straight quotes and the -- in typeaheadfind.properties; the former will help us have one less file to \"-escape when we convert these to .strings files.

Comment on attachment 316847 [details] [diff] [review] fix r=me; you rock! The emdash and smart quotes are so pretty :)

Comment on attachment 316847 [details] [diff] [review] fix sr=pink

Landed on the trunk.