On 4/27/14, 10:06 AM, Zack Weinberg wrote:
maybe we should stop doing that?
The issue is deciding where to put the incoming data. We can't just
buffer it in RAM while the download is proceeding and the user has gone
to lunch without selecting a download location, because in many cases
On 4/28/14, 12:18 AM, Birunthan Mohanathas wrote:
Right now, the new macros support up to 50 variadic arguments.
If someone uses more than that, will that fail to compile or silently
ignore the extra args?
-Boris
P.S. I know, the right answer is they need fewer interfaces... ;)
On 4/28/14, 12:38 AM, Birunthan Mohanathas wrote:
It will fail to compile.
Excellent!
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 5/6/14, 12:25 PM, Benoit Jacob wrote:
To what extent does what I wrote in my previous email, regarding
interactions between different extensions, answer your question?
I'm not sure it answers it at all.
With the example approach you suggested above, one would have to specify
extensions
On 5/7/14, 2:00 PM, Benoit Jacob wrote:
The idea is that if getContext(webgl, {version : N}) returns non-null,
then the resulting context is guaranteed to be WebGL version N, so that
no other versioning mechanism is needed.
Sure, but say some code calls getContext(webgl, { version: 1 }) and
On 5/11/14, 7:50 PM, Chris Pearce wrote:
Should we be preferring mozilla::RefPtr in new code?
Should we be replacing nsRefPtr with mozilla::RefPtr?
I would err on no for both, given
https://bugzilla.mozilla.org/show_bug.cgi?id=820257
-Boris
___
Background: in C++, one-argument constructors are implicit.
What this means is that given this class declaration:
class Foo {
public:
Foo(int arg);
passAFoo(const Foo arg);
};
This bit of C++:
Foo foo(5);
foo.passAFoo(10);
will compile and construct a temporary Foo that it
On 5/13/14, 7:47 AM, Benjamin Smedberg wrote:
Seems there's general agreement. Please make this change to the style
guide.
Done. Added to
https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style#C.2FC.2B.2B_practices
-Boris
On 5/18/14, 2:23 PM, Gavin Sharp wrote:
OMTC is important, and I'm excited to see it land
on Windows, but the Firefox and Performance teams have just come off a
months-long effort to make significant wins in TART, and the thought
of taking a 20% regression (huge compared to some of the
On 6/2/14, 3:34 PM, Paolo Amadini wrote:
It seems to me that if we don't have external compatibility needs, we
might as well move mochitests to use a set of assertion methods that is
the same as xpcshell and maybe other test suites.
Yes, but imho we should be moving xpcshell in the direction
On 6/2/14, 5:33 PM, Gavin Sharp wrote:
Do either of you have reasoning for that other than it looks better
to me?
My personal experience is that when I try to write xpcshell tests the
amount of time it takes to type the test function names is very
noticeable and actively interrupts my
On 6/2/14, 7:26 PM, Martin Thomson wrote:
Sounds like an area ripe for standardisation
Note that standardizing several test suites on the same API might not
work all that well when they have different goals and operating
parameters, because what can you end up with is an API that doesn't
On 6/2/14, 9:44 PM, Boris Zbarsky wrote:
On 6/2/14, 7:26 PM, Martin Thomson wrote:
Sounds like an area ripe for standardisation
Note that standardizing several test suites on the same API might not
work all that well when they have different goals and operating
parameters
Specifically
On 6/3/14, 8:39 AM, Mike de Boer wrote:
I think it helps provide a common, immediate understanding for new contributors
who’d like to write test for the code they contribute, as the add-on SDK and
the NodeJS community already use it exclusively.
I think there's a bit of functional area bias
On 6/3/14, 6:22 AM, Mike de Boer wrote:
Their lack of modularity costs us flexibility in adopting and/ or promoting TDD
development.
Mike, I'm very curious about this part. Do you have a link offhand to a
more detailed explanation of the issues here?
Note that none of us think Mochitest
On 6/3/14, 9:29 AM, Mike de Boer wrote:
Nope, you got me there - I generalised too easily. This statement is based on
personal experience, not science.
I'm not looking for science, necessarily. I'm looking for an
understanding of the problems we're trying to solve.
My basic issue is that
On 6/3/14, 11:19 AM, L. David Baron wrote:
Locally I generally want to see all the failures, since seeing the
complete set of failures is often a much better hint as to the cause
of the failures than just seeing the first one.
Yes, exactly.
-Boris
On 6/3/14, 11:17 AM, Joshua Cranmer wrote:
I'm used to xpcshell tests more than mochitests, and the biggest
difference by far between xpcshell and mocha that I'm aware of is that
mocha counts tests at finer granularity: xpcshell tests work on a
file-by-file basis, whereas mocha tests work at
On 6/3/14, 2:36 PM, Gregory Szorc wrote:
There is a clear win in the ability to reuse, understand, and modify the
common code.
No one is arguing against having common harness code as far as I can see.
I can't even recall which file(s)
contain is/ok from mochitest
SimpleTest.js. Which also
On 6/3/14, 3:31 PM, Boris Zbarsky wrote:
Maybe that's a personal failing of mine, but I suspect not.
More precisely, I expect it's a personal failing that is widespread, not
just my personal little quirk.
-Boris
___
dev-platform mailing list
dev
On 6/4/14, 1:42 PM, Mike de Boer wrote:
I wasn’t implying that they’re broken at all, it’s just that James was hinting
at that.
Our existing testing frameworks are broken in terms of the goals of the
testharness framework, as far as I understand.
For example, one of the primary goals of
On 6/4/14, 1:56 PM, Ted Mielczarek wrote:
The inconsistency between our various test harnesses makes it harder
than necessary to write different types of tests.
Yes, agreed.
RE: the discussion of testharness.js etc, I think those are even farther
afield, since the testing model there is much
On 6/4/14, 11:30 PM, Gavin Sharp wrote:
- benefits to shared API/implementation seem uncontroversial
Agreed.
- specifically, consistency between mochitest/SimpleTest-based
harnesses (mochitest-plain/mochitest-chrome/mochitest-browser) and
xpcshell tests is what we care about primarily. I
On 6/5/14, 11:39 AM, Matthew Gertner wrote:
Our extension injects styles into webpages via a protocol defined using our own protocol
handler using link rel=stylesheet. We have our own nsIContentPolicy which
we use to enforce which resources from this protocol can be injected into content
On 6/6/14, 10:00 AM, Matthew Gertner wrote:
Is this a Firefox bug or somehow by design?
It's by design: when you ask for a window and we haven't actually
created one yet (because this is a new subframe that's doing its initial
load, say), we have to go ahead and create an about:blank one to
On 6/6/14, 7:12 AM, Gijs Kruitbosch wrote:
No, I think that in 99.99% of cases, I don't care about the type, and
therefore I would normally use is() and not care that it's using
non-strict equality. I think the case where there is (a) a possibility
that I could get '5' instead of 5 when code is
Currently we support things like img src=javascript:stuff, as well
as link href=stylesheet href=javascript:stuff and
@import(url(javascript:stuff)). What these do is run the script in a
sandbox and then if it returns a value other than undefined treat that
value as data for the load.
I
On 6/6/14, 11:04 AM, Gijs Kruitbosch wrote:
I'm interested in the API exposure case (bug link please? :-)
I'd have to search, sorry. :(
I would have assumed that you would test that kind of thing by checking if the
relevant API property is enumerable from the object, rather than
checking
On 6/6/14, 12:21 PM, Boris Zbarsky wrote:
Yeah, I've been dealing a lot with edge cases of DOM APIs for the last
year or two
Case in point. I got some try results, and here's one of the failures:
748 INFO TEST-UNEXPECTED-FAIL |
/tests/dom/indexedDB/test/test_multientry.html | exhausted
On 6/6/14, 11:55 AM, Matthew Gertner wrote:
So what's the best way to hook into the window so I am notified when the real
document is created?
The about:blank document is quite real, sadly...
I'm not seeing anything obvious that gets fired when we reuse an inner
for a new document. At
On 6/6/14, 12:42 PM, Matthew Gertner wrote:
On Friday, June 6, 2014 6:33:27 PM UTC+2, Boris Zbarsky wrote:
The about:blank document is quite real, sadly...
From what I'm seeing, the document object that ends up there (window.document)
is not the same one as when DOMWindowCreated is fired
On 6/6/14, 12:21 PM, Boris Zbarsky wrote:
That will be the big question, yes.
https://tbpl.mozilla.org/?tree=Tryrev=e26ab6d5e1e0 says we have quite a
number of things that are in fact assuming that 5 and 5 should test
is(). I'm not sure how much I like throwing in tons of toString
On 6/6/14, 3:19 PM, Ehsan Akhgari wrote:
Can we make is() do those checks explicitly and if neither of these
cases apply, fall back to a non-strict equality check?
Yes. As in, we could make it special-case the number-to-string compare
and use == for that, and use === for everything else.
On 6/6/14, 8:42 PM, Jonas Sicking wrote:
I definitely understand that it'll be a pain to convert existing tests
that rely on the relaxed matching.
Yes. We have about 3300 failing test assertions with is() using ===,
and the vast majority are string-vs-number.
All I'm saying is that we
On 6/20/14, 8:00 AM, Joshua Cranmer wrote:
(there is 0%
coverage of angle).
That's not surprising given that the code coverage test is being done on
Linux, is it?
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 6/24/14, 2:59 AM, Cameron McCormack wrote:
Yes hence the something similar. :-) Was just easiest for working
with while implementing. Making the object iterable seems like the
right thing to do, but our bindings generation scripts don't handle
iterator in IDL yet.
That's at least in part
On 7/1/14, 6:06 AM, Anne van Kesteren wrote:
Hi Doug, Patrick, Boris,
ccing Jonas, since he's been thinking about this a lot recently.
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIContentPolicy
suggests we have somewhat less granularity than Chromium /
On 7/1/14, 10:54 AM, Anne van Kesteren wrote:
Good question. From what I remember the main motivation was having
something distinct from navigating the top-level browsing context. A
service worker might want to know whether it's app top-level
browsing context is being navigated or whether it's
On 7/21/14, 8:36 AM, Markus Stange wrote:
On 21.07.14 13:33, Yonggang Luo wrote:
I am trying to remove the default style for tag window /
but failed to setting the radius.
Setting a border radius on the root element is not supported.
In XUL, right? Works fine in HTML.
-Boris
On 7/21/14, 9:35 AM, Markus Stange wrote:
Oops, I was forgetting about borders. border-radius works for getting
rounded borders on root elements, but it does not work for clipping
backgrounds to a rounded rect.
Right, because of background propagation to the viewport. The spec
calls this out
On 7/21/14, 9:50 PM, Yonggang Luo wrote:
I am not so sure I understand correctly, is that the answer is there is no
solution, the only accept way is using a transparent background?
If you want the background clipped to the rounded border, and the
rounded border to be on the root, then you
On 7/22/14, 9:01 PM, Jonathan Eads wrote:
You can kick the tires here:
https://treeherder.mozilla.org
This looks pretty neat! I do have a few questions/comments:
1) It's trying to run Flash. Will it work correctly if I just don't
let it do that? I haven't found anything broken so far
On 7/23/14, 5:07 AM, Neil wrote:
I think the arrow to the right of the revision is supposed to achieve
this. I'm not sure what the point of the link itself is, or where it's
documented.
Ah, I see, yes.
There is a clear indicator, but it's not obvious. (It's to the left of
the tree name.)
On 7/23/14, 8:39 AM, Ed Morley wrote:
That said, jmathies is also hitting this -
I've CCed you on bug 1042627 - let's discuss there
Done.
2) It seems to use a narrower space than tbpl for the patch
descriptions; at my window width and font size I don't even see the
entire bug number for
As of today, any Web IDL using Promise needs to specify the type the
promise will be resolved with.
For example, an API that used to be written like this:
Promise getLength();
would now be written like this:
Promiseunsigned long getLength();
If you don't put in the type, you will get
Summary: This is an unprefixed form of Element.mozMatchesSelector, which
we've been shipping for a long time.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=886308
Link to standard: http://dom.spec.whatwg.org/#dom-element-matches
(though note
On 8/19/14, 2:52 PM, Look, Yuriy wrote:
I am building my code against Gecko 31 for Windows and a public C++ method
nsIDocument::GetDocShell defined in include\nsIDocument.h on line 1188 does not
get resolved by Visual Studio 2010 linker.
This is a non-virtual non-inline method, with default
On 8/22/14, 5:34 AM, David Rajchenbach-Teller wrote:
If I recall correctly, this is implemented as an object with a field
`out` – I'm not 100% sure of the name of the field, though, so you might
need to experiment.
The field name is value.
I should note that searching the web for xpcom out
On 8/27/14, 12:29 PM, Steve Fink wrote:
Enumerating some of them:
Let me add one:
6. I touched a file or files. Rebuild only the compiled-code tests
that test this stuff.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 8/27/14, 1:28 PM, Ehsan Akhgari wrote:
Do you mean something beyond:
$ ninja -t dom/bindings/test
I have no idea what that command line does, but note that mach build
dom/bindings/test doesn't compile the binding tests, or even regenerate
the test files. I _really_ wish it did.
-Boris
On 8/27/14, 1:46 PM, Ehsan Akhgari wrote:
Ah, that's pretty weird. I would consider that a build system bug.
../mach build content/media/webaudio/compiledtest for example does the
right thing.
Well.
The codegen runs in dom/bindings, not dom/bindings test.
So if I do
mach build
On 8/27/14, 8:16 PM, Boris Zbarsky wrote:
On 8/12/14, 1:05 PM, Ben Hearsum wrote:
Without any changes, future versions of Firefox will cease to function
out-of-the-box on OS X 10.9.5 and 10.10.
Will it still be possible to run old nightlies, presumably by changing
something in system settings
On 8/12/14, 1:05 PM, Ben Hearsum wrote:
Without any changes, future versions of Firefox will cease to function
out-of-the-box on OS X 10.9.5 and 10.10.
Will it still be possible to run old nightlies, presumably by changing
something in system settings?
-Boris
On 9/3/14, 6:53 PM, Nicholas Nethercote wrote:
|mach build binaries| suffices most of the time
It really doesn't for the use case of not building the world when you
change a header and want to just rebuild the files that use the changed
part of the header...
I should also note that a
On 9/3/14, 10:10 PM, Mike Hommey wrote:
Please file a bug with a timestamped log.
Done: https://bugzilla.mozilla.org/show_bug.cgi?id=1062668
And thank you!
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 9/4/14, 12:26 AM, Nicholas Nethercote wrote:
But in lieu of sub-file
dependency tracking you'll take manual overrides that emulate them by
doing partial builds, relying on your knowledge of the codebase to
know that those partial builds are safe.
This is a point worth clarifying.
I'm not
On 9/4/14, 12:51 AM, Joshua Cranmer wrote:
It sounds to me like what you really want is support for a red squiggly
line in your IDE
Not quite, because red squiggly lines don't catch weird C++ namespacing
rules, lack of conversion operators that should be present, etc...
-Boris
On 9/5/14, 11:55 AM, James Graham wrote:
The web-platform-tests testsuite has just landed on
Mozilla-Central.
This is fantastic. Thank you!
Does this obsolete our existing imptests tests, or is this a set of
tests disjoint from those?
-Boris
___
On 9/5/14, 11:55 AM, James Graham wrote:
Instructions for performing the updates are in the README file
[2]. There is tooling available to help in the update process.
Is there a way to document the spec or test suite bugs in the
expectations file? e.g. if I want to add an expected: FAIL and
On 9/7/14, 10:21 AM, James Graham wrote:
There isn't anything at the moment, but it seems like a good idea to
invent something. The easiest thing would be a new key-value pair like
expected-reason: Some reason string
Do you have a preferred syntax here?
Nope. Pretty much anything works for
dictionary AvailableChangeEventInit : EventInit {
boolean available;
This needs a default value.
interface SocketChannelWithATwist { // temporary name
Should this inherit from EventTarget? Seems like it, given the
EventHandler attributes it has. Or does it not trigger those via
On 9/9/14, 2:57 AM, Kilik kuo wrote:
Boris Zbarsky於 2014年9月8日星期一UTC+8下午11時51分04秒寫道：
boolean available;
This needs a default value.
I'm not quite sure about this,
I am. ;)
Since it's an optional argument for AvailableChangeEvent.
Right, and the question is: what is the behavior
On 9/19/14, 8:23 PM, L. David Baron wrote:
W3C recently published the following proposed recommendation (the
stage before W3C's final stage, Recommendation):
The biggest issue I have with this is exiting CR without anything
resembling a comprehensive enough test suite to ensure anything like
On 9/20/14, 5:03 AM, Karl Dubost wrote:
The biggest issue I have with this is exiting CR without anything resembling a
comprehensive enough test suite
* What is a comprehensive enough test suite?
Ideally, one that has a test for every normative requirement in the
specification. This means
On 9/20/14, 5:41 AM, Karl Dubost wrote:
Is the whatwg spec interoperable?
No.
Will it ever be?
That's the goal. Whether we manage to get there, we'll see.
So Boris said incomplete test suite. That's one comment.
Note that I didn't say we should bring the comment back to the AC, since
On 9/20/14, 6:29 PM, Karl Dubost wrote:
This published recommendation has switched
to a non maintenance mode. It may contain
mistakes or things may have changed since
the publication. Please make sure to check
the most up to date document BLAH [with
link to the
On 9/21/14, 9:00 AM, James Graham wrote:
I am substantially less convinced that tying these tests to the spec
lifecycle makes sense.
Agreed. The only reason it's an issue for me is the lack of
errata-issuance by the W3C and hence the tendency to attempt to enshrine
obviously-wrong things in
On 9/22/14, 1:18 PM, James Graham wrote:
I think you'd get a better result by asking for agreement from all the
relevant implementors that they felt that the spec was implementable.
The problem was that in some cases this was more a less a non-goal (in
some cases an anti-goal) for the spec
On 10/2/14, 4:06 AM, Philip Chee wrote:
Can we not reach out to the MooTools people and work together unbreak
the web?
Already done. Now you just have to get the several million sites using
old MooTools versions to update.
-Boris
___
dev-platform
On 10/2/14, 4:53 PM, Jeff Gilbert wrote:
If you want to guarantee it, don't warn, assert.
Note that mochitest-plain tests will go orange on unexpected uncaught
exceptions. Not least because we added that pretty early on in their
evolution.
We're nowhere close to doing that with
On 10/12/14, 9:54 PM, ISHIKAWA, Chiaki wrote:
In this bugzilla, line 693 is actually out of range for the file reported.
The file is much shorter.
Is it? The error is in nsContextMenu.js but your comments in the bug
are about mailContextMenus.js, which is not at all the same thing.
Worse, in
On 10/13/14, 11:28 PM, Yonggang Luo wrote:
If the XUL is truly dead, then mozilla community should consider to remove it
totally from the codebase
Working on it. It's a big project. ;)
-Boris
___
dev-platform mailing list
On 10/15/14, 3:40 AM, glazou wrote:
Guys, you understand there is an ecosystem - even if it is a small one - of
companies relying on XUL for their businesses?
Yes, including Mozilla, via Firefox.
1. does Mozilla still care about us?
I can't answer this question. On a personal level, I
On 10/15/14, 5:01 AM, glazou wrote:
w/o even trying to discuss with
them the situation, the possibilities, the alternatives, the ETA,
the transition plan.
The situation is that we have a bunch of unmaintained code that
complicates layout. And layout needs no extra complications; it has
On 10/15/14, 9:03 AM, Boris Zbarsky wrote:
The situation is that we have a bunch of unmaintained code that
complicates layout.
I feel like I should expand on this.
XUL covers a variety of somewhat-unrelated features, including at least:
1) The XUL box model.
2) The built-in XUL elements
On 10/16/14, 5:30 AM, Neil wrote:
Out of interest, what does it do that complicates layout? You mentioned
the box model of course, but what else is there?
There's a bunch of listbox-related frame constructor complexity (and for
a while it was a quite lively source of security bugs, too).
On 10/16/14, 4:01 PM, Ehsan Akhgari wrote:
Sure. But you're just describing why tests are useful and an absolute
necessity. :-) I think what Bobby was asking for is a much stronger
ask that is not really attainable.
I think what Bobby was actually asking for is this:
If a patch lands and
On 10/24/14, 3:48 AM, Anne van Kesteren wrote:
Then if a known-bad thing was found, such as a plugin,
native form control, or non-CORS cross-origin image,
Or link, right? Otherwise you leak :visited state.
-Boris
___
dev-platform mailing list
On 11/9/14, 11:10 PM, Gregory Szorc wrote:
We currently only attempt to map each review/commit series to a single bug.
This is definitely a problem; it serializes workflow such that you have
to get review on bug 1 and land it before you can even request review on
bug 2 that depends on bug 1,
On 11/10/14, 12:14 PM, Gregory Szorc wrote:
I think if we land support for specifying the base revision to review
(currently it takes all non-public changesets up to the revision you
specify or . if none), that will be a sufficient stop-gap until proper
multi-bug support is implemented.
Yes,
On 11/21/14, 1:17 AM, Yonggang Luo wrote:
I am looking for docs about this
do_CreateInstance returns a new object every time. do_GetService
creates one object and caches it, then keeps returning the cached object.
In practice, for any given class you'd only use one or the other,
depending
On 11/24/14, 4:40 AM, Philipp Kewisch wrote:
Personally I'd prefer if the JS component could just throw and not have
to use Components.returnCode at all, isn't there a way the caller can
catch the exception without it being logged?
There is. The question is _when_ it should do this. Consider
Summary: document.origin returns the Unicode serialization of the
document's origin. The returned value does not depend on what
document.domain was set to.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=931884
Spec: http://dom.spec.whatwg.org/#dom-document-origin
Platform coverage: All
On 12/2/14, 8:17 AM, Kevin Grandon wrote:
We currently use location.origin quite frequently in gaia, and we also use it
in workers.
So the difference between location.origin and document.origin is that
the latter is the origin of the document and the former is the origin of
the document's
On 12/3/14, 2:28 AM, Jonas Sicking wrote:
This difference seems really esoteric to me. Do we really expect developers
to understand this difference and use the right one? Especially given the
very similar names?
I don't. Hence my proposal to remove location.origin.
Are there use cases for
On 12/3/14, 6:30 AM, Anne van Kesteren wrote:
Correct. I thought that was added a long time ago.
location.origin has existed in Firefox since Firefox 21, I guess (and
Firefox 29 for Workers). I guess that does make it hard to remove.
That sucks. :(
Anyway, the difference between a
On 12/18/14, 2:28 PM, Nils Ohlmeier wrote:
Well there is an event listener waiting for the event to fire.
But how else then through a timeout, obviously with a high timeout value like
30 or 60 seconds
We've had quite a number of random oranges from precisely this scenario.
It seems that it's
On 1/23/15 12:06 PM, Tomasz wrote:
Both versions (with returns and conditional statements) compile fine. However,
neither of them works. Both versions crash on browser startup on:
JS_GetProperty(cx, stack, source, source)
Hmm. It's possible that stack came back null if the call into the
On 1/26/15 12:48 PM, Tomasz wrote:
In what cases were the early-return cases actually hit? They correspond
to things like out-of-memory conditions and should not have been getting
hit...
Here:
cgThings.append(CGGeneric('if (!stack) {
On 1/26/15 11:49 AM, Tomasz wrote:
Using immediate returns from the functions was not a good solution as it was
breaking functions where some operations were performed after our code
In what cases were the early-return cases actually hit? They correspond
to things like out-of-memory
On 1/30/15 1:30 AM, nsm.nik...@gmail.com wrote:
Well my work on getting FormData on workers was because Fetch uses it, and
there doesn't seem to have been demand for it on workers before.
That's fair, but it seems like exposing it separately, if it's going to
be ready before the rest of
On 1/30/15 1:25 AM, nsm.nik...@gmail.com wrote:
https://bugzilla.mozilla.org/show_bug.cgi?id=1127703
Thanks.
The fetch spec states that FormData is immediately serialized when send() is called (send
defers to Fetch's extract body routine)
On 2/1/15 4:36 PM, Mats Palmgren wrote:
CSS display:contents has been enabled by default in v37 and my intent
is to ship this feature in v37 on all platforms.
Do we have any indication on whether any other UAs are planning to ship
this?
-Boris
___
On 1/20/15 11:42 AM, Tomasz wrote:
cgThings.append(CGGeneric('nsPIDOMWindow* cwindow =
xpc::WindowGlobalOrNull(obj);\n'))
Yep, that looks good.
error: cannot convert 'nsGlobalWindow*' to 'nsPIDOMWindow*' in initialization
Right, because WindowGlobalOrNull returns nsGlobalWindow*, but the
On 1/21/15 11:22 AM, Tomasz wrote:
---
2:18.70
/home/tomasz/CPPProjects/mozilla-central/obj-x86_64-unknown-linux-gnu/dom/bindings/TestDictionaryBinding.cpp:11:28:
fatal error: nsGlobalWindow.h: No such file or directory
On 1/22/15 9:30 AM, Tomasz wrote:
So, any idea how to fix the following error?
Remove 'signaling_unittests' from the list of tests in
http://mxr.mozilla.org/mozilla-central/source/media/webrtc/signaling/test/moz.build
?
Uh.. why is that #including the binding _cpp_ file? That's broken.
On 2/18/15 12:06 PM, nsm.nik...@gmail.com wrote:
1) ESR - FF 38 is an ESR release and shipping a new API with some parts not yet
supported may not be the best thing to do. What is the usual policy in such a
situation?
How happy are you backporting security fixes for this code that pop up
On 2/19/15 2:26 PM, Benjamin Kelly wrote:
It seems to me that backporting to dom/fetch should be relatively
straightforward. Its pretty isolated code.
The real question there is how much churn you expect in that code over
the next year as the pieces that aren't one yet end up happening.
On 1/23/15 7:50 AM, Tomasz wrote:
This is not what I wanted :) I want to have the exact URLs of the particular
files in which the calls were. So, if a particular method is called from a
JavaScript from Doubleclick.net, I expect to get a URL of this JavaScript.
Yeah, you didn't say that up
On 1/8/15 9:16 PM, Joshua Cranmer wrote:
* Forward declaration of enums
YES!!! This is actually pretty useful for Web IDL enums, since it means
you don't have to include the binding header in your implementation
header just to get the enum.
-Boris
201 - 300 of 952 matches
Mail list logo
