1514437 - Crash on startup when application pathname contains certain non-ASCII characters

Status: VERIFIED FIXED

(Toolkit :: Startup and Profile System, defect, P3)

Description

[Paul Crawford]

Attachment: Crash report for Firefox Mac v63.0.3, dated 2018-12-08

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/12.0.2 Safari/605.1.15

Steps to reproduce:

My Firefox Mac edition was updated (from v62.0.3) to v63.0, via the 'About Firefox' dialogue.


Actual results:

Firefox Mac v63.0, running under macOS 10.13.6 on a Mac Pro 2012 tower, immediately crashed upon startup. 

At first, I tried all the usual troubleshooting steps, such as restarting with add-ons disabled, using a brand new profile, etc., but all to no avail. It took a while to figure out that it was actually because some of the application's ancestor folders' names happened to contain the character '»' (U+00BB, or Option-Shift-\ on a Mac).

Through brief trial & error, it also turned out that certain other characters such as 'µ' (U+00B5, or Option-m on a Mac), and '°' (U+00B0, or Option-Shift-8 on a Mac), also trigger the startup crash.

However, please note that the presence of many other non-ASCII characters in the application's pathname are handled just fine, and do *not* cause a crash. Also, based on at least some limited testing in a Windows 10 Pro VM, this issue does not occur on MS Windows and is restricted to Mac OS.

In my experience, it first appeared in Firefox Mac v63.0 (and is thus a regression from v62.0.3), and is also present in all subsequent v63.x versions, as well as the current v64.0 one.


Expected results:

In this era of widespread Unicode support, Firefox Mac v63+ should be able to startup normally regardless of the characters present in its app pathname.

For now, as a workaround, I have moved my Firefox Mac application into a location whose path does not contain such triggering characters.

Comment 1

[Paul Crawford]

BTW, there was an old bug that seemed related, viz., Bug 107181 (Mozilla won't start up when drive name is "/" or contains non-ASCII characters), but it's marked RESOLVED.

Comment 2

[Neha Kochar [:neha]]

Florian, could you please find someone to look into this?

Comment 3

[Florian Quèze [:florian]]

(In reply to Neha Kochar [:neha] from comment #2)

Florian, could you please find someone to look into this?

The next step would be someone from QA to confirm the bug and find a regression range. This bug is currently not actionable for engineers. I wouldn't be surprised if a specific step to reproduce was missing, as if this bug affected everybody with a non-ascii character in their path, we would probably have several duplicates.

Comment 4

[Paul Crawford]

I appreciate the attention being paid to this issue.

Just wanted to add some notes:

As mentioned in my original post, in terms of the application path there are many non-ASCII characters which actually do not trigger a startup crash in Firefox Mac v63+. However, again from my brief tests, at least three such chars do happen to act as triggers, viz.: '»' (U+00BB, or Option-Shift-\ on a Mac); 'µ' (U+00B5, or Option-m on a Mac); and, '°' (U+00B0, or Option-Shift-8 on a Mac).

{As a side note, I guess it could be that most Firefox Mac users install the application bundle into the default location (their boot volume's top-level 'Applications' folder), which would isolate them from this issue.}

I did a further brief test on my Mac Pro 2012 tower, this time booted up under OS X v10.9 'Mavericks' (the earliest Mac OS version supported by recent Firefox). It's a clean installation of OS X v10.9.5 that I use for my own development testing, with Xcode being the only significant addition. I was readily able to reproduce the startup crash by first creating a test folder on my Desktop named 'Firefox Application Pathname Test°' (note the trailing '°' character), next copying my current Firefox.app v66.0.3 into that folder, and then attempting to launch it from there.

{BTW, given that the crash report implicates Apple's Core Foundation (CF) API, it might be worth noting that this startup crash doe not seem (at least from my brief tests) to be dependent on the presence of an invisible '.CFUserTextEncoding' file in the current user's home directory, nor on what data it contains. [For details, please refer to Apple's Tech Note 'TN2228: Running At Login', § 'Preventing Home Directory Access' (<developer.apple.com/library/archive/technotes/tn2228/_index.html#//apple_ref/doc/uid/DTS40007991-CH1-SUBSECTION15>). This hidden CF config file is also discussed elsewhere on the Web.]}

Now, I would also be among the first to say that this particular kind of crash is not exactly a 'showstopper' issue, as there is such an easy workaround. Nevertheless, it could be disconcerting to someone on a Mac who happens to install their Firefox.app v63+, or upgrade from v62-, in a non-default location containing certain triggering chars. So, thanks again for any assistance.

Comment 5

[Patricia Lawless]

Bulk change of P3 carryover bugs to wontfix for 68.

Comment 6

[Dave Townsend [:mossop]]

Attachment: Bug 1514437: Correctly encode the strings passed through nsIMacAttributionService. r=spohl

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/dbfb48f4d385
Correctly encode the strings passed through nsIMacAttributionService. r=mconley

Comment 8

[Noemi Erli[:noemi_erli]]

https://hg.mozilla.org/mozilla-central/rev/dbfb48f4d385

Comment 9

[Ryan VanderMeulen [:RyanVM]]

Please nominate this for Beta and ESR68 approval when you get a chance. I'm considering this a new regression for ESR60 users migrating to ESR68, so it seems worthwhile to backport.

Comment 10

[Dave Townsend [:mossop]]

Comment on attachment 9076635 [details]
Bug 1514437: Correctly encode the strings passed through nsIMacAttributionService. r=spohl

Beta/Release Uplift Approval Request

• User impact if declined: Startup crash on OSX when the application binary is in a path containing non-ascii characters.
• Is this code covered by automated tests?: No
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: None
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): A simple change to ensure we encode characters correctly when passing from JS to C++ in this one instance.
• String changes made/needed:

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is a regression from ESR60
• User impact if declined: See beta approval request
• Fix Landed on Version: 70.0a1
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): See beta approval request
• String or UUID changes made by this patch:

Comment 11

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9076635 [details]
Bug 1514437: Correctly encode the strings passed through nsIMacAttributionService. r=spohl

Fixes a startup crash when the application path contains certain non-ASCII characters. Approved for 69.0b6 and 68.1esr.

Comment 12

[Alexandru Michis [:malexandru]]

https://hg.mozilla.org/releases/mozilla-beta/rev/8e2e7fc73ab8

Comment 13

[Sebastian Hengst [:aryx] (needinfo me if it's about an intermittent or backout)]

https://hg.mozilla.org/releases/mozilla-esr68/rev/0fe299a52388

Comment 14

[Rares Doghi, Desktop QA]

Hi, This issue is Verified as Fixed in our latest Nightly build 70.0a1 (2019-07-18) as well as Beta 69.0b6. I will mark this issue accordingly.

Please note that I've also tested this issue on the latest Esr build 68.1.0 fuzzin-assan-opt since I couldnt find a normal Macosx64-opt build.