Re: Dropping remains of support for non-UTF-8 file paths on Gtk platforms (was: Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code)

On Tue, Dec 5, 2017 at 11:57 PM, Mike Hommey wrote: > Wouldn't it make sense, then, to actively fail to even start Firefox in > such cases, instead of pretending it kind of works at all, if we can't > even save history or bookmarks properly? Good point. Filed

Re: Dropping remains of support for non-UTF-8 file paths on Gtk platforms (was: Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code)

On Tue, Dec 05, 2017 at 05:16:52PM +0200, Henri Sivonen wrote: > On Tue, Dec 5, 2017 at 4:37 PM, ISHIKAWA,chiaki wrote: > > There are other non-ASCII character issues such as > > https://bugzilla.mozilla.org/show_bug.cgi?id=1258613 > > Very weird bug! (Summary for others:

Re: Dropping remains of support for non-UTF-8 file paths on Gtk platforms (was: Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code)

On 2017/12/06 1:04, Jonathan Kew wrote: On 05/12/2017 15:16, Henri Sivonen wrote: On Tue, Dec 5, 2017 at 4:37 PM, ISHIKAWA,chiaki wrote: There are other non-ASCII character issues such as https://bugzilla.mozilla.org/show_bug.cgi?id=1258613 Very weird bug! (Summary

Re: Dropping remains of support for non-UTF-8 file paths on Gtk platforms (was: Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code)

On 05/12/2017 15:16, Henri Sivonen wrote: On Tue, Dec 5, 2017 at 4:37 PM, ISHIKAWA,chiaki wrote: There are other non-ASCII character issues such as https://bugzilla.mozilla.org/show_bug.cgi?id=1258613 Very weird bug! (Summary for others: decomposed voiced sound mark is

Re: Dropping remains of support for non-UTF-8 file paths on Gtk platforms (was: Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code)

On Tue, Dec 5, 2017 at 4:37 PM, ISHIKAWA,chiaki wrote: > There are other non-ASCII character issues such as > https://bugzilla.mozilla.org/show_bug.cgi?id=1258613 Very weird bug! (Summary for others: decomposed voiced sound mark is rendered on the wrong base character.) >

Re: Dropping remains of support for non-UTF-8 file paths on Gtk platforms (was: Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code)

On 2017/12/05 22:24, Henri Sivonen wrote: On Mon, Dec 4, 2017 at 2:04 PM, Masatoshi Kimura wrote: * If by any chance a profile path contains non-ASCII characters on non-UTF-8 UNIX systems, Firefox 57.0.1 must have broken the profile just like 57.0 broke it on Windows. But

Re: Dropping remains of support for non-UTF-8 file paths on Gtk platforms (was: Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code)

On Tue, Dec 5, 2017 at 3:24 PM, Henri Sivonen wrote: > On Mon, Dec 4, 2017 at 2:04 PM, Masatoshi Kimura wrote: >> * If by any chance a profile path contains non-ASCII characters on >> non-UTF-8 UNIX systems, Firefox 57.0.1 must have broken the profile

Re: Dropping remains of support for non-UTF-8 file paths on Gtk platforms (was: Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code)

On Mon, Dec 4, 2017 at 2:04 PM, Masatoshi Kimura wrote: > * If by any chance a profile path contains non-ASCII characters on > non-UTF-8 UNIX systems, Firefox 57.0.1 must have broken the profile just > like 57.0 broke it on Windows. But we didn't hear any such complaints.

Re: Dropping remains of support for non-UTF-8 file paths on Gtk platforms (was: Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code)

On 2017/12/04 20:19, Henri Sivonen wrote: > I suggest that instead of delaying with a round of telemetry, we make > all non-Windows platforms in nsNativeCharsetUtils.cpp use what's > currently the OSX/Android code path. +1 Some other data points: * If by any chance a profile path contains

Dropping remains of support for non-UTF-8 file paths on Gtk platforms (was: Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code)

On Fri, Dec 1, 2017 at 3:15 AM, Makoto Kato wrote: > I think that we don't have any data when user doesn't use non-UTF-8 > (and C) locale such as ja_JP.eucJP. We should get data via telemetry. What should the telemetry measure? (Measuring whether we compute paths to be

Re: Non-UTF-8 file paths on Gtk platforms

The argument for suggestion #1 seems irrefutable. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao

Re: Non-UTF-8 file paths on Gtk platforms

Given that everyone else working in this area agrees that UTF-8 file paths are the Right Thing and wants to desupport legacy encodings, I would now vote for suggestion 1 (contra what I said last year in bug 960957, which amounts to a variation on your suggestion 2). However, I think it might be a

Non-UTF-8 file paths on Gtk platforms

==Summary== I suggest that we either decide not to support non-UTF-8 file paths in Gecko/Firefox on Gtk platforms or, failing that, use the glib facilities to convert between Unicode and file paths. Opinions? ==Relevant bugs== https://bugzilla.mozilla.org/show_bug.cgi?id=960957