Re: Linux builds now default to building with Gtk+3
Just so people know, ASan builds with GTK3 crash immediately on startup, so you'll want to keep the gtk2 version as described below. Andrew On Wed, Jul 22, 2015 at 6:38 PM, Mike Hommey m...@glandium.org wrote: Hi, If you've followed the recent discussion in the GTK3 linux builds thread, this will come with no surprise, but if not: - Next Linux nightly will have switched to Gtk+3. - As of now on mozilla-inbound, and later on other branches, local Linux (and other non-OSX unices) builds default to Gtk+3. - You will need to install Gtk+3 development files to do those local builds. `mach bootstrap` should be able to do this for you. - You can still do Gtk+2 builds by adding the following to your mozconfig: ac_add_options --enable-default-toolkit=cairo-gtk2 - You can still do Gtk+2 try builds by removing the gtk3.tar.xz entries in browser/config/tooltool-manifests/linux*/releng.manifest. - The Gtk+3 builds that were available on the elm branch will auto-update to normal nightlies in the next few days. - I will switch elm to do Gtk+2 builds, to ensure they don't break in the near future. I'm not sure how long I will keep that running. Big kudos go to, as far as I know, Andrew Comminos, for fixing all the remaining reds and oranges on the Gtk+3 build and allowed to make this possible. And to all the people involved in making the Gtk+3 port work in the first place. Cheers, Mike ___ 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 implement: Moving DevTools to top level /devtools directory
On Thu, Jul 23, 2015 at 11:43 AM, J. Ryan Stinnett jry...@gmail.com wrote: On Thu, Jul 23, 2015 at 8:11 AM, Paul Rouget p...@mozilla.com wrote: I guess by moving things to /devtools/, you also want to update the URLs to chrome://devtools/content. So then, we can compile and open the devtools with non-firefox builds (thunderbird, b2g, seamonkey, ...). But if the devtools include browser code, this won't work. For example, we import chrome://browser/content/utilityOverlay.js, which is Firefox only. The main goal of this work is around making the DevTools codebase more approachable for contributors. We're not explicitly setting out to make reusing the front end easier from non-Firefox, but certainly moving out of /browser is one nudge in the right direction down that path. I'm guessing we'll still have some browser dependencies for the moment, but I'll take a look at this as I work on the file moves. That's correct. The use case is, again: * git clone devtools * ./nightly * point devtools source directory to the git clone * hack on firefox devtools in Nightly, reloading the source as need be Anything else can wait until later as Ryan suggested. Paul: are there things you want for graphene? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charters: All Groups, XML Activity
On Tuesday 2015-07-21 12:14 +0100, James Graham wrote: On 21/07/15 11:29, Ms2ger wrote: This entire Activity is a distraction from the real needs of the web, and if the W3C is serious about its motto, it should focus on those rather than providing support and hosting conferences for people's petty side projects that have no bearing on the web. However, I'll already be happy if we can kill the XForms zombie. Apparently they've had a group in plh's Domain for years, and never produced anything of consequence, and now that he's finally managed to kick them out, they want to return through this back door. If the handful of people who still care about it want to continue wasting each other's time, they can always start a Community Group, or move to another standards development organization. I agree with everything Ms2ger said. I don't think that working on non-web technologies is helpful to the W3C's stated mission, and I think we should encourage those who wish to develop such standards to do so at other venues, leaving the W3C free to give much-needed focus to web-related work. I think it might be easier to make the argument that the groups that are nearly inactive (e.g., EXI, XForms, as far as I can tell) should be ended than to make that argument for groups that actually have active participation and interest (whether relevant to the Web or not). I'm not sure it's really a fight I want to take on right now, though. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Moving DevTools to top level /devtools directory
I guess by moving things to /devtools/, you also want to update the URLs to chrome://devtools/content. So then, we can compile and open the devtools with non-firefox builds (thunderbird, b2g, seamonkey, ...). But if the devtools include browser code, this won't work. For example, we import chrome://browser/content/utilityOverlay.js, which is Firefox only. On Thu, Jul 23, 2015 at 11:36 AM, Panos Astithas p...@mozilla.com wrote: On Thu, Jul 23, 2015 at 8:25 AM, Paul Rouget p...@mozilla.com wrote: On Wed, Jul 22, 2015 at 2:48 PM, Panos Astithas p...@mozilla.com wrote: If you are thinking about shipping them as part of browser.html, we still have XUL dependencies that we need to get rid of first and that work is independent from moving the code to a top-level devtools/ directory. We don't use XUL, but we can still open XUL windows. Would it be possible to use the devtools without chrome://browser/ being accessible? I doubt it, although, to be honest, I am not entirely sure. We already use paths like chrome://browser/content/devtools/debugger.xul in the code, so they would have to be changed first. Would using resource: URLs work better for browser.html? -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implement Fetch?
On 2015-07-17 2:16 PM, Benjamin Kelly wrote: I thought a little bit more about this after stepping away from my computer. I think some of our implementation issues for service workers currently stems from the fact that the fetch spec and necko have modeled the problem with different primitives: - necko provides an object (nsIChannel) to represent the ongoing network request. The network request is described as parameters to the creation of the channel object. The response is defined as a series of callbacks on the nsIStreamListener interface. - In contrast, fetch defines object primitives for Request and Response, but has no explicit object to represent the on-going network request. These are both reasonable ways of doing things, but the impedance mismatch between the two makes it difficult to accurately translate the new specs into gecko. It might be nice to move the DOM code to use the Request/Response model to align things better with the spec. One approach we could take would be to add a new internal networking interface oriented around Request and Response objects. Internally it would still use nsIChannel, but would do all the work to translate to and from Request/Response. The DOM code would then be modified to create a Request, call this interface, and then process the returned Response. We already mostly have this interface in Fetch.h/FetchDriver.h, but we would probably need to adjust it a bit. For example, some of the referrer logic is handled in Fetch.h which requires the use of globals and Promises. In theory, though, we should be able to move this into FetchDriver and provide a clean internal interface to use. We could then start migrating consumers of NS_NewChannel() to the new FetchDriver interface. This would need to be done one-by-one and would probably run into problems with how to specify internal flags and stuff. It would be an incremental approach to use a Request/Response oriented model in the DOM code. I guess this is probably what you were originally suggesting and I was jumping to conclusions that you wanted to replace nsIChannel. Sorry for that. Anyway, what do people think? I think this is a good idea in general, but I'm not sure how well the high level fetch API would map to something internal. Off the top of my head, currently the process of loading something from the network in Gecko (at least for the stuff that we load on behalf of a web page) looks like the following (apologies if I'm forgetting something!): * Construct an nsIURI. Might need to take things such as the document base URI and charset into account. * Check to see whether the principal of the document or the object requesting the load can load that URL. * Check the content policy implementations to see whether they want to block the load. * Create a new channel. Here we may need to deal with details such as the load flags, setting the right loadgroup/notification callbacks, managing the privacy state of the channel if needed, etc. * Deal with the referrer. * Setup an upload stream for POST/etc. * Setup the priority of the channel, if needed. * Deal with CORS, if needed. * Setup the intercept controller if it cannot be obtained through the laodgroup/notification callbacks. * Decide how you would like to consume the content (as in, do you care about individual OnDataAvailable notifications for a streamed load, or do you only care about the final result for a non-streamed one.) * Open the channel (unless you need to do a CORS preflight!) There are some concepts here that do not exist in the current fetch spec (for example, load groups) so we would need to add those to our internal APIs. Also, some of the existing concepts (such as streamed Responses) may not be quite fleshed out yet. Therefore, we need to figure out how to design the internal API in a way that gives us the flexibility that we need in some cases, but also be close to the concepts in the fetch spec, and that is tricky. :-) But it seems like what the Necko/Security teams are working on right now is a step in this direction, and that's great! I should also mention that in addition to the security concerns around fetch interception through service workers, the above steps is *insanely* complex, and almost every time that someone who is not deeply familiar with all of the above steps tries to load something from the network, they're pretty much guaranteed to forget something and as a result potentially open security holes! I look forward to a future where mere mortals can load stuff from the network in Gecko. :-) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Hash table iterators, and a call for help
On Fri, Jul 24, 2015 at 2:06 PM, Philip Chee philip.c...@gmail.com wrote: Does PL_HashTableEnumerateEntries also need to be replaced? And if so what with? That function operates on PLHashTable, which is part of NSPR. (Don't confuse it with PLDHashTable, which is part of XPCOM, as are its subclasses.) It could be replaced with an iterator, though there are two wrinkles: - nsprpub/lib/ds/plhash.c is C, not C++, which would make things harder. - NSPR is kind of a pain to modify. I wonder if converting all the uses of PLHashTable into PLDHashTable would instead be a better approach. Either way, there aren't that many uses of PL_HashTableEnumerateEntries() and I don't think anybody is writing new code that uses PLHashTable, so it's not a compelling change to bother with, IMO. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Proposed W3C Charters: All Groups, XML Activity
On Thu, Jul 23, 2015 at 3:43 PM, L. David Baron dba...@dbaron.org wrote: I'm not sure it's really a fight I want to take on right now, though. Trying to kill things at W3C has generally not seemed worth the effort to me. It's better to ignore it and let it die out by itself due to lack of attention. But being super clear that we don't plan to implement or review any aspects of this group sounds good to me. And leaving a comment that we'd prefer to see the WG closed also seems worth the effort. Chasing it beyond that does not. At least to me. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Moving DevTools to top level /devtools directory
On Thu, Jul 23, 2015 at 10:54 PM, Jeff Griffiths jgriffi...@mozilla.com wrote: On Thu, Jul 23, 2015 at 11:43 AM, J. Ryan Stinnett jry...@gmail.com wrote: On Thu, Jul 23, 2015 at 8:11 AM, Paul Rouget p...@mozilla.com wrote: I guess by moving things to /devtools/, you also want to update the URLs to chrome://devtools/content. So then, we can compile and open the devtools with non-firefox builds (thunderbird, b2g, seamonkey, ...). But if the devtools include browser code, this won't work. For example, we import chrome://browser/content/utilityOverlay.js, which is Firefox only. The main goal of this work is around making the DevTools codebase more approachable for contributors. We're not explicitly setting out to make reusing the front end easier from non-Firefox, but certainly moving out of /browser is one nudge in the right direction down that path. I'm guessing we'll still have some browser dependencies for the moment, but I'll take a look at this as I work on the file moves. That's correct. The use case is, again: * git clone devtools * ./nightly * point devtools source directory to the git clone * hack on firefox devtools in Nightly, reloading the source as need be Anything else can wait until later as Ryan suggested. Paul: are there things you want for graphene? That would be nice, but not absolutely necessary. We use WebIDE for now, so the process of connecting the devtools is not as simple as just pressing F12. It's just that moving to a top level directory, it's 90% of the work. The last 10% is to remove the few dependencies to chrome://browser/ code. So while we're at it … :) -- Paul ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Hash table iterators, and a call for help
On Sun, Jul 12, 2015 at 10:36 PM, Nicholas Nethercote n.netherc...@gmail.com wrote: Last week I landed patches that remove PL_DHashTableEnumerate() from the tree (https://bugzilla.mozilla.org/show_bug.cgi?id=1180072). You should now use PLDHashTable::Iterator if you want to iterate over a PLDHashTable. The iterator is *so* much nicer -- there's none of that bundle up an environment as a |void*| pointer and pass it in with a function pointer annoyance. I have also added Iterator classes to each of nsTHashtable and nsBaseHashtable (https://bugzilla.mozilla.org/show_bug.cgi?id=1181445) and I would like to also eventually remove the enumerate functions from these classes. However, there are 500+ calls to those enumerate functions so it's going to take a while. For now, I've filed bugs to get rid of all the nsTHashtable::EnumerateEntries() calls, which account for ~160 of those 500+. They're all blocking https://bugzilla.mozilla.org/show_bug.cgi?id=1181443. If you find yourself in the mood for some not-too-taxing refactoring, please feel free to take on one or more of the unassigned bugs. The number of calls to replace in each bug ranges from one or two up to 21. If you have any questions please ask. Thank you. With help from several people -- thank you to birtles, ehsan, heycam, mccr8, poiru, TYLin -- nsTHashTable::EnumerateEntries() is *almost* at the point where it can be removed. The 15 calls in netwerk/ (covered by https://bugzilla.mozilla.org/show_bug.cgi?id=1182961) are the only remaining obstacle. Given that, I went ahead and filed bugs to get rid of the ~200 nsBaseHashtable::EnumerateRead() calls and ~140 nsBaseHashtable::Enumerate() calls. They are all marked as blocking https://bugzilla.mozilla.org/show_bug.cgi?id=1181444, and they come in a range of sizes. Some work has been started on these -- thank you to gerald and khuey -- but, again, there's plenty more to be done and assistance would be welcome. If you do want to help, please note that nsBaseHashtable has a subtle distinction between |UserDataType| and |DataType|. As a result: - you should use nsBaseHashtable::Iterator::UserData() if you are replacing an EnumerateRead() call, and - you should use nsBaseHashtable::Iterator::Data() if you are replacing an Enumerate() call. I mentioned this in all the bugs I filed to minimize the likelihood of mix-ups. I also filed all the EnumerateRead()-replacement bugs separately from all the Enumerate()-replacement bugs for the same reason. Please ask me if anything is unclear. Thank you. Nick ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Hash table iterators, and a call for help
On 24/07/2015 09:26, Nicholas Nethercote wrote: I mentioned this in all the bugs I filed to minimize the likelihood of mix-ups. I also filed all the EnumerateRead()-replacement bugs separately from all the Enumerate()-replacement bugs for the same reason. Please ask me if anything is unclear. Thank you. Does PL_HashTableEnumerateEntries also need to be replaced? And if so what with? Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implement Fetch?
On Fri, Jul 24, 2015 at 3:41 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/23/15 11:36 AM, Anne van Kesteren wrote: By SVG resource document do you mean one that is fetched as an image? In Gecko's case I specifically mean one fetched as a paint server. It's somewhat of an implementation detail, possibly; the reason we do it is that we had a bunch of code that assumed you could go from a request to its loadgroup to its docshell to its document, but for SVG paint servers that would produce the linking SVG document, not the paint server document, which would not have been right in various cases. We've already agreed to make resource document loading go away and resolve remote SVG resource URIs by loading those documents as images instead. Rob -- lbir ye,ea yer.tnietoehr rdn rdsme,anea lurpr edna e hnysnenh hhe uresyf toD selthor stor edna siewaoeodm or v sstvr esBa kbvted,t rdsme,aoreseoouoto o l euetiuruewFa kbn e hnystoivateweh uresyf tulsa rehr rdm or rnea lurpr .a war hsrer holsa rodvted,t nenh hneireseoouot.tniesiewaoeivatewt sstvr esn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Moving DevTools to top level /devtools directory
On 23/07/2015 14:40, Mike Hommey wrote: On Thu, Jul 23, 2015 at 02:34:50PM +0800, Philip Chee wrote: On 22/07/2015 05:54, J. Ryan Stinnett wrote: The DevTools team is planning to move our code out of /browser/devtools and /toolkit/devtools and into a new top level /devtools directory. The main goals of this are to reduce confusion for new DevTools contributors and help us better organize our work in the future. It will also aid future users of the code in understanding what pieces they need to include. There should be no impact to DevTools features shipped in different products: Firefox desktop will continue to be the only product that ships the DevTools front end, and all others will ship the DevTools server only. What is the utility of shipping the back end without the front end? Remote-debugging Thunderbird with the devtools in Firefox. Nice. Does this make it easier for non-firefox applications to ship the front end too? e.g. SeaMonkey. Does this make it easier to package the front end as an add-on? e.g. as a replacement for Venkman (DOA, RIP). Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Moving DevTools to top level /devtools directory
On 23/07/2015 17:36, Panos Astithas wrote: On Thu, Jul 23, 2015 at 8:25 AM, Paul Rouget p...@mozilla.com wrote: On Wed, Jul 22, 2015 at 2:48 PM, Panos Astithas p...@mozilla.com wrote: If you are thinking about shipping them as part of browser.html, we still have XUL dependencies that we need to get rid of first and that work is independent from moving the code to a top-level devtools/ directory. We don't use XUL, but we can still open XUL windows. Would it be possible to use the devtools without chrome://browser/ being accessible? I doubt it, although, to be honest, I am not entirely sure. We already use paths like chrome://browser/content/devtools/debugger.xul in the code, so they would have to be changed first. Would using resource: URLs work better for browser.html? I suggest chrome://devtools/content/debugger.xul if you are going to refactor devtools. Use case: SeaMonkey Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implement Fetch?
On 23/07/15 15:47, Anne van Kesteren wrote: * Construct an nsIURI. Might need to take things such as the document base URI and charset into account. For many APIs these days you need to parse the URL before you hand it off. That seems like a somewhat saner setup too, though in theory fetch() has access to this information through request's client. I don't know if this is implied when you write parse the URL, but I'd like to point out that constructing a nsIURI is actually more complicated than parsing a URI. We also have security checks. I haven't checked the specifics for web-facing URIs, but for file:// URIs, these involve actually accessing files. -- David Rajchenbach-Teller, PhD Performance Team, Mozilla signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implement Fetch?
On Thu, Jul 23, 2015 at 6:32 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote: I think this is a good idea in general, but I'm not sure how well the high level fetch API would map to something internal. 1) fetch() is not exactly high-level. 2) We're not talking about fetch(), but about the fetch algorithm, which is reused by every single platform feature. * Construct an nsIURI. Might need to take things such as the document base URI and charset into account. For many APIs these days you need to parse the URL before you hand it off. That seems like a somewhat saner setup too, though in theory fetch() has access to this information through request's client. There are some concepts here that do not exist in the current fetch spec (for example, load groups) Load groups roughly matches the fetch registry I think. I should probably rename that fetch group as Ben suggested to me privately. Filed https://github.com/whatwg/fetch/issues/92 to do so. Also, some of the existing concepts (such as streamed Responses) may not be quite fleshed out yet. Well, they are specified. What is not specified there is the JavaScript API, but we figured out yesterday how to do it, so I expect we'll have everything updated somewhere next week. I should also mention that in addition to the security concerns around fetch interception through service workers, the above steps is *insanely* complex, and almost every time that someone who is not deeply familiar with all of the above steps tries to load something from the network, they're pretty much guaranteed to forget something and as a result potentially open security holes! I look forward to a future where mere mortals can load stuff from the network in Gecko. :-) Yeah, my hope is that we'll eventually get some common abstractions that are safe-by-default and can be used by specifications to load resources without having to worry much about fiddling with all the settings. That still seems like a good bit of time away though. But who knows. -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Moving DevTools to top level /devtools directory
On 22/07/2015 05:54, J. Ryan Stinnett wrote: The DevTools team is planning to move our code out of /browser/devtools and /toolkit/devtools and into a new top level /devtools directory. The main goals of this are to reduce confusion for new DevTools contributors and help us better organize our work in the future. It will also aid future users of the code in understanding what pieces they need to include. There should be no impact to DevTools features shipped in different products: Firefox desktop will continue to be the only product that ships the DevTools front end, and all others will ship the DevTools server only. What is the utility of shipping the back end without the front end? Phil -- Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com http://flashblock.mozdev.org/ http://xsidebar.mozdev.org Guard us from the she-wolf and the wolf, and guard us from the thief, oh Night, and so be good for us to pass. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implement Fetch?
On 7/23/15 11:36 AM, Anne van Kesteren wrote: By SVG resource document do you mean one that is fetched as an image? In Gecko's case I specifically mean one fetched as a paint server. It's somewhat of an implementation detail, possibly; the reason we do it is that we had a bunch of code that assumed you could go from a request to its loadgroup to its docshell to its document, but for SVG paint servers that would produce the linking SVG document, not the paint server document, which would not have been right in various cases. Is that how we model stylesheets too? No, stylesheets just use the loadgroup of the document that linked to them. Is there a particular reason for this design? (I wonder whether we should make the specification match it.) That really depends on what state gets hung off of fetch groups; see above. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implement Fetch?
On Thu, Jul 23, 2015 at 8:19 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 7/23/15 9:47 AM, Anne van Kesteren wrote: Load groups roughly matches the fetch registry I think. I should probably rename that fetch group as Ben suggested to me privately. Filed https://github.com/whatwg/fetch/issues/92 to do so. Sort of. Except fetch group is per-global but there are loadgroups in Gecko that don't correspond to a global (e.g. each SVG resource document has its own loadgroup, which is itself a request in the linking document loadgroup). By SVG resource document do you mean one that is fetched as an image? (As otherwise SVG has its own global.) Is that how we model stylesheets too? Is there a particular reason for this design? (I wonder whether we should make the specification match it.) -- https://annevankesteren.nl/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: disallowing definition of non-configurable properties on a window
A bit belated, since I just landed this on inbound, but... Summary: In ES2015, there is a certain set of invariants that an object is supposed to maintain. One of those is that a non-configurable property can't just disappear. Window objects obviously can't maintain that invariant, so they can't be allowed to have non-configurable properties, at least in terms of observability from script. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1107443 Standard: http://www.ecma-international.org/ecma-262/6.0/#sec-invariants-of-the-essential-internal-methods Platforms: all Estimated release date: Unclear so far; need to see how web-compatible this is. Preference controlling this: no preference, but a !RELEASE_BUILD ifdef. So this will be enabled in nightly and Aurora only. -Boris ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Help with removing __iterator__ from JS
On 7/22/2015 1:56 PM, David Bruant wrote: The ES6 iterator protocol is what you're looking for. See: Alongside with the computed property syntax, you should be able to achieve what you want. Something along the lines of: Well, I was thinking more of something built-in, other than Iterator, to achieve the same effect over a data structure (for example something that could be provided from elsewhere as an argument). But apparently I'm stuck with iterating over keys and reading values separately, or implementing my version of Iterator (at which point I don't see why I shouldn't simply use Iterator in privileged code, rather than implementing MyIterator() everywhere locally or in a MyIterator.jsm). Cheers, Paolo ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Moving DevTools to top level /devtools directory
On Thu, Jul 23, 2015 at 8:11 AM, Paul Rouget p...@mozilla.com wrote: I guess by moving things to /devtools/, you also want to update the URLs to chrome://devtools/content. So then, we can compile and open the devtools with non-firefox builds (thunderbird, b2g, seamonkey, ...). But if the devtools include browser code, this won't work. For example, we import chrome://browser/content/utilityOverlay.js, which is Firefox only. The main goal of this work is around making the DevTools codebase more approachable for contributors. We're not explicitly setting out to make reusing the front end easier from non-Firefox, but certainly moving out of /browser is one nudge in the right direction down that path. I'm guessing we'll still have some browser dependencies for the moment, but I'll take a look at this as I work on the file moves. - Ryan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Moving DevTools to top level /devtools directory
On Thu, Jul 23, 2015 at 02:34:50PM +0800, Philip Chee wrote: On 22/07/2015 05:54, J. Ryan Stinnett wrote: The DevTools team is planning to move our code out of /browser/devtools and /toolkit/devtools and into a new top level /devtools directory. The main goals of this are to reduce confusion for new DevTools contributors and help us better organize our work in the future. It will also aid future users of the code in understanding what pieces they need to include. There should be no impact to DevTools features shipped in different products: Firefox desktop will continue to be the only product that ships the DevTools front end, and all others will ship the DevTools server only. What is the utility of shipping the back end without the front end? Remote-debugging Thunderbird with the devtools in Firefox. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Moving DevTools to top level /devtools directory
On Thu, Jul 23, 2015 at 8:25 AM, Paul Rouget p...@mozilla.com wrote: On Wed, Jul 22, 2015 at 2:48 PM, Panos Astithas p...@mozilla.com wrote: If you are thinking about shipping them as part of browser.html, we still have XUL dependencies that we need to get rid of first and that work is independent from moving the code to a top-level devtools/ directory. We don't use XUL, but we can still open XUL windows. Would it be possible to use the devtools without chrome://browser/ being accessible? I doubt it, although, to be honest, I am not entirely sure. We already use paths like chrome://browser/content/devtools/debugger.xul in the code, so they would have to be changed first. Would using resource: URLs work better for browser.html? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
