We already do not expose MS-DOS encodings other than Cyrillic to the
Web. We still expose them to Firefox extensions in some APIs.
Telemetry shows that usage varies from non-existent to extremely rare
(28 sessions out of 180.82 million sessions for the Western European
DOS code page).
In order to
On 2014-04-22, 8:09 AM, Henri Sivonen wrote:
We already do not expose MS-DOS encodings other than Cyrillic to the
Web. We still expose them to Firefox extensions in some APIs.
Telemetry shows that usage varies from non-existent to extremely rare
(28 sessions out of 180.82 million sessions for
(2014/04/22 2:09), Joshua Cranmer wrote:
On 4/21/2014 11:50 AM, Ehsan Akhgari wrote:
You can check CONFIG['MOZ_BUILD_APP'] against what you pass to
--enable-application in mozconfig files. So that would be 'mailnews' (or
'mail'?) and 'suite' for Thunderbird and Seamonkey respectively.
On 4/22/2014 7:09 AM, Henri Sivonen wrote:
Thunderbird developers will be able to import the code into
comm-central and continued to support these encodings for email and
NNTP if they so choose.
Based on my charset explorations in NNTP, the only common IBM* encoding
not present on the
On 4/22/2014 7:31 AM, Robert O'Callahan wrote:
It's all over the tree, inconsistently applied. Is it relevant anymore? Can
we remove it entirely, or there some places where it's still relevant, and
if so, where ... XPCOM? Or should we be using it everywhere?
Short answer: I don't think it's
On 4/22/2014 4:16 AM, Henri Sivonen wrote:
This does not affect Thunderbird's ability to continue to support
EUC-TW if the Thunderbird developers so choose. (But EUC-TW email
seems improbable, since no one has bothered to register an IANA label
for it.)
I estimate EUC-TW to be unnecessary to
On 4/22/2014 5:55 AM, Gijs Kruitbosch wrote:
On 22/04/2014 05:24, Joshua Cranmer wrote:
For more specific explanation then:
I have a (non-negotiably) JS-implemented XPCOM service called the Folder
Lookup Service. I want to add an API to it called getOrCreateFolder that
returns a
On 4/22/14, 2:51 AM, Joshua Cranmer wrote:
I'm giving to thinking in terms of all of the magic hiding that
XPIDL/XPCOM/xpconnect does, so things like what is my global object
being intrinsically important are annoying to me.
I understand that.
but something like Promises or TextEncoder
On 4/22/2014 2:12 AM, Henri Sivonen wrote:
There is no strong need for the m-c removals to be tied to the ESR
schedule. However, I think it would be preferable to make the
changes before the ESR deadline so that future c-c patches backport
easily to the ESR (if there are security holes in the
On 2014-04-22, 9:24 AM, Henri Sivonen wrote:
I'm somewhat worried that we might break some Web pages for users who are
not fairly represented in our Telemetry data, and that we may not hear about
this before this change hits the release channel.
We have already stopped exposing these encodings
On Wed, Apr 23, 2014 at 1:25 AM, Benjamin Smedberg benja...@smedbergs.uswrote:
On 4/22/2014 7:31 AM, Robert O'Callahan wrote:
It's all over the tree, inconsistently applied. Is it relevant anymore?
Can
we remove it entirely, or there some places where it's still relevant, and
if so, where
On Wednesday 2014-04-23 07:51 +0900, Mike Hommey wrote:
On Wed, Apr 23, 2014 at 10:41:06AM +1200, Robert O'Callahan wrote:
checking For gcc visibility bug with class-level attributes (GCC bug
26905)... yes
checking For x86_64 gcc visibility bug with builtins (GCC bug 20297)... yes
Is
On Wed, Apr 23, 2014 at 07:51:54AM +0900, Mike Hommey wrote:
On Wed, Apr 23, 2014 at 10:41:06AM +1200, Robert O'Callahan wrote:
On Wed, Apr 23, 2014 at 1:25 AM, Benjamin Smedberg
benja...@smedbergs.uswrote:
On 4/22/2014 7:31 AM, Robert O'Callahan wrote:
It's all over the tree,
On Tue, Apr 22, 2014 at 09:25:01AM -0400, Benjamin Smedberg wrote:
On 4/22/2014 7:31 AM, Robert O'Callahan wrote:
It's all over the tree, inconsistently applied. Is it relevant anymore? Can
we remove it entirely, or there some places where it's still relevant, and
if so, where ... XPCOM? Or
Do we currently return NS_OK from Necko in such circumstances or another
error code?
On 2014-04-22, 4:21 PM, Daniel Stenberg wrote:
Hey all,
In the networking team we're about to introduce an error code for
partial transfers (see
https://bugzilla.mozilla.org/show_bug.cgi?id=237623). It will
On 4/22/14, 9:30 PM, Ehsan Akhgari wrote:
Do we currently return NS_OK from Necko in such circumstances or another
error code?
Currently we return NS_OK, so the necko client thinks the transfer
completed successfully.
-Boris
___
dev-platform
On 2014-04-22, 9:59 PM, Boris Zbarsky wrote:
On 4/22/14, 9:30 PM, Ehsan Akhgari wrote:
Do we currently return NS_OK from Necko in such circumstances or another
error code?
Currently we return NS_OK, so the necko client thinks the transfer
completed successfully.
That seems like a huge
On 4/22/14, 10:06 PM, Ehsan Akhgari wrote:
That seems like a huge behavior change. :(
Yes, it is. There's some at-length discussion in the bug about what
behavior various consumers want here.
-Boris
___
dev-platform mailing list
On (2014年04月22日 08:11), Zack Weinberg wrote:
On 2014-04-21 1:07 PM, Steve Fink wrote:
On Sat 19 Apr 2014 08:36:22 AM PDT, ISHIKAWA,chiaki wrote:
egrep ^(\\[[0-9]*\\] |)WARNING $1 | egrep NS_ENSURE | grep -v sort
operation has occurred for the SQL statement | sort | uniq -f1 -c |
sort -n -r
19 matches
Mail list logo
