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 neve
On Feb 21, 2013 3:12 PM, "Robert O'Callahan"
wrote:
>
> On Wed, Feb 20, 2013 at 9:41 AM, Anthony Jones 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 done by including a mouse event
>
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
1<<15 is LOAD_FRESH_CONNECTION, no?
const unsigned long LOAD_NOAUTH = 1 << 16;
... don't add authentification headers automatically
1<<1
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)
>> authenti
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.
> t
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 (cl
- Original Message -
> From: "Matthew Gertner"
> 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
> and runs script in th
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 case
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 intl.p
On 22.02.13 18:41, Henri Sivonen wrote:
On Feb 22, 2013 5:30 PM, "Axel Hecht" 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 tech
On Feb 22, 2013 5:30 PM, "Axel Hecht" 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.
Where should I fil
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 Fri, Feb 22, 2013 at 7:02 AM, Matthew Gertner wrote:
> 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
> content-friendly D
I have an extension that loads an HTML file into a hidden 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 Firefox 1
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
15 matches
Mail list logo
