Re: Implement Fetch?
On Tue, Jul 21, 2015 at 5:01 PM, Honza Bambas hbam...@mozilla.com wrote: The main offenders here are: - synchronous on-*-request global notifications I believe this is mostly what :sicking refers to when he talks about [1] https://etherpad.mozilla.org/BetterNeckoSecurityHooks and I agree that would be useful work.. but casual readers of this thread shouldn't be too depressed - a bunch of high data volume consumers do manage to take their data events off the main thread just fine and has been pointed out I/O is definitely not taking place there. https://etherpad.mozilla.org/BetterNeckoSecurityHooks ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Implement Fetch?
On 7/18/2015 1:42, Kyle Huey wrote: To be abundantly clear, no I/O should be happening (or is, to my knowledge) on the main thread when you use XHR. The limitation today is that various Necko state operations (e.g. opening a channel) can only happen on the main thread. The main offenders here are: - synchronous on-*-request global notifications that are notified via the observer service (main thread only) and are widely used by various add-ons to hook/block/modify requests and responses that may block. This is legacy code. Async or different hook api would have to be designed to replace it. Problem is that all those that hook to these callbacks want to examine and modify or even block the requests, so it needs to be sync in most cases. Everyone want everything... - nsLoadGroup/nsDocShell et al are strictly main thread but this is just about adding locks to the right places I have some plans (no bug# I think) to move at least some of the main thread loops we need to do now (not a few!) before we even start reading the network response from the cache or send out a network request. This may also mean to prepare land for starting network loads (AsyncOpen a channel) off the main thread. Requirements list from your side appreciated. -hb- But that doesn't mean that we are doing I/O there. - Kyle On Jul 18, 2015 4:43 AM, David Rajchenbach-Teller dtel...@mozilla.com wrote: ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: Enabling APZ on nightly desktop (OS X, Windows)
Just a heads-up that I just pushed bug 1157746 to inbound, which enables async scrolling for trackpad/wheel scrolling by default for nightly OS X desktop builds. It requires e10s, and so if you have e10s disabled it has no effect for you. If you have e10s enabled, you should see smoother/more responsive scrolling, and probably more checkerboarding (scrolling into unpainted content areas). Note that this is currently NOT riding the trains, we will leave it enabled on Nightly only until it is more baked, but it should be stable enough for general usage. Bug 1178298 tracks letting it ride the trains. Please file bugs in the Core::Panning and Zooming component if you see anything misbehaving. If you need to turn it off for whatever reason, you can set the layers.async-pan-zoom.enabled pref back to false. Assuming this doesn't get backed out, I intend to also enable the same thing on Windows in the next day or two (bug 1157745). Linux will take a bit longer since there are some test failures we need to sort out first. Cheers, kats ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Need help in resolving compilation issues in building extension
Hi, We build our Firefox binary extension with FF sdk. Our binary extension has been successfully built til FF 39 SDK. When I tried to build our extension for FF 40 beta 5 sdk in VS 2013, I am facing the following compilation issues. The same project is built successfully when i point it to FF 39 SDK. Could you please provide why there is issue being reported in SDK\VS12\MSVC\VC\include\xlocale(1725), SDK\VS12\MSVC\VC\include\xlocinfo(194), and in SDK\VS12\MSVC\VC\include\typeinfo(112). Let me know if you need any info further Compiler output (detailed) == Compiler output (detailed) == 1 cl /c /I..\coCoreFW /IE:\perforce\nco_r8.7.12\src\\Include\EVCert /IE:\perforce\nco_r8.7.12\src\\Include\SymData /IE:\perforce\nco_r8.7.12\SDK\\VS10\Firefox-SDKs /IE:\perforce\nco_r8.7.12\SDK\\VS10\Firefox-SDKs\40.0.0\include /IE:\perforce\nco_r8.7.12\SDK\\VS10\Firefox-SDKs\40.0.0\include\js /IE:\perforce\nco_r8.7.12\SDK\\VS10\Firefox-SDKs\40.0.0\include\nspr /IE:\perforce\nco_r8.7.12\SDK\\VS10\AutoProtect\Include /IE:\perforce\nco_r8.7.12\SDK\\Common\Platform7.1A\include /IE:\perforce\nco_r8.7.12\SDK\\Common\WTL\Include /IE:\perforce\nco_r8.7.12\SDK\\VS12\MSVC\VC\include /IE:\perforce\nco_r8.7.12\SDK\Common\InstallToolBox\Include /IE:\perforce\nco_r8.7.12\src\\Framework2.0\Include /IE:\perforce\nco_r8.7.12\src\\Framework2.0\Include\Events /IE:\perforce\nco_r8.7.12\src\\Framework2.0\Include\Helpers /IE:\perforce\nco_r8.7.12\src\\Framework2.0\Include\Interfaces /IE:\perforce\nco_r8.7.12\src\\Framework2.0\Include /IE:\perforce\nco_r8.7.12\src\\Framework2.0\Include\S ervices /IE:\perforce\nco_r8.7.12\src\\Framework2.0\Common\Events /IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include /IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccGenericLog /IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccGenericEvent /IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccIPC /IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccJobMgr /IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccLib /IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccSettings /IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccService /IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccVerifyTrust /IE:\perforce\nco_r8.7.12\SDK\Common\CC\Include\ccSubSDK /IRelease\ /IE:\perforce\nco_r8.7.12\SDK\\Common\Platform\include /IE:\perforce\nco_r8.7.12\SDK\VS10\\msvc\vc\ATLMFC\include /IE:\perforce\nco_r8.7.12\SDK\VS10\\msvc\vc\include /IE:\perforce\nco_r8.7.12\SDK\\Common\WTL\include /IE:\perforce\nco_r8.7.12\src\\include /IE:\perforce\nco_r8.7.12\src\\Include\WPP /Zi /W4 /WX- /O1 /Oy- /D WIN32 /D NDEBUG /D _WINDOWS /D _USRDLL /D _WTL_NO_CSTRING /D _BIND_TO_CURRENT_VCLIBS_VERSION=1 /D COFIREFOXPLUGIN_EXPORTS /D LOG_PERFORMANCE /D _WPP_TRACING /D NDEBUG /D WIN32 /D _WIN32 /D _CRT_RAND_S /D WPP_CONTROL_HEADER=\E:\perforce\nco_r8.7.12\src\\include\WPP\WPPGuid.h\ /D _WPP_TRACING /D _USING_V110_SDK71_ /D _WINDLL /D _UNICODE /D UNICODE /X /GF /Gm- /EHsc /MD /GS /Gy- /fp:precise /fp:except- /Zc:wchar_t /Zc:forScope /GR- /openmp- /YuStdAfx.h /FpRelease\coFireFoxPluginBeta.pch /FoRelease\\ /FdRelease\vc90.pdb /Gd /TP /analyze- /errorReport:prompt /MP4 DOMDocumentImpl.cpp (TaskId:18) 1 _WPP_TRACING 1 _USING_V110_SDK71_ 1 (TaskId:18) 1 DOMDocumentImpl.cpp (TaskId:18) 1E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\typeinfo(112): error C2504: 'exception' : base class undefined 1E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\typeinfo(144): error C2504: 'exception' : base class undefined 1E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(57): error C2039: '_Collvec' : is not a member of '`global namespace'' 1E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(57): error C2146: syntax error : missing ';' before identifier '_Collvec' 1E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(57): error C4430: missing type specifier - int assumed. Note: C++ does not support default-int 1E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(57): error C2602: 'Previous::std::_Locinfo::_Collvec' is not a member of a base class of 'Previous::std::_Locinfo' 1 E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(57) : see declaration of 'Previous::std::_Locinfo::_Collvec' (TaskId:18) 1 E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(55) : see declaration of 'Previous::std::_Locinfo' (TaskId:18) 1E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(57): error C2868: 'Previous::std::_Locinfo::_Collvec' : illegal syntax for using-declaration; expected qualified-name 1E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(58): error C2039: '_Ctypevec' : is not a member of '`global namespace'' 1E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(58): error C2146: syntax error : missing ';' before identifier '_Ctypevec' 1E:\perforce\nco_r8.7.12\SDK\VS12\MSVC\VC\include\xlocinfo(58): error C4430: missing type specifier - int assumed. Note:
Re: Collecting web platform features implementation status
On 16/07/15 21:26, Anthony Ricaud wrote: Potch and I are working on a website to present Mozilla's point of view on various web platform features. Other browsers have similar websites [1] [2] [3]. This project has been in lingo for a while so, to get it out the door, we're going to focus on one information: what is Mozilla's opinion on features that have not been shipped yet. We see 4 possible answers: in development, favorable, not favorable, no opinion. In order to get accurate data and update it regularly, we need your help. Please go to the following etherpad and insert any information that can help us: https://etherpad.mozilla.org/gecko-web-platform-dashboard Thanks for your help! [1] https://www.chromestatus.com/features [2] https://status.modern.ie [3] http://www.webkit.org/status.html Reminder: We need your help! Please submit a pull request against https://github.com/Rik/platform-status/blob/master/features.json. (I've only received one pull request since moving this JSON to Github :( ) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Collecting web platform features implementation status
I see 3 (now 4) old pull requests that are unmerged. On Tue, Jul 21, 2015 at 8:19 PM, Anthony Ricaud anth...@ricaud.me wrote: On 16/07/15 21:26, Anthony Ricaud wrote: Potch and I are working on a website to present Mozilla's point of view on various web platform features. Other browsers have similar websites [1] [2] [3]. This project has been in lingo for a while so, to get it out the door, we're going to focus on one information: what is Mozilla's opinion on features that have not been shipped yet. We see 4 possible answers: in development, favorable, not favorable, no opinion. In order to get accurate data and update it regularly, we need your help. Please go to the following etherpad and insert any information that can help us: https://etherpad.mozilla.org/gecko-web-platform-dashboard Thanks for your help! [1] https://www.chromestatus.com/features [2] https://status.modern.ie [3] http://www.webkit.org/status.html Reminder: We need your help! Please submit a pull request against https://github.com/Rik/platform-status/blob/master/features.json. (I've only received one pull request since moving this JSON to Github :( ) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to implement: Moving DevTools to top level /devtools directory
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. It is my understanding that the DevTools team received approval for a new top level directory from Brendan several years ago. Bug: https://bugzil.la/912121 (Replies to dev-platform.) - 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
[tangentially related] Are there plans ot move DevTools to a product in Bugzilla to match this code layout? Kevin On Tue, Jul 21, 2015 at 2:54 PM, J. Ryan Stinnett jry...@gmail.com 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. It is my understanding that the DevTools team received approval for a new top level directory from Brendan several years ago. Bug: https://bugzil.la/912121 (Replies to dev-platform.) - Ryan ___ 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: GTK3 linux builds
On Wed, Jul 22, 2015 at 10:59 AM, Mike Hommey m...@glandium.org wrote: Done. https://treeherder.mozilla.org/#/jobs?repo=mozilla-inboundrevision=939320b957c5 Excellent! - deciding how to handle the situation for people who don't have gtk3 installed on their system. Currently, firefox will silently fail to restart after the upgrade. How many people is that? Do we run on GTK 3.0 or is 3.4 required? If GTK3 isn't present can we start distro Fireofx 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: GTK3 linux builds
On Tue, Jul 21, 2015 at 10:31:10PM +1200, Robert O'Callahan wrote: On Tue, Jul 21, 2015 at 7:04 PM, Mike Hommey m...@glandium.org wrote: On Mon, Jul 20, 2015 at 09:22:05PM -0400, Jeff Muizelaar wrote: On Mon, Jul 20, 2015 at 6:18 PM, Mike Hommey m...@glandium.org wrote: There are a few remaining perma reds and oranges, FWIW. Which ones? I don't see anything on elm. Well, it looks like they are now all gone. :) Great! Let's switch now, before they come back! :-) Done. https://treeherder.mozilla.org/#/jobs?repo=mozilla-inboundrevision=939320b957c5 Still left to do: - switching local builds to gtk3 (bug 1186229) - deciding whether it's ready to actually ride the trains - deciding how to handle the situation for people who don't have gtk3 installed on their system. Currently, firefox will silently fail to restart after the upgrade. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTK3 linux builds
On Wed, Jul 22, 2015 at 11:07:23AM +1200, Robert O'Callahan wrote: On Wed, Jul 22, 2015 at 10:59 AM, Mike Hommey m...@glandium.org wrote: Done. https://treeherder.mozilla.org/#/jobs?repo=mozilla-inboundrevision=939320b957c5 Excellent! - deciding how to handle the situation for people who don't have gtk3 installed on their system. Currently, firefox will silently fail to restart after the upgrade. How many people is that? Do we run on GTK 3.0 or is 3.4 required? I suspect a lot of people running KDE will only have gtk2 installed for Firefox, and gtk3 not installed. If GTK3 isn't present can we start distro Fireofx instead? If people are using mozilla builds, they are unlikely to have the distro package installed. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTK3 linux builds
On 07/20/2015 03:30 PM, Robert O'Callahan wrote: On Tue, Jul 21, 2015 at 1:04 AM, Jeff Muizelaar jmuizel...@mozilla.com wrote: I believe Flash does. OK, I can't get it to work, but I think it's just my system. I verified that Fedora 22 (and I think 21) shipped GTK3 Firefox. If there aren't any major blocking bugs for GTK3 = 3.4, and the tests are green, I think we should switch to GTK3 immediately and stop doing GTK2 builds. I know the bugs mentioned in the thread above are fixed for GTK = 3.4. Only Fedora 22 has Gtk3 Firefox and I don't see any complains about flash. But it carries lots of Gtk3 patches from Firefox 40-41 (and maybe 42) - widget layout/borders patches, tab styles and so on. ma. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Array.concat
Hi Amit, These are called ‘Generics’ and are available in Firefox as of JavaScript 1.6 - see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array#Array_generic_methods https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array#Array_generic_methods Please don’t rely on them being available cross-browser, but they are quite easy to shim: a quick duckduckgo search took me to https://github.com/plusdude/array-generics https://github.com/plusdude/array-generics, which seems to get the job done. Hope that helps, Mike. On 21 Jul 2015, at 10:42, Amit Zur amit@capriza.com wrote: Hi, I've noticed that Array.concat is defined in Firefox (in addition to Array.prototype.concat). I couldn't find any reference for this in MDN. It seems to work as expected, accepting any number of arrays as arguments and concatenating them. But is this a standard method of the Array constructor? Thanks, Amit ___ 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: GTK3 linux builds
On Tue, Jul 21, 2015 at 7:04 PM, Mike Hommey m...@glandium.org wrote: On Mon, Jul 20, 2015 at 09:22:05PM -0400, Jeff Muizelaar wrote: On Mon, Jul 20, 2015 at 6:18 PM, Mike Hommey m...@glandium.org wrote: There are a few remaining perma reds and oranges, FWIW. Which ones? I don't see anything on elm. Well, it looks like they are now all gone. :) Great! Let's switch now, before they come back! :-) 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: Proposed W3C Charters: All Groups, XML Activity
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/21/2015 05:36 AM, L. David Baron wrote: The W3C is proposing revised charters for all of the working groups in the XML Activity: https://lists.w3.org/Archives/Public/public-new-work/2015Jul/.html http://www.w3.org/XML/2015/05/activity-proposal.html (which has a brief summary of the work) recharter: Efficient XML Interchange Working Group http://www.w3.org/XML/2015/05/exi-charter.html recharter: XML Query Working Group http://www.w3.org/XML/2015/05/query-charter.html recharter: XML Core Working Group http://www.w3.org/XML/2015/05/xml-core-charter.html recharter: XML Processing Model Working Group http://www.w3.org/XML/2015/05/xproc-charter.html recharter: XSLT Working Group http://www.w3.org/XML/2015/05/xsl-charter.html bring back to life: XForms Working Group http://www.w3.org/XML/2015/05/xforms-charter.html Mozilla has the opportunity to send comments or objections through Thursday, July 30. Please reply to this thread if you think there's something we should say as part of this charter review, or whether you think we should explicitly abstain. (Note that we can only explicitly abstain from the set of charters as a whole, not individually, at least on the ballot form, though I suppose we could do so in prose.) (My inclination is at minimum to explicitly abstain, with comments that they shouldn't expect browser implementation.) I'd personally prefer to shut down the entire Activity. None of these groups will help lead the web to its full potential (if that's still the W3C's motto). They are completely out of touch with what's happened on the Web is the last decade, exemplified by the following quote from the XML Core proposed charter: The Working Group has current plans to: 1. Publish a sixth edition of XML 1.0 as an Edited Recommendation, to include the changes for the LEIRI specification, at such time as IRI-bis is final. 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. HTH Ms2ger -BEGIN PGP SIGNATURE- iQEcBAEBAgAGBQJVrh8gAAoJEOXgvIL+s8n2OG0H/ioMX2t9p01ngpsKhmsX5yAC rNvBAf+yhkT6AanCXmXvdnvUbYXjo2zgSQmxPrhRkLWIYQHTjQN4guMoc1v5HljW JE2Aa5xT5tbKPQ2p/6smwQZyBWZxa7OwapefzrtRBXILyqOFeTG4qqgnd7Hvw1Nx N9G0e+JgiQjpvZLA3+gncLqpFwpGvQ6RIisfdFlO3QCJy6W4z2skzpLwk3oEEvuk umLYl2w6bHycn5XNEFrggZ+/q/gYzUP0hWF9+fuaHbvnPsAHAtsBPEt4tt3ocLQY Pggmb4HYF7LVmrLCo5r8iHOOWVO16iFkDa0X3YRW37AOJ3j7qLUAlKD6qnApAco= =OzSY -END PGP SIGNATURE- ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Help with removing __iterator__ from JS
Hello! We have an old JS extension that allows objects to modify how they behave when used with for-in. However this extension will never make it into ES6 and is actually incompatible with how iteration is defined there. So please don't use __iterator__anymore. I would really appreciate your help with removing __iterator__ from the OS.File interface, which makes very heavy use of this feature. Bug 938704 hasn't seen any serious work since 2013. We also need to look into the addon-sdk, where many of the custom collection types implement __iterator__ and thus addon authors might iterate over them with for-in ... Aside: Please also try avoid using Iterator(). Thank you, Tom ___ 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 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. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Help with removing __iterator__ from JS
If I recall correctly, the difficulty with the OS.File removal is that some clients of this code were taking advantage of the old API in ways that do not match the new one. I will try and take another look at it over the summer. Cheers, David On 21/07/15 13:07, Tom Schuster wrote: Hello! We have an old JS extension that allows objects to modify how they behave when used with for-in. However this extension will never make it into ES6 and is actually incompatible with how iteration is defined there. So please don't use __iterator__anymore. I would really appreciate your help with removing __iterator__ from the OS.File interface, which makes very heavy use of this feature. Bug 938704 hasn't seen any serious work since 2013. We also need to look into the addon-sdk, where many of the custom collection types implement __iterator__ and thus addon authors might iterate over them with for-in ... Aside: Please also try avoid using Iterator(). Thank you, Tom ___ firefox-dev mailing list firefox-...@mozilla.org https://mail.mozilla.org/listinfo/firefox-dev -- 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
Array.concat
Hi, I've noticed that Array.concat is defined in Firefox (in addition to Array.prototype.concat). I couldn't find any reference for this in MDN. It seems to work as expected, accepting any number of arrays as arguments and concatenating them. But is this a standard method of the Array constructor? Thanks, Amit ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTK3 linux builds
On Mon, Jul 20, 2015 at 09:22:05PM -0400, Jeff Muizelaar wrote: On Mon, Jul 20, 2015 at 6:18 PM, Mike Hommey m...@glandium.org wrote: There are a few remaining perma reds and oranges, FWIW. Which ones? I don't see anything on elm. Well, it looks like they are now all gone. :) Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: GTK3 linux builds
On 2015年07月21日 16:04, Mike Hommey wrote: On Mon, Jul 20, 2015 at 09:22:05PM -0400, Jeff Muizelaar wrote: On Mon, Jul 20, 2015 at 6:18 PM, Mike Hommey m...@glandium.org wrote: There are a few remaining perma reds and oranges, FWIW. Which ones? I don't see anything on elm. Well, it looks like they are now all gone. :) Mike GTK2 had a few issues: See, for example, the next bug which was originally noticed when I was composing e-mail messages in thuderbird. https://bugzilla.gnome.org/show_bug.cgi?id=696624 Bug 696624 - Summary:Japanese (Korean/Chinese) XIM input mode indicator has not been working unde... [Originally, I submitted the following mozilla bugzilla entry because I did not realize it was NOT the problem of TB/FF per se. https://bugzilla.mozilla.org/show_bug.cgi?id=854825 Bug 854825 - Japanese (Korean/Chinese) XIM input mode indicator has not been working for TB and FF under linux. (with known solution) ] Unfortunately, it was not possible to catch/grab attentions of GTK library developers any more now that GTK3 was their main focus. (Yet, surprisingly the bug was carried over to GTK3 library, too. So hoping to attention, I submitted a bugzilla entry: Bug 731190 - Summary:XIM input mode indicator does not work. (It shows black box, e.g.) https://bugzilla.gnome.org/show_bug.cgi?id=731190 [Although the bugzilla did not mention any fix, I think the today's code may have fixed the issue in a really different manner. I don't even see the same function any more in the current code if I am not mistaken.] Yes, sticking with the old and proven software module has a merit, but when we find it has a hitherto unknown bug, we are often faced with the problem that original developers are no longer interested in fixing such old library. I think it is about time we move to GTK3 library. CI ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Array.concat
On Tuesday, July 21, 2015 at 4:01:53 PM UTC+3, Till Schneidereit wrote: On Tue, Jul 21, 2015 at 12:19 PM, Mike de Boer mdeb...@mozilla.com wrote: Hi Amit, These are called 'Generics' and are available in Firefox as of JavaScript 1.6 - see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array#Array_generic_methods https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array#Array_generic_methods Please don't rely on them being available cross-browser, but they are quite easy to shim: a quick duckduckgo search took me to https://github.com/plusdude/array-generics https://github.com/plusdude/array-generics, which seems to get the job done. And perhaps also don't use them in Firefox: they're a non-standard feature we'd rather get rid of, if we could. We *might* be able to at some point in the future, but only if people abstain from using them. Thanks for the info guys ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Array.concat
On Tue, Jul 21, 2015 at 12:19 PM, Mike de Boer mdeb...@mozilla.com wrote: Hi Amit, These are called ‘Generics’ and are available in Firefox as of JavaScript 1.6 - see https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array#Array_generic_methods https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Array#Array_generic_methods Please don’t rely on them being available cross-browser, but they are quite easy to shim: a quick duckduckgo search took me to https://github.com/plusdude/array-generics https://github.com/plusdude/array-generics, which seems to get the job done. And perhaps also don't use them in Firefox: they're a non-standard feature we'd rather get rid of, if we could. We *might* be able to at some point in the future, but only if people abstain from using them. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
