Note that we have bug 990804 opened for providing such a service.
Unfortunately, this bug is currently stalled because we apparently
didn't have a clear idea of what API clients would need.
I'm willing to pick this for Q2, if there is interest.
Cheers,
David
On 26/03/15 07:46, Randell Jesup
Hi All,
I've been googling now for a far too long trying to find definitive
documentation about the license governing the usage and distribution of
libxul. All I can find is a very short wiki page that states that the
licensing of xulrunner is being discussed internally to address some
On Thu, Mar 26, 2015 at 2:46 AM, Randell Jesup rjesup.n...@jesup.org
wrote:
Some examples pointed out to me: FilePicker, the spell-checker, the
DeviceStorage DOM code, DOM cache code in Manager.cpp (via
BodyStartWriteStream()), even perhaps ResolvedCallback in
ServiceWorkers. (I haven't
On Thu, Mar 26, 2015 at 6:26 AM, Jesse Nicholson ascensionsyst...@gmail.com
wrote:
Hi All,
I've been googling now for a far too long trying to find definitive
documentation about the license governing the usage and distribution of
libxul. All I can find is a very short wiki page that states
On Fri, Mar 27, 2015 at 10:25 AM, Robert O'Callahan
rob...@ocallahan.org wrote:
Switching method names to start with a capital letter would be helpful too
... especially where it's leaked into MFBT.
FWIW, here is the contents of mfbt/STYLE:
MFBT uses standard Mozilla style, with the
On 27 March 2015 at 01:19, Bobby Holley bobbyhol...@gmail.com wrote:
Can we switch from 4-space to 2-space indentation at some point too?
Together, those would remove the most glaring formatting differences. The
others (bracing single-line consequents, aNamingWarts, etc) might be harder.
I've
I guess we can add a command line option to our executable that calls the
function and prints the results and exits and then invoke ourselves to do this
in a new process and parse the output. What a silly bug.
Thanks,
Andreas
Sent from Mobile.
On Mar 26, 2015, at 07:03, Daniel Stenberg
I'm wondering if anyone can point me to some documentation on customizing
what get's built into libxul. All I can find is outdated random forum posts
about changing defines in a nsStaticXULComponents, specifically
XUL_MODULES define, but that information seems to no longer apply.
I'm looking to
dom/media has a very useful system called SharedThreadPool that gives you
static on-demand access to a named (and refcounted) threadpool. Probably
just moving that to XPCOM and then coming up with a naming convention
(MiscThreadPool or something) might solve this problem.
On Thu, Mar 26, 2015 at
Is the bug tasking this marked dev-doc-needed? We will have SD
A bunch of cleanup to do
On Thursday, March 26, 2015, Jan De Mooij jdemo...@mozilla.com wrote:
Hi all,
After some discussion, we want to switch SpiderMonkey and XPConnect style
for pointers/references from |T *p| to |T* p| (and
==Summary==
I suggest that we either decide not to support non-UTF-8 file paths in
Gecko/Firefox on Gtk platforms or, failing that, use the glib
facilities to convert between Unicode and file paths.
Opinions?
==Relevant bugs==
https://bugzilla.mozilla.org/show_bug.cgi?id=960957
On 3/26/2015 3:00 AM, Randell Jesup wrote:
Force a buffer in 2GB memory and always copy into/out of that buffer?
That may work, other than it's inconvenient to force a buffer into 2GB
space at the time when you need it, and thus we'd have to perma-allocate
a large enough buffer for this.
Actually, I'm going to steal bug 990804 and see if we can get something
worked out now. My plan is just to duplicate the STS code with a different
XPCOM uuid for now.
On Thu, Mar 26, 2015 at 9:29 AM, Benjamin Kelly bke...@mozilla.com wrote:
On Thu, Mar 26, 2015 at 2:46 AM, Randell Jesup
On Thu, 26 Mar 2015, Benjamin Smedberg wrote:
What is the largest buffer that we can expect to need? Since VM allocation
happens in 64k boundaries, is it sufficient to just use a 64k buffer for
this?
As per a recent comment in the bug however, it doesn't work to just reserve
some memory in
On Fri, Mar 27, 2015 at 5:05 AM, Andreas Gal andreas@gmail.com wrote:
I guess we can add a command line option to our executable that calls the
function and prints the results and exits and then invoke ourselves to do
this in a new process and parse the output. What a silly bug.
Surely
On 2015-03-26 3:07 PM, Jesse Nicholson wrote:
I'm wondering if anyone can point me to some documentation on customizing
what get's built into libxul. All I can find is outdated random forum posts
about changing defines in a nsStaticXULComponents, specifically
XUL_MODULES define, but that
Hi all,
After some discussion, we want to switch SpiderMonkey and XPConnect style
for pointers/references from |T *p| to |T* p| (and |T ref| to |T ref|).
This matches the rest of the project and will make life easier for
developers working on multiple parts of the tree.
Although this will break
\o/
Can we switch from 4-space to 2-space indentation at some point too?
Together, those would remove the most glaring formatting differences. The
others (bracing single-line consequents, aNamingWarts, etc) might be harder.
On Thu, Mar 26, 2015 at 3:52 PM, Jan De Mooij jdemo...@mozilla.com
On Fri, Mar 27, 2015 at 12:19 PM, Bobby Holley bobbyhol...@gmail.com
wrote:
\o/
Can we switch from 4-space to 2-space indentation at some point too?
Together, those would remove the most glaring formatting differences. The
others (bracing single-line consequents, aNamingWarts, etc) might be
dom/network/UDPSocket doesn't use SocketTransportService directly so it
doesn't create exception. It should be ok to leave it outside of Necko.
Best Regards,
Shih-Chiang Chien
Mozilla Taiwan
On Thu, Mar 26, 2015 at 11:37 PM, Randell Jesup rjesup.n...@jesup.org
wrote:
Can we stop exposing the
Thanks to detective work by a subscriber to dev.media (Tor-Einar
Jarnbjo), we've found the cause of unexplained ICE (NAT-traversal)
failures in WebRTC on Windows (bug 1107702). This may also affect the
code in netwerk that tracks the network link status.
It turns out that 32bit Windows programs
As a result of some conversations on IRC, it came to light that a bunch
of blocking IO operations were apparently moved off of MainThread
(presumably to avoid UI 'jank'), and instead Dispatched to
STREAMTRANSPORTSERVICE (aka STS thread).
Some examples pointed out to me: FilePicker, the
Force a buffer in 2GB memory and always copy into/out of that buffer?
That may work, other than it's inconvenient to force a buffer into 2GB
space at the time when you need it, and thus we'd have to perma-allocate
a large enough buffer for this. (Note GetAdapters*() is typically used
with a
On 2015-03-26 11:14 AM, Patrick McManus wrote:
good catch.. looking at
https://mxr.mozilla.org/mozilla-central/ident?i=NS_SOCKETTRANSPORTSERVICE_CONTRACTID
the only uses I see other than the one Ehsan unearthed are expected.. so
maybe that's the sum of the short term work.
Great! Filed
Nathan suggests the following plan to avoid code duplication:
1) Move STS code into xpcom/io under a different name and XPCOM uuid.
2) Make the necko STS a no-op inherit from the xpcom code with a different
uuid.
This would give us two service instances without duplicating any code.
Also, I'll
media uses it by agreement and in an appropriate way to support rtcweb.
On Thu, Mar 26, 2015 at 10:20 AM, Kyle Huey m...@kylehuey.com wrote:
Can we stop exposing the socket transport service's nsIEventTarget outside
of Necko?
- Kyle
On Thu, Mar 26, 2015 at 8:14 AM, Patrick McManus
:
On Thu, Mar 26, 2015 at 2:46 AM, Randell Jesup rjesup.n...@jesup.org
wrote:
t. (I even thought
there was a separate SocketTransportService which was different from
StreamTransportService.)
You're right they are different things.
The socket transport service is a single thread that
Can we stop exposing the socket transport service's nsIEventTarget outside
of Necko?
- Kyle
On Thu, Mar 26, 2015 at 8:14 AM, Patrick McManus mcma...@ducksong.com
wrote:
good catch.. looking at
https://mxr.mozilla.org/mozilla-central/ident?i=NS_SOCKETTRANSPORTSERVICE_CONTRACTID
the only uses
thanks bkelly
On Thu, Mar 26, 2015 at 9:01 AM, Benjamin Kelly bke...@mozilla.com wrote:
Actually, I'm going to steal bug 990804 and see if we can get something
worked out now. My plan is just to duplicate the STS code with a different
XPCOM uuid for now.
On Thu, Mar 26, 2015 at 9:29 AM,
On 2015-03-26 11:00 AM, Kyle Huey wrote:
On Thu, Mar 26, 2015 at 7:49 AM, Patrick McManus mcma...@ducksong.com
wrote:
Is this thread mostly just confusion from these things sounding so much
alike? Or am I confused now?
Most likely.
Does anyone have actual data to show that this is a
Can we stop exposing the socket transport service's nsIEventTarget outside
of Necko?
If we move media/mtransport to necko... or make an exception for it (and
dom/network/UDPSocket and TCPSocket, etc). Things that remove loaded
footguns (or at least lock them down) are good.
Glad the major real
good catch.. looking at
https://mxr.mozilla.org/mozilla-central/ident?i=NS_SOCKETTRANSPORTSERVICE_CONTRACTID
the only uses I see other than the one Ehsan unearthed are expected.. so
maybe that's the sum of the short term work.
On Thu, Mar 26, 2015 at 10:06 AM, Ehsan Akhgari
One more place:
https://bugzilla.mozilla.org/show_bug.cgi?id=1147921
-hb-
On 3/26/2015 16:14, Patrick McManus wrote:
good catch.. looking at
https://mxr.mozilla.org/mozilla-central/ident?i=NS_SOCKETTRANSPORTSERVICE_CONTRACTID
the only uses I see other than the one Ehsan unearthed are
33 matches
Mail list logo
