Last Comment Bug 401175 - FAYT no longer displays information in the status bar
: FAYT no longer displays information in the status bar
Status: RESOLVED FIXED
: regression
Product: Camino Graveyard
Classification: Graveyard
Component: General (show other bugs)
: Trunk
: PowerPC Mac OS X
: -- normal (vote)
: Camino2.0
Assigned To: Smokey Ardisson (offline for a while; not following bugs - do not email)
:
Mentors:
Depends on:
Blocks: 377801
  Show dependency treegraph
 
Reported: 2007-10-25 17:18 PDT by Smokey Ardisson (offline for a while; not following bugs - do not email)
Modified: 2008-04-22 14:29 PDT (History)
5 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
fix (2.30 KB, patch)
2008-04-21 11:42 PDT, Smokey Ardisson (offline for a while; not following bugs - do not email)
stuart.morgan+bugzilla: review+
mikepinkerton: superreview+
Details | Diff | Review

Description Smokey Ardisson (offline for a while; not following bugs - do not email) 2007-10-25 17:18:15 PDT
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.
Comment 1 Stuart Morgan 2008-03-29 16:03:01 PDT
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.
Comment 2 philippe (part-time) 2008-03-29 20:50:49 PDT
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') 
Comment 3 Smokey Ardisson (offline for a while; not following bugs - do not email) 2008-03-29 21:43:12 PDT
(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.
Comment 4 Smokey Ardisson (offline for a while; not following bugs - do not email) 2008-04-06 18:55:46 PDT
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 :/
Comment 5 Smokey Ardisson (offline for a while; not following bugs - do not email) 2008-04-21 11:42:59 PDT
Created attachment 316847 [details] [diff] [review]
fix

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 6 Stuart Morgan 2008-04-21 20:19:54 PDT
Comment on attachment 316847 [details] [diff] [review]
fix

r=me; you rock! The emdash and smart quotes are so pretty :)
Comment 7 Mike Pinkerton (not reading bugmail) 2008-04-22 13:44:48 PDT
Comment on attachment 316847 [details] [diff] [review]
fix

sr=pink
Comment 8 Smokey Ardisson (offline for a while; not following bugs - do not email) 2008-04-22 14:29:05 PDT
Landed on the trunk.

Note You need to log in before you can comment on or make changes to this bug.