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 https://bugzilla.mozilla.org/show_bug
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: decomposed voiced sound
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 for others: decomposed voi
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
rendered on the wrong b
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.)
> But the bug I mention o
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 we didn't hear any suc
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 just
>> like 57.0 broke it on Windows. But we
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.
Are you referring to
htt
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 non-ASC
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 UTF-8 in the code that sti
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 obor
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
==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
https://bugzilla
13 matches
Mail list logo
