I've been finding and, to a lesser extent, reporting and writing
patches for bugs where a localization sets the fallback encoding to a
value that doesn't suit the purpose of the fallback. In some cases,
there such bogosity in the intl.properties file (e.g. translation of
the word windows as part
I have an extension that loads an HTML file into a hidden browser and runs
script in the context of the hidden browser window. That script needs to be
able to make crossdomain XHR requests to chrome:// and resource:// URLs that
are apparently now blocked in Firefox 19 (they weren't blocked in
On Fri, Feb 22, 2013 at 7:02 AM, Matthew Gertner matt...@salsitasoft.comwrote:
Is there a better way to let content do crossdomain XHR? Or is there a
good way to provide a usable XML DOM from chrome to content? I can always
reparse responseText to create my own DOM if there's a way to create a
On 22.02.13 15:37, Henri Sivonen wrote:
I've been finding and, to a lesser extent, reporting and writing
patches for bugs where a localization sets the fallback encoding to a
value that doesn't suit the purpose of the fallback. In some cases,
there such bogosity in the intl.properties file (e.g.
On Feb 22, 2013 5:30 PM, Axel Hecht l...@mozilla.com wrote:
There's just no other way than post-mortem work. That's one of the
reasons why we're not taking arbitrary changesets to ship to any audience
beyond aurora and nightly, for beta and release, we got to have technical
checks in place.
On Friday 2013-02-22 16:37 +0200, Henri Sivonen wrote:
I've been finding and, to a lesser extent, reporting and writing
patches for bugs where a localization sets the fallback encoding to a
value that doesn't suit the purpose of the fallback. In some cases,
there such bogosity in the
On 22.02.13 20:02, L. David Baron wrote:
On Friday 2013-02-22 16:37 +0200, Henri Sivonen wrote:
I've been finding and, to a lesser extent, reporting and writing
patches for bugs where a localization sets the fallback encoding to a
value that doesn't suit the purpose of the fallback. In some
- Original Message -
From: Matthew Gertner matt...@salsitasoft.com
To: dev-platform@lists.mozilla.org
Sent: Friday, February 22, 2013 7:02:40 AM
Subject: Accessing @mozilla.org/xmlextras/xmlhttprequest;1 from content
I have an extension that loads an HTML file into a hidden browser
sry for double posting this to dev-apps-firefox. got a hint that this group
would be the better group.
hi
i'm willing to fix https://bugzilla.mozilla.org/show_bug.cgi?id=836602
Summary: The rest api should not send cookies and thus now uses the
LOAD_ANONYMOUS flag. But this flag also denies
bernhardr...@gmail.com wrote:
i'm willing to fix
https://bugzilla.mozilla.org/show_bug.cgi?id=836602
Summary: The rest api should not send cookies and thus now uses the
LOAD_ANONYMOUS flag. But this flag also denies (client side)
authentication like my custom firefox sync requires.
On 2/22/2013 5:41 PM, Brian Smith wrote:
bernhardr...@gmail.com wrote:
i'm willing to fix
https://bugzilla.mozilla.org/show_bug.cgi?id=836602
Summary: The rest api should not send cookies and thus now uses the
LOAD_ANONYMOUS flag. But this flag also denies (client side)
authentication like
On 2/22/13 7:25 PM, bernhardr...@gmail.com wrote:
const unsigned long LOAD_NOCOOKIES = 1 15;
... just stop sending / accepting cookies at this request
115 is LOAD_FRESH_CONNECTION, no?
const unsigned long LOAD_NOAUTH = 1 16;
... don't add authentification headers automatically
116 is
On Feb 21, 2013 3:12 PM, Robert Oapos;Callahan rob...@ocallahan.org
wrote:
On Wed, Feb 20, 2013 at 9:41 AM, Anthony Jones ajo...@mozilla.com wrote:
We really have to choices:
A. Provide an API that allows applications to specify whether they are
type 1 or type 2. It could be implicitly
Hi,
I wanted to let you all know about bug 842913, of which I just landed the patch
for on mozilla-inbound.
The goal of the bug is to make the process of working with the /browser and
/toolkit themes easier for new contributors. The previous names of
{winstripe,pinstripe,gnomestripe} were
14 matches
Mail list logo
