custom-strings.txt do not work in TB 38.0.1



3 years ago
3 years ago


(Reporter:, Unassigned)



38 Branch
Mac OS X

Firefox Tracking Flags

(Not tracked)



(2 attachments)



3 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Firefox/38.0
Build ID: 20150525141253

Steps to reproduce:

Thunderbird 38.0.1, Mac OS X 10.10.3

Prior to 38.0.1 (in 37.x and earlier versions), a special file called custom-strings.txt when added to the installation location of Applications->TB->Contents->MacOS->chrome (this is in case of OS X), would shorten the Status column value as seen in the TB UI to what ever the file had contained. So, my custom-strings.txt look like the following:

chrome%3A//messenger/locale/*%.*f MB

When added to the above mentioned location, the Status column, for e.g. instead of showing Replied (long name) would show instead "A" as dictated by the above file entry. Same thing for other values listed above.




Actual results:

After upgrading from 37.1.0 to 38.0.1, custom-strings.txt no longer work. I have tested this both by doing an upgrade from 37.1.0 to 38.0.1 with an existing profile and also doing a fresh/new install of 38.0.1 with a brand new profile. In both cases, even though custom-strings.txt is present, it will not show the Status column value to what the file dictates. This is reproduce-able always.

Expected results:

custom-strings.txt should replace the Status column value as follows:



3 years ago
Severity: normal → major
OS: Unspecified → Mac OS X
Hardware: Unspecified → All

Comment 2

3 years ago
I'm unable to reproduce this on either Windows 7 or Linux x86_64 release builds. Putting the custom-strings.txt file into the chrome directory of the installation works on 31.7.0 and after updating to 38.0.1 as intended (with both testing and production profiles). That file also wasn't removed during the automated update, as tested on Windows. Thus, either it's something MacOSX-specific (which I don't have available for testing) or in your installation.

Do you see anything in the Error Console? From the forum thread, you've already tried a fresh profile for testing without success, so that's apparently not causing the issue either.

Comment 3

3 years ago
The only error that I see in the Error Console is:

Timestamp: 6/15/15, 9:26:08 AM
Error: unclosed token
Source File: moz-nullprincipal:{2e33d59e-357c-8448-b2d4-4b2a151a1e64}
Line: 1, Column: 1
Source Code:

I tried with both existing and a fresh/new profile and see the same behavior, so nothing profile specific. I'm hoping that someone else who may be using this on OS X can confirm/deny this behavior.

Comment 4

3 years ago
I can concur that this behavior is specific to OS X. I tested it on my Windows 7 PC and custom-strings.txt work as expected.

Comment 5

3 years ago
Source File: moz-nullprincipal:{2e33d59e-357c-8448-b2d4-4b2a151a1e64} error in the Error Console is due to the Quicktext add-on which is not updated to work with 38.0.1

Comment 6

3 years ago
I take it that disabling it didn't resolve the issue?

Comment 7

3 years ago
Oh, just saw this:
> Disabling it, made the error go away. Quicktext add-on seem to be
> abandoned by it's author and not updated to make it work with 38.0.1,
> but that's a different story.

Resolving as invalid in this case as it's a 3rd-party issue.
Feel free to reopen if the problem reoccurs.
Last Resolved: 3 years ago
Resolution: --- → INVALID

Comment 8

3 years ago
As for the Error Console message, I'm sorry if my response was not clear enough earlier. By "Disabling it, made the error go away" meant that the Error Console message went away after I disabled Quicktext add-on. The custom-strings.txt issue still exist.
Resolution: INVALID → ---

Comment 9

3 years ago
My misunderstanding, apologies...

Comment 10

3 years ago
I had some time to test this. And it does not work for me with TB 38, but same for TB 36. Maybe I have done something wrong (I followed the STR)... I'm wondering, that the file needs to go into Contents/MacOS, since v2 signing this folder is for binaries only (helper apps, tools...). All non-code files are now in Contents/Resources. Nevertheless, adding a file into the signed Thunderbird application, will break the build signature ("a sealed resource is missing or invalid") and is therefore not recommended.

Comment 11

3 years ago
Created attachment 8624237 [details]

This how it should show with custom-strings.txt in place

Comment 12

3 years ago
Created attachment 8624239 [details]

This is the default without custom-strings.txt

Comment 13

3 years ago
I've included 2 screen shots showing the behavior with/without custom-strings.txt in use. Note that on Windows, the chrome folder by default exist in the TB install directory under C:\Program Files (x86)\Mozilla Thunderbird. Whereas, in OS X, this same chrome folder does not exist by default. It need to be first created under the Contents->MacOS folder before placing the custom-strings.txt file in it. Note that in my and rsx11m testing, custom-strings.txt work as expected on Windows/Linux. On OS X, I've been using this and it worked fine in all the versions prior to 38.0.1

Comment 14

3 years ago
After reading Nomis101's comment #10, think I figured out what the issue is. Prior to 38.0.1, on OS X, Contents/MacOS was not v2 signed, hence when you create the chrome folder and add the custom-strings.txt, it worked as expected. However, as Nomis101 mentioned, 38.0.1, Contents/MacOS contain only binaries and is v2 signed. Hence custom-strings.txt did not work. As a test, I created a chrome folder under Contents/Resources and placed custom-strings.txt in there and it is working as expected !.

rsx11m: I think you are the author of this KB article: ?. If so, could you please update to reflect this change?. Thanks


3 years ago
Severity: major → minor

Comment 15

3 years ago
Nomis101: Thank you for your help regarding this issue. Much appreciated.

Comment 16

3 years ago
(In reply to from comment #14)
> rsx11m: I think you are the author of this KB article:
> ?.
> If so, could you please update to reflect this change?. Thanks

Yes, I wrote that article, but rather than hiding it in something that was written specifically for 5.0, I'd rather create a new general article on using that feature.

Meanwhile, resolving this as WFM given that just the location has changed (though documentation says to create/use the chrome folder in the directory where the binary of the application is located).
Last Resolved: 3 years ago3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.