On 9/11/13 2:13 PM, Marcos Caceres wrote:
callback PromiseInit = void (object resolve, object reject);
[Constructor(PromiseInit init)]
interface Promise {...}
What members does PromiseInit dictionary have? ^_^
It's not a dictionary. It's a callback, like the IDL snippet above says.
So
On 9/16/13 10:36 PM, Adam Kowalczyk wrote:
Alright then, *would* be useful if supported more widely, is what I
should have said.
My point is the counterfactual has been given a chance and failed
If there's no hope for getting traction with other vendors, then it
pretty much settles it.
On 9/20/13 11:14 AM, Patrick Brosset wrote:
The helper is here:
http://mxr.mozilla.org/mozilla-aurora/source/toolkit/devtools/LayoutHelpers.jsm#370
379 if (docShell.isBrowserOrApp) {
...
389 } else {
390 return win.frameElement;
391 }
So for anything on desktop it is in fact
On 9/20/13 12:24 PM, Paul Rouget wrote:
@all: Is there a way to know which DOM element holds a docShell? Basically,
which
iframe owns the docshell?
We should add one as needed.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 9/20/13 6:23 PM, Bobby Holley wrote:
It seems like we're going to need a story for this kind of stuff.
Sure. That story may not be WebIDL (e.g. there are proposals to not
have a Date type in IDL at all and just use raw numeric timestamps for
dates).
One major goal of the bindings is
On 10/2/13 3:33 PM, Erik Rose wrote:
What keeps you off DXR? (What are the MXR things you use constantly? Or the
things which are seldom-used but vital?)
MXR things I use constantly that don't seem to have obvious dxr
counterparts:
* Search on the firefox tree to follow pre-hg blame.
On 10/8/13 10:32 PM, Justin Dolske wrote:
Would that be a kungFuDeathGrep? (Sorry. Just making weak pun.)
You mean mozilla::WeakpPunT?
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 10/9/13 12:01 PM, Gervase Markham wrote:
In the spirit of learning from this, what's next on the chopping block?
RDF
* XSLT (Chrome have already announced they will remove it:
We'd need to do the same extension thing they're proposing or something;
this is used in the wild for sites
On 10/9/13 2:25 PM, Ehsan Akhgari wrote:
On 2013-10-09 12:18 PM, Boris Zbarsky wrote:
On 10/9/13 12:01 PM, Gervase Markham wrote:
In the spirit of learning from this, what's next on the chopping block?
RDF
We use RDF in Firefox, in localstore.rdf among others I guess.
Right. We should
On 10/9/13 8:36 PM, Zack Weinberg wrote:
if Web Components lives up to its
promise, perhaps it could be used for the built-in form controls?
For what it's worth, we've tried that with XBL. It died on the
performance and memory usage beach...
-Boris
On 10/10/13 10:28 AM, Axel Hecht wrote:
My point is, the perf was completely abysmal, and the key is to use
nsINodeInfo for the xpath patterns instead of DOM localName and
namespaceURI string comparisons.
This may still be an issue, though I wouldn't be surprised if the speed
of .localName in
On 10/10/13 12:43 PM, Matthew Gertner wrote:
This page loads script both from the local disk (using the same protocol handler) and
remote script loaded via HTTPS. When I try to access properties on objects instantiated
in the remote script from my local script, I get permission denied errors.
On 10/10/13 1:06 PM, Matthew Gertner wrote:
Yes. Not sure if it's relevant but the remote script (and some of the local scripts)
are loaded using RequireJS, which means that the script tag is added
dynamically to the document after if has finished loading.
Shouldn't matter.
So you're
On 10/11/13 7:42 PM, Zack Weinberg wrote:
On 2013-10-11 1:08 PM, Ralph Giles wrote:
On 2013-10-10 12:28 PM, Steve Fink wrote:
It seems like the optimal efficiency vs surface exposure vs frequency
of use tradeoff would be to do everything but the top formats (JPG,
PNG, GIF?) in JS.
That's
On 10/11/13 10:23 PM, Kyle Huey wrote:
Are you sure? I thought we killed pluggable decoders a while back.
Hmm. I didn't realize that. In that case, I'm not sure. :(
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 10/29/13 4:42 PM, Boris Zbarsky wrote:
In that case, we might as well switch to typedefs. JS engine hackers
are landing them in non-JS code anyway, because they're so used to it in
their own code (c.f. bug 884410 and bug 930782 at the very least, making
changes to DOM code to add typedef
On 10/31/13 3:05 PM, Monica Chew wrote:
Can we agree on using the using directive instead of typedefs when it comes to
namespaces? I think it's less likely to lead to confusing compile errors than
typedefs.
class nsSVGUtils
{
using mozilla::gfx::FillRule;
I believe this is not valid C++,
On 11/9/13 12:53 PM, Philip Chee wrote:
Not directly related but. Some time back I wanted to turn on profiling
for SeaMonkey on our trunk builds but was vetoed because turning on
profiling (I was told) causes a pref hit.
It does, but a pretty small one, and only on x86-32 (because there is
On 11/17/13 5:26 PM, Ehsan Akhgari wrote:
I don't think that we need to try to fix this problem any more than the
general problem of denoting our dependencies explicitly. It's common for
you to remove an #include from a header and find dozens of .cpp files in
the tree that implicitly depended
On 11/19/13 12:05 PM, David Rajchenbach-Teller wrote:
Generally, I believe that it's a good idea, if DOM Promises have the
equivalent of:
https://dutherenverseauborddelatable.wordpress.com/2013/10/14/recent-changes-to-promise-jsm-and-task-jsm/
Is this the case already?
It's been the case
On 11/20/13 6:51 AM, Anne van Kesteren wrote:
On Tue, Nov 19, 2013 at 5:30 PM, Boris Zbarsky bzbar...@mit.edu wrote:
We could report all rejections, but I'm a bit leery of adding so much noise
that people start ignoring the report altogether; a common problem in the
past.
Given that we report
On 11/20/13 7:34 AM, Boris Zbarsky wrote:
We could certainly try to report everything. It would be pretty
bare-bones, since for things that are not Error we don't have line/file
information as to where they originated, so all we can report is that
some promise somewhere was rejected
On 11/21/13 2:00 PM, Paolo Amadini wrote:
I hope to see a comparable or even better level of debuggability in the
native Promise implementation soon!
Are there bugs filed on what's missing here? It should be pretty simple
to implement all sorts of things here as needed, but we need a clear
On 11/21/13 3:15 PM, Gavin Sharp wrote:
It would be good to explore alternatives to Bonsai.
https://github.com/mozilla/mozilla-central is supposed to have full
CVS history, right?
Hmm. Where in there is the equivalent of
On 11/21/13 2:43 PM, Laura Thomson wrote:
it's a search engine for some of our CVS repositories
It's not just a search engine. It's also the only way to get CVS blame
sanely without doing a local pull of the CVS repository or trying to
make git do something useful for you. And a lot of our
On 11/22/13 9:40 AM, Benjamin Smedberg wrote:
Is for..of on live DOM nodelists supposed to correctly iterate even when
items are removed from the list?
I believe the current behavior is identical to what would happen with an
array here. Consider http://jsfiddle.net/hpmHg/3/
The core issue
On 11/22/13 11:41 AM, Ehsan Akhgari wrote:
Hmm to the best of my knowledge, we don't generate the *.i files unless
if you explicitly request them. Is that what you did in that build?
ccache obvously always generates .i files, since those are what it uses
as its cache key.
And then it
On 11/22/13 12:11 PM, Aki Sasaki wrote:
I'm not seeing this in gecko-dev; can you find this same issue in
that repo?
No, this one behaves sanely. Going to the parent of the relevant
changeset gets you to a changeset where
layout/html/forms/src/nsGfxTextControlFrame2.cpp is present, and
On 11/25/13 1:31 PM, Ryan VanderMeulen wrote:
What does the OOM rate of 32bit builds on Win64 have to do with whether
or not making 64bit Firefox builds would help?
I think Benjamin's point was that only about 1/4 of the OOM crashes were
on Win64 [1]. The rest were on Win32, and hence would
On 11/25/13 7:07 PM, L. David Baron wrote:
http://www.w3.org/TR/performance-timeline/
Performance Timeline
http://www.w3.org/TR/user-timing/
User Timing
Have we had anyone at all review these specs? My past experience with
that working group and set of editors doesn't make me
On 11/27/13 11:51 AM, Rob Campbell wrote:
IMO, this is implementation detail for describing the data structures used by a
timeline “entry”
There are specs that expose these entries too, so this is not
implementation detail but something we'll need to end up implementing
when Facebook and
On 12/2/13 11:39 PM, Mike Hommey wrote:
1. By the way, those type of bugs that show up at different number of
unified sources are existing type of problems waiting to arise when we
add source files, and running non-unified builds doesn't catch them.
A number of the ones I saw you file seemed
On 12/4/13 3:17 PM, Lawrence Mandel wrote:
Very true. However, at least in this case, if the bug had been closed at some
point, the issue still would have surfaced when it became relevant due to the
filing of duplicate bug 924048. In fact, there are 42 duplicates of this bug
that have been
On 12/10/13 9:49 AM, Benoit Jacob wrote:
since AFAIK we don't have a HashSet class in mfbt or xpcom.
It's called nsBaseHashtable. Granted, using it as a hashset is not that
intuitive.
-Boris
___
dev-platform mailing list
There's been a bit of silence on this front after the big Node push
ended, but at this point https://etherpad.mozilla.org/classinfo is
tracking the list of remaining interfaces that are exposed to the web in
any way but not entirely on WebIDL bindings yet.
Some of these have associated bugs
On 12/12/13 10:34 PM, Gregory Szorc wrote:
Just landed in inbound are patches that hopefully resolve the issue
where WebIDL changes required a clobber on Windows.
Thank you again for picking this up and getting it done!
-Boris
___
dev-platform
https://wiki.mozilla.org/WebAPI/ExposureGuidelines has the guidelines we
decided on for new web APIs. Please remember to follow these when
adding or modifying any web-exposed APIs.
Also, please remember that we generally have an sr requirement for
web-facing API changes.
And if you
On 1/7/14 12:47 PM, Martin Thomson wrote:
I’ll just point out that this isn’t a bug if there are test cases that pass.
That depends on whether the test cases are correct (e.g. whether they
were written independently of the code, whether they were reviewed, etc)
-Boris
On 1/7/14 2:29 PM, Mike Hoye wrote:
- Indent with 4 spaces,
Mike, do you have the background on why 4 is preferred to 2? The things
you cite don't seem to differentiate between these two options...
One reason I've seen 2 preferred to 4 (apart from keeping line lengths
down) is that:
On 1/7/14 7:57 PM, Mark Finkle wrote:
Changing the line length policy would also avoid needing to wrap the multiple
conditions onto separate lines.
I often wrap conditions just to make the more readable... Something like
this:
if ((x || y) (z || w))
is a lot less readable for me than:
On 1/8/14 1:08 PM, Garrett Robinson wrote:
Can an emacs modeline execute arbitrary elisp?
It can if it uses certain modeline features.
The default behavior of emacs is to silently apply the modelines that
don't use those features and for the ones to do not apply them unless
the user explicitly
On 1/16/14 7:15 AM, Sergi Mansilla wrote:
I still think that automatically batching the changes that DOM operations cause
at the end of the event loop
This is already basically done in Gecko, no? Unless you explicitly
flush out layout or style, we don't actually update them when the DOM
On 1/16/14 12:05 PM, Ted Mielczarek wrote:
Have you tried `mach build binaries`?
That doesn't do the same thing as mach build dirname, though.
Certainly not for dom/bindings...
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 1/16/14 2:29 PM, David Bruant wrote:
I don't understand the last sentence. Is memory corruption referring to the
global state you mentioned before?
Yes.
When you wrote parallel-safe above, was that implicitly thread-parallelism?
Yes.
As a web developer, I'm happy with
On 1/30/14 5:03 AM, Till Schneidereit wrote:
What are the plans for moving Promises into SpiderMonkey?
Moving Promises per se is not hard.
The hard part is that this requires SpiderMonkey to grow a concept of an
even loop. And then we have to decide whether it's built-in or
On 2/3/14 12:36 PM, Gregory Szorc wrote:
Also, I believe chrome JS is never JIT compiled, so not getting JIT
benefits with generators doesn't seem like a concern?
Chrome JS running in a window context (script elements from XUL
documents and overlays) is currently baseline compiled but not ion
On 2/12/14 4:46 AM, Masayuki Nakano wrote:
I'm not sure which is the best name for the classes. E.g., DOMWheelEvent
vs. PointerEvent.
I believe in this case PointerEvent is correct, because
http://www.w3.org/TR/pointerevents/#pointerevent-interface but
DOMWheelEvent should probably be just
On 2/12/14 8:44 AM, Girish Sharma wrote:
I want to track the creation and removal of docshells from a top level
content docshell. Is it possible ?
There are no built-in facilities for this right now, as far as I can
tell. You could simply add something
One option would be to watch
On 2/12/14 9:44 AM, Gijs Kruitbosch wrote:
Dumb question: Could you listen for dom-window-destroyed
You could, but if the window gets bfcached that gets delayed somewhat
indefinitely, no?
-Boris
___
dev-platform mailing list
On 2/12/14 10:23 AM, Girish Sharma wrote:
I am wondering, is this why google.co.in also not emit an unload event on
the chrome vent event handler ?
Most likely, yes.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 2/17/14 9:29 AM, Ms2ger wrote:
For C++ interfaces, namespaced IFoo or Foo.
namespaced IFoo always makes me search MSDN for information about this
Windows interface we must be using... Why is that form preferable?
-Boris
___
dev-platform
On 2/20/14 5:27 AM, Arpad Borsos wrote:
njn suggested I post the complete list, so here goes. Feedback welcome.
It'd be pretty awesome to get some idea of the number-of-objects
distribution for these objects, so we have a metric of how much memory
we'd save. Saving 58 bytes in the singleton
On 2/21/14 6:07 AM, Masayuki Nakano wrote:
nsDOMEvent will be just Event.
Just like Element is just Element as long as you're in DOM code, yes.
This is a good thing, imo.
Of course in code not in the mozilla::dom namespace, you get
mozilla::dom::Event or dom::Event, which seems fine to me.
On 2/26/14 3:58 PM, Wesley Hardman wrote:
Personally, I would prefer to have it already available.
We have several deployment targets with different tradeoffs. Broadly
speaking:
Phones: expensive data, limited storage. Want to not use up the
storage, so download lazily.
Consumer
On 2/26/14 11:06 PM, Masayuki Nakano wrote:
I'd like to want some suggestions about our classes which do NOT
represent DOM classes.
I don't have terribly strong opinions on these, in general...
1. All of them which don't start with nsDOM are in mozilla.
This seems fine as a general rule of
On 2/28/14 10:49 AM, Gregory Szorc wrote:
Speaking of compiler warnings, do people commonly run into compiler
warning mismatch with warnings-as-errors due to running separate
versions of Clang/GCC/MSVC locally than what runs in automation?
I did, to the point where I locally don't
On 2/28/14 12:26 PM, Neil wrote:
Perhaps we could probably use string buffers directly as atoms.
Atoms have various info string buffers don't (like the hashcode).
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 2/28/14 3:48 PM, Gregory Szorc wrote:
* A lot of us want to kill client.mk. Having automation not directly
calling it will allow us to finally do this.
This will make bisects a bit exciting, because the right command to run
to do a toplevel build will depend on the exact revision you have
On 3/3/14 1:54 PM, Jan Honza Odvarko wrote:
An example of the stack trace:
http://example.com/path/file.html:102
Which exact API is this string coming from? We have a number of
different APIs here, returning slightly different things. :(
-Boris
On 3/3/14 2:28 PM, Felipe G wrote:
A possible solution to that is to only pause the page that is being translated
(with,
say, EnterModalState) until we can finish working on it, while letting
other pages and the UI work normally.
The other pages can still modify the DOM of the page in
On 3/3/14 9:07 PM, Boris Zbarsky wrote:
document.documentElement.cloneNode(true): ~18ms
document.cloneNode(true): ~8ms
Oh, and the difference between these two is that in the former clones of
img elements try to do image loads, which takes about 70% of the
cloning time
On 3/5/14 3:50 AM, Martin Thomson wrote:
For my gratification, why is this information not also provided as an object?
It is, for XPConnect/DOM exceptions. Just not for built-in JS ones...
-Boris
___
dev-platform mailing list
On 3/5/14 12:10 PM, WaltS wrote:
I'm all for moving forward with option #4.
As long as #4 will have a way to subscribe to a list and get in the
right mail folder the old mails as well, correctly threaded with new
ones, sounds good. The problem is, doing that with SMTP is rocket science.
On 3/12/14 10:43 PM, Ehsan Akhgari wrote:
That being said, doing that probably means doing the work to
expose the base interface (nsIDOMCSSRule) as well. Do you mind doing
this before landing this code please?
Converting CSSRule is actually somewhat nontrivial because the C++
inheritance
We're at a point where we are actively trying to eliminate xpconnect
usage on the web.
I'm happy to enumerate the reasons we're doing that if people care, but
the practical upshot is:
1) Do not add new objects with classinfo to nsDOMClassInfo.cpp unless
you've explicitly been told it's OK
On 3/14/14 7:09 PM, Neil wrote:
Not that I'm planning on adding any new components, but what
alternatives are there, particularly for non-core consumers?
For core consumers, JS-implemented WebIDL is the way to go.
For non-core, if you control the Gecko you build against, then the
answer is
On 3/15/14 4:31 PM, smaug wrote:
I think we should add some checks to test_interfaces to enforce this.
(Assuming we can detect xpcom stuff via different kind of prototypes vs.
webidl implemented stuff)
We actually can: the toString() in the prototype object returns very
different things in
On 3/17/14 9:25 AM, Benjamin Smedberg wrote:
Isn't this something which pagemod addons and greasemonkey already do?
To some extent. In a lot of cases, those are running with the principal
of the page, not with a system principal; that makes a big difference.
Do we not have a safe way now
On 3/19/14 9:41 PM, Justin Dolske wrote:
It uses a weak reference with the observer service, plus a dummy strong
reference (via addEventListener()) to automatically manage the
lifetime... When the node/document does away, so does the event listener.
This is sort of ok for notifications that
On 3/19/14 10:40 PM, Ehsan Akhgari wrote:
Why do we have to touch that list on shutdown?
We Release() all the things in it (nsIWeakReferences in this case).
That said, the minutes cases are the ones where the notification is
one that's actually fired at shutdown, because then we start
CSS.escape is an API defined at
http://dev.w3.org/csswg/cssom/#the-css.escape%28%29-method which allows
web pages to create a valid CSS identifier that will parse to a given
string. A typical use case is:
document.querySelector('#' + CSS.escape(stringIDontControl))
Unless there are
On 3/20/14 12:11 PM, Anne van Kesteren wrote:
Seems fine, specification should probably clarify surrogate handling.
I would expect a paired surrogate in JavaScript to end up as a single
escape.
Non-ASCII stuff is OK in CSS idents, so it doesn't need escaping at all:
it's just left as-is.
On 3/21/14 11:02 AM, Bobby Holley wrote:
I'm also curious to hear about the overhead of compartments now that we
have zones.
An important question: which of these system compartments actually share
a zone with each other? I know the goal is all of them, but are we
actually getting there?
On 3/21/14 1:09 PM, Bobby Holley wrote:
For JSMs and stuff, they should all go into the system zone.
I realize that, emphasis on should. Have we verified that this is
happening?
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 3/21/14 6:34 PM, Jim Blandy wrote:
What if these DOM nodes
I don't believe there are any DOM nodes involved in the situation that
Kyle described at the start of this thread...
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 3/23/14 1:38 AM, Jim Blandy wrote:
For example, suppose we had:
observerService.addSettingObserver(obj, dirty, true)
which promises to set obj's 'dirty' property to true. If obj is
collected, this observer can obviously be dropped.
How do we know when obj is collected?
Or put
On 3/23/14 2:21 AM, Jim Blandy wrote:
See my slightly longer explanation in the previous message. The
advantage over passing true for ownsWeak is that my proposed API is
completely deterministic.
I'm not sure I follow The current setup in the observer service is
also completely
On 3/23/14 2:55 AM, Jim Blandy wrote:
I hope we're not talking past each other... the visible behavior of
Services.obs.addObserver(glurph, () = { alert(Glurph!); }, true)
(pretending that the function supported nsIWeakReference) depends on
when the GC notices the function is garbage. No?
Ah,
On 3/25/14 2:22 PM, Matthew Gertner wrote:
Is this a bug or am I misunderstanding something about the way the
DOMWindowCreated event works?
Is the url about:blank when the window is created, perhaps? It's hard
to say without knowing exactly what you're logging/measuring.
-Boris
On 3/26/14 10:13 PM, Botond Ballo wrote:
The name compression is unfortunate here. It took me some time to
understand what the real issue is.
Agreed. (Any ideas for a better word? For me 'supersede' comes to mind,
as in a newer message supersedes an older one so the older one can be
dropped,
On 3/28/14 2:15 PM, Gregory Szorc wrote:
I'm concerned about this as well.
Is the concern the spew, or the performance of changing __proto__?
In practice, what gets slow with a changing __proto__ is property access
on the object, because the JS engine throws away type inference
information
On 3/28/14 4:03 PM, David Rajchenbach-Teller wrote:
The prototype mutation is hardly necessary for bug 939072, it is just a
nice way to avoid a few indirections.
Note that indirection is not free in perf terms either.
But again, I doubt that the code in bug 939072 is gated on property
access
On 3/28/14 5:42 PM, Benoit Jacob wrote:
So... maybe MOZ_MAYBE_PLAY_STARCRAFT?
I'd like to suggest MOZ_IF_REACHED_EXPLODE_COMPUTER.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 3/29/14 8:55 AM, Paolo Amadini wrote:
- You get better performance on long Promise chains
Do we have hard data on this? I would be very interested in testcases
that show performance issues with the Promise objects we're shipping on
the web.
-Boris
On 3/29/14 9:00 AM, Mike Hoye wrote:
I've lowered the karmic threshold for wiki edits to 30
Thanks!
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 3/29/14 2:33 PM, Gregory Szorc wrote:
If Promise.jsm is obviously superior
It's not, as far as I can tell. Nor is it fully API-compatible with the
Promise spec. For example, it has no Promise.race and no
Promise.prototype.catch. So code that expects per-spec behavior may not
work with
On 3/29/14 4:57 PM, Boris Zbarsky wrote:
For example, it has no Promise.race and no
Promise.prototype.catch.
And Promise.resolve() can throw in the case of Promise.jsm (which it can
never do per spec). I didn't dig into the details of the implementation
to look for any other
On 3/30/14 6:00 AM, Paolo Amadini wrote:
It does, as soon as bug 941920 lands. We were holding it off due to
compatibility concerns, but the general availability of the DOM Promise
object changes the landscape and we're crash-landing it (I'd have
appreciated some coordination on this, but bug
On 3/31/14 8:18 AM, Paolo Amadini wrote:
I've edited bug 939636 to depend on three key issues out of the list
I posted before. I think that once those are addressed, there will be
no reason to stick to Promise.jsm any longer.
Thanks. I'll see what I can do about getting these knocked out.
TL;DR: If you need to produce a JS::Value from some C++ type, use
mozilla::dom::ToJSValue. Anything else will probably need to be
search-and-replaced out of the codebase later.
Background: There are some situations in which it's not possible to just
use WebIDL bindings to handle conversions
On 4/11/14 10:41 PM, Boris Zbarsky wrote:
4) A reference to a WebIDL-binding object which inherits from both
nsWrapperCache and nsISupports.
5) A reference to any C++ type which singly-inherits from nsISupports
(e.g. any nsIFoo).
6) An nsRefPtr or nsCOMPtr around an object that satisfies
On 4/14/14 5:13 AM, Aryeh Gregor wrote:
But doesn't Mercurial hide all but the first line by
default in the places you'd normally look for it (e.g., log)?
The normal place I'd look for the detailed message is something like
https://hg.mozilla.org/mozilla-central/rev/, which shows the
We've been shipping :scope in querySelector(All) for a while now,
enabled in nightly/aurora, disabled in beta/release.
The spec is no longer trying to do wild and wooly stuff with it, so I
believe our implementation matches the spec.
Any objections to turning this on? Anyone actively in
On 4/21/14, 11:35 PM, Joshua Cranmer wrote:
I'm referring to using a Promise, essentially, in backend code of
Thunderbird. There is no window
I mean Window in the DOM Window sense.
Promises can be created using some other global (which one is up to the
person creating it), but typically
On 4/22/14, 12:24 AM, Joshua Cranmer wrote:
I managed to, in one of my playground techniques, create a global using
a backstage pass and some xpconnect APIs, so it's not impossible but it
is damn annoying.
Right. If you don't have a global to start with, your life will
_really_ suck if you
On 4/22/14, 2:51 AM, Joshua Cranmer wrote:
I'm giving to thinking in terms of all of the magic hiding that
XPIDL/XPCOM/xpconnect does, so things like what is my global object
being intrinsically important are annoying to me.
I understand that.
but something like Promises or TextEncoder
On 4/22/14, 9:30 PM, Ehsan Akhgari wrote:
Do we currently return NS_OK from Necko in such circumstances or another
error code?
Currently we return NS_OK, so the necko client thinks the transfer
completed successfully.
-Boris
___
dev-platform
On 4/22/14, 10:06 PM, Ehsan Akhgari wrote:
That seems like a huge behavior change. :(
Yes, it is. There's some at-length discussion in the bug about what
behavior various consumers want here.
-Boris
___
dev-platform mailing list
On 4/23/14, 5:08 PM, Ehsan Akhgari wrote:
Do you know if other UAs already ship this, or have plans for doing so?
Testing on
http://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2965
indicates that release versions of Safari and Chrome ship this, while IE
11 does not. Neither does
On 4/26/14, 11:32 AM, Zack Weinberg wrote:
it might be better to just create files in the ultimate target
directory if we aren't already.
We create the file before the user has picked the ultimate target directory.
-Boris
___
dev-platform mailing
101 - 200 of 952 matches
Mail list logo
