Re: Web IDL review checklist updated

[Kyle Huey]

On Mon, Apr 3, 2017 at 9:07 AM, Boris Zbarsky  wrote:
> I just updated https://wiki.mozilla.org/WebAPI/WebIDL_Review_Checklist to
> remove some no-longer relevant bits and add various new parts.
>
> The primary audience for this document are people doing Web IDL reviews
> (bcced; you can see the list at
> ),
> but obviously anyone _requesting_ such review should consider running
> through the list before doing so.
>
> Suggestions for further additions (or just edits of the page!) are much
> appreciated.
>
> -Boris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

There should probably be something about checking that the spec is
something other vendors are interested in, or that Mozilla has a good
reason to go ahead without them.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIAtom has been deCOMtaminated and is now called nsAtom

[Kyle Huey]

Awesome!

You couldn't get to mozilla::Atom?

- Kyle

On Oct 8, 2017 7:27 PM, "Nicholas Nethercote" 
wrote:

> Greetings,
>
> I have been deCOMtaminating nsIAtom over the past two months:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1392883.
>
> A big step that landed over a week ago was the devirtualization of nsIAtom,
> which means it is no longer a subclass of nsISupports:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1400459.
>
> And I just landed (on autoland) the final step of renaming nsIAtom as
> nsAtom. This is tracked at
> https://bugzilla.mozilla.org/show_bug.cgi?id=1400460.
>
> Apologies for any conflicts or problems caused in outstanding patches. For
> patches less than 1.5 weeks old (i.e. post-devirtualization) it's very
> likely that simply replacing all nsIAtom occurrences with nsAtom will
> suffice. For patches older than that here is a summary of changes that
> might be required.
>
> - nsIAtom --> nsAtom
>
> - nsCOMPtr --> RefPtr
>
> - nsCOMArray --> nsTArray>
>   - Count() --> Length()
>   - ObjectAt() --> ElementAt()
>   - AppendObject() --> AppendElement()
>   - RemoveObjectAt() --> RemoveElementAt()
>
> - ns*Hashtable -->
>   ns*Hashtable, ...>
>
> - nsInterfaceHashtable --> nsRefPtrHashtable
>
>   # If the array contains atoms.
> - nsCOMPtr --> nsTArray>
>   - nsArrayBase::Create() --> nsTArray()
>   - GetLength() --> Length()
>   - do_QueryElementAt() --> operator[]
>
> Nick
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please use nsGlobalWindow{Inner,Outer}

[Kyle Huey]

On Fri, Nov 10, 2017 at 8:41 AM, Nika Layzell  wrote:
> Hey,
>
> Bug 1414974 (https://bugzilla.mozilla.org/show_bug.cgi?id=1414974) is in
> mozilla-central, and it introduces the nsGlobalWindowInner and
> nsGlobalWindowOuter types. These represent inner and outer nsGlobalWindow
> objects, and can be cast from the nsPIDOMWindowInner/Outer objects using
> nsGlobalWindowInner/Outer::Cast.
>
> Please avoid introducing new code which uses nsGlobalWindow directly,
> instead using the specific types, as it is going away soon™.
>
> Thanks!
> Nika
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Nice to see that this is still moving forward!

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MozPromises are now in XPCOM

[Kyle Huey]

On Tue, Aug 18, 2015 at 8:17 PM, Bobby Holley  wrote:
> I gave a lightning talk at Whistler about MozPromise and a few other new
> tools to facilitate asynchronous and parallel programming in Gecko. There
> was significant interest, and so I spent some time over the past few weeks
> untangling them from dom/media and hoisting them into xpcom/.
>
> Bug 1188976 has now landed on mozilla-central, MozPromise (along with
> TaskQueue, AbstractThread, SharedThreadPool, and StateMirroring) can now be
> used everywhere in Gecko.
>
> I also just published a blog post describing why MozPromises are great and
> how they work: http://bholley.net/blog/2015/mozpromise.html
>
> Feedback is welcome. These tools are intended to allow developers to easily
> and safely run code on off-main-thread thread pools, which is something we
> urgently need to do more of in Gecko. Go forth and write more parallel code!
>
> bholley
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform

Does MozPromise have the same "skipping the event loop" behavior that
JS promises have?  Or is that limited just to StateMirroring?

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MozPromises are now in XPCOM

[Kyle Huey]

On Wed, Aug 19, 2015 at 2:04 PM, Bobby Holley  wrote:
> On Wed, Aug 19, 2015 at 1:39 PM, Kyle Huey  wrote:
>>
>> Does MozPromise have the same "skipping the event loop" behavior that
>> JS promises have?
>
>
> They do not.
>
>>
>> Or is that limited just to StateMirroring?
>
>
> Correct, as well as StateWatching. StateMirroring uses StableState to
> dispatch the atomic state updates, and StateWatching uses it to run
> notifications.
>
> bholley
>

Good.  This should be clearly documented, as its a subtle but
important distinction from JS promises, which people are likely to be
familiar with.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MozPromises are now in XPCOM

[Kyle Huey]

On Wed, Aug 19, 2015 at 5:23 PM, Bobby Holley  wrote:
> On Wed, Aug 19, 2015 at 2:12 PM, Kyle Huey  wrote:
>>
>> On Wed, Aug 19, 2015 at 2:04 PM, Bobby Holley 
>> wrote:
>> > On Wed, Aug 19, 2015 at 1:39 PM, Kyle Huey  wrote:
>> >>
>> >> Does MozPromise have the same "skipping the event loop" behavior that
>> >> JS promises have?
>> >
>> >
>> > They do not.
>> >
>> >>
>> >> Or is that limited just to StateMirroring?
>> >
>> >
>> > Correct, as well as StateWatching. StateMirroring uses StableState to
>> > dispatch the atomic state updates, and StateWatching uses it to run
>> > notifications.
>> >
>> > bholley
>> >
>>
>> Good.  This should be clearly documented, as its a subtle but
>> important distinction from JS promises, which people are likely to be
>> familiar with.
>
>
> Done: https://hg.mozilla.org/integration/mozilla-inbound/rev/db24d3cda834
>

<3

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CloseFile() latency on Windows

[Kyle Huey]

We recently dealt with something similar in Gecko.  See
https://bugzilla.mozilla.org/show_bug.cgi?id=1152046

- Kyle

On Mon, Sep 28, 2015 at 2:41 PM, Gregory Szorc  wrote:
> As part of profiling a Python process on Windows using Process Monitor.exe,
> I noticed that closing file handles using CloseFile() takes 1+ms. Contrast
> this with other I/O related system calls like WriteFile() that tend to take
> ~1us. (I /think/ it only takes a longer time if the file has been written
> to.) This is on Windows 10 running natively (no VM) when writing to an SSD.
> Files are opened with _fopen() in "a+" mode if it matters. I can also repro
> in "a" mode.
>
> When writing thousands of files in rapid succession, this 1+ms pause
> (assuming synchronous I/O) piles up. Assuming a 1ms pause, writing 100,000
> files spends 100s in CloseFile()! The process profile also shows the bulk
> of the time in CloseFile(), so this is a real hot spot.
>
> Both Mercurial and the Firefox build system need to write thousands of
> files in rapid order. Both are using Python. Both should experience
> significant performance improvements if we find a more efficient way to do
> bulk file writing (which currently is over 2x slower than Linux and OS X).
>
> Short of going full overlapped I/O (which will be a PITA with Python), the
> best I can think of is to perform CloseFile() on a background thread or
> pool of background threads.
>
> I was curious if anyone has dug into optimizing the writing of thousands of
> files on Windows and can share any insights so we can make the Firefox
> build system and Mercurial significantly faster on Windows.
>
> gps
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Disabling C++ tests by default?

[Kyle Huey]

How much time does it save?

- Kyle

On Thu, Oct 1, 2015 at 10:10 PM, Gregory Szorc  wrote:
> Currently, the Firefox build system builds C++ tests by default. This adds
> extra time to builds for something that a significant chunk of developers
> don't care about because they don't run them.
>
> An easy way to get faster builds is to disable C++ tests by default
> (requiring a mozconfig entry to enable them - which would be enabled in
> automation, of course). A more involved solution is to build them on
> demand, when tests are executed (unless a build option says to build them
> like today).
>
> I was curious if Gecko developers (the audience I perceive that cares about
> them the most) would be generally opposed to disabling building C++ tests
> by default. If not, we can go with an easy solution (and require people who
> care to add a mozconfig entry). If so, we go with the harder solution.
>
> Is disabling building C++ tests by default a reasonable change?
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: IDB getAll/getAllKeys/openKeyCursor

[Kyle Huey]

I intend to ship the following features in Gecko 44:

IDBObjectStore.getAll
IDBObjectStore.getAllKeys
IDBObjectStore.openKeyCursor
IDBIndex.getAll
IDBIndex.getAllKeys

These features will be available on all platforms and are specced at
[0].  The bug tracking this work is [1].  Some of these features are
available today behind the dom.indexedDB.experimental preference,
while others have unconditionally exposed prefixed versions.  We have
achieved spec agreement and interop with Blink, who also intends to
release these early next year.

- Kyle

[0] https://w3c.github.io/IndexedDB/
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1196841
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: mozilla::RefPtr is dead, long live ::RefPtr

[Kyle Huey]

Huzzah!

When are you going to do nsCOMPtr? ;)

- Kyle

On Sun, Oct 18, 2015 at 7:43 AM, Nathan Froyd  wrote:
> Hi all,
>
> Bug 1207245 has landed on mozilla-central.  Its main purpose in life is to
> unify mozilla::RefPtr and nsRefPtr (both of which live in MFBT) into a
> single RefPtr class.  This new RefPtr class, like nsRefPtr, lives at the
> *global* scope, not in the mozilla:: namespace.  Follow-up patches or ideas
> on how to fix this welcome; I have brute-force ideas on how to do it, but
> they require large quantities of machine time.
>
> The new RefPtr works exactly the same as the old nsRefPtr: getter_AddRefs,
> interoperation with nsCOMPtr, etc.  It's worth noting that if you used
> byRef with mozilla::RefPtr for (XP)COM outparam semantics, you'll have to
> use getter_AddRefs now instead.  Please note that getter_AddRefs zeroes out
> the pointer prior to passing it as an outparam (as it has always done),
> which byRef did *not* do.  (You should not have been depending on this
> behavior, but if you were...)
>
> Updating patches/commits affected by these changes should be as simple as
> running:
>
> perl -p -i -e 's#mozilla/nsRefPtr.h#mozilla/RefPtr.h#'
> perl -p -i -e 's#mozilla::RefPtr#RefPtr#'
> perl -p -i -e 's#nsRefPtr<#RefPtr<#'
> perl -p -i -e 's#byRef#getter_AddRefs#'
>
> over the affected files.
>
> As a side-effect of these changes, mozilla::RefCounted and
> mozilla::external::AtomicRefCounted have moved to their own header,
> mozilla/RefCounted.h.
>
> Happy hacking,
> -Nathan
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: mozilla::RefPtr is dead, long live ::RefPtr

[Kyle Huey]

I meant removing the ns prefix (i.e. s/nsCOMPtr/COMPtr/), which is the
net effect of this change for places that previous used nsRefPtr,
AIUI.

- Kyle

On Sun, Oct 18, 2015 at 8:24 AM, Boris Zbarsky  wrote:
> On 10/18/15 11:11 AM, Kyle Huey wrote:
>>
>> When are you going to do nsCOMPtr? ;)
>
>
> Are we sure there is no codesize hit when moving from nsCOMPtr (which tries
> to share implementation via nsCOMPtr_base) to RefPtr?
>
> -Boris
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Question: why an external DTD is accessed (or not)? (svg11.dtd)

[Kyle Huey]

Bug 994305 is on file for this.

- Kyle

On Sat, Nov 21, 2015 at 10:57 AM, ISHIKAWA,chiaki  wrote:
> Hi,
>
> I have been puzzled at a pair of strange warning messages over the last few
> years, but can't hold the curiosity any longer.
>
> So here is my question.
>
> During the invocation of TB |make mozmill| test suite by running locally
> produced DEBUG version of C-C test, I have seen the following error messages
> in the log.
> Below, 35 is the number of times the error was seen in the latest run.
> The next [4482] is a sample of the process ID and should be ignored.
>
>  35 [4482] WARNING: Failed to open external DTD: publicId "-//W3C//DTD
> SVG 1.1//EN" systemId "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd";
> base
> "file:///NREF-COMM-CENTRAL/comm-central/mail/themes/linux/mail/tabs/selected-start.svg"
> URL "resource://gre/res/dtd/svg11.dtd": file
> /NREF-COMM-CENTRAL/comm-central/mozilla/parser/htmlparser/nsExpatDriver.cpp,
> line 705
>
>  35 [4482] WARNING: Failed to open external DTD: publicId "-//W3C//DTD
> SVG 1.1//EN" systemId "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd";
> base
> "file:///NREF-COMM-CENTRAL/comm-central/mail/themes/linux/mail/tabs/selected-end.svg"
> URL "resource://gre/res/dtd/svg11.dtd": file
> /NREF-COMM-CENTRAL/comm-central/mozilla/parser/htmlparser/nsExpatDriver.cpp,
> line 705
>
> It seems that the  TB binary seems to try to access external DTD and
> failed(?).
>
> From what I read in the past, W3C's position seems to be that
> the web resource of W3C should not be accessed during the runtime for
> obvious performance reasons, and the application is encouraged to have
> a local copy anyway.
> But if my reading of the code was correct, it was as if TB by way of mozilla
> library was doing just that (?)
> Or is it simply TB's packaging forgets to place svg11.dtd in the expected
> place?
>
> Any sensible explanation why this is happening (or not) and why we have
> this pair of warning messages printed during the execution of the DEBUG
> version of C-C TB is appreciated.
>
> These messages were visible in January 2013 and possibly earlier.
> I have deleted the log due to space reasons :-(
>
> Actually, I see another failure of opening external DTD, but it occurs just
> once, so it is not THAT disturbing.
> I can wait for the explanation for *THAT*: xhtml11.dtd.
> (Maybe the explanation for the pair of messages would solve the puzzle for
> this one, too.)
>
>   1 [5300] WARNING: Failed to open external DTD: publicId "" systemId
> "resource:///res/dtd/xhtml11.dtd" base
> "moz-nullprincipal:{e2a85fc4-28dc-412e-befa-2feaea7c9705}" URL
> "resource://gre/res/dtd/xhtml11.dtd": file
> /NREF-COMM-CENTRAL/comm-central/mozilla/parser/htmlparser/nsExpatDriver.cpp,
> line 705
>
> The last message started to appear in my local log in March 2013 for the
> first time. Maybe it might have something to do with moz-nullprincipal
> thingy (for security hardening).
>
>
> TIA
>
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

nsThread now leaks runnables if dispatch fails

[Kyle Huey]

(This is a continuation of the discussion in bug 1218297)

In bug 1155059 we made nsIEventTarget::Dispatch take an
already_AddRefed instead of a raw pointer.  This was done to allow the
dispatcher to transfer its reference to the runnable to the thread the
runnable will run on.  That solves a race condition we've had
historically where the destructor of a runnable can run on either the
dispatching thread or the executing thread, depending on whether the
executing thread can run the event to completion before the
dispatching thread destroys the nsCOMPtr on the stack.  So far, so
good.

In bug 1218297 we saw a case where dispatch to a thread (the socket
transport service thread in this case) fails because the thread has
already shut down.  In our brave new world, nsThread simply leaks the
runnable.  It can't release the reference it holds, because that would
reintroduce the race condition we wanted to avoid, and it can't
release the reference on the correct thread so it's already gone away.
But now we have a new source of intermittent leaks.

Was this anticipated when designing bug 1155059?  I don't think
leaking is acceptable here, so we may need to back that out and return
to living with that race condition.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsThread now leaks runnables if dispatch fails

[Kyle Huey]

The "race condition" here is the question of which thread the runnable
destructor runs on.  If the executing thread is already shut down the
destructor still runs on the "wrong" dispatching thread (or not at
all).  Since the point of fixing the original race is to guarantee
that the destructor runs on the executing thread it's useful to
consider this an extension of the original race.

- Kyle

On Mon, Jan 4, 2016 at 10:39 PM, Ting-Yu Chou  wrote:
>
>> In bug 1218297 we saw a case where dispatch to a thread (the socket
>> transport service thread in this case) fails because the thread has
>> already shut down.  In our brave new world, nsThread simply leaks the
>> runnable.  It can't release the reference it holds, because that would
>> reintroduce the race condition we wanted to avoid, and it can't
>> release the reference on the correct thread so it's already gone away.
>
>
> I am a bit confused with this, if the executing thread has already shut
> down,
> why would releasing the reference dispatching thread holds reintroduce the
> race
> condition? Who is racing with dispatching thread?
>
> Ting
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsThread now leaks runnables if dispatch fails

[Kyle Huey]

On Mon, Jan 4, 2016 at 4:10 PM, Randell Jesup  wrote:
>>Kyle Huey writes:
>>
>>> (This is a continuation of the discussion in bug 1218297)
>>>
>>> In bug 1155059 we made nsIEventTarget::Dispatch take an
>>> already_AddRefed instead of a raw pointer.  This was done to allow the
>>> dispatcher to transfer its reference to the runnable to the thread the
>>> runnable will run on.  That solves a race condition we've had
>>> historically where the destructor of a runnable can run on either the
>>> dispatching thread or the executing thread, depending on whether the
>>> executing thread can run the event to completion before the
>>> dispatching thread destroys the nsCOMPtr on the stack.
>>
>>IIUC solving the race condition wasn't the goal of the change in
>>API, but something that was done to retain existing workarounds
>>for leaks.
>
> Solving the "who knows what thread this will be released on" was a
> primary goal.  See comment 0, and the discussion here it references.
>
> Independently, bsmedberg wanted to make Dispatch infallible (at least
> normally), thus making the pattern of "avoid leak in the case of
> Dispatch failing" irrelevant (once done, which it hasn't been).

This seems like the best path forward.

> I started the conversion of Dispatch(rawptr) in the tree to
> Dispatch(already_AddRefed<>); xidorn took over finishing it but hasn't
> yet.  We should re-energize that.

>From the perspective of bug 1218297, that change doesn't actually
affect anything.

> There's considerable discussion in the bug of when leaks occur and also
> the assumed behavior of DispatchToMainThread (which is especially
> failure-prone because of how XPCOM dispatch works - even when MainThread
> still exists, that can fail in shutdown).

Ok, cool.  I didn't want to read the entire thing :)

>>> In bug 1218297 we saw a case where dispatch to a thread (the socket
>>> transport service thread in this case) fails because the thread has
>>> already shut down.  In our brave new world, nsThread simply leaks the
>>> runnable.
>
> Yup.  In cases where we anticipate a possible Dispatch failure (which is
> supposed to become impossible, but isn't currently) you can use the
> (still-existing) raw ptr interface and handle Dispatch failure
> explicitly to release the (leaked) reference, if it's safe.  Not all
> cases are safe to release in that case (which is what drove the initial
> bug filing, where it tried to release JS objects on Dispatch failure off
> mainthread).  Leaking is better than crashing/sec-bugs.

No, you can't.  If you can the raw ptr interface today Dispatch will
create its own reference and pass that to the already_AddRefed version
which then leaks it.  There's no way for the caller to handle this
safely.  Again, as karlt points out, Dispatch leaks today even if the
caller does everything correctly.

Leaking is better than crashing/sec-bugs, but that doesn't mean that
we get to introduce leaks to fix crash/sec-bugs, especially when it's
possible to fix the bug through other means.

> If the problem is that when this happens, a leak is reported by infra,
> then we could ping the leak-checker that there was a dispatch failure
> and leaks are expected.  Even better but maybe not possible would be
> annotate the root of the leak and suppress anything tied to it.

The problem is not that a leak is reported, the problem is that we
leak.  Automatically hiding our bugs is not good engineering practice.

>>> It can't release the reference it holds, because that would
>>> reintroduce the race condition we wanted to avoid, and it can't
>>> release the reference on the correct thread so it's already gone away.
>>> But now we have a new source of intermittent leaks.
>>>
>>> Was this anticipated when designing bug 1155059?  I don't think
>>> leaking is acceptable here, so we may need to back that out and return
>>> to living with that race condition.
>>
>>I agree this approach is not going to work out.  Short term, I
>>think the situation could be improved and most of those changes
>>kept by adding a DispatchOrLeak() variant that can be used by the
>>callers that want to leak.  Then we still have the leaks we had
>>prior to 2265e031ab97 but the new ones are resolved.
>>
>>For the remaining (old) leaks I can think of two options:
>>
>>1) Never call Dispatch() when it might fail and assert that it
>>   does not.
>>
>>2) Keep and additional reference to the runnable in the caller if
>>   it doesn't want Dispatch() to release the l

dump() calls now available in NSPR logging

[Kyle Huey]

In Bug 1059469 I added a logging module for calls to dump() on Window
and WorkerGlobalScope.  You can enable it with
NSPR_LOG_MODULES="Dump:5".  This is really handy when you're using
other logging modules and want to see how content script execution
fits into the logging output.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: dump() calls now available in NSPR logging

[Kyle Huey]

It would not be hard to add to the message manager and XPConnect.  Patches
welcome :)

- Kyle

On Thu, Jan 7, 2016 at 9:32 PM, Kan-Ru Chen (陳侃如)  wrote:

> Kyle Huey  writes:
>
> > In Bug 1059469 I added a logging module for calls to dump() on Window
> > and WorkerGlobalScope.  You can enable it with
> > NSPR_LOG_MODULES="Dump:5".  This is really handy when you're using
> > other logging modules and want to see how content script execution
> > fits into the logging output.
>
> This is great! You said Window and WorkerGlobalScope so I guess this is
> not for chrome JS. A related issue, regarding to OneLogger (Bug 881389)
> should we also unify the chrome JS logging story with NSPR logging?
>
>Kanru
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Feedback needed on proposal to add a web primitive for queuing microtasks

[Kyle Huey]

In principle, I don't see any reason not to do this.

- Kyle

On Wed, Jan 13, 2016 at 1:59 PM, Boris Zbarsky  wrote:

> Please see https://github.com/whatwg/html/issues/512
>
> Right now this is in the "does anyone have an objection to the basic
> idea?" stage.  So if someone does, please speak up!
>
> I've already noted a possible concern about abuse, but Promise and
> MutationObserver kinda allow that already; it just takes a bit of skill to
> do it.  I haven't thought of other problems with it thus far.
>
> -Boris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to stop revving UUIDs when changing XPIDL interfaces

[Kyle Huey]

As the XPIDL module owner, I support this.

- Kyle

On Fri, Jan 15, 2016 at 7:58 AM, Ehsan Akhgari 
wrote:

> Historically we have enforced updating the XPIDL interface UUIDs when you
> made any changes to it.  This was needed because of two reasons:
>
> * Backwards compatibility with binary extensions.  Since many changes to
> XPIDL interfaces caused the underlying v-table layout to change, revving
> the UUID enabled previously compiled extensions to fail getting the
> interface through QueryInterface() in the first place, preventing crashes
> when they try to use the interface.
>
> * Incremental builds.  Our build system used to not repack the compiled
> XPT file unless it detected a change in the UUID, which would manifest as
> weird issues when you landed code changing an interface without changing
> its UUID, in that in incremental builds the XPT file would be outdated, but
> in clobbered builds it would be correct.
>
> We have created Mercurial hooks that enforce a UUID change when an idl
> file is touched because of these requirements.
>
> Ever since Firefox 41, we have stopped supporting binary components in
> extensions, so the first reason doesn’t apply any more.  And since
> yesterday I have fixed bug 977464 which fixes the second issue.  So as far
> as I can tell, there is no reason to keep revving UUIDs any more. Therefore
> I would like to propose that we should remove the Mercurial hook (bug
> 1170718) and relax this requirement on trunk, and let this ride the trains.
>
> Three points worth mentioning here.
>
> * Thunderbird still supports binary components in extensions.  In <
> https://bugzilla.mozilla.org/show_bug.cgi?id=977464#c31> Kent said that
> Thunderbird is OK with change.
>
> * My proposal has no bearing on whether changes to XPIDL interfaces needs
> to be considered as part of the uplift approval process, as such changes
> can still have an impact on JS extension compatibility. Therefore under my
> proposal we’d reword the approval canned questionnaire on Bugzilla to talk
> about changes to XPIDL interfaces in addition to string changes, in lieu of
> mentioning UUID changes.
>
> * UUIDs are still the unique identifiers used in QueryInterface()
> implementations and you'd still need to tag the interface with a UUID when
> you create a new XPIDL interface.
>
> Please let me know if you have any questions or concerns.
>
> Cheers,
> Ehsan
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dominator tree memory analysis now in Nightly

[Kyle Huey]

This is awesome.  We've talked about how much we've wanted this since the
early days of MemShrink back in 2011.  Thanks to everyone who was involved.

- Kyle

On Thu, Jan 14, 2016 at 1:50 PM, Nick Fitzgerald 
wrote:

> Hi folks!
>
> Dominator trees give you fine-grained insight into memory retention.
>
> In a graph rooted by some node R, a node A is said to dominate B iff every
> path to B starting from R passes through A. In the context of a heap graph,
> another way to say this would be that A is retaining B: if the garbage
> collector found A to be unreachable and eligible for reclaiming, than B
> would also be unreachable and eligible for reclaiming.
>
> We also use this to calculate the "true" memory cost of a node in the heap
> graph. This is the "retained size" and contrasts with the naive "shallow
> size". For example, imagine a large binary tree where there are no outside
> references into subtrees, only to the root. The root node itself has a
> small shallow size: a left branch pointer, a value, and a right branch
> pointer. However, it is retaining the whole rest of this large tree's
> structure, and so its retained size is significant.
>
> Here is a screenshot of the dominator tree (combined with allocation stack
> tracking) in action to debug the memory overhead of loading large source
> files in a CodeMirror editor: http://i.imgur.com/sGsVJb9.png
>
> And here is a reminder of how to enable to memory tool within the
> devtools: http://i.imgur.com/hEPTqrT.png
>
> If you would like to use this tool for the whole runtime rather than
> scoped to a single tab, use the browser toolbox. Here are instructions for
> enabling and using the browser toolbox:
> https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox
>
> Please try it out, give me your feedback, and file bugs in the "Firefox"
> product and "Developer Tools: Memory" component!
>
> My thanks to the folks who reviewed patches for this feature: Jordan
> Santell, Steve Fink, Boris Zbarsky, and Jim Blandy.
>
> Cheers,
>
> Nick
>
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Splitting inner and outer windows

[Kyle Huey]

Early in the next release cycle I plan to land a patch that will remove
nsPIDOMWindow in favor of two separate types for inner and outer windows
(fittingly, called nsPIDOMWindowInner/nsPIDOMWindowOuter)  I'll also make
changes to the XPIDL interface hierarchy (effectively removing nsIDOMWindow
and introducing two new base interfaces for inner and outer windows) to
support this.  When the dust settles places that today use nsPIDOMWindow or
nsIDOMWindow will instead use a type that specifies, at compile time,
whether we have an inner or outer window.

The actual methods exposed on nsPIDOMWindow will be carried over in almost
all cases.  Splitting the interface itself, or nsGlobalWindow, apart will
happen later.

You can follow along in bug 1241764.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Splitting inner and outer windows

[Kyle Huey]

They will continue to implement nsIDOMWindow just like they do
nsIDOMWindowInternal.  We're simply not going to use it for anything.

- Kyle

On Fri, Jan 22, 2016 at 7:53 AM, Dave Townsend 
wrote:

> Does this mean that window objects will no longer implement
> nsIDOMWindow (at least as far as JS is concerned)? Querying for
> nsIDOMWindow is something add-ons do a lot and I'd expect to see a lot
> of add-ons break if we changed that.
>
> On Thu, Jan 21, 2016 at 9:52 PM, Kyle Huey  wrote:
> > Early in the next release cycle I plan to land a patch that will remove
> > nsPIDOMWindow in favor of two separate types for inner and outer windows
> > (fittingly, called nsPIDOMWindowInner/nsPIDOMWindowOuter)  I'll also make
> > changes to the XPIDL interface hierarchy (effectively removing
> nsIDOMWindow
> > and introducing two new base interfaces for inner and outer windows) to
> > support this.  When the dust settles places that today use nsPIDOMWindow
> or
> > nsIDOMWindow will instead use a type that specifies, at compile time,
> > whether we have an inner or outer window.
> >
> > The actual methods exposed on nsPIDOMWindow will be carried over in
> almost
> > all cases.  Splitting the interface itself, or nsGlobalWindow, apart will
> > happen later.
> >
> > You can follow along in bug 1241764.
> >
> > - Kyle
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Splitting inner and outer windows

[Kyle Huey]

On Fri, Jan 22, 2016 at 11:24 AM, Bobby Holley 
wrote:

>
>
> On Thu, Jan 21, 2016 at 9:52 PM, Kyle Huey  wrote:
>
>> Early in the next release cycle I plan to land a patch that will remove
>> nsPIDOMWindow in favor of two separate types for inner and outer windows
>> (fittingly, called nsPIDOMWindowInner/nsPIDOMWindowOuter)  I'll also make
>> changes to the XPIDL interface hierarchy (effectively removing
>> nsIDOMWindow
>> and introducing two new base interfaces for inner and outer windows) to
>> support this.  When the dust settles places that today use nsPIDOMWindow
>> or
>> nsIDOMWindow will instead use a type that specifies, at compile time,
>> whether we have an inner or outer window.
>>
>
> Huzzah!
>
>
>> The actual methods exposed on nsPIDOMWindow will be carried over in almost
>> all cases.  Splitting the interface itself, or nsGlobalWindow, apart will
>> happen later.
>>
>
> Is the nsGlobalWindow split likely to happen soon, or is it being
> indefinitely postponed? We have a fair amount of code that uses it directly
> to avoid virtual calls.
>
>
>>
>> You can follow along in bug 1241764.
>>
>> - Kyle
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
My long term plan of sorts is to move "outer" windows into docshell rather
than actually splitting it.

I don't expect to work on that part myself anytime soon though.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: IndexedDB access in third-party iFrames disabled or not?

[Kyle Huey]

We changed this in bug 1147821.  It looks like the documentation hasn't
been updated.

- Kyle

On Mon, Jan 25, 2016 at 10:26 AM,  wrote:

> Is IndexedDB supposed to be accessible in third-party iFrames? From what I
> understand, the MDN documentation says IndexedDB is *not* accessible in
> third-party iFrames, but from my own tests, I have been fully able to use
> IndexedDB in third-party iFrames.
>
> The MDN documentation link:
> https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB#Security
> Search for "It's important to note that IndexedDB doesn't work for content
> loaded into a frame"
>
> MDN links to RESOLVED FIXED Bugzilla 595307:
> https://bugzilla.mozilla.org/show_bug.cgi?id=595307
>
> I guess I don't really understand what the status is. I'm able to use
> IndexedDB in third-party iFrames, but maybe I shouldn't be able to? What
> are Firefox's plans for IndexedDB in third-party iFrames?
>
> If necessary, I can upload some test code. Hopefully this is the right
> place to ask, thanks for reading this!
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: IndexedDB access in third-party iFrames disabled or not?

[Kyle Huey]

Awesome, thanks.

- Kyle

On Mon, Jan 25, 2016 at 10:56 AM, Chris Mills  wrote:

> Whoops, sorry about that. I’ve updated it now, and made sure that we don’t
> repeat this erroneous point in any other docs.
>
> Chris Mills
>  Senior tech writer || Mozilla
> developer.mozilla.org || MDN
>  cmi...@mozilla.com || @chrisdavidmills
>
> > On 25 Jan 2016, at 18:35, Kyle Huey  wrote:
> >
> > We changed this in bug 1147821.  It looks like the documentation hasn't
> > been updated.
> >
> > - Kyle
> >
> > On Mon, Jan 25, 2016 at 10:26 AM,  wrote:
> >
> >> Is IndexedDB supposed to be accessible in third-party iFrames? From
> what I
> >> understand, the MDN documentation says IndexedDB is *not* accessible in
> >> third-party iFrames, but from my own tests, I have been fully able to
> use
> >> IndexedDB in third-party iFrames.
> >>
> >> The MDN documentation link:
> >>
> https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API/Using_IndexedDB#Security
> >> Search for "It's important to note that IndexedDB doesn't work for
> content
> >> loaded into a frame"
> >>
> >> MDN links to RESOLVED FIXED Bugzilla 595307:
> >> https://bugzilla.mozilla.org/show_bug.cgi?id=595307
> >>
> >> I guess I don't really understand what the status is. I'm able to use
> >> IndexedDB in third-party iFrames, but maybe I shouldn't be able to? What
> >> are Firefox's plans for IndexedDB in third-party iFrames?
> >>
> >> If necessary, I can upload some test code. Hopefully this is the right
> >> place to ask, thanks for reading this!
> >> ___
> >> dev-platform mailing list
> >> dev-platform@lists.mozilla.org
> >> https://lists.mozilla.org/listinfo/dev-platform
> >>
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Bug Program Next Steps

[Kyle Huey]

On Fri, Jan 29, 2016 at 3:45 PM, Emma Humphries  wrote:

> We believe that the number of outstanding, actionable bugs is the best
> metric of code quality available, and that how this number changes over
> time will be a strong indicator of the evolving quality of Firefox.
>

Why do we believe that?

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Splitting inner and outer windows

[Kyle Huey]

This has landed (and stuck) on inbound.

- Kyle

On Thu, Jan 21, 2016 at 9:52 PM, Kyle Huey  wrote:

> Early in the next release cycle I plan to land a patch that will remove
> nsPIDOMWindow in favor of two separate types for inner and outer windows
> (fittingly, called nsPIDOMWindowInner/nsPIDOMWindowOuter)  I'll also make
> changes to the XPIDL interface hierarchy (effectively removing nsIDOMWindow
> and introducing two new base interfaces for inner and outer windows) to
> support this.  When the dust settles places that today use nsPIDOMWindow or
> nsIDOMWindow will instead use a type that specifies, at compile time,
> whether we have an inner or outer window.
>
> The actual methods exposed on nsPIDOMWindow will be carried over in almost
> all cases.  Splitting the interface itself, or nsGlobalWindow, apart will
> happen later.
>
> You can follow along in bug 1241764.
>
> - Kyle
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

[Kyle Huey]

Are you using it from JS or C++?  If you're using it from JS, nothing has
changed.

- Kyle

On Wed, Feb 10, 2016 at 4:32 PM, Devan Shah  wrote:

> Hello
>
> nsIDOMWindow is deprecated now according to:
> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDOMWindow
> is there an alternative for this interface. I am using a lot of functions
> from this interface and also using nsIPromptFactory which relies on
> nsIDOMWindow a lot for all of it functions.
>
> Is there any way to get an alternative with the same functionality which
> requires minimal changes or is there a way that I can get the nsIDOMWindow
> interface and all of its functionality back by adding the interface locally
> and implementing the functions locally.
>
> Thanks
> Devan Shah
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

[Kyle Huey]

Ok ... ignoring the question of how you're using it from C++ since binary
addons are gone, many of the methods on nsIDOMWindow moved to nsPIDOMWindow
and then to nsPIDOMWindowInner/Outer, depending on what version of Gecko
you're using.  Today on trunk nsIPromptFactory takes a mozIDOMWindowProxy,
which is a base interface of nsPIDOMWindowOuter.  You can look at
http://mxr.mozilla.org/mozilla-central/source/dom/base/nsPIDOMWindow.h to
see what's there.  Some methods on nsIDOMWindow that were unused were
removed completely, though I don't think there were many.

- Kyle

On Wed, Feb 10, 2016 at 4:40 PM, Devan Shah  wrote:

> I am using it from c++
>
> On Wed, Feb 10, 2016 at 7:38 PM, Kyle Huey  wrote:
>
>> Are you using it from JS or C++?  If you're using it from JS, nothing has
>> changed.
>>
>> - Kyle
>>
>> On Wed, Feb 10, 2016 at 4:32 PM, Devan Shah 
>> wrote:
>>
>>> Hello
>>>
>>> nsIDOMWindow is deprecated now according to:
>>> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDOMWindow
>>> is there an alternative for this interface. I am using a lot of functions
>>> from this interface and also using nsIPromptFactory which relies on
>>> nsIDOMWindow a lot for all of it functions.
>>>
>>> Is there any way to get an alternative with the same functionality which
>>> requires minimal changes or is there a way that I can get the nsIDOMWindow
>>> interface and all of its functionality back by adding the interface locally
>>> and implementing the functions locally.
>>>
>>> Thanks
>>> Devan Shah
>>> ___
>>> dev-platform mailing list
>>> dev-platform@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-platform
>>>
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

[Kyle Huey]

Yeah, ok, nsPIDOMWindow then.

- Kyle

On Wed, Feb 10, 2016 at 4:49 PM, Devan Shah  wrote:

> Version 45, I am using the SDK from
> https://ftp.mozilla.org/pub/firefox/releases/45.0b4/win32/en-US/firefox-45.0b4.sdk.zip.
> Which I still see the nsIPromptFactory has
>
>   /* void getPrompt (in nsIDOMWindow aParent, in nsIIDRef iid, [iid_is
> (iid), retval] out nsQIResult result); */
>   NS_IMETHOD GetPrompt(nsIDOMWindow *aParent, const nsIID & iid, void
> **result) = 0;
>
>
>
> <https://ftp.mozilla.org/pub/firefox/releases/45.0b4/win32/en-US/firefox-45.0b4.sdk.zip>
>
> On Wed, Feb 10, 2016 at 7:43 PM, Kyle Huey  wrote:
>
>> Ok ... ignoring the question of how you're using it from C++ since binary
>> addons are gone, many of the methods on nsIDOMWindow moved to nsPIDOMWindow
>> and then to nsPIDOMWindowInner/Outer, depending on what version of Gecko
>> you're using.  Today on trunk nsIPromptFactory takes a mozIDOMWindowProxy,
>> which is a base interface of nsPIDOMWindowOuter.  You can look at
>> http://mxr.mozilla.org/mozilla-central/source/dom/base/nsPIDOMWindow.h
>> to see what's there.  Some methods on nsIDOMWindow that were unused were
>> removed completely, though I don't think there were many.
>>
>> - Kyle
>>
>> On Wed, Feb 10, 2016 at 4:40 PM, Devan Shah 
>> wrote:
>>
>>> I am using it from c++
>>>
>>> On Wed, Feb 10, 2016 at 7:38 PM, Kyle Huey  wrote:
>>>
>>>> Are you using it from JS or C++?  If you're using it from JS, nothing
>>>> has changed.
>>>>
>>>> - Kyle
>>>>
>>>> On Wed, Feb 10, 2016 at 4:32 PM, Devan Shah 
>>>> wrote:
>>>>
>>>>> Hello
>>>>>
>>>>> nsIDOMWindow is deprecated now according to:
>>>>> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDOMWindow
>>>>> is there an alternative for this interface. I am using a lot of functions
>>>>> from this interface and also using nsIPromptFactory which relies on
>>>>> nsIDOMWindow a lot for all of it functions.
>>>>>
>>>>> Is there any way to get an alternative with the same functionality
>>>>> which requires minimal changes or is there a way that I can get the
>>>>> nsIDOMWindow interface and all of its functionality back by adding the
>>>>> interface locally and implementing the functions locally.
>>>>>
>>>>> Thanks
>>>>> Devan Shah
>>>>> ___
>>>>> dev-platform mailing list
>>>>> dev-platform@lists.mozilla.org
>>>>> https://lists.mozilla.org/listinfo/dev-platform
>>>>>
>>>>
>>>>
>>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

[Kyle Huey]

Yes, you need to QueryInterface between nsIDOMWindow and nsPIDOMWindow.

What are you actually doing with the Firefox SDK?

- Kyle

On Wed, Feb 10, 2016 at 5:03 PM, Devan Shah  wrote:

> I tried to use nsPIDOMWindow, but issues is that functions like:
>
> Function GetContentDOMWindow in nsIWebBrowser is expecting: NS_IMETHOD
> GetContentDOMWindow(nsIDOMWindow * *aContentDOMWindow) = 0;
> (firefox-45.0b4\firefox-sdk\include\nsIWebBrowser.h)
> Function: NS_IMETHOD GetPrompt(nsIDOMWindow *aParent, const nsIID & iid,
> void **result) = 0; from nsIPromptFactory
>
> So makes it all not compatible.
>
> Is there any way I can rebuild the Firefox SDK with the old nsIDOMWindow
>
> On Wed, Feb 10, 2016 at 7:51 PM, Kyle Huey  wrote:
>
>> Yeah, ok, nsPIDOMWindow then.
>>
>> - Kyle
>>
>> On Wed, Feb 10, 2016 at 4:49 PM, Devan Shah 
>> wrote:
>>
>>> Version 45, I am using the SDK from
>>> https://ftp.mozilla.org/pub/firefox/releases/45.0b4/win32/en-US/firefox-45.0b4.sdk.zip.
>>> Which I still see the nsIPromptFactory has
>>>
>>>   /* void getPrompt (in nsIDOMWindow aParent, in nsIIDRef iid, [iid_is
>>> (iid), retval] out nsQIResult result); */
>>>   NS_IMETHOD GetPrompt(nsIDOMWindow *aParent, const nsIID & iid, void
>>> **result) = 0;
>>>
>>>
>>>
>>> <https://ftp.mozilla.org/pub/firefox/releases/45.0b4/win32/en-US/firefox-45.0b4.sdk.zip>
>>>
>>> On Wed, Feb 10, 2016 at 7:43 PM, Kyle Huey  wrote:
>>>
>>>> Ok ... ignoring the question of how you're using it from C++ since
>>>> binary addons are gone, many of the methods on nsIDOMWindow moved to
>>>> nsPIDOMWindow and then to nsPIDOMWindowInner/Outer, depending on what
>>>> version of Gecko you're using.  Today on trunk nsIPromptFactory takes a
>>>> mozIDOMWindowProxy, which is a base interface of nsPIDOMWindowOuter.  You
>>>> can look at
>>>> http://mxr.mozilla.org/mozilla-central/source/dom/base/nsPIDOMWindow.h
>>>> to see what's there.  Some methods on nsIDOMWindow that were unused were
>>>> removed completely, though I don't think there were many.
>>>>
>>>> - Kyle
>>>>
>>>> On Wed, Feb 10, 2016 at 4:40 PM, Devan Shah 
>>>> wrote:
>>>>
>>>>> I am using it from c++
>>>>>
>>>>> On Wed, Feb 10, 2016 at 7:38 PM, Kyle Huey  wrote:
>>>>>
>>>>>> Are you using it from JS or C++?  If you're using it from JS, nothing
>>>>>> has changed.
>>>>>>
>>>>>> - Kyle
>>>>>>
>>>>>> On Wed, Feb 10, 2016 at 4:32 PM, Devan Shah 
>>>>>> wrote:
>>>>>>
>>>>>>> Hello
>>>>>>>
>>>>>>> nsIDOMWindow is deprecated now according to:
>>>>>>> https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIDOMWindow
>>>>>>> is there an alternative for this interface. I am using a lot of 
>>>>>>> functions
>>>>>>> from this interface and also using nsIPromptFactory which relies on
>>>>>>> nsIDOMWindow a lot for all of it functions.
>>>>>>>
>>>>>>> Is there any way to get an alternative with the same functionality
>>>>>>> which requires minimal changes or is there a way that I can get the
>>>>>>> nsIDOMWindow interface and all of its functionality back by adding the
>>>>>>> interface locally and implementing the functions locally.
>>>>>>>
>>>>>>> Thanks
>>>>>>> Devan Shah
>>>>>>> ___
>>>>>>> dev-platform mailing list
>>>>>>> dev-platform@lists.mozilla.org
>>>>>>> https://lists.mozilla.org/listinfo/dev-platform
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

[Kyle Huey]

Ok.  I thought we killed binary components in extensions ...

There will be a lot of changes around windows and their XPIDL interfaces in
Gecko over the next while so you should expect to have to update this code
fairly frequently if you're actually calling methods on nsIDOMWindow.

- Kyle

On Wed, Feb 10, 2016 at 5:10 PM, Devan Shah  wrote:

> I was using the xulrunner SDK, but that is no longer created any more so
> using the firefox SDK.
>
> I am using it to create a plugin which can be used to launch a web browser
> which communicates with a proxy server which can be used to capture all the
> http traffic.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

[Kyle Huey]

Alright, just QueryInterface between nsIDOMWindow and nsPIDOMWindow when
you have one and need the other and you should be fine.

- Kyle

On Wed, Feb 10, 2016 at 5:15 PM, Devan Shah  wrote:

> Currently I just want to get it up and running again on FF 45 again, with
> out making too much changes because we plan to deprecate this feature mid
> this year or so.
>
> Just need to get it working on Firefox 45, currently works perfectly on
> Firefox 38.
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

[Kyle Huey]

Right, that will work, although you could nsCOMPtr to make it a lot
prettier:

void test(nsIDOMWindow* aDOMWindow, nsIBaseWindow** aBaseWindow)
{
  nsCOMPtr window = do_QueryInterface(aDOMWindow);
  nsCOMPtr docShell;
  if (window)
window->GetDocShell(getter_AddRefs(docShell));
  nsIWebShell* rootWebShell = 0;
  NS_IF_RELEASE(rootWebShell);
//return status;
}

- Kyle

On Wed, Feb 10, 2016 at 5:22 PM, Devan Shah  wrote:

> Do you happen to have a QueryInterface example,
>
> Would something like the following work:
>
> void test(nsIDOMWindow* aDOMWindow, nsIBaseWindow** aBaseWindow)
> {
>   nsPIDOMWindow* window = 0;
>   nsresult status = aDOMWindow->QueryInterface(NS_GET_IID(nsPIDOMWindow),
> (void**)&window);
>   nsIDocShell* docShell = 0;
>   if (window)
> window->GetDocShell(&docShell);
>   nsIWebShell* rootWebShell = 0;
>   NS_IF_RELEASE(rootWebShell);
>   NS_IF_RELEASE(docShell);
>   NS_IF_RELEASE(window);
> //    return status;
> }
>
> On Wed, Feb 10, 2016 at 8:16 PM, Kyle Huey  wrote:
>
>> Alright, just QueryInterface between nsIDOMWindow and nsPIDOMWindow when
>> you have one and need the other and you should be fine.
>>
>> - Kyle
>>
>> On Wed, Feb 10, 2016 at 5:15 PM, Devan Shah 
>> wrote:
>>
>>> Currently I just want to get it up and running again on FF 45 again,
>>> with out making too much changes because we plan to deprecate this feature
>>> mid this year or so.
>>>
>>> Just need to get it working on Firefox 45, currently works perfectly on
>>> Firefox 38.
>>>
>>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

[Kyle Huey]

Yes, SizeToContent is only accessible to JS now.

- Kyle

On Wed, Feb 10, 2016 at 5:28 PM, Devan Shah  wrote:

> yep
>
> This is how I was using nsIDOMWindow before:
>
> NS_IMETHODIMP WebBrowserChrome::OnLocationChange(nsIWebProgress*
> aWebProgress,
> nsIRequest* aRequest,
> nsIURI *location,
> uint32_t aFlags)
> {
> PRBool isSubFrameLoad = PR_FALSE; // Is this a subframe load
> if (aWebProgress) {
> nsCOMPtr  domWindow;
> nsCOMPtr  topDomWindow;
> aWebProgress->GetDOMWindow(getter_AddRefs(domWindow));
> if (domWindow) { // Get root domWindow
> domWindow->GetTop(getter_AddRefs(topDomWindow));
> }
> if (domWindow != topDomWindow)
> isSubFrameLoad = PR_TRUE;
> }
> if (!isSubFrameLoad)
> CWebBrowserChromeUI::UpdateCurrentURI(this);
> return NS_OK;
> }
>
> So here just changing nsCOMPtr to nsCOMPtr
> and using QueryInterface should do the trick right?
>
> Also I am using a function called SizeToContent() from nsIDOMWindow which
> I do not see exists any more in nsPIDOMWindow either was this one removed
> completly.
>
> On Wed, Feb 10, 2016 at 8:24 PM, Kyle Huey  wrote:
>
>> Right, that will work, although you could nsCOMPtr to make it a lot
>> prettier:
>>
>> void test(nsIDOMWindow* aDOMWindow, nsIBaseWindow** aBaseWindow)
>> {
>>   nsCOMPtr window = do_QueryInterface(aDOMWindow);
>>   nsCOMPtr docShell;
>>   if (window)
>> window->GetDocShell(getter_AddRefs(docShell));
>>   nsIWebShell* rootWebShell = 0;
>>   NS_IF_RELEASE(rootWebShell);
>> //return status;
>> }
>>
>> - Kyle
>>
>> On Wed, Feb 10, 2016 at 5:22 PM, Devan Shah 
>> wrote:
>>
>>> Do you happen to have a QueryInterface example,
>>>
>>> Would something like the following work:
>>>
>>> void test(nsIDOMWindow* aDOMWindow, nsIBaseWindow** aBaseWindow)
>>> {
>>>   nsPIDOMWindow* window = 0;
>>>   nsresult status =
>>> aDOMWindow->QueryInterface(NS_GET_IID(nsPIDOMWindow), (void**)&window);
>>>   nsIDocShell* docShell = 0;
>>>   if (window)
>>> window->GetDocShell(&docShell);
>>>   nsIWebShell* rootWebShell = 0;
>>>   NS_IF_RELEASE(rootWebShell);
>>>   NS_IF_RELEASE(docShell);
>>>   NS_IF_RELEASE(window);
>>> //return status;
>>> }
>>>
>>> On Wed, Feb 10, 2016 at 8:16 PM, Kyle Huey  wrote:
>>>
>>>> Alright, just QueryInterface between nsIDOMWindow and nsPIDOMWindow
>>>> when you have one and need the other and you should be fine.
>>>>
>>>> - Kyle
>>>>
>>>> On Wed, Feb 10, 2016 at 5:15 PM, Devan Shah 
>>>> wrote:
>>>>
>>>>> Currently I just want to get it up and running again on FF 45 again,
>>>>> with out making too much changes because we plan to deprecate this feature
>>>>> mid this year or so.
>>>>>
>>>>> Just need to get it working on Firefox 45, currently works perfectly
>>>>> on Firefox 38.
>>>>>
>>>>>
>>>>
>>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: nsIDOMWindow is deprecated now is there an alternative?

[Kyle Huey]

You get the nsIDOMWindow, and then QueryInterface to nsPIDOMWindow to call
GetTop on it.

- Kyle

On Wed, Feb 10, 2016 at 5:35 PM, Devan Shah  wrote:

> In the below code i use aWebProgress to and then GetDOMWindow on that,
> however GetDOMWindow only allows nsIDOMWindow, would the QueryInterface
> accommodate for this for this
>
> NS_IMETHODIMP WebBrowserChrome::OnLocationChange(nsIWebProgress*
> aWebProgress,
> nsIRequest* aRequest,
> nsIURI *location,
> uint32_t aFlags)
> {
> PRBool isSubFrameLoad = PR_FALSE; // Is this a subframe load
> if (aWebProgress) {
> nsCOMPtr  domWindow;
> nsCOMPtr  topDomWindow;
> aWebProgress->GetDOMWindow(getter_AddRefs(domWindow));
> if (domWindow) { // Get root domWindow
> domWindow->GetTop(getter_AddRefs(topDomWindow));
> }
> if (domWindow != topDomWindow)
> isSubFrameLoad = PR_TRUE;
> }
> if (!isSubFrameLoad)
> CWebBrowserChromeUI::UpdateCurrentURI(this);
> return NS_OK;
> }
>
> On Wed, Feb 10, 2016 at 8:30 PM, Kyle Huey  wrote:
>
>> Yes, SizeToContent is only accessible to JS now.
>>
>> - Kyle
>>
>> On Wed, Feb 10, 2016 at 5:28 PM, Devan Shah 
>> wrote:
>>
>>> yep
>>>
>>> This is how I was using nsIDOMWindow before:
>>>
>>> NS_IMETHODIMP WebBrowserChrome::OnLocationChange(nsIWebProgress*
>>> aWebProgress,
>>> nsIRequest* aRequest,
>>> nsIURI *location,
>>> uint32_t aFlags)
>>> {
>>> PRBool isSubFrameLoad = PR_FALSE; // Is this a subframe load
>>> if (aWebProgress) {
>>> nsCOMPtr  domWindow;
>>> nsCOMPtr  topDomWindow;
>>> aWebProgress->GetDOMWindow(getter_AddRefs(domWindow));
>>> if (domWindow) { // Get root domWindow
>>> domWindow->GetTop(getter_AddRefs(topDomWindow));
>>> }
>>> if (domWindow != topDomWindow)
>>> isSubFrameLoad = PR_TRUE;
>>> }
>>> if (!isSubFrameLoad)
>>> CWebBrowserChromeUI::UpdateCurrentURI(this);
>>>     return NS_OK;
>>> }
>>>
>>> So here just changing nsCOMPtr to nsCOMPtr
>>> and using QueryInterface should do the trick right?
>>>
>>> Also I am using a function called SizeToContent() from nsIDOMWindow
>>> which I do not see exists any more in nsPIDOMWindow either was this one
>>> removed completly.
>>>
>>> On Wed, Feb 10, 2016 at 8:24 PM, Kyle Huey  wrote:
>>>
>>>> Right, that will work, although you could nsCOMPtr to make it a lot
>>>> prettier:
>>>>
>>>> void test(nsIDOMWindow* aDOMWindow, nsIBaseWindow** aBaseWindow)
>>>> {
>>>>   nsCOMPtr window = do_QueryInterface(aDOMWindow);
>>>>   nsCOMPtr docShell;
>>>>   if (window)
>>>> window->GetDocShell(getter_AddRefs(docShell));
>>>>   nsIWebShell* rootWebShell = 0;
>>>>   NS_IF_RELEASE(rootWebShell);
>>>> //return status;
>>>> }
>>>>
>>>> - Kyle
>>>>
>>>> On Wed, Feb 10, 2016 at 5:22 PM, Devan Shah 
>>>> wrote:
>>>>
>>>>> Do you happen to have a QueryInterface example,
>>>>>
>>>>> Would something like the following work:
>>>>>
>>>>> void test(nsIDOMWindow* aDOMWindow, nsIBaseWindow** aBaseWindow)
>>>>> {
>>>>>   nsPIDOMWindow* window = 0;
>>>>>   nsresult status =
>>>>> aDOMWindow->QueryInterface(NS_GET_IID(nsPIDOMWindow), (void**)&window);
>>>>>   nsIDocShell* docShell = 0;
>>>>>   if (window)
>>>>> window->GetDocShell(&docShell);
>>>>>   nsIWebShell* rootWebShell = 0;
>>>>>   NS_IF_RELEASE(rootWebShell);
>>>>>   NS_IF_RELEASE(docShell);
>>>>>   NS_IF_RELEASE(window);
>>>>> //return status;
>>>>> }
>>>>>
>>>>> On Wed, Feb 10, 2016 at 8:16 PM, Kyle Huey  wrote:
>>>>>
>>>>>> Alright, just QueryInterface between nsIDOMWindow and nsPIDOMWindow
>>>>>> when you have one and need the other and you should be fine.
>>>>>>
>>>>>> - Kyle
>>>>>>
>>>>>> On Wed, Feb 10, 2016 at 5:15 PM, Devan Shah 
>>>>>> wrote:
>>>>>>
>>>>>>> Currently I just want to get it up and running again on FF 45 again,
>>>>>>> with out making too much changes because we plan to deprecate this 
>>>>>>> feature
>>>>>>> mid this year or so.
>>>>>>>
>>>>>>> Just need to get it working on Firefox 45, currently works perfectly
>>>>>>> on Firefox 38.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Suggesting new name for nsIDOMEvent::GetInternalNSEvent

[Kyle Huey]

What's wrong with AsWidgetEvent? We do AsFoo a fair bit.

- Kyle
On Feb 10, 2016 8:58 PM, "Aidin Gharibnavaz"  wrote:

> In Bug 1235830 , I'm
> going to rename this method to something more meaningful. I need suggestion
> about what the name should be.
>
> Summary of the discussion so far:
>
> * WidgetEvent() can't be used, since it's also the name of a type.
> * GetWidgetEvent() is good, but may suggests that method can return
> nullptr.
> * AsWidgetEvent() don't have this ambiguousness, but is not a good name.
>
> Any other ideas?
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Using rr chaos mode to find intermittent bugs

[Kyle Huey]

On Thu, Feb 11, 2016 at 11:35 AM, Robert O'Callahan 
wrote:

> On Thu, Feb 11, 2016 at 11:55 PM, Nicolas B. Pierron <
> nicolas.b.pier...@mozilla.com> wrote:
>
> > On 02/10/2016 08:04 PM, Robert O'Callahan wrote:
> >
> >> Background:
> >> http://robert.ocallahan.org/2016/02/introducing-rr-chaos-mode.html
> >>
> >> I just landed on rr master support for a "-h" option which enables a
> chaos
> >> mode for rr recording. This is designed to help reproduce intermittent
> >> test
> >> failures under rr. […]
> >>
> >
> > Thanks Roc, I will give it a try.
> >
> > On the other hand, I used to rely more on the "-c" option to achieve a
> > similar thing in the past, instead of the "-e" option.
> >
> > The reason I did so being that the thread I am interested in does a few
> > syscalls compared to the rest of the program.  Thus I felt that using
> "-e"
> > option would give it an unfair large time slices compared to what is
> > supposed to happen if the threads are running concurrently.
>
>
> The -e option is gone now because the new scheduler (with or without chaos
> mode) does not take system calls into account when calculating the length
> of a timeslice. We only count conditional branches.
>

So we context switch at a syscall now only when the current thread happens
to become unschedulable?

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: rr chaos mode update

[Kyle Huey]

On Sun, Feb 14, 2016 at 9:16 PM, Robert O'Callahan 
wrote:

> Over the last few days we have had a lot of positive experiences
> reproducing bugs with rr chaos mode. Kyle tells me that, in fact, he's been
> able to reproduce every single bug he tried with enough machine time thrown
> at it.
>

Of five or so, but yes.

At this point the limiting factor is getting developers to actually debug
> and fix recorded test failures. Anyone should be able to set up a VM on
> their local machine, build Firefox, record some failures and fix them. For
> best results, run just one test that's known intermittent, or possibly the
> whole directory of tests if there might be inter-test dependencies. Use
> --shuffle and --run-until-failure. The most convenient way to run rr with
> chaos mode is probably to create a script rr-chaos that prepends the
> --chaos option, and use --debugger rr-chaos.
>

You can generally pass --debugger=/path/to/rr --debugger-args="record -h"
to mach to get things working.

Lots of tests have been disabled for intermittency over the years. Now we
> have the ability to fix (at least some of) them without much pain, it may
> be worth revisiting them, though i don't know how to prioritize that.
>

FWIW, every failure that I've debugged to completion so far has been a bug
in the test (although I have two fatal assertion bugs I'm working through
that will obviously be flaws in Gecko).  I think one of the things we
really want to get a feeling for is how often we find actual bugs in the
product.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: rr chaos mode update

[Kyle Huey]

On Sun, Feb 14, 2016 at 9:37 PM, L. David Baron  wrote:

> On Sunday 2016-02-14 21:26 -0800, Kyle Huey wrote:
> > On Sun, Feb 14, 2016 at 9:16 PM, Robert O'Callahan 
> wrote:
> > > Over the last few days we have had a lot of positive experiences
> > > reproducing bugs with rr chaos mode. Kyle tells me that, in fact, he's
> been
> > > able to reproduce every single bug he tried with enough machine time
> thrown
> > > at it.
> >
> > Of five or so, but yes.
>
> How many of those were intermittents that were never actually
> reported on Linux on our test infrastructure (i.e., reported only on
> other platforms), but that you were able to reproduce in rr's chaos
> mode on Linux?
>

At least one, bug 1150737, had only appeared in any great quantity on 10.6,
and may never have appeared on non-Mac tests in automation.  Chaos mode
reproduced it in a minute or two on Linux.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: rr chaos mode update

[Kyle Huey]

Seems like a good thing to expect developers to do locally today.

- Kyle

On Mon, Feb 15, 2016 at 6:08 PM, Justin Dolske  wrote:

> On 2/14/16 9:25 PM, Bobby Holley wrote:
>
> How far are we from being able to use cloud (rather than local) machine
>> time to produce a trace of an intermittently-failing bug? Some one-click
>> procedure to produce a trace from a failure on treeherder seems like it
>> would lower the activation energy significantly.
>>
>
> And with that... At some point, what about having all *new* tests be
> battle-tested by X runs of rr-chaos testing?  If it passes, it's allowed to
> run in the usual CI automation. If it fails, it's not (and you have a handy
> recording to debug).
>
> Justin
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: rr chaos mode update

[Kyle Huey]

rr runs fine under VMWare ;)

- Kyle

On Mon, Feb 15, 2016 at 6:18 PM, Bobby Holley  wrote:

> On Mon, Feb 15, 2016 at 6:15 PM, Kyle Huey  wrote:
>
>> Seems like a good thing to expect developers to do locally today.
>>
>
> I don't think that's realistic for developers who aren't on Linux.
>
>
>>
>> - Kyle
>>
>> On Mon, Feb 15, 2016 at 6:08 PM, Justin Dolske 
>> wrote:
>>
>> > On 2/14/16 9:25 PM, Bobby Holley wrote:
>> >
>> > How far are we from being able to use cloud (rather than local) machine
>> >> time to produce a trace of an intermittently-failing bug? Some
>> one-click
>> >> procedure to produce a trace from a failure on treeherder seems like it
>> >> would lower the activation energy significantly.
>> >>
>> >
>> > And with that... At some point, what about having all *new* tests be
>> > battle-tested by X runs of rr-chaos testing?  If it passes, it's
>> allowed to
>> > run in the usual CI automation. If it fails, it's not (and you have a
>> handy
>> > recording to debug).
>> >
>> > Justin
>> >
>> > ___
>> > dev-platform mailing list
>> > dev-platform@lists.mozilla.org
>> > https://lists.mozilla.org/listinfo/dev-platform
>> >
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and ship: IDBKeyRange.includes()

[Kyle Huey]

*Summary*: This simple API allows one to test whether a given key is
included in an IDBKeyRange
*Bug*: https://bugzilla.mozilla.org/show_bug.cgi?id=1251498
*Link to standard*: http://w3c.github.io/IndexedDB/#dom-idbkeyrange-includes
*Platform coverage*: All platforms
*Estimated or target release*: Firefox 47
*Preference behind which this will be implemented*: No preference
Do other browser engines implement this? Blink is planning to implement and
ship this per discussions with Joshua Bell.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Exit code -11 must die

[Kyle Huey]

On Mon, Feb 29, 2016 at 9:03 AM, Benjamin Smedberg 
wrote:

> On 2/27/2016 9:06 PM, Randell Jesup wrote:
>
>> months until recently it popped up a bit).  Note that this failure
>> *never* results in a crashdump, and I've never seen it locally, just in
>> Automation.
>>
>
> What we do know:
>
>  * Exit code -11 is evidence a SIGSEGV (crash).
>
> This I don't know, but somebody may know (+ted):
>
>  * Are we sure that the crash is happening in firefox.exe? Or is it
>possible that some other process is crashing and taking down our
>test harness with it?
>  * Can somebody point to exactly what line of code in the test harness
>collects the -11 code?
>  * Is there no crash dump because the crash reporter is turned off?
>  o If it's turned on, is the crash reporter itself crashing? Or is
>the test harness not picking up the crash dump?
>
>
> We *need* to find some solution to it -- even if it's to decide it's a
>> (safe) artifact of some underlying problem outside of our control.
>>
>
> Is "we" you? Are you asking somebody else to help you with this, or own
> the problem completely?
>
>I'd
>> far rather find a true cause and either fix or wallpaper it.  But right
>> now it's stopping me from landing some important code changes.
>>
>> On the plus side, I have a nice Try run which will cause it 100% of the
>> time - though when I tried to provoke it on a loaner Test VM after
>> painfully emulating what's needed to run tests, it wouldn't fail -- but
>> I don't trust that was a well-setup recreation of a real Try run.
>>
>> https://treeherder.mozilla.org/#/jobs?repo=try&revision=b2eb01359621
>>
>> IIRC, there was recently a post about how you can submit a try job and
> have the VM stay alive afterwards for postmortem debugging. I don't
> remember/can't find the details right now
>
> Can we also submit a try job with rr enabled, and get a recording of the
> failure? That combination could lead to a pretty quick cause diagnosis of
> this, since it's Linux.
>
> Also, does this failure happen if you disable all the tests except for the
> one which is permafailing
> (dom/media/tests/mochitest/identity/test_setIdentityProviderWithErrors.html)?
> If so, that would make it easier to record and debug.
>

If these are running on EC2 we can't throw rr at it.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: call prompt service dynamically

[Kyle Huey]

You're probably just not linking to the xpcom glue library in eclipse/gcc.

- Kyle

On Tue, Mar 8, 2016 at 8:33 PM, Tobias Wolf  wrote:

> We`re develping a PKCS11 modul in c/c++ for a custom card reader to
> support. I just want to display a simple dialog. The code below works great
> until I stay on MS Visual Studio. But our project is running on eclipse/gcc.
>
>  nsCOMPtr promptService = do_GetService("@
> mozilla.org/embedcomp/prompt-service;1"));
>  promptService->Alert(NULL, NULL, NULL);
>
> I`m getting the following error during linking, that comes because of the
> different coding convention between VS and mingw/gcc on windows.
>
> C:/download/xulrunner-41.0b9.en-US.win64.sdk/xulrunner-sdk/include/nsCOMPtr.h:514:
> undefined reference to
> `nsCOMPtr_base::assign_from_gs_contractid(nsGetServiceByContractID, nsID
> const&)'
>
> Am Montag, 7. März 2016 18:50:36 UTC+1 schrieb Benjamin Smedberg:
> > On 3/7/2016 11:17 AM, Tobias Wolf wrote:
> > > I try to call this code dynamically:
> > >
> > > nsCOMPtr promptService = do_GetService("@
> mozilla.org/embedcomp/prompt-service;1"));
> > > promptService->Alert(NULL, NULL, NULL);
> > >
> > > I do the following:
> > >
> > > nsISomeInterface* mXPTCStub;
> > > nsresult rc;
> > > nsXPTCVariant params[3];
> >
> > Why are you trying to do this? Are you writing a shim layer that
> > connects some other dynamic/scripting language to XPCOM?
> >
> > >
> > > rc = NS_GetXPTCallStub(NS_IPROMPTSERVICE_IID, proxy, &mXPTCStub);
> > >
> > > params[0].val.p = NULL;
> > > params[0].type = nsXPTType::T_VOID;
> > > params[0].flags = 0;
> > >
> > > params[1].val.p = (void*)title;
> > > params[1].type = nsXPTType::T_CHAR_STR;
> > > params[1].flags = 0;
> > >
> > > params[2].val.p = (void*)text;
> > > params[2].type = nsXPTType::T_CHAR_STR;
> > > params[2].flags = 0;
> > >
> > > rc = NS_InvokeByIndex(mXPTCStub, 1, 3, params);
> > > NS_DestroyXPTCallStub(mXPTCStub);
> > >
> > > But I don`t know how to use NS_GetXPTCallStub!
> > > What means the second and third parameter from NS_GetXPTCallStub?
> >
> > Have you read the doccomments at
> >
> http://mxr.mozilla.org/mozilla-central/source/xpcom/reflect/xptcall/xptcall.h#174
> > ?
> >
> > If you are trying to *invoke* a method, you don't need an xptcall stub
> > at all. You just need NS_InvokeByIndex.
> >
> > An XPTCall stub is used to *implement* an XPCOM object whose
> > type/interface definition isn't known at compile time, typically by
> > mirroring it to an underlying scriptable object. You would need to
> > implement a c++ class which implements nsIXPTCProxy and implements
> > CallMethod.
> >
> > --BDS
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Kyle Huey]

On Fri, Mar 11, 2016 at 2:03 AM, Benjamin Smedberg 
wrote:

> This is notice of an intent to deprecate support within Firefox for the
> following old versions of MacOS: 10.6, 10.7, and 10.8
>
> The motivation for this change is that we have continued failures that are
> specific to these old operating systems and don't have the resources on
> engineering teams to prioritize these bugs. Especially with the deployment
> of e10s we're seeing intermittent and permanently failures on MacOS 10.6
> that we are not seeing elsewhere. We get very little testing of old MacOS
> versions from our prerelease testers and cannot dedicate much paid staff
> testing support to these platforms. We also have an increasingly fragile
> set of old hardware that supports automated tests on 10.6 and do not intend
> to replace this.
>
> This will affect approximately 1.2% of our current release population.
> Here are the specific breakdowns by OS version:
> 10.6
> 0.66%
> 10.7
> 0.38%
> 10.8
> 0.18%
>
> The final timeframe for this deprecation has not been finalized, but the
> current proposal is to remove support in Firefox 46. We will try and update
> existing users on old MacOS versions to the Firefox 45 ESR release stream,
> so that they stay with security update support through the end of 2016.
>
> Because of the ESR update window, I would like to finalize this decision
> by Monday. If you have questions or concerns about this plan, please reply
> to the firefox-dev mailing list immediately. Jeff Griffiths will be working
> with our communications team to coordinate more public communications such
> as post to the Future of Firefox blog.
>
> --BDS
>

Why can't we just not ship e10s to these users?  We have a number of other
populations we're not shipping to, at least for now.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Kyle Huey]

On Fri, Mar 11, 2016 at 4:28 PM, Terrence Cole  wrote:

> We need to drop support for OSX 10.8 and Windows Vista yesterday, not next
> year. We need to cut our losses and ship E10S while we're still relevant.
> We need to be the browser that works best on Android and Windows 10, not
> the browser that happens to already be installed.
>

You do realize that you're talking about throwing away nearly 20% of our
user base, right?

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: On nsICancelableRunnable (or how bad decisions come back to haunt you)

[Kyle Huey]

On Fri, Mar 11, 2016 at 7:04 AM, Gabriele Svelto 
wrote:

>  Many moons ago, while we were frantically trying to make Firefox OS 1.0
> run half-decently, I introduced a derived class of nsIRunnable that
> could be canceled: nsICancelableRunnable. As with many other things that
> led to the first release of FxOS this was done in a rush and without
> much thinking. It's only goal at the time was to allow me to cancel a
> single, simple, stateless runnable that could take a while to run.
>
> Thinking about it afterwards I came to the conclusion that this was a
> terrible approach: implementing the Cancel() method was up to the user
> and there was no telling on which threads Run() and Cancel() could be
> called making it potentially racy. So I thought it could be replaced by
> adding a Cancel() method to the event queue that would just remove the
> event in a thread-safe way. This seemed a cleaner, safer approach.
>
> But then I looked into our code and discovered that
> nsICancelableRunnable has spread like a disease through the codebase and
> it's systematically used in workers to let us cancel events posted to
> them. Ouch. Some of its uses highlight its problems: in some cases its
> only purpose is to force calling the Run() method by the calling thread
> so that certain objects get destroyed on that thread (possibly to
> prevent leaks). In other cases we have patterns like this:
>
> Run() {
>   if (mDoSomething) {
> DoSomething();
>   }
> }
>
> Cancel() {
>   mDoSomething = false;
> }
>
> Which is fine if both methods are called by the same thread, but most
> likely not if they're called on different threads and the interface
> itself does nothing to prevent you from doing it.
>
> All in all I'd still like to get rid of it but I'm not sure if my
> original approach of moving the cancel functionality into the EventQueue
> is the right way to go. Which leads me to the point of this e-mail: to
> gather feedback on my idea to get rid of it. Since I don't have enough
> knowledge about all the affected areas I'd like to hear from those who
> actually used it.


On workers Run and Cancel are always called by the same thread, so there is
no race.

Much of the "disease" you see is simply support for DOM worker threads,
because every runnable that can run on those threads must be cancelable.
Workers do not guarantee one of the invariants that other XPCOM threads do:
that every runnable is eventually run after being successfully dispatched.
Instead we guarantee that every runnable is either Run() or Cancel()ed.

The disadvantage of pushing this into the event queue is that today
runnables that are dispatched from other threads to workers *must*
implement nsICancelableRunnable, which means authors of code that runs on
workers must think about this.  We do already have an exception for
NS_DispatchToCurrentThread though (via ExternalRunnableWrapper), so this
may be something we can relax.  It would generally require us to write
cleanup code (for the existing runnables and any future ones) to run from
destructors, and historically destructors could run on either the
dispatching thread or the executing thread (although that has changed
somewhat.)

Regardless, your plan should probably involve me ;)

- Kyle

PS. Subscribe to the mailing list so you don't get caught in moderation.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: revisit and implement navigator.hardwareConcurrency

[Kyle Huey]

On Mon, Mar 14, 2016 at 2:30 PM, Ehsan Akhgari 
wrote:

> On 2016-03-14 3:23 PM, Boris Zbarsky wrote:
> > On 9/8/15 3:21 PM, Luke Wagner wrote:
> >> On a more technical detail: WebKit and Chromium have both shipped,
> >> returning the number of logical processors where WebKit additionally
> >> clamps to 2 (on iOS) or 8 (otherwise) [6] which is explicitly allowed
> >> by WHATWG text [7].  I would argue for not clamping (like Chrome),
> >
> > Given the use cases, should we clamp to our per-origin limit?
>
> I brought this up in an in person meeting about this a while ago.  It
> seems pretty hard to justify returning a number more than our per-origin
> worker limit.  To be clear, this will be a clamping different to what
> WebKit does.
>

That number is 20 or 50 or something like that though.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: The convention to pass a parameter when ownership transfer is optional

[Kyle Huey]

Conceptually already_AddRefed is a move reference.  And it's destructor
asserts (in debug builds) that the reference was indeed moved, so it cannot
be used as a conditional transfer under any circumstances.

- Kyle

On Thu, Mar 17, 2016 at 8:07 PM,  wrote:

>
> https://hg.mozilla.org/mozilla-central/file/3e04659fdf6aef792f7cf9840189c6c38d08d1e8/mfbt/UniquePtr.h#l182
>
> "To unconditionally transfer ownership of a UniquePtr into a method, use a
> |UniquePtr| argument.  To conditionally transfer ownership of a resource
> into a method, should the method want it, use a |UniquePtr&&| argument."
>
> Does that also apply to already_AddRefed<>&& or we stick to
> https://bugzilla.mozilla.org/show_bug.cgi?id=1247972#c19?
>
> Btw, we have some code like
> https://hg.mozilla.org/mozilla-central/file/3e04659fdf6aef792f7cf9840189c6c38d08d1e8/dom/base/WebSocket.cpp#l2790
> where it really should be just already_AddRefed<> since the ownership is
> always transferred.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Introducing MOZ_ALWAYS_SUCCEEDS

[Kyle Huey]

For when you are too lazy to type MOZ_ALWAYS_TRUE(NS_SUCCEEDS(foo)).

This was added in bug 1259294, which merged to mozilla-central this morning.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Removing the Chromium event loop

[Kyle Huey]

In the department-of-paying-down-technical-debt, I'm planning to remove
much of the Chromium event loop over the next few months. You can follow
along in bug 1260828.

The rough outline:

Step 1: Replace Task with nsIRunnable, without changing any other
semantics.  This will happen in late April, after Gecko 48 branches.
Step 2: Either remove PostDelayedTask, or reimplement its semantics in
nsThread.
Step 3: Remove Chromium event loops using TYPE_DEFAULT and
TYPE_MOZILLA_NONMAINTHREAD. These are the simplest cases, because
TYPE_DEFAULT runs a Chromium Tasks only event loop, and
TYPE_MOZILLA_NONMAINTHREAD just glues delayed and idle tasks into the
normal XPCOM event loop.
Step 4: Tackle TYPE_MOZILLA_PARENT and TYPE_MOZILLA_CHILD. These run the
main threads of parent and content processes respectively, and aren't much
harder than step 3.

The other types (TYPE_UI, TYPE_IO, and TYPE_MOZILLA_NONMAINUITHREAD)
involve varying levels of platform specific event loop or API integration
that will probably be more difficult to untangle. They also won't block my
long-term desire to build a scheduler for Gecko, so are lower priority.

If you have objections, speak now or forever hold your peace.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing the Chromium event loop

[Kyle Huey]

On Wed, Mar 30, 2016 at 11:34 AM, Benjamin Smedberg 
wrote:

> I support this plan!
>
> Mostly.
>
> I've been unhappy with the fact that our event loop uses refcounted
> objects by default. *Most* runnables are pure-C++ and really don't need to
> be refcounted/scriptable.
>
> I'm asking you to consider unifying these two things by making our event
> loop work more like chromium and just using c++ objects without a refcount
> by default? Then to post a scriptable event to an event loop you'd have to
> have it own a separate scriptable object.
>
> If that sounds like too much churn for your project, then please proceed
> with your original plan!
>
> --BDS
>

Well, it's obviously easier to move from new/delete to refcounted than the
reverse ... is there a reason to believe it's actually worth the cost of
de-refcountifying all the runnables in Gecko?

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing the Chromium event loop

[Kyle Huey]

On Wed, Mar 30, 2016 at 1:11 PM, Nathan Froyd  wrote:

> On Wed, Mar 30, 2016 at 2:34 PM, Benjamin Smedberg
>  wrote:
> > I've been unhappy with the fact that our event loop uses refcounted
> objects
> > by default. *Most* runnables are pure-C++ and really don't need to be
> > refcounted/scriptable.
>
> I've been thinking about this too.  gfx has a separate thread pool
> that was created partly because of the desire to be Gecko-free and
> partly because of the overhead that nsIRunnable has.  It would be nice
> to eliminate one of those objections.  Making this change would also
> bring down bloat from vtables and essentially-useless methods.
>

Frankly, I think this is an ex-post-facto rationalization for not liking
nsIRunnable because it's XPCOMy/not new and shiny/etc. We had this same
problem with many of the same people and the same justifications with the
mfbt RefCounted class that turned out to be a nightmare to untangle.  Turns
out things our boring old stuff had like leak checking were actually
useful!  Who could have guessed?

Unless they have actual evidence showing this matters I don't care about
their objections.

*shots_fired.jpg*

> I'm asking you to consider unifying these two things by making our event
> > loop work more like chromium and just using c++ objects without a
> refcount
> > by default? Then to post a scriptable event to an event loop you'd have
> to
> > have it own a separate scriptable object.


I'll pose to you the same question I posed bsmedberg, is this actually
worth fiddling with all the existing runnables.  It's not just scriptable
stuff that needs to be changed.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing the Chromium event loop

[Kyle Huey]

On Thu, Mar 31, 2016 at 6:43 AM, Nathan Froyd  wrote:

> On Thu, Mar 31, 2016 at 8:08 AM, Gabriele Svelto 
> wrote:
> > On this topic, did anyone experiment with trying to lighten the
> > synchronization burden when handling nsEventQueues? Both nsThread and
> > nsThreadPool acquire a mutex each time we need to get the next runnable;
> > we could pull out all pending runnables every time we acquire the lock
> > (up to a predefined maximum) to amortize the synchronization cost. In my
> > measurements mutex-handling was also quite expensive on low-end ARM
> > cores, not so much on x86 as long as the mutex was not contended.
>
> There was some optimization work done in bug 1195767 and bug 1202497
> to reduce the amount of locking we do for both nsThreadPool and
> nsThread, respectively, and to use signaling on internal condition
> variables rather than broadcast.  I know the changes were significant
> in the case of nsThreadPool on some platforms; in the nsThread case we
> are obviously doing less work, but I didn't try to measure the
> savings.  I don't think we've experimented with trying to pull out
> multiple events per lock acquisition (which sounds pretty tricky to do
> such that you're actually saving work).


That sounds very difficult to do if the event loop gets spun.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing the Chromium event loop

[Kyle Huey]

On Thu, Mar 31, 2016 at 3:19 AM, Honza Bambas  wrote:

> On 3/30/2016 20:21, Kyle Huey wrote:
>
>> In the department-of-paying-down-technical-debt, I'm planning to remove
>> much of the Chromium event loop over the next few months. You can follow
>> along in bug 1260828.
>>
>> The rough outline:
>>
>> Step 1: Replace Task with nsIRunnable, without changing any other
>> semantics.  This will happen in late April, after Gecko 48 branches.
>> Step 2: Either remove PostDelayedTask, or reimplement its semantics in
>> nsThread.
>> Step 3: Remove Chromium event loops using TYPE_DEFAULT and
>> TYPE_MOZILLA_NONMAINTHREAD. These are the simplest cases, because
>> TYPE_DEFAULT runs a Chromium Tasks only event loop, and
>> TYPE_MOZILLA_NONMAINTHREAD just glues delayed and idle tasks into the
>> normal XPCOM event loop.
>> Step 4: Tackle TYPE_MOZILLA_PARENT and TYPE_MOZILLA_CHILD. These run the
>> main threads of parent and content processes respectively, and aren't much
>> harder than step 3.
>>
>> The other types (TYPE_UI, TYPE_IO, and TYPE_MOZILLA_NONMAINUITHREAD)
>> involve varying levels of platform specific event loop or API integration
>> that will probably be more difficult to untangle. They also won't block my
>> long-term desire to build a scheduler for Gecko, so are lower priority.
>>
>> If you have objections, speak now or forever hold your peace.
>>
>
> Few questions:
>
> - how will this impact the IPC pumping that is based on Tasks?
>

It will be changed to not use Tasks.


> - do you have more details/ideas/bugs about your scheduler?  I may have
> similar thoughts, like adding priorities to (not only) main thread events.
> Backtrack (bug 1148204) should give hints (at least) how such a scheduler
> should behave and check if does what we want.
>

At a very high level, there will be an event queue per global and we'll
prioritize the queues for things in the foreground.  There are also
opportunities to prioritize within a given queue, according to the HTML
spec, but it's not clear how much of that is web compatible.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Crash signature change: signatures now include abort messages

[Kyle Huey]

Does this catch MOZ_RELEASE_ASSERT and similar?  It would be nice to
distinguish those somehow in crash-stats.

- Kyle

On Wed, Apr 6, 2016 at 2:18 PM, Benjamin Smedberg 
wrote:

> A change just landed which will change the way crash signatures are
> computed for intentional aborts. Previously the crash signature would be
> "NS_DebugAbort | ". Now the signature will be "Abort |  message up to 80 chars> | ".
>
> This should make it much easier to distinguish various classes of abort.
>
> Thanks to Adrian Gaudebert for taking this in bug 803779!
>
> --BDS
>
> --
> Benjamin Smedberg
> Engineering Manager, Firefox
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Treat cookies set over non-secure HTTP as session cookies

[Kyle Huey]

Why should we be the ones to take the web compat hit on this?

- Kyle
On Apr 14, 2016 1:55 AM, "Chris Peterson"  wrote:

> Summary: Treat cookies set over non-secure HTTP as session cookies
>
> Exactly one year ago today (!), Henri Sivonen proposed [1] treating
> cookies without the `secure` flag as session cookies.
>
> PROS:
>
> * Security: login cookies set over non-secure HTTP can be sniffed and
> replayed. Clearing those cookies at the end of the browser session would
> force the user to log in again next time, reducing the window of
> opportunity for an attacker to replay the login cookie. To avoid this,
> login-requiring sites should use HTTPS for at least their login page that
> set the login cookie.
>
> * Privacy: most ad networks still use non-secure HTTP. Content sites that
> use these ad networks are prevented from deploying HTTPS themselves because
> of HTTP/HTTPS mixed content breakage. Clearing user-tracking cookies set
> over non-secure HTTP at the end of every browser session would be a strong
> motivator for ad networks to upgrade to HTTPS, which would unblock content
> sites' HTTPS rollouts.
>
> However, my testing of Henri's original proposal shows that too few sites
> set the `secure` cookie flag for this to be practical. Even sites that
> primarily use HTTPS, like google.com, omit the `secure` flag for many
> cookies set over HTTPS.
>
> Instead, I propose treating all cookies set over non-secure HTTP as
> session cookies, regardless of whether they have the `secure` flag. Cookies
> set over HTTPS would be treated as "secure so far" and allowed to persist
> beyond the current browser session. This approach could be tightened so any
> "secure so far" cookies later sent over non-secure HTTP could be downgraded
> to session cookies. Note that Firefox's session restore will persist
> "session" cookies between browser restarts for the tabs that had been open.
> (This is "eternal session" feature/bug 530594.)
>
> To test my proposal, I loaded the home pages of the Alexa Top 25 News
> sites [2]. These 25 pages set over 1300 cookies! Fewer than 200 were set
> over HTTPS and only 7 had the `secure` flag. About 900 were third-party
> cookies. Treating non-secure cookies as session cookies means that over
> 1100 cookies would be cleared at the end of the browser session!
>
> CONS:
>
> * Sites that allow users to configure preferences without logging into an
> account would forget the users' preferences if they are not using HTTPS.
> For example, companies that have regional sites would forget the user's
> selected region at the end of the browser session.
>
> * Ad networks' opt-out cookies (for what they're worth) set over
> non-secure HTTP would be forgotten at the end of the browser session.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1160368
>
> Link to standard: N/A
>
> Platform coverage: All platforms
>
> Estimated or target release: Firefox 49
>
> Preference behind which this will be implemented:
> network.cookie.lifetime.httpSessionOnly
>
> Do other browser engines implement this? No
>
> [1]
> https://groups.google.com/d/msg/mozilla.dev.platform/xaGffxAM-hs/aVgYuS3QA2MJ
> [2] http://www.alexa.com/topsites/category/Top/News
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Moving XP to ESR?

[Kyle Huey]

12% of our users are on Windows XP.

- Kyle

On Mon, Apr 18, 2016 at 6:04 AM, Henri Sivonen  wrote:

> XP has now gone for two years without security patches from Microsoft.
> Additionally, as of its latest release, Chrome no longer supports XP.
>
> When 46 ships, it would be a great time to make AUS advertise 45 ESR
> builds to XP (even on non-ESR) channel. This would keep XP supported
> through the ESR cycle but would put an end to the XP tax on trunk.
>
> Are we already on track to doing this? If not, why not?
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Moving XP to ESR?

[Kyle Huey]

On Tue, Apr 19, 2016 at 1:20 PM, Ted Mielczarek  wrote:

> On Tue, Apr 19, 2016, at 04:14 PM, Nils Ohlmeier wrote:
> > The good news is that dxr does not find anything using IsXPSP3OrLater().
> > But this looks like we have a bit of version specific code in our tree:
> >
> https://dxr.mozilla.org/mozilla-central/search?q=XP_WIN&redirect=false&case=true
>
> FYI, the "XP" here means "cross-platform", and XP_WIN is set whenever
> we're building for Windows.
>
>
> > And on top of that come the costs for maintaining XP machines as part of
> > the treeherder setup.
> >
> > So it is not easy to quantify, but there is a “XP tax” we pay.
>
> This is true. We hit this with toolchain support, we're actively jumping
> through hoops to continue targeting XP with newer versions of MSVC.


We jump through some hoops to support things like Linux and Mac too, and
those platforms combined have far fewer users than XP.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: use nsresult& outparams in constructors to represent failure

[Kyle Huey]

On Wed, Apr 20, 2016 at 9:52 PM, Kris Maglione 
wrote:

> On Thu, Apr 21, 2016 at 02:10:59PM +1000, Nicholas Nethercote wrote:
>
>> On Thu, Apr 21, 2016 at 1:23 PM, Kris Maglione 
>> wrote:
>>
>>>
>>> If we do this, can we please use |nsresult*| rather than |nsresult&|?
>>>
>>
>> I prefer a reference because of the guarantee of non-nullness. But I
>> could live with a pointer if people think it's better.
>>
>
> There isn't a strict guarantee of non-nullness for reference parameters.
> This is an extreme example, but technically valid:
>
>  T th(*(nsresult*)0);
>

IIRC this is undefined behavior, so when you do this the compiler is
allowed to format your hard drive.

Or, somewhat more likely, a function which already takes a |nsresult*|
> argument might do:
>
>  T th(*aRv);
>
> I suppose either of those are less likely than someone passing |nullptr|,
> but if we really want to guarantee non-nullness, we can do that easily
> enough with a template type like GSL's |non_null|.
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

nsRunnable is now mozilla::Runnable on trunk

[Kyle Huey]

Sometime later this week Task will become Runnable too.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Static analysis for "use-after-move"?

[Kyle Huey]

Can we catch this pattern with a compiler somehow?

Foo foo;
foo.x = thing;
DoBar(mozilla::Move(foo));
if (foo.x) { /* do stuff */ }

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

NS_New*RunnableMethod* -> New*RunnableMethod

[Kyle Huey]

NS_NewRunnableMethod has been replaced with mozilla::NewRunnableMethod.
NS_NewRunnableMethodWithArg[s] has also been collapsed into
mozilla::NewRunnableMethod.  It also now returns an already_AddRefed.

The Chromium versions of these methods have been removed.

NS_NewRunnableFunction still survives, but at some point it will be changed
too.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: MOZ_WARN_UNUSED_RESULT has been renamed as MOZ_MUST_USE

[Kyle Huey]

On Fri, Apr 29, 2016 at 1:46 PM, Chris Peterson 
wrote:

> On 4/29/16 5:53 AM, Nathan Froyd wrote:
>
>> This is a noble goal, but there is an enormous amount of code that
>> would need to be modified to make this feasible.  Perhaps if you
>> exempted nsresult from MOZ_MUST_USE types.
>>
>
> In theory, nsresult seems like an important type to check.
>
> That said, I once tried building Gecko with `#define NS_IMETHOD
> MOZ_WARN_UNUSED_RESULT NS_IMETHOD_(nsresult)`. There were over 10,000
> warnings for XPCOM method callers not checking nsresult return values, so
> this approach does not seem practical. :(


nsresult is required in a lot of method signatures (thanks XPIDL!) which
makes it often not an important type to check.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to deprecate: MacOS 10.6-10.8 support

[Kyle Huey]

On Thu, May 5, 2016 at 8:23 PM,  wrote:

> On Tuesday, May 3, 2016 at 8:32:26 PM UTC-7, Lawrence Mandel wrote:
> > On Tue, May 3, 2016 at 11:11 PM, Xidorn Quan 
> wrote:
> >
> > > On Wed, May 4, 2016 at 9:46 AM, Lawrence Mandel 
> > > wrote:
> > >
> > >> On Tue, May 3, 2016 at 6:56 PM, Mike Hommey  wrote:
> > >>
> > >> > On Tue, May 03, 2016 at 05:18:17PM -0500, Adam Roach wrote:
> > >> > > On 5/3/16 4:59 PM, Justin Dolske wrote:
> > >> > > > On 5/3/16 12:21 PM, Gregory Szorc wrote:
> > >> > > >
> > >> > > > > * The update server has been reconfigured to not serve Nightly
> > >> > > > > updates to
> > >> > > > > 10.6-10.8 (bug 1269811)
> > >> > > >
> > >> > > > Are we going to be showing some kind of notice to affected users
> > >> upon
> > >> > > > Release? That is, if I'm a 10.6 user and I update to Firefox
> 48, at
> > >> > some
> > >> > > > point should I see a message saying I'll no longer receive
> future
> > >> > > > updates?
> > >> > >
> > >> > > Even better, is there any way to get the update system to
> > >> automatically
> > >> > move
> > >> > > such users over to 45ESR?
> > >> >
> > >> > Did we introduce changes to profile data between 45 and 48? Because
> > >> > that usually breaks downgrade paths.
> > >> >
> > >>
> > >> We discussed this earlier and decided that we were not going to
> > >> automatically move users from Firefox to ESR. For one thing, the user
> has
> > >> not opted to be on this channel. A channel change also involves both
> > >> engineering and test work. It does seem prudent to test the scenario
> to
> > >> know whether users can move from 47 to ESR 45.2.0 without issue.
> > >
> > >
> > > Is it feasible to make 48 an ESR as well so that we don't need to ask
> > > users to downgrade it to ESR 45?
> > >
> >
> > I don't think so. I also don't know that we're going to recommend that
> > users migrate to ESR (need to verify that there are no incompatible
> profile
> > changes) although that is certainly an option.
> >
> > Lawrence
>
> (Note: Please see "OSX Support Cycle" below.)
>
> These are important decisions. However, expecting all end-users to be able
> to handle a manual migration to ESR, or understand what is happening or why
> is somewhat flawed. I believe downgrading should NOT be considered as an
> option, except for tech savvy users.
>
> The best option, from my perspective (supporting a wide array of users, OS
> versions, hardware), is to make the final 10.6-10.8 version be (or become)
> the next ESR with a startup page providing them with the choice and action
> buttons/links. Subsequent startups would load follow-up startup pages with
> the appropriate reminders.
>
> The pages should explain very simply and succinctly that no new features
> will be coming and only security updates/patches will be made until "X"
> date when support ends (but the browser will still be usable). The first
> page should be VERY overt and obnoxious. The 2nd, 3rd, etc. can be more
> like what Google Chrome did recently (ie. notice bar at top of the content
> area).
>
> SIDEBAR: "OSX Support Cycle"
>
> While we are on this subject, what is the plan for Firefox support of 10.9
> later this year when Apple pushes out its latest OSX? How about a year from
> now when 10.10 support ends? Where does the annual Firefox/OSX support
> depreciation end?
>
> Apple has shifted to warp speed with their rapid release cycle. Every
> version of Windows has a minimum 10 year support lifecycle (security
> patches, etc.) OSX now has 3.
>
> If Mozilla and other developers simply follow Apple's "not supported"
> timeline, there will be a growing number of end users who will be left out.
> Where do you think they will go? If they migrate to Windows there is a much
> greater chance they will stick with Edge or whatever is there and leave
> Firefox behind.
>

We *don't* follow Apple's timeline though.  Snow Leopard was dropped by
Apple back in 2013.  Mozilla's decisions are driven by considering, among
other factors, how many users remain on that platform and the engineering
difficulty of continuing to support it.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Reverting to VS2013 on central and aurora

[Kyle Huey]

I think we should strongly consider just requiring SSE at this point.

- Kyle

On Fri, May 6, 2016 at 7:10 AM, Mike Hoye  wrote:

> On 2016-05-06 12:26 AM, Gregory Szorc wrote:
>
>> FWIW, the crashes we've seen so far are from incorrectly emitted movss
>> instructions. This instruction is part of the original SSE instruction
>> set,
>> which was initially unveiled by Intel on the Pentium 3 in 1999 and later
>> by
>> AMD on the Duron and Athlon XP in 2000-2001. I'm not sure why we still
>> need
>> Firefox to run on processors manufactured in the 90s.
>>
> Per an IRC conversation with chutten, Firefox users on CPUs that do not
> support SSE are 0.015% of our user base. (compared to 0.4% for no-SSE2). A
> third of those are on otherwise-unsupported configurations (pre-SP3 XP,
> etc), this work provides continuity of support to 0.01% of our users.
>
> - mhoye
>
>
> 09:59  So, to put it clearly and precisely, of the Firefox
> Population in release and beta who are reporting at least base telemetry
> collection on machines running supported configurations, only 0.01% cannot
> definitively say they have SSE.
> 10:00  (according to a 1% random sample as stored in the
> longitudinal dataset)
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Ignoring viewpoints of non-Mozilla-employees can't be the way to go for a OSS project!

[Kyle Huey]

Because you are *still* (as of 10 minutes ago) removing the off-topic
labels that were applied to clearly off-topic comments I have temporarily
removed your editbugs permissions.

- Kyle

On Mon, May 9, 2016 at 11:23 AM, Tobias B. Besemer <
tobias.bese...@googlemail.com> wrote:

> Hi!
>
> Ignoring viewpoints of non-Mozilla-employees can't be the way to go for a
> OSS Project!
> The same mistake made Oracle with OpenOffice!
> Now the project is almost death!
> Think Mozilla should find his way back to his roots!
> Would be nice, if some people think about it!
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1114647
> I removed the marker that my comments are "Offtopic" ... (because I write
> my viewpoint to this topic!)
> ...and re-opened my attachment!
> Even if the employees are not interested how other OSS-Geeks see things
> that belong to the integration for Mozilla Products into Windows, this
> opinions of not-employees are anyway not "Offtopic", or "Spam"!
>
>
> Greets, Tobias.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Is Telemetry::Accumulate threadsafe?

[Kyle Huey]

And if not, why is this not documented?

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is Telemetry::Accumulate threadsafe?

[Kyle Huey]

Ok.
https://treeherder.mozilla.org/logviewer.html#?job_id=27652194&repo=mozilla-inbound#L9753
seems to indicate that it is not currently threadsafe, but 1258183 adds a
lot of locks so hopefully that will help.

- Kyle

On Wed, May 11, 2016 at 11:46 AM, Georg Fritzsche 
wrote:

> Bug 1141565 made it thread-safe, bug 1258183 is dealing with some
> remaining TSan issues.
>
> Georg
>
> On Wed, May 11, 2016 at 7:23 PM, Kyle Huey  wrote:
>
>> And if not, why is this not documented?
>>
>> - Kyle
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Updating 32-bit Windows users to 64-bit Windows builds?

[Kyle Huey]

On Thu, May 12, 2016 at 2:46 PM, Karl Tomlinson  wrote:

> Lawrence Mandel writes:
>
> > Do we need this criteria?
> >
> > RAM - Does it hurt to move an instance that has <4GB?
>
> Yes.  OOM will be more common with 64-bit builds on systems with
> less RAM because 64-bit builds use more memory.
>

Our OOM crashes are almost always from running out of virtual memory, not
physical.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Chromium and XPCOM event queues are now unified

[Kyle Huey]

On inbound (and soon central), for Chromium MessageLoops that belong to an
XPCOM thread (either the main thread, or created via the thread manager)
posting tasks now calls through to the underlying XPCOM thread's dispatch
implementation.  This could cause subtle breakage because event ordering
has changed, so if you see weirdness starting today please let me know,
particularly if its in APZ, plugins, or media, which make the heaviest use
of the chromium event queue.

You can check out bug 1269056 for more details.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows 7 tests in AWS

[Kyle Huey]

On Fri, May 13, 2016 at 11:07 AM, Chris AtLee  wrote:

> I'm very happy to let you know that we've recently started running some of
> our Windows 7 tests in AWS. Currently we're running these suites in Amazon
> for all branches of gecko 49 and higher:
> * Web platform tests + reftests
> * gtest
> * cppunit
> * jittest
> * jsreftest
> * crashtest
>
> Since these are now working in AWS, it means we can scale up the number of
> machines with load. This should mean a big improvement in getting test
> results back for Windows 7!
>

<3


> Work is being tracked in
> https://bugzilla.mozilla.org/show_bug.cgi?id=1271355.
>
> If you find any issues, please reach out in #releng, or file a bug and link
> it to the one above.
>
> Thanks in particular to jmaher and Q for helping to get this work done.
>
> Cheers,
> Chris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to name our JSContext getter(s): let the bikeshed begin

[Kyle Huey]

Do we really need the ForThread part?  Is the long term plan to merge
JSRuntime and JSContext, or are they going to remain distinct
indefinitely?

- Kyle

On Sun, May 29, 2016 at 6:10 PM, Boris Zbarsky  wrote:
> We currently have the following functions in nsContentUtils for getting
> various JSContexts:
>
> GetSafeJSContext()
> GetDefaultJSContextForThread()
> RootingCx()
> RootingCxForThread()
>
> We also have workers::GetCurrentThreadJSContext() for use on workers only.
>
> Now that we're about to move to only having one JSContext per thread (see
> bug 1276276) I think we should do some consolidating and renaming here.  In
> particular, we should stash the unique JSContext for the thread in the
> CycleCollectedJSRuntime and have only one accessor to get it, which goes
> through CycleCollectedJSRuntime::Get().  This does mean a TLS lookup in some
> cases in which right now we just do a pointer-chase, but has the benefit of
> simplicity.  And if we ever add non-worker threads with DOM stuff on them
> (which we're talking about anyway), we'd want this no matter what.
>
> My proposal is that we name this accessor something like
> JSContextForThread().  We can put this in nsContentUtils, in the
> "mozilla::dom' namespace, or the "xpc" namespace...  I don't have a strong
> preference here.
>
> If we _really_ want to we can keep a RootingCxForThread() around which
> returns exactly the same thing as JSContextForThread() but makes it clear
> that we plan to use it for rooting only.  I think we should nix RootingCx().
>
> Thoughts?
>
> -Boris
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to name our JSContext getter(s): let the bikeshed begin

[Kyle Huey]

On Sun, May 29, 2016 at 6:21 PM, Boris Zbarsky  wrote:
> On 5/29/16 6:17 PM, Kyle Huey wrote:
>>
>> Do we really need the ForThread part?
>
>
> I wanted to make it clear that we're getting something that's OK to use
> without synchronization, but maybe that's redundant and we can just have a
> dom::GetJSContext() or something.  dom::JSContext() would have ambiguity
> issues, of course.  I don't have super-strong opinions here.
>
>> Is the long term plan to merge
>> JSRuntime and JSContext, or are they going to remain distinct
>> indefinitely?
>
>
> Unclear.  See discussion the SpiderMonkey folks are having starting at
> https://bugzilla.mozilla.org/show_bug.cgi?id=650361#c27

Segregating the thread-specific and thread-agnostic parts into
separate classes seems like a good idea.

Given that it only makes sense to use a thread-specific object on that
thread, and it only makes sense to get the thread-agnostic object here
*from TLS* on one thread, I don't think we need any "thread" naming.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Non-standard stuff in the /dom/ directory

[Kyle Huey]

On Tue, Aug 16, 2016 at 8:56 PM,   wrote:
> I'm wondering, would it be worth while cleaning up the dom/ directory to move 
> non-standard stuff out of there?
>
> There is a bunch of legacy stuff from B2G that could be moved out to, say, 
> b2g/apis or some such for historical reasons.
>
> It would make searching/working-with for standardized DOM related stuff much 
> easier.

s/moved out/deleted/

This is a complicated subject caught in a variety of internal
politics.  I suggest you raise it with your management chain ;)

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Getting rid of already_AddRefed?

[Kyle Huey]

On Mon, Sep 12, 2016 at 10:53 AM, Daniel Holbert  wrote:
> On 08/12/2014 07:59 AM, Benjamin Smedberg wrote:
>> But now that nsCOMPtr/nsRefPtr support proper move constructors, [...]
>> Could we replace every already_AddRefed return value with a nsCOMPtr?
>
> I have a variant of bsmedberg's original question here. He asked about
> return values, but I'm wondering:
> Could we replace every already_AddRefed *function-parameter* with a move
> reference to a RefPtr/nsCOMPtr?
>
> (Sorry if this was answered in this thread; I skimmed through it &
> didn't find a definitive answer immediately. It seems like this might be
> a strictly easier thing to fix up, as compared to return values.)
>
> As a concrete example, at this usage site...
> https://dxr.mozilla.org/mozilla-central/rev/1851b78b5a9673ee422f189b92e5f1e86b82a01c/dom/base/nsDOMMutationObserver.h#468
> ...is there any benefit to us using
> already_AddRefed&& aOwner, instead of
> nsCOMPtr&&?
>
> (I believe we have the "already_AddRefed as a parameter" pattern in our
> code in order to avoid an extra addref/release when ownership is being
> transferred into a function.  But, RefPtr/nsCOMPtr with move references
> would let us do that just as well, more concisely & less arcanely.)

There's an important semantic difference: something that takes a move
reference to a smart pointer is not obligated to accept the reference.
If I do smartptr.forget() I know afterwards that smartptr is empty and
the reference that used to exist in it is Not My Problem (TM), whereas
if I call something with a move reference to smartptr I may have to
handle the error case, depending on what the callee does.

Those sorts of non-local effects, IMHO, make code harder to read.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: removing about:bloat

[Kyle Huey]

On Mon, Oct 10, 2016 at 2:07 PM, Andrew McCreight
 wrote:
> In bug 1308652, I'm planning on removing about:bloat. It disables XPCOM
> leak tracking while it is running, so running it can cause false negative
> leaks (bug 1271182). I don't think anybody uses it much any more, so I'm
> going to remove it.

Wow.  Hats off to you for tracking that down.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows XP and Vista Long Term Support Plan

[Kyle Huey]

On Fri, Oct 21, 2016 at 3:05 AM,   wrote:
> My point for the above paragraph is that even if Mozilla stops security 
> updates for ESR 52, these computers will still need to get around on the 
> Internet. These machines will still need to do log ins and banking. The world 
> isn't the same as back in the day when Netscape 4 roamed the web or even in 
> 2008 when Mozilla dropped support for Windows 98 SE with 2.0.0.20. Part of 
> securing the web means making sure that every server has a digital 
> certificate with Let's Encrypt. But that part only works if the browser has 
> up to date TLS and digital certificates. What happens to Vista and XP on ESR 
> 52 or even OSX 10.6-10.8 on ESR 45 when a POODLE style attack drives everyone 
> from TLS 1.2 to TLS 1.3 with no fall back? What happens when older 
> certificates are found to have been compromised by a third party like a crime 
> syndicate or government intelligence agency? Do ESR 52 and ESR 45 get stuck 
> with corrupted certificates while the latest versions of Firefox get their 
> certificates refresh
 ed
>  ?

No.  These machines should not be on the Internet anymore.  If the
operating system vendor is no longer supporting their product with
security releases an out of date TLS stack is a minor problem compared
to the remote code execution that's going to pwn the machine.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Runnable labeling for Quantum DOM

[Kyle Huey]

On Thu, Dec 1, 2016 at 8:21 PM, Boris Zbarsky  wrote:
> P.S.  This is awesome.  ;)

Indeed.  So glad this is finally happening.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

DOM Bindings Meeting - Monday @ 12:30 PM PST

[Kyle Huey]

Our (ostensibly) weekly DOM bindings meetings continue on Monday February
25th at 12:30 PM PST.

Meeting details:

* Monday, February 25, 2012, 12:30 PM PST (9:30 PM CET)
* Conference room 7-N, San Francisco office, 7th floor.
* Dial-in Info:
 - Vidyo room: SFO-7N
 - In office or soft phone: extension 92
 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
 - Toll-free: 800-707-2533 then password 369
 - Conference num 95704
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Windows 7 Platform Update & June 2010 SDK

[Kyle Huey]

On Wed, Feb 27, 2013 at 5:33 AM, Gian-Carlo Pascutto
wrote:

> Hi all,
>
> just a heads up: the Windows 7 platform update that's being shipped
> today has the following KB article:
> http://support.microsoft.com/kb/2670838?wa=wsignin1.0
>
> Interesting part:
> "If you are a Windows 7 DirectX developer who uses the June 2010 DirectX
> Software Development Kit (SDK), you will have to update your development
> environments after you install this platform update."
>
> As far as I know, we use this for Windows/ANGLE builds. So it's possible
> these may now be broken?
>
> The recommended solution seems to be to use the Win8 SDK, but I
> understood we need specific flags to compile with that.
>
> Can someone who's most familiar with the Windows compiles clear this
> out, and perhaps update the wiki if needed?
>
> --
> GCP
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

For whatever its worth, I did a local build just now after the update with
no problems.  I don't know what "you'll have to update" implies, but the
build appears to run fine.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

DOM Bindings Meeting - Monday @ 12:30 PM PST

[Kyle Huey]

Our (ostensibly) weekly DOM bindings meetings continue on Monday March 4th
at 12:30 PM PST.

Meeting details:

* Monday, March 4, 2012, 12:30 PM PST (9:30 PM CET)
* Conference room 7-N, San Francisco office, 7th floor.
* Dial-in Info:
 - Vidyo room: SFO-7N
 - In office or soft phone: extension 92
 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
 - Toll-free: 800-707-2533 then password 369
 - Conference num 95704
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Turning off window.Components for the web

[Kyle Huey]

On Tue, Mar 5, 2013 at 11:33 AM, Bobby Holley  wrote:

> This makes sense in terms of |if (Components)| browser detection. But if a
> site is grabbing interface constants off of nsIDOMFoo interfaces, it seems
> very unlikely that said site would work in another browser. The other
> problem with shimming in interface constants is that we don't know which
> interfaces to do it for (though we can take an educated guess and do it for
> XHR and a few others).
>

You're clearly not jaded enough if you don't expect websites to do totally
non-standard things that have standard equivalents based on UA
sniffing/browser detection ;-)

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Reminder: NSPR synchronization primitives are not to be used

[Kyle Huey]

This is a friendly reminder that you should not be using NSPR
synchronization primitives in new Gecko code unless you have a very good
reason to.  We built all these nice wrappers on them that provide deadlock
checking, RAII, leak checking, etc. that you should use instead.

Instead of
PRLock - use xpcom/glue/Mutex.h a non-recursive mutex with RAII helpers for
scoped locking/unlocking.
PRCondVar - use xpcom/glue/CondVar.h basically a shim wrapper over PRCondVar
PRLock+PRCondVar - use xpcom/glue/Monitor.h a non-reentrant (i.e. different
from Java) monitor with RAII helpers for scoped locking/unlocking and all
the condvar methods
PRMonitor - use xpcom/glue/ReentrantMonitor.h a reentrant (Java style)
monitor with RAII helpers for scoped locking/unlocking and all the condvar
methods.  You shouldn't use a reentrant monitor unless you absolutely need
it.

All of these wrappers provide deadlock checking, leak checking, RAII
lock/unlock helpers, and methods for asserting ownership or lack there of
on the current thread (in various states of implementation).  Unless there
is an extremely compelling reason Gecko code should be using these and not
raw NSPR synchronization primitives.

Gecko reviewers should be enforcing this.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ChromeWorkers and staying off the Main thread

[Kyle Huey]

On Thu, Mar 14, 2013 at 7:08 AM,  wrote:

> Hi all,
>
> To what extent is the Main thread consumed by a (Chrome)Workers
> postMessage() and onmessage() calls to other Sub(Chrome)Workers?
>
> Specifically, if a sub-worker postMessage()s to it's listening parent
> Worker, and the parent Worker posts back to the sub does this hit the main
> thread significantly?
>
> I'm trying to decide on a design patters as to if it's worth using:
>
> Master
>Worker
>SubWorker
>SubWorker
>SubWorker
>
> vs
>
> Master
>Worker
>Worker
>Worker
>
> If a sub worker can post and receive messages with less performance hit on
> Main, then the overhead of a Worker handler would seem worthwhile.
>
>
> Cheers,
>
> Neil
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

Message passing from a worker to a sub-worker (or vice versa) only involves
the worker thread and the sub-worker thread.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ChromeWorkers and staying off the Main thread

[Kyle Huey]

On Thu, Mar 14, 2013 at 8:31 AM,  wrote:

> On Thursday, 14 March 2013 14:19:57 UTC, Kyle Huey  wrote:
> >
> >
> >
> > Message passing from a worker to a sub-worker (or vice versa) only
> involves
> >
> > the worker thread and the sub-worker thread.
> >
> >
> >
> > - Kyle
>
> Excellent thanks Kyle, that's what I was hoping.
>
>
> Before I go ahead and re-invent the wheel, does anyone know of any message
> routing pattern to effectively marshal a message from one worker back to
> the poster?
>
> The only option I can see is some kind of combination of
> MessageEvent.target.id +MessageEvent.timeStamp and a lookup table to post
> a response back to the correct onmessage handler. Just wondered if there's
> something more elegant I'm missing?
>

Do you have some sort of hierarchy of workers?  If you just have a parent
and a child talking to each other I don't see why you would need to marshal
anything.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

DOM Bindings Meeting - Monday @ 12:30 PM PDT

[Kyle Huey]

Our (ostensibly) weekly DOM bindings meetings continue on Monday March 18th
at 12:30 PM PDT.  Note the time change.

Meeting details:

* Monday, March 18, 2012, 12:30 PM PDT (8:30 PM CET)
* Conference room 7-N, San Francisco office, 7th floor.
* Dial-in Info:
 - Vidyo room: SFO-7N
 - In office or soft phone: extension 92
 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
 - Toll-free: 800-707-2533 then password 369
 - Conference num 95704
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Automatic tree clobbering is coming

[Kyle Huey]

On Fri, Mar 29, 2013 at 9:47 PM, Philip Chee  wrote:

> I'm running Windows7 and the mozilla-build system. We *have* to use
> relative paths because some parts of mozilla-build (I can't remember
> which) would choke on absolute paths.
>

Unless there's some problem with comm-central specifically, this has been
fixed for months (maybe even years).

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

DOM Bindings Meeting - Monday @ 12:30 PM PDT

[Kyle Huey]

Our (ostensibly) weekly DOM bindings meetings continue on Monday April 1st
at 12:30 PM PDT.  Note the time change for Europe.

Meeting details:

* Monday, April 1, 2013, 12:30 PM PDT (9:30 PM CEST)
* Conference room 7-N, San Francisco office, 7th floor.
* Dial-in Info:
 - Vidyo room: SFO-7N
 - In office or soft phone: extension 92
 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
 - Toll-free: 800-707-2533 then password 369
 - Conference num 95704
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

The current state of WARNINGS_AS_ERRORS is untenable

[Kyle Huey]

(Ignoring whether or not WARNINGS_AS_ERRORS is a good idea, ignoring
whether or not having it disabled by default on developer builds but
enabled on automation is a good idea, ignoring whether or not we can deal
with the tendency of gcc to lurch from complaining incessantly about one
silly thing to complaining about another on version upgrades, ignoring the
differences in warnings between different compilers ..)

The lack of platform parity for WARNINGS_AS_ERRORS being enabled at all
makes developing on Windows a complete PITA.  There are 50+ directories[0]
that have WARNINGS_AS_ERRORS enabled for gcc/clang and not MSVC.  So I come
along and write a patch that builds just fine on my machine, and push it to
inbound and every other platform is broken.  Now I have to push pretty much
every patch I write to try (or I just have to disable WARNINGS_AS_ERRORS in
directories where problems occur).

Either this parity issue needs to be fixed or we need to turn off
WARNINGS_AS_ERRORS.

- Kyle

[0] http://hg.mozilla.org/mozilla-central/rev/4983b42d58c9
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

DOM Bindings Meeting - Monday @ 12:30 PM PDT

[Kyle Huey]

Our (ostensibly) weekly DOM bindings meetings continue on Monday April 8th
at 12:30 PM PDT.

Meeting details:

* Monday, April 8, 2013, 12:30 PM PDT (9:30 PM CEST)
* Conference room 7-N, San Francisco office, 7th floor.
* Dial-in Info:
 - Vidyo room: SFO-7N
 - In office or soft phone: extension 92
 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
 - Toll-free: 800-707-2533 then password 369
 - Conference num 95704
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Preparing for the next windows PGO build memory exhaustion

[Kyle Huey]

On Sat, Apr 13, 2013 at 8:40 AM, Asa Dotzler  wrote:

> I have a really basic question. Is PGO's performance gains something users
> are actually going to notice or are we mostly talking about synthetic
> benchmark pissing contests here?


As we saw when we accidentally disabled it the other day, it shows up all
over our performance tests.


> What's PGO's impact on start-up time or new window time or the loading of
> a Twitter or Facebook web page?
>

I don't know about Twitter or Facebook specifically, but we do have
measurements for our talos pageset.

Some examples of what we saw disabling PGO:

Ts, Paint - XP - 16.3% increase (Startup)
Ts Paint, MAX Dirty Profile - XP - 16% increase (Startup)
Ts, Paint - Win7 - 15.3% increase (Startup)
Ts Paint, MED Dirty Profile - Win7 - 15.5%  (Startup)
Ts Paint, MAX Dirty Profile - Win7 - 14% increase (Startup)

Tp5 Optimized - XP - 23.9% increase (Pageload)
Tp5 Optimized Responsiveness - XP - 42.3% increase (Pageload)
Tp5 Optimized (%CPU) - XP - 7.68% increase (Pageload)
Tp5 Optimized - Win7 - 21.9% increase (Pageload)
Tp5 Optimized Responsiveness - Win7 - 38.9% increase (Pageload)
Tp5 Optimized (%CPU) - Win7 - 5.36% increase (Pageload)

15% startup regressions and 20% pageload regressions aren't anything to
sneeze at.

I've also seen over the years that we have a really difficult time
> diagnosing and fixing some high profile crashes because of PGO and if we
> can eliminate those or make them easier to diagnose and fix and all it
> costs us is a some points on Sunspider, I'm wondering if it doesn't make
> sense to just drop PGO and focus on finding performance wins elsewhere.


Amusingly enough Sunspider is probably the least effected benchmark by PGO
because it spends all it's time in JIT code.  But if Ts and Tp5 are models
of what users see then it costs us a lot more than a few Sunspider points.
On the other hand, if they aren't good models then we essentially have no
performance testing ...

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

DOM Bindings Meeting - Monday @ 12:30 PM PDT

[Kyle Huey]

Our (ostensibly) weekly DOM bindings meetings continue on Monday April 15th
at 12:30 PM PDT.

Meeting details:

* Monday, April 15, 2013, 12:30 PM PDT (3:30 PM EDT/9:30 PM CEST)
* Conference room 7-N, San Francisco office, 7th floor.
* Dial-in Info:
 - Vidyo room: SFO-7N
 - In office or soft phone: extension 92
 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
 - Toll-free: 800-707-2533 then password 369
 - Conference num 95704
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rethinking the amount of system JS we use in Gecko on B2G

[Kyle Huey]

The things on Justin's list do not appear to be infrequently running code.
Wifi, RIL, Apps, mozbrowser, etc are going to be running all the time.

- Kyle


On Mon, Apr 22, 2013 at 7:11 AM, Andreas Gal  wrote:

> JS is a big advantage for rapid implementation of features and it's
> easier to avoid exploitable mistakes. Also, in many cases JS code
> (bytecode, not data) should be slimmer than C++. Using JS for
> infrequently executing code should be a memory win. I think I would
> like to hear from the JS team on reducing memory use of JS and
> disabling any compilation for infrequently running code before we give
> up on it.
>
> Andreas
>
> Sent from Mobile.
>
> On Apr 22, 2013, at 7:05, Justin Lebar  wrote:
>
> > Of course attachments don't work great on newsgroups.  I've uploaded
> > the about:memory dumps I tried to attach to people.m.o:
> >
> > http://people.mozilla.org/~jlebar/downloads/merged.json.xz
> > http://people.mozilla.org/~jlebar/downloads/unmerged.json.xz
> >
> > On Sun, Apr 21, 2013 at 7:51 PM, Justin Lebar 
> wrote:
> >> I think we should consider using much less JS in the parts of Gecko
> that are
> >> used in B2G.  I'd like us to consider writing new modules in C++ where
> >> possible, and I'd like us to consider rewriting existing modules in C++.
> >>
> >> I'm only proposing a change for modules which are enabled for B2G.  For
> modules
> >> which aren't enabled on B2G, I'm not proposing any change.
> >>
> >> What I'd like to come out of this thread is a consensus one way or
> another as
> >> to whether we continue along our current path of writing many features
> that are
> >> enabled on B2G in JS, or whether we change course.
> >>
> >> Since most of these features implemented in JS seem to be DOM features,
> I'm
> >> particularly interested in the opinions of the DOM folks.  I'm also
> interested
> >> in the opinions of JS folks, particularly those who know about the
> memory usage
> >> of our new JITs.
> >>
> >> In the remainder of this e-mail I'll first explain where our JS memory
> is
> >> going.  Then I'll address two arguments that might be made against my
> proposal
> >> to use more C++.  Finally, I'll conclude by suggesting a plan of action.
> >>
> >> === Data ===
> >>
> >> Right now about 50% (16mb) of the memory used by the B2G main process
> >> immediately after rebooting is JS.   It is my hypothesis that we could
> greatly
> >> reduce this by converting modules to C++.
> >>
> >> On our 256mb devices, we have about 120mb available to Gecko, so this
> 16mb
> >> represents 13% of all memory available to B2G.
> >>
> >> To break down the 16mb of JS memory, 8mb is from four workers:
> ril_worker,
> >> net_worker, wifi_worker (x2).  5mb of the 8mb is under "unused-arenas";
> this is
> >> fragmentation in the JS heap.  Based on my experience tackling
> fragmentation in
> >> the jemalloc heap, I suspect reducing this would be difficult.  But
> even if we
> >> eliminated all of the fragmentation, we'd still be spending 3mb on
> these four
> >> workers, which I think is likely far more than we need.
> >>
> >> The other 8mb is everything else in the system compartment (all our
> JSMs,
> >> XPCOM components, etc).  In a default B2G build you don't get a lot of
> insight
> >> into this, because most of the system compartments are squished
> together to save
> >> memory (bug 798491).  If I set jsloader.reuseGlobal to false, the
> amount of
> >> memory used increases from 8mb to 15mb, but now we can see where it's
> going.
> >>
> >> The list of worst offenders follows, but because this data was
> collected with
> >> reuseGlobal turned off, apply generous salt.
> >>
> >>  0.74 MB modules/Webapps.jsm
> >>  0.59 MB anonymous sandbox from devtools/dbg-server.jsm:41
> >>  0.53 MB components/SettingsManager.js
> >>  0.53 MB chrome://browser/content/shell.xul
> >>  0.49 MB components/WifiWorker.js
> >>  0.43 MB modules/DOMRequestHelper.jsm
> >>  0.38 MB modules/XPCOMUtils.jsm
> >>  0.34 MB RadioInterfaceLayer.js
> >>  0.31 MB AppsUtils.jsm
> >>  0.27 MB Webapps.js
> >>  0.22 MB BrowserElementParent.jsm
> >>  0.21 MB app://system.gaiamobile.org/index.html
> >>
> >> Many (but certainly not all) of these modules could be rewritten in C++.
> >>
> >> Beyond this list, it's death by a thousand cuts; there are 100
> compartments in
> >> there, and they each cost a small amount.
> >>
> >> I've attached two about:memory dumps collected on my hamachi device
> soon after
> >> reboot, so you can examine the situation more closely, if you like.
> >> merged.json was collected with the default config, and unmerged.json was
> >> collected with jsloader.reuseGlobal set to false.
> >>
> >> Download and extract these files and then open them with the button at
> >> the bottom
> >> of about:memory in Nightly.
> >>
> >> (Before you ask: Most of the heap-unclassified in these dumps is
> >> graphics memory,
> >> allocated in drivers.)
> >>
> >> === Should we use JS because it's nicer than C++? ===
> >>
> >> I recognize 

DOM Bindings Meeting - Monday @ 12:30 PM PDT

[Kyle Huey]

Our (ostensibly) weekly DOM bindings meetings continue on Monday April 22th
at 12:30 PM PDT.

Meeting details:

* Monday, April 22, 2013, 12:30 PM PDT (3:30 PM EDT/9:30 PM CEST)
* Conference room 7-N, San Francisco office, 7th floor.
* Dial-in Info:
 - Vidyo room: SFO-7N
 - In office or soft phone: extension 92
 - US/INTL: 650-903-0800 or 650-215-1282 then extension 92
 - Toll-free: 800-707-2533 then password 369
 - Conference num 95704
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Accelerating exact rooting work

[Kyle Huey]

On Tue, Apr 23, 2013 at 8:18 AM, Ehsan Akhgari wrote:

> Can the stuff in objdir/dom/bindings be fixed whole-sale by changing the
> WebIDL codegen?
>

Yes.  bz is looking into it.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Storage in Gecko

[Kyle Huey]

On Fri, Apr 26, 2013 at 11:17 AM, Gregory Szorc  wrote:

> I'd like to start a discussion about the state of storage in Gecko.
>
> Currently when you are writing a feature that needs to store data, you
> have roughly 3 choices:
>
> 1) Preferences
> 2) SQLite
> 3) Manual file I/O
>
> Preferences are arguably the easiest. However, they have a number of
> setbacks:
>
> a) Poor durability guarantees. See bugs 864537 and 849947 for real-life
> issues. tl;dr writes get dropped!
> b) Integers limited to 32 bit (JS dates overflow b/c milliseconds since
> Unix epoch).
> c) I/O is synchronous.
> d) The whole method for saving them to disk is kind of weird.
> e) The API is awkward. See Preferences.jsm for what I'd consider a
> better API.
> f) Doesn't scale for non-trivial data sets.
> g) Clutters about:config (all preferences aren't config options).
>
> We have SQLite. You want durability: it's your answer. However, it too
> has setbacks:
>
> a) It eats I/O operations for breakfast. Multiple threads. Lots of
> overhead compared to prefs. (But hard to lose data.)
> b) By default it's not configured for optimal performance (you need to
> enable the WAL, muck around with other PRAGMA).
> c) Poor schemas can lead to poor performance.
> d) It's often overkill.
> e) Storage API has many footguns (use Sqlite.jsm to protect yourself).
> f) Lots of effort to do right. Auditing code for 3rd party extensions
> using SQLite, many of them aren't doing it right.
>
> And if one of those pre-built solutions doesn't offer what you need, you
> can roll your own with file I/O. But that also has setbacks:
>
> a) You need to roll your own. (How often do I flush? Do I use many small
> files or fewer large files? Different considerations for mobile (slow
> I/O) vs desktop?)
> b) You need to roll your own. (Listing it twice because it's *really*
> annoying, especially for casual developers that just want to implement
> features - think add-on developers.)
> c) Easy to do wrong (excessive flushing/fsyncing, too many I/O
> operations, inefficient appends, poor choices for mobile, etc).
> d) Wheel reinvention. Atomic operations/transactions. Data marshaling. etc.
>
> I believe there is a massive gap between the
> easy-but-not-ready-for-prime-time preferences and
>
> the-massive-hammer-solving-the-problem-you-don't-have-and-introducing-many-new-ones
> SQLite. Because this gap is full of unknowns, I'm arguing that
> developers tend to avoid it and use one of the extremes instead. And,
> the result is features that have poor durability and/or poor
> performance. Not good. What's worse is many developers (including
> myself) are ignorant of many of these pitfalls. Yes, we have code review
> for core features. But code review isn't perfect and add-ons likely
> aren't subjected to the same level of scrutiny. The end result is the
> same: Firefox isn't as awesome as it could be.
>
> I think there is an opportunity for Gecko to step in and provide a
> storage subsystem that is easy to use, somewhere between preferences and
> SQLite in terms of durability and performance, and "just works." I don't
> think it matters how it is implemented under the hood. If this were to
> be built on top of SQLite, I think that would be fine. But, please don't
> make consumers worry about things like SQL, schema design, and PRAGMA
> statements. So, maybe I'm advocating a generic key-value store. Maybe
> something like DOM Storage? Maybe SQLite 4 (which is emphasizing
> key-value storage and speed)? Just... something. Please.
>
> Anyway, I just wanted to see if others have thought about this. Do
> others feel it is a concern? If so, can we formulate a plan to address
> it? Who would own this?
>
> Gregory
>

Have you explored using IndexedDB?

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Storage in Gecko

[Kyle Huey]

On Fri, Apr 26, 2013 at 11:43 AM, Gregory Szorc  wrote:

>  On 4/26/2013 11:26 AM, Kyle Huey wrote:
>
> On Fri, Apr 26, 2013 at 11:17 AM, Gregory Szorc  wrote:
>
>> I'd like to start a discussion about the state of storage in Gecko.
>>
>> Currently when you are writing a feature that needs to store data, you
>> have roughly 3 choices:
>>
>> 1) Preferences
>> 2) SQLite
>> 3) Manual file I/O
>>
>> Preferences are arguably the easiest. However, they have a number of
>> setbacks:
>>
>> a) Poor durability guarantees. See bugs 864537 and 849947 for real-life
>> issues. tl;dr writes get dropped!
>> b) Integers limited to 32 bit (JS dates overflow b/c milliseconds since
>> Unix epoch).
>> c) I/O is synchronous.
>> d) The whole method for saving them to disk is kind of weird.
>> e) The API is awkward. See Preferences.jsm for what I'd consider a
>> better API.
>> f) Doesn't scale for non-trivial data sets.
>> g) Clutters about:config (all preferences aren't config options).
>>
>> We have SQLite. You want durability: it's your answer. However, it too
>> has setbacks:
>>
>> a) It eats I/O operations for breakfast. Multiple threads. Lots of
>> overhead compared to prefs. (But hard to lose data.)
>> b) By default it's not configured for optimal performance (you need to
>> enable the WAL, muck around with other PRAGMA).
>> c) Poor schemas can lead to poor performance.
>> d) It's often overkill.
>> e) Storage API has many footguns (use Sqlite.jsm to protect yourself).
>> f) Lots of effort to do right. Auditing code for 3rd party extensions
>> using SQLite, many of them aren't doing it right.
>>
>> And if one of those pre-built solutions doesn't offer what you need, you
>> can roll your own with file I/O. But that also has setbacks:
>>
>> a) You need to roll your own. (How often do I flush? Do I use many small
>> files or fewer large files? Different considerations for mobile (slow
>> I/O) vs desktop?)
>> b) You need to roll your own. (Listing it twice because it's *really*
>> annoying, especially for casual developers that just want to implement
>> features - think add-on developers.)
>> c) Easy to do wrong (excessive flushing/fsyncing, too many I/O
>> operations, inefficient appends, poor choices for mobile, etc).
>> d) Wheel reinvention. Atomic operations/transactions. Data marshaling.
>> etc.
>>
>> I believe there is a massive gap between the
>> easy-but-not-ready-for-prime-time preferences and
>>
>> the-massive-hammer-solving-the-problem-you-don't-have-and-introducing-many-new-ones
>> SQLite. Because this gap is full of unknowns, I'm arguing that
>> developers tend to avoid it and use one of the extremes instead. And,
>> the result is features that have poor durability and/or poor
>> performance. Not good. What's worse is many developers (including
>> myself) are ignorant of many of these pitfalls. Yes, we have code review
>> for core features. But code review isn't perfect and add-ons likely
>> aren't subjected to the same level of scrutiny. The end result is the
>> same: Firefox isn't as awesome as it could be.
>>
>> I think there is an opportunity for Gecko to step in and provide a
>> storage subsystem that is easy to use, somewhere between preferences and
>> SQLite in terms of durability and performance, and "just works." I don't
>> think it matters how it is implemented under the hood. If this were to
>> be built on top of SQLite, I think that would be fine. But, please don't
>> make consumers worry about things like SQL, schema design, and PRAGMA
>> statements. So, maybe I'm advocating a generic key-value store. Maybe
>> something like DOM Storage? Maybe SQLite 4 (which is emphasizing
>> key-value storage and speed)? Just... something. Please.
>>
>> Anyway, I just wanted to see if others have thought about this. Do
>> others feel it is a concern? If so, can we formulate a plan to address
>> it? Who would own this?
>>
>> Gregory
>>
>
> Have you explored using IndexedDB?
>
>
> Not seriously. The "this is an experimental technology" warning on MDN is
> off-putting.
>

Yeah that's not accurate.  It's pretty solid now.  It's the storage backend
for everything in b2g for instance ... and it's not going to see any
changes that aren't backwards compatible.


> Is IndexedDB ready for use by internal Gecko consumers, including add-ons?
>

Yes.

Can you use it from the main thread (for cases where a dedicated worker is
> too heavy weight)?
>

You can only use it from the main thread right now.  Worker support is
coming (Bug 798875).


> What are current risks associated with this "experimental technology?"
>

It's not experimental.

Aside from those concerns, I reckon IndexedDB could fill the gap I
> described. I want to learn more.
>

Always happy to answer questions.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Storage in Gecko

[Kyle Huey]

Resending to list.

On Fri, Apr 26, 2013 at 12:02 PM, Gregory Szorc  wrote:

> On 4/26/2013 11:52 AM, Kyle Huey wrote:
>
> Could you please point me at a "good" implementation of a Gecko consumer
> of IndexedDB? If you don't know which are good, an MXR search URL will
> suffice :)
>

I haven't looked at any of them closely but there are lots of uses at
http://mxr.mozilla.org/gaia/search?string=indexeddb


> I'm looking at
>
> https://mxr.mozilla.org/mozilla-central/source/addon-sdk/source/lib/sdk/indexed-db.js
> .
> Is all that principal magic necessary? Is there an MDN page documenting
> all this?
>

I think that's just necessary for separating jetpack addons from one
another.  If you're ok with it being possible for some other piece of
chrome to access your database and just use a unique name for it it's
unnecessary, AIUI.

- Kyle
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform