On Fri, Jul 24, 2015 at 12:15:22PM +0800, Philip Chee wrote:
> On 23/07/2015 14:40, Mike Hommey wrote:
> > On Thu, Jul 23, 2015 at 02:34:50PM +0800, Philip Chee wrote:
> >> On 22/07/2015 05:54, J. Ryan Stinnett wrote:
> >>> The DevTools team is planning to move our code out of
> >>> /browser/devtoo
On Fri, Jul 24, 2015 at 2:06 PM, Philip Chee wrote:
>
> Does PL_HashTableEnumerateEntries also need to be replaced? And if so
> what with?
That function operates on PLHashTable, which is part of NSPR. (Don't
confuse it with PLDHashTable, which is part of XPCOM, as are its
subclasses.)
It could b
On Thu, Jul 23, 2015 at 10:54 PM, Jeff Griffiths wrote:
> On Thu, Jul 23, 2015 at 11:43 AM, J. Ryan Stinnett wrote:
>> On Thu, Jul 23, 2015 at 8:11 AM, Paul Rouget wrote:
>>> I guess by moving things to /devtools/, you also want to update the
>>> URLs to chrome://devtools/content.
>>> So then, w
On 23/07/2015 17:36, Panos Astithas wrote:
> On Thu, Jul 23, 2015 at 8:25 AM, Paul Rouget wrote:
>
>> On Wed, Jul 22, 2015 at 2:48 PM, Panos Astithas wrote:
>> > If you are thinking about shipping them as part of browser.html, we still
>> > have XUL dependencies that we need to get rid of first
On 23/07/2015 14:40, Mike Hommey wrote:
> On Thu, Jul 23, 2015 at 02:34:50PM +0800, Philip Chee wrote:
>> On 22/07/2015 05:54, J. Ryan Stinnett wrote:
>>> The DevTools team is planning to move our code out of
>>> /browser/devtools and /toolkit/devtools and into a new top level
>>> /devtools direc
On 24/07/2015 09:26, Nicholas Nethercote wrote:
> I mentioned this in all the bugs I filed to minimize the likelihood of
> mix-ups. I also filed all the EnumerateRead()-replacement bugs
> separately from all the Enumerate()-replacement bugs for the same
> reason. Please ask me if anything is uncle
On Fri, Jul 24, 2015 at 3:41 AM, Boris Zbarsky wrote:
> On 7/23/15 11:36 AM, Anne van Kesteren wrote:
>
>> By "SVG resource document" do you mean one that is fetched as an
>> image?
>>
>
> In Gecko's case I specifically mean one fetched as a paint server.
>
> It's somewhat of an implementation de
On Sun, Jul 12, 2015 at 10:36 PM, Nicholas Nethercote
wrote:
>
> Last week I landed patches that remove PL_DHashTableEnumerate() from
> the tree (https://bugzilla.mozilla.org/show_bug.cgi?id=1180072). You
> should now use PLDHashTable::Iterator if you want to iterate over a
> PLDHashTable. The ite
On Thu, Jul 23, 2015 at 3:43 PM, L. David Baron wrote:
> I'm not sure it's really a fight I want to take on right now,
> though.
Trying to kill things at W3C has generally not seemed worth the effort
to me. It's better to ignore it and let it die out by itself due to
lack of attention.
But being
Just so people know, ASan builds with GTK3 crash immediately on startup, so
you'll want to keep the gtk2 version as described below.
Andrew
On Wed, Jul 22, 2015 at 6:38 PM, Mike Hommey wrote:
> Hi,
>
> If you've followed the recent discussion in the "GTK3 linux builds"
> thread, this will come
On Tuesday 2015-07-21 12:14 +0100, James Graham wrote:
> On 21/07/15 11:29, Ms2ger wrote:
>
> >This entire Activity is a distraction from the real needs of the web,
> >and if the W3C is serious about its motto, it should focus on those
> >rather than providing support and hosting conferences for p
On Thu, Jul 23, 2015 at 11:43 AM, J. Ryan Stinnett wrote:
> On Thu, Jul 23, 2015 at 8:11 AM, Paul Rouget wrote:
>> I guess by moving things to /devtools/, you also want to update the
>> URLs to chrome://devtools/content.
>> So then, we can compile and open the devtools with non-firefox builds
>>
On Thu, Jul 23, 2015 at 8:11 AM, Paul Rouget wrote:
> I guess by moving things to /devtools/, you also want to update the
> URLs to chrome://devtools/content.
> So then, we can compile and open the devtools with non-firefox builds
> (thunderbird, b2g, seamonkey, ...).
> But if the devtools include
A bit belated, since I just landed this on inbound, but...
Summary: In ES2015, there is a certain set of invariants that an object
is supposed to maintain. One of those is that a non-configurable
property can't just disappear. Window objects obviously can't maintain
that invariant, so they
On 7/23/15 11:36 AM, Anne van Kesteren wrote:
By "SVG resource document" do you mean one that is fetched as an
image?
In Gecko's case I specifically mean one fetched as a paint server.
It's somewhat of an implementation detail, possibly; the reason we do it
is that we had a bunch of code that
On Thu, Jul 23, 2015 at 8:19 AM, Boris Zbarsky wrote:
> On 7/23/15 9:47 AM, Anne van Kesteren wrote:
>> Load groups roughly matches the "fetch registry" I think. I should
>> probably rename that "fetch group" as Ben suggested to me privately.
>> Filed https://github.com/whatwg/fetch/issues/92 to d
On 7/23/15 9:47 AM, Anne van Kesteren wrote:
Load groups roughly matches the "fetch registry" I think. I should
probably rename that "fetch group" as Ben suggested to me privately.
Filed https://github.com/whatwg/fetch/issues/92 to do so.
Sort of. Except fetch group is per-global but there are
On 7/23/15 7:29 AM, Paolo Amadini wrote:
Well, I was thinking more of something built-in, other than Iterator,
to achieve the same effect over a data structure (for example something
that could be provided from elsewhere as an argument).
Paolo,
I might be missing something, but why is __iterat
On 23/07/15 15:47, Anne van Kesteren wrote:
> > * Construct an nsIURI. Might need to take things such as the
> document base
> > URI and charset into account.
>
> For many APIs these days you need to parse the URL before you hand it
> off. That seems like a somewhat saner setup too, though in theo
On Thu, Jul 23, 2015 at 6:32 AM, Ehsan Akhgari wrote:
> I think this is a good idea in general, but I'm not sure how well the high
> level fetch API would map to something internal.
1) fetch() is not exactly high-level.
2) We're not talking about fetch(), but about the fetch algorithm,
which is
On 2015-07-17 2:16 PM, Benjamin Kelly wrote:
I thought a little bit more about this after stepping away from my computer.
I think some of our implementation issues for service workers currently
stems from the fact that the fetch spec and necko have modeled the problem
with different primitives:
I guess by moving things to /devtools/, you also want to update the
URLs to chrome://devtools/content.
So then, we can compile and open the devtools with non-firefox builds
(thunderbird, b2g, seamonkey, ...).
But if the devtools include browser code, this won't work. For
example, we import
chrome:/
On 7/22/2015 1:56 PM, David Bruant wrote:
The ES6 iterator protocol is what you're looking for. See:
Alongside with the computed property syntax, you should be able to
achieve what you want. Something along the lines of:
Well, I was thinking more of something built-in, other than Iterator,
to a
On Thu, Jul 23, 2015 at 8:25 AM, Paul Rouget wrote:
> On Wed, Jul 22, 2015 at 2:48 PM, Panos Astithas wrote:
> > If you are thinking about shipping them as part of browser.html, we still
> > have XUL dependencies that we need to get rid of first and that work is
> > independent from moving the c
24 matches
Mail list logo
