Re: Rethinking the crash experience
On 07/07/14 22:09, Ted Mielczarek wrote: I believe this was the primary reasoning behind the current implementation (it's been a while, I'm a little fuzzy). We need to handle startup crashes, so we need the native crashreporter UI regardless of whether we build an in-product crash reporting UI. This absolutely makes sense. [...] It's also worth noting that our behavior matches the behavior of existing OS platform crash reporters--on all the OSes I'm aware of there's a dialog similar to our own, so it's not an unfamiliar workflow to users. That being said the crashreporter UX is essentially unchanged from what we shipped in Firefox 3.0, so there's certainly room for improvement! Note, however, that there is a big UX difference between what OSes do and what we do. Random OS: Hey, look, *I* didn't crash, Firefox did. Firefox: Hey, look, *I* crashed. which I suggest we turn into Firefox: Oh, by the way, I recovered. Cheers, David -- 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
Capturing the JS stack in case of crash
Often, we find ourselves attempting to debug JS code that causes a crash, generally by miscalling a XPCOM component that causes an assertion failure. Unfortunately, in such cases, the native stack captured gives little to no indication that can help developers find out how we reached this specific assertion. This is true both when we run code locally, on Try or when Firefox is released to users. Could we find a way to capture the JS stack? I have the impression that it would be sufficient to modify our assertion macros to call a DumpJSStack() equivalent before actually crashing, and to attach the output to the Crash Reporter if available. Cheers, David -- 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: Rethinking the crash experience
On 08/07/14 16:25, Tobias Besemer wrote: Am Samstag, 5. Juli 2014 14:21:47 UTC+2 schrieb David Rajchenbach-Teller: [...] 3. Crash report is stored to disk, without any dialog; 4. If the crash happened during Firefox shutdown, do nothing, otherwise restart Firefox to its previous state (obviously, we need some measure to prevent this from looping); [...] Please not! I always restart FF offline! This gives me a small footprint. If FF restarts online with reloading all tabs, this can go worst ... Maybe a option for this, if it will be implemented? Something like Restart automatically? ??? Or like on the profile manager: Don't ask this again? in the crash reporter ??? Well, clearly, we would need an option for this. I suspect that many power users would prefer the Crash Reporter. Cheers, David -- 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: Unimplement: @-moz-document regexp support?
On Monday 2014-07-07 15:18 -0400, Ehsan Akhgari wrote: That seems pretty bad. I think we should at least stop supporting it for Web content. David, what do you think? I'm ok with restricting it to UA and user style sheets, although if we're going to do that because of security risks I'd like to get a good understanding of what those are and of what we do and don't expect authors to do when sanitizing CSS from untrusted sources to include in their Web content. I think it might make more sense to continue discussion in the bug. (I also think sending this out in the format of an intent-to-implement message was confusing for an initial proposal to do something that hadn't yet been discussed with any owners or peers of the module. I think the format is intended to say that a change has already been accepted by owners/peers but requires wider review.) -David On 2014-07-07, 4:56 AM, Frederik Braun wrote: Summary: Attackers can extract secret URL components (e.g. session IDs, oauth tokens) using @-moz-document. Using the regexp support and assuming a CSS injection (no XSS needed!), the attacker can probe the current URL with some regular expressions and send the URL parameters to a third party. A demo of this exploit can be found at http://html5sec.org/cssession/. This attack has also been published in the academic paper Scriptless Attacks: Stealing the pie without touching the sill[1] by Mario Heiderich et al. and numerous other presentations on this topic [2,3]. My suggestion is to either kill -moz-document for public web content or remove regexp support. What do you think? Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1035091 Spec: n/a. This was pushed out of CSS3 and did not make it to CSS4 selectors. MDN: https://developer.mozilla.org/en-US/docs/Web/CSS/@document Target release: ?? Platform coverage: desktop, android [1] http://www.nds.rub.de/research/publications/scriptless-attacks/ [2] http://www.slideshare.net/x00mario/stealing-the-pie [3] https://speakerdeck.com/mikewest/xss-no-the-other-s-cssconf-eu-2013 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- 턞 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
Improving Session Restore Experience (was Re: Reordering opened windows)
(Cc-ing Philipp Sackl, for UX feedback.) At the moment, the simplified algorithm is the following: 1. Read sessionstore.js; 2. Open first window; 3. Synchronously, for each window in sessionstore.js, in the order in which the windows have been opened initially, trigger window opening; (Whenever a window is opened, restore its contents.) Drawbacks: * all windows are racing for CPU, DOM, http cache, etc. which makes startup jank and pretty much ensures that Firefox becomes usable only once all windows have finished loading; * weird on-screen activity during startup, with all these windows showing up in an apparently arbitrary order, whether in front or in the back. Ideally, I would like to change it as follows: 1. Read sessionstore.js; 2. Open first window; 3. Open the window most likely to be used immediately (i.e. the most recently used window); 4. Asynchronously, once that window is restored, open in the background the second window most likely to be used immediately; 5. etc. (Whenever a window is opened, restore its contents.) With this scheme, I believe that there are good chances that the user will be presented with the right window immediately, that the window will be usable faster and that the loading of other windows will take place in the background, without distracting visual effects. However, we cannot do this as changing the order in which windows are opened also changes their order in the Windows taskbar and, possibly, their order in MacOS X desktops. Now, you are right, we can probably do as follows: 1. Read sessionstore.js; 2. Open first window; 3. For each window in sessionstore.js, in the order in which the windows have been opened initially, trigger window opening (hidden); 4. Once we have opened the window that should appear first, make it visible, restore its contents; 5. Asynchronously, once that window is restored and the second window has been opened, make it visible and restore its contents; 6. etc. A bit more complicated, but it should provide almost the same result. Cheers, David On 06/07/14 11:08, Neil wrote: David Rajchenbach-Teller wrote: We are considering redesigning slightly how windows are reopened by Session Restore, to ensure that most recently used windows are loaded first. I can't quite tell from your phrasing whether the bottleneck here is the time it takes to open windows. I'm assuming it is, and that Session Restore has to wait for all the windows to open so that it can prioritise loading the most recent window first. Since Session Restore already knows things such as the size and position of the window it wants to restore, I'm wondering whether it might it be possible to open the windows to about:blank and then start loading browser.xul in the most recent window first. (Obviously this only helps if there are three or more windows to restore, since you have to have loaded browser.xul in the first window to know you want to restore the previous session.) -- 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: Rethinking the crash experience
On 07/07/14 21:21, Ehsan Akhgari wrote: We should keep in mind that sometimes due to startup crashes, we don't get to run any of the code in Firefox, so we can't gate the crash report submission on that code at least in the case of startup crashes. Cheers, Ehsan Yes, we clearly need to keep the behavior as a fallback, in case of startup or near-startup crash. Cheers, David -- 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
Rethinking the crash experience
I haven't experienced crashes in some time, so I may have missed some redesigns, but last time I did, the crash experience looked as follows: 1. Something goes wrong in the code of Firefox; 2. Firefox dies; 3. Crash Reporter appears; 4. Eventually, if the user has clicked restart, Firefox restarts. Point 3. strikes me as rubbing the nose of the user in the problem we encountered, as well as possibly counter-productive if the crash takes place during shutdown. Could we redesign this as follows? 1. Something goes wrong in the code of Firefox; 2. Firefox dies; 3. Crash report is stored to disk, without any dialog; 4. If the crash happened during Firefox shutdown, do nothing, otherwise restart Firefox to its previous state (obviously, we need some measure to prevent this from looping); 5. Upon the next restart, display a bottom doorhanger on all windows Firefox or an add-on encountered a problem [a few seconds ago / on July 4rd, 2014] and recovered. If you wish, Firefox can report it automatically so that we can fix the bug report/not this time/always report/never report. My apologies if this is part of the ongoing CrashManager work. Cheers, David -- 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
Reordering opened windows
Hi, We are considering redesigning slightly how windows are reopened by Session Restore, to ensure that most recently used windows are loaded first. I believe that, in many cases, this would enable users to start browsing faster. However, this has been tried in the past and reverted because it caused windows to appear in the Windows taskbar in an order unpredictable by power users. Is anyone aware of an APIs that could be used to change the order of Windows in the taskbar? The only one I know of is ShowWindow and it is my understanding that using it would cause ugly flicker. Cheers, David -- 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: Depending on libnotify
Well, we basically have the Windows version implemented already. We could possibly use Watchman for other platforms. How do others feel about introducing a dependency towards Watchman? I'm not so happy about the idea of using libuv. We already have many ways of performing I/O and introducing yet another one doesn't sound good, unless we decide to make a coordinated effort to migrate Necko towards libuv. Plus, if I recall correctly, libuv makes no effort to allow access to non-POSIXy stuff, which is bad for us. The inotify limitation on watchers is indeed annoying in the long run, but ok for the kind of applications we have in mind, so that's ok for me. Thanks, David On 02/07/14 18:45, Gregory Szorc wrote: I've written a cross-platform file watching API for Windows/OS X/Linux before. It's no fun. -- 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
Depending on libnotify
For its recently landed WebIDE, the devtools team needs a component to watch changes in a directory (they are currently using a somewhat hackish workaround that they want to replace with something better supported). Both Windows and MacOS X provide built-in functions for this purpose but most Unices including Linux do not. Under Linux, I would like to use libnotify. It is not quite clear to me whether this is something I can do at the moment. Apparently, we already have dependencies towards libnotify in our gnome bindings and our gtk WebAppRT. Can someone shed some light on the subject? Thanks, David -- 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: Depending on libnotify
The main usecase is an editor that needs to 1/ reload resources when they have been modified by an outside application; 2/ see when resources are added or removed. In other words, watching a directory (recursively) for add/remove/modify changes to files. Which library do you suggest? Cheers, David On 02/07/14 13:19, Mike Hommey wrote: libnotify != libinotify. You're talking about the former, but you're thinking about the latter. Note that inotify is not really well suited for some kinds of directory monitoring (so, depends what you really need), and is phased out in favor of fanotify. Also note that glib, which we *do* depend on has a file monitor API, but afaik it's inotify-based and I don't know how well it overcomes the inotify limitations. Mike ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- 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: Depending on libnotify
According to the manpage of fanotify, « there is no support for create, delete, and move events, » which would make it useless for our scenario. What kind of drawbacks are you talking about in the case of inotify? The possible race condition that [1] attempts to solve? Are there any build incantations needed to use glib? Thanks, David [1] https://mail.gnome.org/archives/dashboard-hackers/2004-October/msg00022.html On 02/07/14 15:07, Mike Hommey wrote: I don't know what the windows and osx file monitoring APIs offer. If they have the same kind of drawbacks as inotify for recursive directory monitoring, then it's probably fine to go with inotify, in which case glib is the best choice, as we already depend on it. Otherwise, I'd go with a little shim around the fanotify system calls. There is fanotify support since glibc 2.13, but I'm not sure that's old enough for all the systems we support. (our current glibc dependency is on a version = 2.7, fwiw) Mike -- 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: Intent to implement and ship: Improved ruby parsing in HTML with new tag omission rules
On Wednesday 2014-07-02 10:05 +0300, Henri Sivonen wrote: On Tue, Jul 1, 2014 at 10:58 PM, Koji Ishii kojii...@gluesoft.co.jp wrote: Platform coverage: all platforms (parsing only, layout will be in separate intents) The parsing change is the easy part. Is there a plan to get the layout part implemented? My general take on this issue is: 1) As far as assigning the time of core developers goes, it seems that there's always higher-priority stuff to work on instead of complex ruby layout. 2) If someone else has different priorities, really values complex ruby working and can develop an implementation that truly just takes normal review time from the core developers, I think it makes sense let someone other than the core developers to implement complex ruby. 3) I think the HTML parsing algorithm shouldn't be used as a way to block point 2 from happening. But is point 2 happening? We have a summer intern working on ruby this summer; I'm reasonably optimistic that she'll get much of css-ruby implemented, although maybe omitting some of the harder bits like 'ruby-position: inter-character' (which really isn't so much hard as different from the rest and therefore requiring separate code). See the 7-digit dependencies of https://bugzilla.mozilla.org/showdependencytree.cgi?id=256274maxdepth=1hide_resolved=0 -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
Tree Closure Stats - June 2014
Hi Everyone, (cross posted to dev-platform) Below is the stats for Tree Closures for the main trees that the sheriffs manage. Please feel free to let me know if you have any questions._ _A lot of the backlog numbers were down to there being AWS machines not picking up jobs fast enough. RelEng have been working on this_. Mozilla Inbound_ 2014-06 backlog: 9:46:52 checkin-compilation: 1 day, 2:47:16 checkin-test: 2 days, 23:38:59 infra: 16:57:27 no reason: 0:00:33 other: 1:41:36 total: 5 days, 6:52:43 _Mozilla-Central_ 2014-06 backlog: 4:55:13 checkin-compilation: 3:40:03 checkin-test: 6:24:24 infra: 9:37:15 no reason: 0:00:54 other: 1:42:27 total: 1 day, 2:20:16 _Fx-Team_ 2014-06 backlog: 9:30:43 checkin-compilation: 0:12:54 checkin-test: 9:52:53 infra: 12:14:43 no reason: 0:00:22 other: 1:41:36 total: 1 day, 9:33:11 _B2G-Inbound_ 2014-06 backlog: 5:06:17 checkin-compilation: 4:37:29 checkin-test: 6:54:03 infra: 8:43:13 no reason: 3:19:53 other: 1:01:39 total: 1 day, 5:42:34 If you would like to see how this compares to previous months please see http://futurama.theautomatedtester.co.uk/ David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Session Restore (sessionstore)
I am currently running benchmarks to find the influence of each part of Session Restore data on startup duration. The work is ongoing, but for the moment, I can confirm that closed tabs and closed windows have strictly no measurable influence on startup duration. The ongoing work towards differential updates will remove any influence they may still have at runtime. Consequently, I suggest we concentrate on other parts of Session Restore. Next benchmarks planned: history and forms. Cheers, David On 28/06/14 13:27, Tobias Besemer wrote: I often restart FF because of memory use bloat - a restart cleans up that memory use somewhat. When I do that I expect all my history for each tab to be retained, and to be able to undo closed tabs. History would be retained, old form data would be cleared, closed tabs would be forgotten, but a setting to keep them would be possible. Or I might have to restart because I installed an add-on, etc... This solution would not be for a restart in case of a Firefox- or Extension-Update. It is not uncommon for me to have over 100 tabs, and my wife has had close to 1000 (obviously not fully loaded). I'd say she qualifies as a power user. ;^) I have so much, too. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- 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: Session Restore (sessionstore)
See bug https://bugzilla.mozilla.org/show_bug.cgi?id=956713 for details on the proposed Journaled Storage mechanism. This should bring down the number of writes by an order of magnitude. Cheers, David On 28/06/14 14:32, Tobias Besemer wrote: Am Samstag, 28. Juni 2014 14:25:35 UTC+2 schrieb Tim Taubert: Tobias Besemer wrote: The amount of I/O is always a problem! E.g. for Notebooks in battery use. Yes, of course. That is a known problem and we're working on it by increasing the write interval when running on battery and working towards a journaled storage. As I said before, cleaning sessionstore data on write will not buy you much as we write a lot when Firefox is running. This is the problem we're tackling in the long run and band-aid fixes won't help here. It is not just a question of battery! Too much writing accesses also harms the life-time of HDs or SSDs! I also asked before (on the bugs) about more informations to the journaled storage ... If it is - like I think - a lot of small files, I don't like it! A lot of small files wast a lot of un-used bytes on the storage and brings a big fragmentation to it! This significantly slows down a system! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- 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: Session Restore (sessionstore)
While we should and will reduce the total amount of I/O due to Session Restore, I must add that we have not attempted to compare it to the total amount of I/O due to cache access for instance. I would not be surprised if the cache caused several orders of magnitude more I/O than Session Restore, in which case our efforts on Session Restore would have little to no impact on the life-time of your device or on the battery usage. Tobas, if you have an opportunity to perform a comparison, this would be an interesting piece of data. Cheers, David On 28/06/14 14:32, Tobias Besemer wrote: It is not just a question of battery! Too much writing accesses also harms the life-time of HDs or SSDs! I also asked before (on the bugs) about more informations to the journaled storage ... If it is - like I think - a lot of small files, I don't like it! A lot of small files wast a lot of un-used bytes on the storage and brings a big fragmentation to it! This significantly slows down a system! ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- 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: Session Restore (sessionstore)
I don't follow what you have in mind. Assuming that you suggest we move to sqlite, you seem to be suggesting that we should considerably increase the amount of I/O. Or do I misunderstand what you say? Also, readability of sqlite being better than that of json is quite debatable. Best regards, David On 28/06/14 18:18, Tobias Besemer wrote: OK, I made a short test with: sqlite3.exe places.sqlite .dump places.dump It creates in my case a file with ~9.5MB. But it is really fast !!! :D Also it is much better readable with an editor then JSON and can be used in any other program that can handle SQL ... I think 3MB more for each backup is OK ... Better - if HD is a prob - just make 10 backups then 15 ... IMHO ... ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- 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: Are you interested in doing dynamic analysis of JS code?
I would be interested in adding boundary checks and invariant checks that could be eliminated in opt builds. Is this in the scope of your project? On 25/06/14 17:15, Jason Orendorff wrote: We're considering building a JavaScript API for dynamic analysis of JS code. Here's the sort of thing you could do with it: - Gather code coverage information (useful for testing/release mgmt?) - Trace all object mutation and method calls (useful for devtools?) - Record/replay of JS execution (useful for devtools?) - Implement taint analysis (useful for the security team or devtools?) - Detect when a mathematical operation returns NaN (useful for game developers?) Note that the API would not directly offer all these features. Instead, it would offer some powerful but mind-boggling way of instrumenting all JS code. It would be up to you, the user, to configure the instrumentation, get useful data out of it, and display or analyze it. There would be some overhead when you turn this on; we don't know how much yet. We would present a detailed example of how to use the proposed API, but we are so early in the process that we're not even sure what it would look like. There are several possibilities. We need to know how to prioritize this work. We need to know what kind of API we should build. So we're looking for early adopters. If that's you, please speak up and tell us how you'd like to instrument JS code. -- 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
Intent to unimplement: proprietary window.crypto functions/properties
[dev.platform cc'd for visibility - please follow-up to dev.tech.crypto] Summary: We intend to remove the proprietary window.crypto functions and properties. See https://developer.mozilla.org/en-US/docs/JavaScript_crypto for what will be affected by this change. Our reasoning is as follows: These functions have never been (and never will be) standardized. The implementation has near-nonexistent test coverage. What few tests exist were written as a result of finding easily-encountered bugs years after the original implementation landed[0][1][2]. As it is exposed to web content, it represents a considerable attack surface. It is not well-maintained. It is incompatible with our process-separation and sandboxing efforts. It is not supported or enabled on Firefox OS. Meanwhile, we are making progress on implementing the webcrypto specification[3]. When complete, webcrypto should provide compatible functionality for what these functions are currently being used to do. Any functionality not implementable using webcrypto is available to addons (see the interfaces in security/manager/ssl/public). Note: this does not include window.crypto.subtle or window.crypto.getRandomValues, which are part of webcrypto and do not need to be removed. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1030963 Spec: n/a Platform coverage: desktop, android Target release: 33 Pref: n/a [0] https://bugzilla.mozilla.org/show_bug.cgi?id=849553 [1] https://bugzilla.mozilla.org/show_bug.cgi?id=934716 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=935618 [3] https://bugzilla.mozilla.org/show_bug.cgi?id=865789 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Identifiable TBPL Try push tab titles
Thanks for that change. It's really helpful for my day-to-day use of TBPL. Cheers, David signature.asc Description: OpenPGP digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
BzAPI Compatibility API has been rolled out to production BMO
Until recently, Bugzilla supported only older Web technologies, namely XMLRPC and JSONRPC. The BMO team created a new REST API in the summer of 2013 to provide a modern Web interface to Bugzilla. Prior to the native REST API[1], a separate proxy service called BzAPI[2] was created that provided a REST API using data obtained through the older RPC interfaces as well as various other Bugzilla data sources, including CSV representations. This was a great interim solution, but now that we have a native API, and since the system hosting the proxy is not maintained by Mozilla IT, the BzAPI service will need to be decommissioned at some point. Check out the wiki page[3] for the differences between BzAPI and the native API. To ease the transition, we have created a native BzAPI compatibility layer (bug 880669[4]) that acts almost exactly the same as BzAPI but will translate the queries to the native API layer. Thus clients who currently use BzAPI will just need to change the REST URL to the built-in API[5], which is slightly different from the native one[6]. Even though we've done our own testing, we are interested in having more people test the compat API by changing their dashboards, scripts, apps, etc. to point to the compat API URL instead of the BzAPI proxy. Then try to see if anything doesn't display properly, is missing, or generates an error of some kind. We have a component[7] in Bugzilla under the BMO product that we would like people to use to let us know. You can also browse[8] for bugs that have already been submitted. We plan to leave the compat API in place for the foreseeable future, but we do not plan to make any major changes or enhancements to it. We will be working to enhance the native REST API instead with the upstream Bugzilla community. So any requests for improvements or new features will need to be directed the native API component[9]. Thanks Mozilla BMO Team [1] https://wiki.mozilla.org/BMO/REST [2] https://wiki.mozilla.org/Bugzilla:REST_API [3] https://wiki.mozilla.org/Bugzilla:API_Comparison [4] https://bugzilla.mozilla.org/show_bug.cgi?id=880669 [5] https://bugzilla.mozilla.org/bzapi [6] https://bugzilla.mozilla.org/rest [7] https://bugzilla.mozilla.org/enter_bug.cgi?product=bugzilla.mozilla.orgcomponent=Extensions%3A%20BzAPI%20Compatibility [8] https://bugzilla.mozilla.org/buglist.cgi?product=bugzilla.mozilla.orgcomponent=Extensions%3A%20BzAPI%20Compatibility [9] https://bugzilla.mozilla.org/enter_bug.cgi?product=Bugzillacomponent=WebService ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposed W3C Charter: XML Processing Model Working Group
The W3C is proposing a revised charter for: XML Processing Model Working Group http://lists.w3.org/Archives/Public/public-new-work/2014May/0009.html http://www.w3.org/XML/2014/03/xproc-charter.html deadline for comments: June 19 Mozilla has the opportunity to send comments or objections through June 19. Please reply to this thread if you think there's something we should say. I intend to explicitly abstain from the charter review unless somebody gives a good reason to do otherwise. -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: Standardized assertion methods
On Friday 2014-06-06 17:42 -0700, Jonas Sicking wrote: I definitely understand that it'll be a pain to convert existing tests that rely on the relaxed matching. But rather than making the implementation of is() be more complex and/or more relaxed, could we instead convert those tests to either is_relaxed(a, b) or ok(a == b) Ideally it seems like we want to convert the existing tests to test the correct equality, but that requires some knowledge of what they're supposed to be testing, and also somewhat more manual changes to the tests. Temporarily converting them to is_relaxed (or maybe a scarier sounding name, like deprecated_relaxed_is) might help in fixing the 99% case so that we don't add more problems on top of our existing ones, 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: Overriding the CSP for privileged protocols
On Friday 2014-06-06 00:30 -0700, Matthew Gertner wrote: As things stand, it should be possible for responsible extensions such as ours (we implement our own nsIContentPolicy for our protocol) to do things like inject CSS into pages. We should probably have mechanisms for addons to inject CSS into pages without having to insert a link into the document, though. Injecting link elements can be observed by the page, could break page script (I've seen scripts looking for the first/last style sheet link to add a rule to it), and can presumably be undone by the page if it wants to break the addon. Having a more distinct mechanism for this might avoid these CSP issues. -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: DOMMatrix
On Monday 2014-06-02 20:45 -0700, Rik Cabanier wrote: - change isIdentity() so it's a flag. I'm a little worried about this one at first glance. I suspect isIdentity is going to be used primarily for optimization. But we want optimizations on the Web to be good -- we should care about making it easy for authors to care about performance. And I'm worried that a flag-based isIdentity will not be useful for optimization because it won't hit many of the cases that authors care about, e.g., translating and un-translating, or scaling and un-scaling. -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: Standardized assertion methods
On Wednesday 2014-06-04 14:10 -0400, Boris Zbarsky wrote: For example, should mochitest-plain be consistent with mochitest-chrome? I would argue yes; the distinction between which tests go in which one is more or less arbitrarily decided by what APIs we do or don't have on SpecialPowers. Maybe the right answer is that pure-JS tests like xpcshell and mochitest-browser should be consistent and combined JS-and-markup tests like mochitest-plain and mochitest-chrome should (separately) be consistent but we shouldn't worry about consistency between the two groups of tests? I would very much welcome us actually having this discussion and deciding _this_ point first, before we start deciding which APIs should be deprecated and which should be preferred in which test harness. I strongly agree here about wanting consistency between mochitest-plain and mochitest-chrome because the distinction between them is very small. As a somewhat unusually but actually probably not all that extreme example, when writing content/canvas/test/test_drawWindow.html, I realized most of the way through writing the test -- i.e., when figuring out why the test I'd written didn't show the without-patch failures that were expected -- that half of the test needed to move to mochitest-chrome. So there are now two files, one in mochitest-plain and the other (content/canvas/test/chrome/test_drawWindow_widget_layers.html) in mochitest-chrome that share between them a common JS file containing the actual test assertions. (I believe I didn't want to move the whole test, because, if my memory is correct (I'm writing this offline), we run mochitest-chrome on fewer platforms than mochitest-plain.) -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
Proposed W3C Charter: Social Web Working Group
The W3C is proposing a new charter for two groups: Social Web Working Group http://www.w3.org/2013/socialweb/social-wg-charter.html Social Interest Group http://www.w3.org/2013/socialweb/social-ig-charter.html both in: http://lists.w3.org/Archives/Public/public-new-work/2014May/0011.html deadline for comments: June 10 Mozilla has the opportunity to send comments or objections through June 10. Please reply to this thread if you think there's something we should say. Tantek has been involved in the development of this charter (the Social Web WG) and thinks we should support it, so I intend to support it unless I hear a good reason to do otherwise. -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: bugzilla can now show bugs that have been updated since you last visited them
That sounds quite useful. Thanks, David On 04/06/14 08:34, Byron Jones wrote: thanks to dylan's work on bug 489028, bugzilla now tracks when you view a bug, allowing you to search for bugs which have been updated since you last visited them. see my blog post for more details: http://wp.me/p1JUqW-9M -- 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: Standardized assertion methods
On Tuesday 2014-06-03 15:21 +0200, Mike de Boer wrote: On 03 Jun 2014, at 15:07, Boris Zbarsky bzbar...@mit.edu wrote: I assume that the mochitest version will use a different reporter that doesn't throw-and-terminate, to preserve the current semantics of mochitest assertions. (If this assumption is incorrect, we need to have a separate discussion about that.) If so, we'll have the same methods but different semantics in the different harnesses. Not sure how much of a problem that is in practice... not least because I don't think people actually write xpcshell tests all that much. Ideally, run-until-failure would be a configurable option per test suite. For example, in automation we’d continue on failure and locally we’d stop on failure. Additionally, that’d be configurable per test and per run. 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. -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
Tree Closure Stats - May 2014
Hi Everyone, (cross posted to dev-platform) Below is the stats for Tree Closures for the main trees that the sheriffs manage. Please feel free to let me know if you have any questions. _Mozilla Inbound _Closures due to test failures on Inbound are slightly higher than normal. 2014-05 checkin-compilation: 23:53:02 checkin-test: 3 days, 0:45:33 infra: 11:52:28 planned: 2:34:02 total: 4 days, 15:05:05_ Mozilla Central _ 2014-05 checkin-compilation: 0:02:34 checkin-test: 12:57:52 infra: 12:58:48 total: 1 day, 1:59:14 _ Fx-Team _ 2014-05 checkin-compilation: 0:08:23 checkin-test: 20:24:28 infra: 13:42:36 no reason: 0:00:03 total: 1 day, 10:15:30_ B2G Inbound_ The higher than normal infra closure was down to a 3rd party repository having their master branch tracked which was unfortunately broken. 2014-05 backlog: 6:08:36 checkin-compilation: 1 day, 14:58:51 checkin-test: 15:15:13 infra: 2 days, 1:17:26 total: 4 days, 13:40:06 If you would like to see how this compares to previous months please see http://futurama.theautomatedtester.co.uk/ David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Uncaught rejections in xpcshell will now cause orange
Dear everyone, After weeks tracking and fixing blockers, we are in the process of attempting to land bug 976205. If this sticks, it will change the behavior of xpcshell tests with respect to uncaught asynchronous errors: uncaught promise rejections using Promise.jsm will cause TEST-UNEXPECTED-FAIL. Rationales: 1. uncaught exceptions have always been treated as errors, there is no reason to assume that promise rejections, which implement the same behavior as exceptions, are different; 2. experience has shown that ignoring promise rejections could very easily hide a real bug. Precautions: In order to make sure that all uncaught rejections are reported and to make it easier to pinpoint their sources, we had to make a single assumption. Namely, we assume if a call to `add_task` leaves a rejected promise without any error-handler, this rejection will remain uncaught. So far, this heuristic hasn't caused any false positive. We intend to progressively extend this policy to: - mochitests (bug 1016387); - addon-sdk tests (bug 998277); - DOM Promise (bug 989960). Cheers, David -- 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: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
Regarding the current certificate exception mechanism:
* there is only a single certificate store on the device and therefore
that all exceptions are device-wide
This is an implementation detail - it would not be difficult to change
exceptions to per-principal-per-app rather than just per-principal.
* only one exception can exist per domain at a time
In combination with point 3, is this a limitation? Do we want to support
this? If so, again, it wouldn't be that hard.
* the exception is per-domain, not per-port, so if we add an exception
for port 993 (imaps), that would also impact https.
I don't think this is the case. Either way, it shouldn't be the case.
In summary, it would not be difficult to ensure that the certificate
exception service operates on a per-principal-per-app basis, which would
allow for what we want, I believe (e.g. exceptions for
{email-app}/example.com:993 would not affect {browser-app}/example.com:443).
In terms of solving the issue at hand, we have a great opportunity to
not implement the press this button to MITM yourself paradigm that
desktop browsers currently use. The much safer option is to ask the user
for the expected certificate fingerprint. If it matches the certificate
the server provided, then the exception can safely be added. The user
will have to obtain that fingerprint out-of-band over a hopefully secure
channel.
I would be wary of implementing a more involved scheme that involves
remote services.
Cheers,
David
On 05/28/2014 03:30 PM, Andrew Sutherland wrote:
tl;dr: We need to figure out how to safely allow for invalid
certificates to be used in the Firefox OS Gaia email app. We do want
all users to be able to access their email, but not by compromising the
security of all users. Read on if you work in the security field / care
about certificates / invalid certificates.
== Invalid Certificates in Email Context
Some mail servers out there use self-signed or otherwise invalid SSL
certificates. Since dreamhost replaced their custom CA with valid
certificates
(http://www.dreamhoststatus.com/2013/05/09/secure-certificate-changes-coming-for-imap-and-pop-on-homiemail-sub4-and-homiemail-sub5-email-clusters-on-may-14th/)
and StartCom started offering free SSL certificates
(https://www.startssl.com/?app=1), the incidence of invalid certificates
has decreased. However, there are still servers out there with invalid
certificates. With deeply regrettable irony, a manufacturer of Firefox
OS devices and one of the companies that certifies Firefox OS devices
both run mail servers with invalid certificates and are our existing
examples of the problem.
The Firefox OS email app requires encrypted connections to servers.
Unencrypted connections are only legal in our unit tests or to
localhost. This decision was made based on a risk profile of devices
where we assume untrusted/less than 100% secure wi-fi is very probable
and the cellular data infrastructure is only slightly more secure
because there's a higher barrier to entry to setting up a fake cell
tower for active attacks.
In general, other email apps allow both unencrypted connections and
adding certificate exceptions with a friendly/dangerous flow. I can
speak to Thunderbird as an example. Historically, Thunderbird and its
predecessors allowed certificate exceptions. Going into Thunderbird
3.0, Firefox overhauled its exception mechanism and for a short time
Thunderbird's process required significantly greater user intent to add
an exception. (Preferences, Advanced, Certificates, View Certificates,
Servers, Add Exception.) At this time DreamHost had invalid
certificates, free certificates were not available, invalid certificates
were fairly common, Thunderbird's autoconfig security model already
assumed a reliable network connection, Thunderbird could only run on
desktops/laptops which were more likely to have a secure network, etc.
We relented and Thunderbird ended up where it is now. Thunderbird
immediately displays the Add Security Exception UI; the user only
needs to click Confirm Security Exception. (Noting that Thunderbird's
autoconfig process is significantly more multi-step.)
== Certificate Exception Mechanisms in Platform / Firefox OS
Currently, the only UI affordance to add certificate exceptions is
exposed by the browser app/subystem for HTTPS sites. I assert that this
is a different risk profile and we wouldn't want to follow it blindly
and don't actually want to follow it at all[1].
There are general bugs filed on being able to import a new CA or
certificate at https://bugzil.la/769183 and https://bugzil.la/867899.
Users with adb push access also have the potentially to manually import
certificates from the command line, see
https://groups.google.com/forum/#!msg/mozilla.dev.b2g/B57slgVO3TU/G5TA-PiFI_EJ
It is my understanding that:
* there is only a single certificate store on the device and therefore
that all
Re: B2G, email, and SSL/TLS certificate exceptions for invalid certificates
On 05/28/2014 06:01 PM, Karl Dubost wrote: Andrew, Le 29 mai 2014 à 09:50, Andrew Sutherland asutherl...@asutherland.org a écrit : Trusting you as a human doesn't translate into protecting the users of your server from man-in-the-middle attacks. How do you translate the human trust into the technical trust infrastructure supported by Firefox and Thunderbird and the rest of the Internet? I was replying to the self-signed certificate == laziness. What I'm saying is that if you have 4 users on your server. You may decide to create a certificate yourself and educate your users about what message the certificate will send to their mail client and teach them why they can accept the warning message in this case. But without verifying that the certificate they received is the certificate you created, those users are open to attack. On desktop we unfortunately allowed this to become common. We have an opportunity here to not make the same mistake on mobile. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Style guide clarity on C++-isms
On Wednesday 2014-05-28 21:03 -0700, Nicholas Nethercote wrote:
static T inc(T aPtr) { return IntrinsicAddSubT::add(aPtr, 1); }
static T dec(T aPtr) { return IntrinsicAddSubT::sub(aPtr, 1); }
static T or_( T aPtr, T aVal) { return __sync_fetch_and_or(aPtr, aVal); }
static T xor_(T aPtr, T aVal) { return __sync_fetch_and_xor(aPtr, aVal); }
static T and_(T aPtr, T aVal) { return __sync_fetch_and_and(aPtr, aVal); }
static ValueType inc(ValueType aPtr) { return add(aPtr, 1); }
static ValueType dec(ValueType aPtr) { return sub(aPtr, 1); }
When it comes to questions of style, IMO clarity should trump almost
everything else, and spotting typos in functions like this is *much*
harder when they're multi-line.
Furthermore, one-liners like this are actually pretty common, and
paving the cowpaths is often a good thing to do.
I'd be happy for this to be allowed; I've used this style quite a
bit, for similar reasons (clarity and density).
I also like a similar two-line style for code that doesn't fit on
one line, as in:
bool WidthDependsOnContainer() const
{ return WidthCoordDependsOnContainer(mWidth); }
bool MinWidthDependsOnContainer() const
{ return WidthCoordDependsOnContainer(mMinWidth); }
bool MaxWidthDependsOnContainer() const
{ return WidthCoordDependsOnContainer(mMaxWidth); }
from
http://hg.mozilla.org/mozilla-central/file/9506880e4879/layout/style/nsStyleStruct.h#l1321
but I think that variant may be less widely used.
-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: CSSOM-View scroll-behavior property
On Saturday 2014-05-24 20:00 -0700, Jonas Sicking wrote: I guess what I'm arguing is that smooth-scrolling vs. instant scrolling shouldn't be a per-element CSS property, but rather a per-callsite API argument. I think I tend to agree; I noticed the same thing during the CSS WG meeting last week and sent: http://lists.w3.org/Archives/Public/www-style/2014May/0255.html -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: Do we still need Trace Malloc?
On Monday 2014-05-19 07:25 -0700, Nicholas Nethercote wrote: Do we still need Trace Malloc? I suspect it's barely used these days. For memory profiling, we have about:memory and DMD. For shutdown leak detection we have ASAN and Valgrind. Trace Malloc is documented here: https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/Debugging_memory_leaks#Trace_Malloc Trace Malloc is enabled for all TBPL debug builds. I'm not sure why; I did a try run today where I disabled it and it was green. It's used to get stacks within the deadlock detector, but I'm not sure if that's necessary, and it doesn't seem like it would be that hard to replace if it is necessary. Are you talking about removing it from the debug builds done on our infra, or removing it from the tree? I think the former is fine; I'd like to know more about the memory graph analysis abilities of ASAN before being ok with the latter. (It was enabled because we used to track shutdown leak metrics and some other metrics, but when we switched to tracking performance/memory metrics from graphs to tracking them via regression notices, regression notices weren't added for those measurements, so they just kept regressing without people noticing. At some point we then stopped running them because nobody was looking at them. I wouldn't mind having that metric tracked again in some way because it does catch some real leak regressions in addition to shutdown leaks.) There's also Leaky, which is documented on the abovementioned wiki page. I think it works in tandem with Trace Malloc, and may be a candidate for removal as well. I don't think leaky is in the tree anymore. (It was once in tools/leaky/.) -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: Do we still need Trace Malloc?
On Monday 2014-05-19 20:09 -0700, Nicholas Nethercote wrote: On Mon, May 19, 2014 at 5:32 PM, L. David Baron dba...@dbaron.org wrote: Another is being able to find the root strongly connected components of the memory graph, which is useful for finding leaks in other systems (e.g., leaks of trees of GTK widget objects) that aren't hooked up to cycle collection. It's occasionally even a faster way of debugging non-CC but nsTraceRefcnt-logged reference counted objects. How does trace-malloc do that? It sounds like it would need to know about object and struct layout. Roughly the same way a conservative collector would -- assuming any word-aligned memory in one object in the heap that contains something that's the address of something else in the heap (including in the interior of the allocation) is a pointer to that object in the heap. (It's actually done in the leaksoup tool outside of trace-malloc.) -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 ship: Hyperlink Auditing (a ping)
On Friday 2014-05-16 13:35 +0100, Jonathan Kew wrote: Maybe that's OK, but I do think this changes things in a significant way, and we should give some priority to addressing the concerns. Maybe the send-ping preference should be exposed at a similar level to Do Not Track? There's a tradeoff there, though. If enough users opt out of the preference for sites to care, then sites will just use other ways to track users that aren't controlled by the preference. (And sites could certainly use other ways that don't show up in the Loading... message in the status bar as well; some of these would probably also be faster than redirects.) We need to be careful to design the preferences we expose to the user in ways that make sense even if sites don't want to honor those preferences. It's not clear to me that it makes sense to have a preference to disable one particular tracking feature when sites can do that sort of tracking in many other ways that aren't controlled by the preference. -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 ship: Hyperlink Auditing (a ping)
On Friday 2014-05-16 08:58 -0400, Wesley Hardman wrote: Can you detect if a ping is enabled? If so, having a preference isn't going to be particularly useful as sites will just fallback to the redirect method. If it is added as a UI preference, it needs to be silent, or else the preference is really track via pings, or track via slower redirect. Sites can certainly tell if it's enabled with the help of a server (which those using it would have anyway); they can try it once, and if they get the ping, set a cookie. (And then they might use the faster ping method rather than the redirect only if the cookie is set.) -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 ship: Hyperlink Auditing (a ping)
On Friday 2014-05-16 09:40 -0400, Curtis Koenig wrote: On 16 May, 2014, at 09:37 AM, Kyle Huey m...@kylehuey.com wrote: The point being made is that the preference is not a real choice. If you disable this feature you can still be tracked in the exact same way by methods that exist today and are not covered by the preference. True, but those methods are being done outside of a browser feature we have control over. In this case given that we can implement and control this particular feature behavior we should try to implement it in a way that aligns with our projects values. No, I don't think we can implement control over this particular feature behavior, since for the user to actually have control, the description of the preference needs to be understandable and then actually do what it says. We can control one technical underpinning of tracking which links a user follows, but we can't control all of them. This means that any preference for this that we expose to users would either have to be described in technical jargon that's not meaningful to most users, would have to either be untruthful or unclear about what effects it has. Compare this to the preference for DNT, which says Tell sites that I do not want to be tracked. [1] That's understandable, but also makes it clear that it's not preventing tracking but telling the other end about a preference. Supporting user control should mean that the choices we expose to users actually control useful and understandable things. -David [1] Speaking of DNT -- if it's all just the honor system for honoring this preference anyway -- why shouldn't it just be based on the DNT header anyway? We send the DNT header in the network request for the ping, right? -- 턞 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: Argument validation as a JSM?
I remember opening a bug for this ~2.5 years ago. The answer was that most of these assertions are so trivial to write that putting them in a module would actually make reading the code harder than simpler. I don't think the situation has changed since then. Cheers, David On 15/05/14 08:04, ajvinc...@gmail.com wrote: I've been thinking a bit about writing a JSM for validating arguments coming into a function. The first part would be the set of assertion functions: * a non-empty string * a whole number * a positive number * a non-negative number * a function * instanceof * typeof * member of a set * Custom validation function returning true or false * etc. The second part would be how to respond to an assertion failure: * Throw an Error * Throw Components.Exception * Report to JS console service * Report to a provided Log.jsm logger * Trigger a debugger keyword * Custom failure function * Ordered combinations of the above Above all else, the module should have a simple API. Something like this could be useful throughout the Mozilla codebase, and for addons or custom XULRunner applications. Suggestions? If there's an existing module out there, I'd like to hear of it before reinventing the wheel. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- 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
Proposed W3C Charter: CSS Working Group
The W3C is proposing a revised charter for: Cascading Style Sheets (CSS) Working Group http://lists.w3.org/Archives/Public/public-new-work/2014May/.html http://www.w3.org/Style/2013/css-charter.html deadline for comments: May 29 Mozilla has the opportunity to send comments or objections through May 29. Please reply to this thread if you think there's something we should say. As with charters for other long-lived groups, the details in the list of deliverables largely matter only in that they might constrain what the group is allowed to work on without a new charter; the dates tend to be largely fiction. My intent (unless I get other comments) is to support the charter, but point to comments that have been made on the working group mailing list since the charter was sent out for review (some of which are about documents omitted from the list) so that the W3C has a chance to incorporate those comments (which it probably wouldn't if no AC representative mentioned them). -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) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposal to revise W3C Process
W3C recently published the following proposal to revise the W3C process, which is effectively in the Proposed Recommendation stage right now: http://www.w3.org/2014/05/Process-20140506/ The document contains a description of the major changes in the Status of this Document section. The most substantive change is to merge the Last Call and Candidate Recommendation stages of the process, and begin the Advisory Committee review at Candidate Recommendation. There are also substantive changes to the rules for what constitutes adequate implementation experience. It has been developed mostly in public, in a community group: http://www.w3.org/community/w3process/ (I'm nominally a member, but didn't participate much.) Mozilla has the opportunity to send comments as a W3C member through June 13. Comments can also be made on the public-w3process mailing list. The document will also be under discussion at the Advisory Committee meeting on June 9-10, which I am attending, so if there are comments you think Mozilla should make, it's best that I hear about them prior to that meeting. This is an incremental change to the process. It's making some rather substantive changes to the stages W3C specifications go through, and mostly leaving other areas of the process alone. I'd prefer not to drag other (unrevised) areas of the process document into this process cycle in the hopes that there will be further revisions of the process document to improve other areas of the process (and thus not go another 9 years without a revision to the process), although I concede I haven't talked to others about that idea. If there are things you think Mozilla should raise in its comments, please bring them up in this thread. -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: WebGL 2.0
On Tuesday 2014-05-06 10:15 -0700, Ralph Giles wrote: It looks like doing so would violate to webgl1 spec. An attempt to use any features of an extension without first calling getExtension to enable it must generate an appropriate GL error and must not make use of the feature. https://www.khronos.org/registry/webgl/specs/1.0/#5.14.14 This model generally isn't how extensibility/versioning has been done on the Web platform. On the other hand, it's a model that's less problematic than most of the alternatives that have been proposed, in that it does deal reasonably with multiple implementations and iterative addition of features. The main problem I see is the implementation cost that Anne mentioned: as all these extensions accumulate, that requires implementations to track (forever) which extensions have been requested and whether the API being used has been properly requested. As more and more extensions accumulate, this code could become complicated, possibly even with complexity worse than O(N) in the number of extensions or versions. I also wonder if there's a tension here relating to the target audience. Is WebGL intended primarily for porting applications written for other platforms (and with those other platforms practices and conventions in mind) or primarily for authors building things on the Web platform (and accustomed to its conventions)? -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: OS.File design issue from bug 961080 (making downloads respect umask)
On 28/04/14 21:00, Paolo Amadini wrote: On 4/28/2014 7:44 PM, Zack Weinberg wrote: Based on all discussion to this point, I'm proposing this low-level API: fileObject.setPermissions(options); OS.File.setPermissions(path, options); Generally, this looks good to me. I'd rather use unix as a prefix than posix, to match the rest of the API. Unless somebody disagrees, all that's left is nitpicking and we can finish that discussion on the bug. Cheers, David -- 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: Who is the moderator/owner of this group?
On Sunday 2014-04-27 09:29 -0700, Dave Hylands wrote: Every time I send an email to dev-platform, I get the following email as a reply. Can we get supp...@lativio.com removed from the mailing list? To answer your question in the subject, the moderator of the (mailman side of) this group is listed on: https://lists.mozilla.org/listinfo/dev-platform which says (at the bottom) that it's bsmedberg. Note that the mailman (lists.mozilla.org) - NNTP (news.mozilla.org) - google groups interaction means that moderators sometimes have limited power, since they're only moderator for what happens in mailman. -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: People building and debugging Firefox on Windows wanted
My improvements were closer to 5%. I use VS2013's amd64_x86 cross-compiler. I didn't touch the -FS flag (I imagine it just becomes meaningless). Debug build, before: build 17:06, objdir 3.83GB Debug build, -Z7:build 16:06, objdir 5.22GB Opt build, before: build 17:47, objdir 3.01GB Opt build, -Z7: build 16:59, objdir 4.43GB I used the opt Z7 build for a bug investigation and, at least at first glance, I didn't notice any problems with the debugging information. David - Original Message - From: Mike Hommey m...@glandium.org To: Neil n...@parkwaycc.co.uk Cc: dev-platform@lists.mozilla.org Sent: Thursday, April 24, 2014 11:04:35 PM Subject: Re: People building and debugging Firefox on Windows wanted On Thu, Apr 24, 2014 at 10:19:11AM +0100, Neil wrote: Mike Hommey wrote: mk_add_options export MOZ_DEBUG_FLAGS=-Z7 -Z7 is faster than -Zi? Surprisingly, yes. Do VS2013 users need to turn off -FS? Maybe, although it may just be ignored if using -Z7. 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: Can we remove NS_HIDDEN, NS_HIDDEN_(...)?
On Wednesday 2014-04-23 07:51 +0900, Mike Hommey wrote: On Wed, Apr 23, 2014 at 10:41:06AM +1200, Robert O'Callahan wrote: checking For gcc visibility bug with class-level attributes (GCC bug 26905)... yes checking For x86_64 gcc visibility bug with builtins (GCC bug 20297)... yes Is that a problem? No, that's just how we choose between #pragma visibility and -fvisibility=hidden https://bugzilla.mozilla.org/show_bug.cgi?id=273336#c0 describes the advantages of #pragma visibility over -fvisibility=hidden (at least on Linux; from bsmedberg's post it sounds like it doesn't make a difference on Mac). (That patch was later conditioned on configure tests in bugs 293438 and 307168 to work around compiler bugs; this is the configure test you're observing.) -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: ASSERTION: bad size recorded: 'aInstanceSize == 0 || entry-GetClassSize() == aInstanceSize
On Saturday 2014-04-19 08:36 +0900, ISHIKAWA,chiaki wrote: I see the following ASSERTION error about *800* times during test run of |mach mochitest-plain| of full debug build of FF created from M-C portion (./mozilla) of C-C source tree. They look grave but test harness seems to pass the tests themsevles most of the time. ###!!! ASSERTION: bad size recorded: 'aInstanceSize == 0 || entry-GetClassSize() == aInstanceSize', file /REF-COMM-CENTRAL/comm-central/mozilla/xpcom/base/nsTraceRefcnt.cpp, line 441 What does this error mean? I have not seen these assertions in full debug TB test and so not sure how grave or light the assertions are. A typical trace shows something like this (sanitized a bit to remove the timestamp at the beginning of the each line) : It probably means that there are two different classes reporting the same name to nsTraceRefcnt. Classes that use the NS_IMPL_ISUPPORTSn or NS_IMPL_ADDREF + NS_IMPL_RELEASE macros should use the fully qualified class name and not depend on being inside namespace declarations. In this case, I think the problem is mozilla::dom::MessagePort and mozilla::dom::workers::MessagePort. -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: Is XPath still a thing?
On 14/04/2014 22:28, Eric Shepherd wrote: I think I know the answer to this, but want to confirm: is XPath a going concern? We want to be sure of its current status before migrating its documentation to where it ought to be assuming that it is in fact something people still use. XPath is still a going concern from where I stand. Web Testing people, who use Selenium WebDriver, use XPath extensively since they struggle to get to have testable documents. Having decent documentation for them would be awesome :) David P.S. Having a native implementation of XPath makes Selenium WebDriver a lot faster than say Internet Explorer which doesnt have a native implementation and relies on a JavaScript polyfill. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Is XPath still a thing?
Not from my side! David On 14/04/2014 22:41, Eric Shepherd wrote: On 2014-04-14 21:38:24 +, David Burns said: XPath is still a going concern from where I stand. Web Testing people, who use Selenium WebDriver, use XPath extensively since they struggle to get to have testable documents. Having decent documentation for them would be awesome :) On 2014-04-14 21:38:20 +, Anne van Kesteren said: I don't think we should actively recommend it. We're maintaining the existing code, but are not upgrading our level of support or anything. And if we could get rid of the existing code, we would. Well, there's the expected yes/no answer I was looking for. My inclination is to go ahead and migrate the doc and keep it in the main body of our documentation content, but maybe with an added notice that support is limited yadda yadda yadda... Any disagreements? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Policy for disabling tests which run on TBPL
On Wednesday 2014-04-09 11:00 -0700, Gregory Szorc wrote: The simple solution is to have a separate in-tree manifest annotation for intermittents. Put another way, we can describe exactly why we are not running a test. This is kinda/sorta the realm of bug 922581. The harder solution is to have some service (like orange factor) keep track of the state of every test. We can have a feedback loop whereby test automation queries that service to see what tests should run and what the expected result is. Of course, we will want that integration to work locally so we have consistent test execution between automation and developer machines. I think both of these are bad. It should be visible near the tests whether they are running or not, rather than out of band, so that module owners and those working on the code are aware of the testing coverage. Annotating something as intermittent is halfway to disabling, and should thus be reviewed by test authors / module owners just like disabling should be; it sounds like you're proposing changing that as well. The latter solution also breaks being able to describe a test run with reference to a revision in the VCS repository. -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: Policy for disabling tests which run on TBPL
On Tuesday 2014-04-08 11:41 -0700, Gavin Sharp wrote: I see only two real goals for the proposed policy: - ensure that module owners/peers have the opportunity to object to any disable test decisions before they take effect - set an expectation that intermittent orange failures are dealt with promptly (dealt with first involves investigation, usually by a developer familiar with the code, and can then lead to either them being fixed, disabled, or ignored) I'm fine with the initial policy proposed at the top of the thread; this part of the subthread seemed to be about a proposal to auto-retry failing tests and report them as passing if they intermittently pass; that's the bit I'm not comfortable with. -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: Policy for disabling tests which run on TBPL
On Friday 2014-04-04 11:58 -0700, jmaher wrote: As the sheriff's know it is frustrating to deal with hundreds of tests that fail on a daily basis, but are intermittent. When a single test case is identified to be leaking or failing at least 10% of the time, it is time to escalate. Escalation path: 1) Ensure we have a bug on file, with the test author, reviewer, module owner, and any other interested parties, links to logs, etc. 2) We need to needinfo? and expect a response within 2 business days, this should be clear in a comment. 3) In the case we don't get a response, request a needinfo? from the module owner with the expectation of 2 days for a response and getting someone to take action. 4) In the case we go another 2 days with no response from a module owner, we will disable the test. Are you talking about newly-added tests, or tests that have been passing for a long time and recently started failing? In the latter case, the burden should fall on the regressing patch, and the regressing patch should get backed out instead of disabling the test. Ideally we will work with the test author to either get the test fixed or disabled depending on available time or difficulty in fixing the test. This is intended to respect the time of the original test authors by not throwing emergencies in their lap, but also strike a balance with keeping the trees manageable. If this plan is applied to existing tests, then it will lead to style system mochitests being turned off due to other regressions because I'm the person who wrote them and the module owner, and I don't always have time to deal with regressions in other parts of code (e.g., the JS engine) leading to these tests failing intermittently. If that happens, we won't have the test coverage we need to add new CSS properties or values. More generally, it places a much heavier burden on contributors who have been part of the project longer, who are also likely to be overburdened in other ways (e.g., reviews). That's why the burden needs to be placed on the regressing change rather than the original author of the test. Two exceptions: 1) If a test is failing at least 50% of the time, we will file a bug and disable the test first These 10% and 50% numbers don't feel right to me; I think the thresholds should probably be substantially lower. But I think it's easier to think about these numbers in failures/day, at least for me. 2) When we are bringing a new platform online (Android 2.3, b2g, etc.) many tests will need to be disabled prior to getting the tests on tbpl. That's reasonable as long as work is done to try to get the tests enabled (at a minimum, actually enabling all the tests that are passing reliably, rather than stopping after enabling the passing tests in only some directories). -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: Policy for disabling tests which run on TBPL
On Friday 2014-04-04 12:49 -0700, jmaher wrote: If this plan is applied to existing tests, then it will lead to style system mochitests being turned off due to other regressions because I'm the person who wrote them and the module owner, and I don't always have time to deal with regressions in other parts of code (e.g., the JS engine) leading to these tests failing intermittently. If that happens, we won't have the test coverage we need to add new CSS properties or values. Interesting point. Are these tests failing often? Can we invest some minimal time into these to make them more reliable from a test case or test harness perspective? They're not failing often. But there has been at least one (and I think more) occasion where changes in very unrelated code (one was tracked down to a JS JIT change) caused them, and a bunch of other tests, to start failing intermittently at higher frequency. I think detecting this sort of pattern, of a low level change causing large numbers of tests to fail at moderate frequency, should be detected in a way that doesn't lead to us disabling large numbers of tests (and then probably failing to re-enable them when the problem is resolved). I think we could use better tools for finding regression windows for intermittent failures. I'd also note that I've been trying to give frequent intermittent oranges in layout a reasonably high priority, and encourage others to do the same. I think we've been doing a reasonably good job at this lately, although rates of progress have varied. -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: mozilla::Atomic considered harmful
On Wednesday 2014-04-02 12:50 +0900, Mike Hommey wrote: On Tue, Apr 01, 2014 at 08:34:01PM -0400, Ehsan Akhgari wrote: That is the code after I changed it. :-) Here is the original patch which introduced this bug: https://bug935778.bugzilla.mozilla.org/attachment.cgi?id=8385072 The thread safety issue was _not_ there before that patch. I'm not saying there was a thread safety issue before. I'm saying that in your example, there is largely the same thread safety issue whether the code uses a plain int or an atomic one. The use of atomics is _not_ hiding this bug. That's not the issue. The issue is that the syntax is hiding the use of atomics. And whether the code would have had a thread-safety bug if it hadn't been using atomics is also not relevant; lots of single-threaded code has thread-safety bugs if you magically decide to violate its threading invariants and use the same object on multiple threads when it wasn't designed for that. The issue here is whether this particular way of writing threadsafe code leads people modifying that code to make mistakes because they don't even notice that it's threadsafe code. As I said in the bug, all this is saying is that thread safety is hard, and atomics are merely one of the tools to achieve thread safety. They are not a magic wand that fixes thread safety. Did you read https://bugzilla.mozilla.org/show_bug.cgi?id=987887#c20? Did you read my answer to that comment? I think you're continuing to ignore the fact that using operator overloading obscures what those operators are doing underneath, and when that difference is important to the reader of the code, overloading might not be a good idea. Continuing to reduce my argument here to atomics should be a magic wand is really depressing. I also think that making their API not have operators like std::atomic has would bring a false sense of security to people writing code using them, because it would supposedly be less confusing when it really wouldn't. Can you please give an example of that concern? I'm not sure if I follow. Just take the original patch which introduced the bug. I seriously don't believe if the patch had been using FetchAndAdd instead of ++/-- the issue would have had more chance of being caught at review. And I don't believe it would make people more likely to make atomic-using code thread safe. You might claim that the increased chance of being caught is small, but claiming it's zero is laughable. -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: Promise.jsm and the predefined Promise object
On 3/31/14 1:34 PM, smaug wrote: Promise.jsm and Promise are still interoperable from the functional point of view, the difference is in the above non-functional characteristics. Promise.jsm also has better performance due to the fact that it avoids the JavaScript / C++ / JavaScript turnaround time on chain resolution, Has this shown up in profiles? If so, could you please give links to the profiles, since we should get fast promise handling to the web platform. I don't remember that we did any benchmark on this. I seem to remember that this was an assumption based on a discussion with bz a long time ago, but it might have been someone else. Numbers would be interesting, though. Paolo, do you have plans to perform benchmarking? Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Firebug in embedded XULRunner.
Le mercredi 19 février 2014 13:43:57 UTC+1, apransk...@gmail.com a écrit : We need to debug and measure execution time of JavaScript inside the pages we display. For this sort of work, web developers tend to use PhantomJS or CasperJS nowadays. http://phantomjs.org/ http://casperjs.org/ (built on top of Phantom (Webkit) or SlimerJS (Gecko)). I have no idea as to the Java embedding story for this though. David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Promise.jsm and the predefined Promise object
On 3/29/14 7:33 PM, Gregory Szorc wrote: If Promise.jsm is obviously superior, why don't we expose that version to chrome-privileged global scopes by default? One less footgun. If we did this, we would end up with two distinct Promise globals, with two distinct semantics. This seems to me like the bigger footgun. Also, keeping the necessity to import Promise.jsm will make it easier to eventually migrate from Promise.jsm to [a superset of] DOM Promise once we consider that everything is ready for that migration. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Warning about mutating the [[Prototype]] of an object ?
The prototype mutation is hardly necessary for bug 939072, it is just a nice way to avoid a few indirections. On 3/28/14 7:15 PM, Gregory Szorc wrote: I'm concerned about this as well. In bug 939072, we're looking at doing some dynamic prototype mutation so Sqlite.jsm can do things like auto-close databases that have been inactive for a while (freeing resources in the process). The prototype mutation allows us to do this transparently without consumers of the API having to care about the state of the connection. I'd appreciate if someone could chime in on bug 939072 with a recommended solution that won't bog down performance. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: MOZ_ASSUME_UNREACHABLE is being misused
On Friday 2014-03-28 13:41 -0700, Jeff Gilbert wrote: My vote is for MOZ_ASSERT_UNREACHABLE and MOZ_OPTIMIZE_FOR_UNREACHABLE. It's really handy to have something like MOZ_ASSERT_UNREACHABLE, instead of having a bunch of MOZ_ASSERT(false, Unreachable.) lines. Consider MOZ_ASSERT_UNREACHABLE being the same as MOZ_OPTIMIZE_FOR_UNREACHABLE in non-DEBUG builds. I agree on the first (adding a MOZ_ASSERT_UNREACHABLE), but I don't think MOZ_OPTIMIZE_FOR_UNREACHABLE sounds dangerous enough -- the name should make it clear that it's dangerous for the code to be reachable (i.e., the compiler can produce undefined behavior). MOZ_DANGEROUSLY_ASSUME_UNREACHABLE is one idea I've thought of for that, though it's a bit of a mouthful. -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: Spring cleaning: Reducing Number Footprint of HG Repos
What are mission critical repos since you just put everything in the same list? If we start removing project branches to be put on outsourced VCS we remove any sheriff support for that project branch since, as been pointed out many times, we dont have access to the server side commit hooks and can't close the tree. This may (I want to use *want* but don't have the data to prove it) impact engineering productivity. We have this situation with Gaia which has its canonical repo on Github. Sheriffs can land checkin-needed but can't close the tree. The way the B2G people do it is to remove everyone from the repo and then re-add (or thats how they used to do it) which then spams you with you are now getting notifications for repository X which is annoying. There is the other thing we need to worry about is the constant DDoS of Github[1]. We have seen that when there is a massive one it will take down their site for hours impacting engineering productivity again since people can't pull or push. I couldn't find similar reports on bitbucket but it can happen to any third party we may use. David [1] https://github.com/blog/1796-denial-of-service-attacks On 26/03/2014 23:53, Taras Glek wrote: *User Repos* TLDR: I would like to make user repos read-only by April 30th. We should archive them by May 31st. Time spent operating user repositories could be spent reducing our end-to-end continuous integration cycles. These do not seem like mission-critical repos, seems like developers would be better off hosting these on bitbucket or github. Using a 3rd-party host has obvious benefits for collaboration self-service that our existing system will never meet. We are happy to help move specific hg repos to bitbucket. Once you have migrated your repository, please comment in https://bugzilla.mozilla.org/show_bug.cgi?id=988628so we can free some disk space. *Non-User Repos* There are too many non-user repos. I'm not convinced we should host ash, oak, other project branches internally. I think we should focus on mission-critical repos only. There should be less than a dozen of those. I would like to stop hosting non-mission-critical repositories by end of Q2. This is a soft target. I don't have a concrete plan here. I'd like to start experimenting with moving project branches elsewhere and see where that takes us. *What my hg repo needs X/Y that 3rd-party services do not provide?* If you have a good reason to use a feature not supported by github/bitbucket, we should continue hosting your repo at Mozilla. *Why Not Move Everything to Github/Bitbucket/etc?* Mozilla prefers to keep repositories public by-default. This does not fit Github's business model which is built around private repos. Github's free service does not provide any availability guarantee. There is also a problem of github not supporting hg. I'm not completely sure why we can't move everything to bitbucket. Some of it is to do with anecdotal evidence of robustness problems. Some of it is lack of hooks (sans post-receive POSTs).Additionally, as with Github there is no availability guarantee. Hosting arbitrary Moz-related hg repositories does not make strategic sense. We should do the absolute minimum(eg http://bke.ro/?p=380) required to keep Firefox shipping smoothly and focus our efforts on making Firefox better. Taras ps. Footprint stats: *Largest User Repos Out Of ~130GB* 1.1Gdmt.alexandre_gmail.com 1.1Gjblandy_mozilla.com 1.1Gjparsons_mozilla.com 1.2Gbugzilla_standard8.plus.com 1.2Gmbrubeck_mozilla.com 1.2Gmrbkap_mozilla.com 1.3Gdcamp_campd.org 1.3Gjst_mozilla.com 1.4Gblassey_mozilla.com 1.4Ggszorc_mozilla.com 1.4Giacobcatalin_gmail.com 1.5Gcpearce_mozilla.com 1.5Ghurley_mozilla.com 1.6Gbsmedberg_mozilla.com 1.6Gdglastonbury_mozilla.com 1.6Gdtc-moz_scieneer.com 1.6Gjlund_mozilla.com 1.6Gsarentz_mozilla.com 1.6Gsbruno_mozilla.com 1.7Gmshal_mozilla.com 1.9Gmhammond_skippinet.com.au 2.1Glwagner_mozilla.com 2.4Garmenzg_mozilla.com 2.4Gdougt_mozilla.com 2.5Gbschouten_mozilla.com 2.7Ghwine_mozilla.com 2.8Geakhgari_mozilla.com 2.8Gmozilla_kewis.ch 2.9Grcampbell_mozilla.com 3.1Gbhearsum_mozilla.com 3.1Grjesup_wgate.com 3.2Gagal_mozilla.com 3.3Gaxel_mozilla.com 3.3Gprepr-ffxbld 4.2Gjford_mozilla.com 4.3Gmgervasini_mozilla.com 4.6Glsblakk_mozilla.com 5.0Gbsmith_mozilla.com 5.5Gnthomas_mozilla.com 5.8Gcoop_mozilla.com 6.5Gjhopkins_mozilla.com 7.7Graliiev_mozilla.com 9.2Gcatlee_mozilla.com 13Gstage-ffxbld *Space Usage by Non-user repos ~100GB* 24K integration/gaia-1_4 28K addon-sdk 28K projects/collusion 32K integration/gaia-1_1_0
Re: Spring cleaning: Reducing Number Footprint of HG Repos
On Wednesday 2014-03-26 16:53 -0700, Taras Glek wrote: *User Repos* TLDR: I would like to make user repos read-only by April 30th. We should archive them by May 31st. Time spent operating user repositories could be spent reducing our end-to-end continuous integration cycles. These do not seem like mission-critical repos, seems like developers would be better off hosting these on bitbucket or github. Using a 3rd-party host has obvious benefits for collaboration self-service that our existing system will never meet. We are happy to help move specific hg repos to bitbucket. Once you have migrated your repository, please comment in https://bugzilla.mozilla.org/show_bug.cgi?id=988628so we can free some disk space. This seems like a pretty disruptive change -- it involves breaking links to the places lots of little pieces of our infrastructure live. It also means that we're not in control of our own data in a way that's often useful to us -- having access to our history is often very important for understanding the present (such as understanding why code is the way it is). If we don't have reliable archiving of our history, those of us who think it's important will end up spreading that work around and probably being less efficient at it. (For example, I try to save dev-platform threads that I think are important locally because I don't trust the Google Groups archive to be permanent.) It also makes it harder to find Mozilla-related things. For example, many of us publish version-controlled patch queues as user repositories. If I'm reviewing a patch queue and want to apply the queue, I occasionally look around at see if that user has published the patch queue as a user repository so that I can apply it. If there's no longer a standard place for them to be published, I'll end up either sorting out the patch order manually or waiting 24 hours for somebody in another timezone to wake up and tell me where it is. *Non-User Repos* There are too many non-user repos. I'm not convinced we should host ash, oak, other project branches internally. I think we should focus on mission-critical repos only. There should be less than a dozen of those. I would like to stop hosting non-mission-critical repositories by end of Q2. The goal of project branches is so that teams can collaborate on a project that needs continuous integration testing during its development. Are we not using it for that? Hosting arbitrary Moz-related hg repositories does not make strategic sense. We should do the absolute minimum(eg http://bke.ro/?p=380) required to keep Firefox shipping smoothly and focus our efforts on making Firefox better. I think it makes sense if individual developers are going to end up spending more time/resources working around the fact that we don't do it than it would take to continue doing it. I don't have data one way or another, but I think it's a real possibility. -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: Spring cleaning: Reducing Number Footprint of HG Repos
On Thursday 2014-03-27 14:11 +0900, Mike Hommey wrote: Note that while user repositories are self-service on the creation side, there is no obvious way to self-service a user repo removal. I'm not in They're just as easy to remove as to create: https://developer.mozilla.org/en-US/docs/Creating_Mercurial_User_Repositories#Editing_your_personal_repository -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
talk on XPCOM and String APIs
During a Layout work week in Taipei last week, I gave a talk on: (1) some bits of XPCOM and its history that I thought were worth talking about (2) our string APIs (a bit about what the internal string APIs do and why and how to use them) (roughly a half hour on each topic) Since others might be interested, it's at: https://air.mozilla.org/xpcom-and-internal-strings-in-gecko/ -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: Proposed W3C Charter: Timed Text Working Group (WebVTT and TTML)
On Monday 2014-03-17 13:31 -0400, Richard Eyre wrote: Thanks for adding me Anne, you did get my email correct :-). Personally, I'm not interested in developing TTML. I still agree to all the points from our previous discussion from the page you linked, Anne. I'm not really sure whether having a joint working group would be of benefit, particularly if there isn't interest in developing TTML in the WebVTT community, which from my experience is the case. It also scares me a bit because having a joint group might result in WebVTT being modified for TTML specific reasons, such as better interoperability, or otherwise, (possibly?) which wouldn't be good for the spec moving forward due to our previous concerns. Sorry for not catching up on this thread until it's too late, but anyway: I'm inclined to think that it's not worth putting up a massive fight over the group's organization here, which I think is what it would take to change this plan. I think I'd rather focus the bandwidth of our communication with W3C management on other issues. I think if the group goes off into the weeds, it's worth putting up a fight over that, primarily in the group itself. (On the other hand, I think it is worth listening to the real needs of producers who have large libraries of captions that they'd like to convert to WebVTT.) I suppose I should at least send late feedback over the decision process, and perhaps also that there should be more mention of the working group operating as two subgroups than Teleconferences: Weekly for TTML, and as needed for WebVTT. -David On Mon, Mar 17, 2014 at 9:42 AM, Anne van Kesteren ann...@annevk.nl wrote: On Tue, Feb 25, 2014 at 7:56 AM, L. David Baron dba...@dbaron.org wrote: The W3C is proposing a revised charter for: Timed Text Working Group http://lists.w3.org/Archives/Public/public-new-work/2014Feb/0004.html http://www.w3.org/2013/10/timed-text-charter.html deadline for comments: March 20 This new charter is quite substantive, in that it recharters a working group that was previously only for TTML to now be to develop both TTML and WebVTT. My understanding is that the two halves of the group are expected to operate somewhat separately but also interact, although the charter doesn't seem to say that explicitly. Mozilla has the opportunity to send comments or objections through March 20. Please reply to this thread if you think there's something we should say. So we commented pretty strongly against this in the past: http://lists.w3.org/Archives/Public/www-archive/2013May/0034.html Has something changed? (Not sure I got the correct email address for Rick, I found it on old archived email from a year ago.) -- http://annevankesteren.nl/ -- 턞 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: Should nsIPrefBranch.set*Pref return NS_ERROR_UNEXPECTED on type mismatch?
On Thursday 2014-03-20 13:38 -0400, Irving Reid wrote: In a way we're dancing around competing footguns here - do we protect against bad code trying to break our preferences by setting a value to the wrong type, or do we protect against a broken preference messing up our code because we can't recover from a wrong type? It seems possible to fix both problems (for prefs with values in a default preferences file) by making the pref code refuse to set a preference to a type other than the one in the default preferences file. If the set were in a user preferences file, it would just be ignored; if it were in a set*Pref call, it would throw an exception. Whether this is worth the work or the (probably not huge, but also nonzero) compatibility risk is another question. [ Written on an airplane; sorry if I missed responses in the last 11 hours. ] -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: Memory management in features implemented in JS
So basically, you want to add a finalizer for JS component? Note that we already have a weak (post-mortem) finalization module for JS, hidden somewhere in mozilla-central. It's not meant to be used for performance critical code, and it provides no guarantees about cycles, but if this is necessary, I could rework it in something a bit faster/more robust. Cheers, David On 3/20/14 1:25 AM, smaug wrote: And we could add a flag to WrappedJS so that it would call some callback when it is about to go away. That would let cleanup of WeakPromise happen asap. Basically keep a hashtable wrappedjs - objects_implementing_callback_interface_foo. Then when adding an object to the hashtable, wrappedjs would get marked with a flag, that it should look at the hashtable when it is going away, and if there is value in the hashtable, call the foo. This cleanup mechanism could be used with weak observers and weak listeners too. -Olli ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Memory management in features implemented in JS
Couldn't we insist that any reference to a DOM element in JS (or at least in JS-implemented components) must be a weak pointer-style wrapper? I seem to remember that we have introduced something along these lines a few years ago as a way to fight against leaks of references to DOM by add-ons. On 3/20/14 12:39 AM, Kyle Huey wrote: Followup to dev-platform please. -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship: @counter-style rule
On Wednesday 2014-03-12 22:43 -0400, Ehsan Akhgari wrote: It's sad to see us ship a new feature using the old XPConnect based DOM bindings, as we have been transition to the new WebIDL based bindings [2]. 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? I don't think we should do this before landing; I'd rather convert all CSS rules at once in https://bugzilla.mozilla.org/show_bug.cgi?id=851892 -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: Using preferences off the main thread now asserts
On Thursday 2014-03-06 19:52 -0800, Nicholas Nethercote wrote: On Thu, Mar 6, 2014 at 8:20 AM, Kyle Huey m...@kylehuey.com wrote: It's taken over 3 years, but Bug 619487 is now fixed, and the preferences service will assert (fatally) if you try to use it off the main thread. Out of curiosity, what's the benefit of this? Is it just a correctness issue? The bug didn't have much detail. It's an issue of not crashing when trying to manipulate the same hashtable from two different threads at the same time without any sort of locking. -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: W3C Proposed Recommendations: WAI-ARIA (accessibility)
On Tuesday 2014-02-25 09:43 -0500, david bolter wrote: I support this W3C Recommendation. Yep. While I wasn't entirely happy with some of the history that led to the current state, I agree we should support it. (In particular, in the early days of ARIA I was told, in private conversations, that it was intended as a temporary measure until HTML5 was ready and had enough of the semantics needed. But I never asked the people telling me that that that intent should be documented publicly, and as far as I know there's no public record of it, and it probably didn't represent any consensus at the time. I'd probably have preferred that the semantics needed for accessibility were part of the semantics of the language rather than a separate add-on that can be inconsistent, but that's also not the way the Web platform works today. I did learn something about the value of working in public, though.) So I'll submit a review in support of advancing to Recommendation as-is. -David On Tue, Feb 11, 2014 at 2:22 PM, L. David Baron dba...@dbaron.org wrote: W3C recently published the following proposed recommendations (the stage before W3C's final stage, Recommendation): Accessible Rich Internet Applications (WAI-ARIA) 1.0 http://www.w3.org/TR/2014/PR-wai-aria-20140206/ WAI-ARIA 1.0 User Agent Implementation Guide http://www.w3.org/TR/2014/PR-wai-aria-implementation-20140206/ -- 턞 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: Blink removing the concept of user styles?
On Sunday 2014-03-02 10:58 -0800, Asa Dotzler wrote: How much simpler could our style code be if we followed this path? What do the standards and other browser vendors say about this? Horrible idea? Great idea? Mixed? This is in preparation for simplifying the Blink style resolution code by removing the concept of user styles. https://src.chromium.org/viewvc/chrome?revision=234007view=revision Conceptually, not at all. It would be one fewer item in an array. -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: We live in a memory-constrained world
On Friday 2014-02-28 11:04 +, Neil wrote: Henri Sivonen wrote: Any chance static atoms could reside as plain old static C data structures in the data segment of libxul.so instead of being heap-allocated? At least under MSVC, they have vtables, so they need to be constructed, so they're not static. Note that their string storage is static, through the use of fake string buffers (possibly this should be switched to fake literal strings). Remember that since this is all in a shared library (which might be loaded at different addresses, or even different addresses in different processes [1]), you also have to worry about relocations. In other words, whenever you have a pointer in a static data structure pointing to some other data, that pointer needs to get fixed up when the library loads, which makes the memory that pointer is in less likely to be shared across processes (depending, I guess, on how many processes are able to load the library at its default address, which may in turn depend on security features that try to randomize library base addresses). This also slows down loading of shared libraries. Or something like that; please correct me if this is wrong. -David [1] Shouldn't be an issue with Nuwa-cloned processes on B2G, though. -- 턞 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: Consensus sought - when to reset try repository?
On Friday 2014-02-28 17:24 -0800, Hal Wine wrote: So, the question is - what say developers -- what's the balance point between: - too often, making collaborating on try pushes hard - too infrequent, introducing increasing push times Why not change the try repo reset procedure so that instead of just cloning mozilla-central, you also pull from the old try repo into the new one all of the heads of try pushes made within the last one or two weeks. (Presumably there's a list of them somewhere, or it could be maintained?) Then the try reset won't break things for those recent pushes, but only the older ones. -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: Consensus sought - when to reset try repository?
On Friday 2014-02-28 17:44 -0800, John Schoenick wrote: Or taking this a step further, having a rolling cronjob |hg strip| revisions not on m-c older than a certain date would remove the need to perform resets entirely, and give a predictable date after which your try push would disappear. You could even add a keep me for N days parameter to try syntax for pushes that we'd like to stick around. I'm not sure how well hg strip would interact with a repository that people are pushing to at the same time, 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: Fixing build warnings [was: Re: Always brace your ifs]
On Thursday 2014-02-27 15:44 -0500, Zack Weinberg wrote: This is exactly the same thing dbaron said the last time I brought this up (quite some time ago - 2010, maybe?) I didn't buy it then and I don't buy it now. I think it is far more likely that a maybe-used-uninitialized true positive will *go unnoticed* because we've trained ourselves to ignore those warnings, and I don't think better precision in a valgrind run is worth the risk of letting a true positive slip through in a release build. Those bugs tend to be security critical. I'm ok with it if you're initializing it to a value that's properly handled as a reasonable default by the later code. But if you're initializing it to something that's arbitrary or useless (like, say, initializing an enumerated type to 0 so that you'll fall into whichever case that happens to be, whether it involves assuming a tagged pointer is of a certain type or not), I'm still against, and I'd rather see the valgrind warning. But I'm ok with restructuring the code to avoid having either problem. I also defy anyone to demonstrate a measurable performance impact from the tiny amount of additional machine code that might be emitted if we added initializations to squelch all those warnings. I'm not at all concerned about performance impact. -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: Proposed W3C Charter: Geolocation Working Group
On Monday 2014-02-24 23:57 -0800, L. David Baron wrote: The W3C is proposing a revised charter for: Geolocation Working Group http://lists.w3.org/Archives/Public/public-new-work/2014Feb/0002.html http://www.w3.org/2014/02/geo-charter.html deadline for comments: March 15 I don't know any of the background on this one. Actually, I do know one piece of background, which is that the comparison to the prevous charter is this: http://services.w3.org/htmldiff?doc1=http%3A%2F%2Fwww.w3.org%2F2008%2Fgeolocation%2Fcharter%2Fcharter-2doc2=http%3A%2F%2Fwww.w3.org%2F2014%2F02%2Fgeo-charter.html (removed material in red; added material in yellow or green) -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
Proposed W3C Charter: Timed Text Working Group (WebVTT and TTML)
The W3C is proposing a revised charter for: Timed Text Working Group http://lists.w3.org/Archives/Public/public-new-work/2014Feb/0004.html http://www.w3.org/2013/10/timed-text-charter.html deadline for comments: March 20 This new charter is quite substantive, in that it recharters a working group that was previously only for TTML to now be to develop both TTML and WebVTT. My understanding is that the two halves of the group are expected to operate somewhat separately but also interact, although the charter doesn't seem to say that explicitly. Mozilla has the opportunity to send comments or objections through March 20. Please reply to this thread if you think there's something we should say. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Proposed W3C Charter: Geolocation Working Group
The W3C is proposing a revised charter for: Geolocation Working Group http://lists.w3.org/Archives/Public/public-new-work/2014Feb/0002.html http://www.w3.org/2014/02/geo-charter.html deadline for comments: March 15 I don't know any of the background on this one. Mozilla has the opportunity to send comments or objections through March 15. Please reply to this thread if you think there's something we should say. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla http://www.mozilla.org/ 턂 signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Always brace your ifs
On Saturday 2014-02-22 15:57 -0800, Gregory Szorc wrote: On Feb 22, 2014, at 8:18, Kyle Huey m...@kylehuey.com wrote: If you needed another reason to follow the style guide: https://www.imperialviolet.org/2014/02/22/applebug.html Code coverage would have caught this as well. The time investment into 100% line and branch coverage is debatable. But you can't argue that code coverage has its place, especially for high-importance code such as crypto. AFAIK, our automation currently does not collect code coverage from any test suite. Should that change? There was some automation running code coverage reports (with gcov, I think) for at least reftests + mochitests for an extended period of time; I found it useful for improving style system test coverage while it was running. I'm not sure how strong our commitment is to keeping such tests running, though; I frequently have to defend the tests against people who want to disable them because they take a long time (i.e., a long time for a single test file, which sometimes leads the tests to approach the per-file timeouts on slow VMs) or because they happen to exhibit the latest JIT crash frequently because they run a lot of code. I'm worried we're moving to a model where tests need to have active defenders to keep them running (even though that isn't how features on the Web platform work), because we blame the old test rather than the new regression. -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: Announcing AsyncShutdown
Indeed, AsyncShutdown should help you in the normal scenario, i.e. if Firefox is quit normally. It won't help you if the process crashes, is killed by the task manager, or the computer goes to sleep. Cheers, David On 2/18/14 6:35 PM, Noitidart wrote: Much thanks David. Im working on an addon called Floppers. It's for Twitter. It also tells you who has blocked you. So how it does this is it checks the history of users that you have been in contact with but not on your Following or Follewer lists, it checks behind the scense. How it does it is by Requesting Friend on each account behind the scense, after the XMLHTTPRequest completes, the req either goes through or come back saying you are blocked, and i updated my SQLite database. However if it went through I must cancel the request so the user on the other end never sees the req came. So its critical I keep firefox open for at least 1 more XMLHTTPReq and thats to cancel the req. Which should be just 1 to 30 seconds max (for super slow connections). Im worried if a ctrl+alt+del happens after the friend req is sent, im trying to find a way to notify the user when the process is hung up or crashed after the first req. Much thanks for the reply David and really appreciate this module nonetheless, it should help me with making that final call if they don't ctrl+alt+del the process or some other thing causes the process to hang/crash. -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Announcing AsyncShutdown
No, this module is not designed to transact events, just to ensure that we do not proceed with shutdown before the appropriate time. What is your application need exactly? Cheers, David On 2/18/14 11:13 AM, noitid...@gmail.com wrote: what if someone were to ctrl+alt+delete the process. would the queue of events be queued to run on startup? i have a great need for that -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Announcing AsyncShutdown
I'm happy to announce that the AsyncShutdown module is now considered
stable and to invite you to make use of it in your code, should you need
the feature.
The AsyncShutdown module is a simple mechanism designed to help us
handle dependencies between asynchronous modules during shutdown. A
typical example is a module that needs during shutdown to collect data
(asynchronously) then write it to the profile dir (asynchronously)
before profile-before-change completes. AsyncShutdown lets us avoid
(most of) the mess of spinning nested event loops, offers a readable API
and handles {dead, live}locks and error reporting.
For more details, see http://wp.me/p52O1-mn and
https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/AsyncShutdown.jsm
For the moment, this module is only for JavaScript, but we plan to
eventually port it to C++, so if you need it in C++, please get in touch
(bug 918317).
Asynchronously yours,
David
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
ISomething, nsISomething or mozISomething?
Do we have naming conventions for new xpcom interfaces? I believe that I have seen all three forms on the tree. I need to pick one for my new bug. Which one should I pick? Cheers, David (Cross-posting to ask.mozilla.org) -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Possible to make all (CSS) transitions 0/1ms to speed up FxOS Gaia tests?
On Sunday 2014-02-16 22:37 -0500, Paul Rouget wrote: Andrew Sutherland wrote: Is it possible / advisable to have Gecko support some preference or other magical mechanism to cause transitions and non-infinite animations to effectively complete in some extremely small time interval / on the next turn of the event loop, at least for durations originally less than 1second/other short time? I briefly looked for such an existing mechanism, but was unable to find one. Yes. You can use advanceTimeAndRefresh from nsIDOMWindowUtils. See comment here: http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/base/nsIDOMWindowUtils.idl#1264 I'd warn you that advanceTimeAndRefresh is somewhat dangerous since: (1) it requires that you take complete control of the clock, and you *must* remember to call restoreNormalRefresh when you're done, or else the clock will never advance, and (2) it affects all presentations that happen to share the same refresh driver, which is something that might change over time. It might work here -- but it's a sharp tool, so be careful with it. -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
W3C Proposed Recommendations: WAI-ARIA (accessibility)
W3C recently published the following proposed recommendations (the stage before W3C's final stage, Recommendation): Accessible Rich Internet Applications (WAI-ARIA) 1.0 http://www.w3.org/TR/2014/PR-wai-aria-20140206/ WAI-ARIA 1.0 User Agent Implementation Guide http://www.w3.org/TR/2014/PR-wai-aria-implementation-20140206/ There's a call for review to W3C member companies (of which Mozilla is one) open until March 7. If there are comments you think Mozilla should send as part of the review, or if you think Mozilla should voice support or opposition to the specification, please say so in this thread. (I'd note, however, that there have been many previous opportunities to make comments, so it's somewhat bad form to bring up fundamental issues for the first time at this stage.) -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
W3C Proposed Recommendations: MathML 3.0 and XML Entity Definitions for Characters
W3C recently published the following proposed edited recommendations (the stage before W3C's final stage, Recommendation, but to revise an existing recommendation, and thus also simultaneously like a last call) related to MathML: Mathematical Markup Language (MathML) Version 3.0 2nd Edition http://www.w3.org/TR/2014/PER-MathML3-20140211/ XML Entity Definitions for Characters (2nd Edition) http://www.w3.org/TR/2014/PER-xml-entity-names-20140211/ There's a call for review to W3C member companies (of which Mozilla is one) open until March 11. If there are comments you think Mozilla should send as part of the review, or if you think Mozilla should voice support or opposition to the specification, please say so in this thread. (I'd note, however, that there have been many previous opportunities to make comments, so it's somewhat bad form to bring up fundamental issues for the first time at this stage.) -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: Proposed W3C Charter: HTML5 Chinese Interest Group
On Wednesday 2014-02-12 11:16 +0800, Kan-Ru Chen (陳侃如) wrote: Kyle Huey m...@kylehuey.com writes: On Wed, Feb 12, 2014 at 3:27 AM, L. David Baron dba...@dbaron.org wrote: W3C is proposing a revised charter for the HTML5 Chinese Interest Group. For more details, see: http://www.w3.org/2013/12/html-ig-zh-charter.html http://lists.w3.org/Archives/Public/public-new-work/2014Jan/0007.html Mozilla has the opportunity to send comments or objections through February 24. Please reply to this thread if you think there's something we should say. Does Mozilla have someone who would be interested in and capable of following discussions in this group? I'm subscribed to the mailing list but was not following the discussions very closely. Is there anything I could do in addition to follow the discussions? It looks like it's just a mailing list plus occasional teleconferences. It's hard for me to know whether it would be useful to follow more closely, given that I don't read Chinese. So I think it's best for those of you who read and speak Chinese to figure out whether it's worth doing anything more. -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: Tagging legitimate main thread I/O
On 2/10/14 2:43 PM, Benjamin Smedberg wrote: On 2/7/2014 10:31 AM, David Rajchenbach-Teller wrote: Since main thread I/O keeps being added to the tree, for good or bad reasons, I believe that we should adopt a convention of tagging legitimate main thread I/O. When you say tagging do you mean just code comments, or some other marker that we can use in automated tooling to root out untagged main-thread I/O? I am thinking about code comments. However, BenWa's suggestion of formalizing this as labels for the profiler sounds useful, too. Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Tagging legitimate main thread I/O
When we encounter main thread I/O, most of the time, it is something that should be rooted out. However, in a few cases (e.g. early during startup, late during shutdown), these pieces of I/O should actually be left untouched. Since main thread I/O keeps being added to the tree, for good or bad reasons, I believe that we should adopt a convention of tagging legitimate main thread I/O. e.g. : - « Reading on the main thread as threads are not up yet ». - « Reading on the main thread as we may need to install XPCOM components required before profile-after-change. » - ... Any thoughts? Cheers, David -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Tagging legitimate main thread I/O
On 02/07/14 10:31, ISHIKAWA, Chiaki wrote: Message: [10549] WARNING: Security network blocking I/O on Main Thread: file /REF-COMM-CENTRAL/comm-central/mozilla/security/manager/ssl/src/nsNSSCallbacks.cpp, line 422 This generally happens when javascript calls a function on an nsIX509Cert that attempts to verify it synchronously. If the certificate has an OCSP uri, network IO will block the main thread. For instance, AddonUpdateChecker.jsm calls CertUtils.checkCert, which traverses the peer's certificate chain (in an inefficient way, but that's beside the point). Getting a certificate's chain causes a verification to happen, which often results in network IO. This is in part due to the legacy certificate verification library we're currently hard at work replacing. In short, this is not legitimate main thread IO, but it's being fixed. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to ship background-blend-mode
On Thursday 2014-02-06 22:02 +1300, Robert O'Callahan wrote: On Thu, Feb 6, 2014 at 6:58 PM, Rik Cabanier caban...@gmail.com wrote: We would like to ship mix-blend-mode too. In our experiments, Firefox has the most stable implementation. (We only have 1 open bug ) However, we're taking a slow path today and it might take us a while to implement the fast path. We're facing similar problems on the other browsers so we're doing the same staggered approach there. I think what we have is reasonable to ship. It's the same situation as our SVG filters implementation basically. OK with me, then. -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 ship background-blend-mode
On Wednesday 2014-02-05 20:37 -0800, Rik Cabanier wrote: Spec http://www.w3.org/TR/compositing-1/#background-blend-mode *Summary* This new CSS property allows you to specify blending between background images and the background color. I'm a little concerned about shipping background-blend-mode without mix-blend-mode, just because mix-blend-mode is the primary blending control, and background-blend-mode handles an edge case. I'm worried that shipping support for the edge case first will encourage authors to contort what they're doing in order to fit that edge case, and, as a result, harm other things (for example, by making things that should be content be background images instead, and hurting accessibility). Otherwise I think this is reasonable, 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: Parallel sandboxed iframes
Hi, So far, nobody said that the idea was either stupid or impossible/impractical, so I went ahead and filed https://bugzilla.mozilla.org/show_bug.cgi?id=961689 David ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Parallel sandboxed iframes
Hi, Machines are getting more cores, web devs want to make use of that opportunity. We (webdev hat) have WebWorkers, that's cool, but one can only do ~math in there. It's not possible to update a UI in real time from a WebWorker. It's not possible to update a canvas or WebGL context either. New APIs are being designed and implemented to cover this specific use case. We have cross-origin iframes which are very very close from being able to run in parallel. Communication between an iframe and its cross-origin parent are more or less restricted to: * postMessage + message event * resizing the iframe from the parent (which modifies the viewport dimensions inside the iframe?) that's the ideal view, because, of course, web reality kicks in and document.domain allows for a frame and its parent to dynamically change of origin (and synchronous communication can begin) and there is also named access on cross-origin Windows which has proven to be web-required [1]. It looks like cross-origin iframes are a dead end from a practical point of view when it comes to parallelism. Enters: Sandboxed iframes! A sandboxed iframe has the same properties than cross-origin iframes with the benefit of document.domain being disabled [2] (I need to look at the named access thing). So in theory, it could run in parallel from its parent. I'm writing this message to ask about the practical aspects. From what I understand, it's already possible to create process-separated frames [3] which I feel isn't that far away from a parallel iframe (though for now, I haven't been really able to make it work :-/). Sandboxed iframes have flags to disable a bunch of things (plugin, top navigation, etc.) if that can help finding a workable subset that can work in parallel from its parent. I believe parallel sandboxed iframes would be a good thing also because it would encourage web developers to use them also for their security characteristics. It would also save the work of creating new WebWorker-specific APIs. Thoughts? David [1] https://bugzilla.mozilla.org/show_bug.cgi?id=916939 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=907892 [3] remote option described in https://developer.mozilla.org/en-US/Add-ons/SDK/Low-Level_APIs/frame_utils ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Terminating xulrunner?
Having proper support for multi-profile is great, by opposition to the current hidden on the command line support, but I believe that this discussion deserves its own thread (and its own bug). Cheers, David On 1/16/14 4:13 PM, WaltS wrote: User thoughts. You can close this bug as WONTFIX, since the stand alone profile manager, which I use is built on xulrunner. [214675 – Remove Profile Manager UI](https://bugzilla.mozilla.org/show_bug.cgi?id=214675) [Profile Manager | MDN](https://developer.mozilla.org/en-US/docs/Profile_Manager) Maybe that page should be also be removed from MDN. That way I won't be able to keep recommending it to users. I think having a stand alone profile manager is a great idea though. I use it to run Nightly alongside the Beta with separate profiles for each. I also use it for Thunderbird release and Daily. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- David Rajchenbach-Teller, PhD Performance Team, Mozilla ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Parallel sandboxed iframes
Le jeudi 16 janvier 2014 18:31:59 UTC+1, Boris Zbarsky a écrit : It's pretty far away in Gecko as it stands, because we have all sorts of global state (class statics, say!) that is not parallel-safe. Process-separated is likely to be simpler to get to work without pesky things like memory corruption. I don't understand the last sentence. Is memory corruption referring to the global state you mentioned before? When you wrote parallel-safe above, was that implicitly thread-parallelism? As a web developer, I'm happy with process-separated if it's easier, at least for a first shot, but I can imagine the costs aren't the same at scale. Maybe the current rarity of sandboxed iframe on the web makes it a practical idea? I forgot to mention that Blink is planning [1] to work on site isolation [2] (a site is an eTLD IIUC). I think it flows that sandboxed iframes will be process-isolated (since a sandboxed iframe is in its own site). I believe this lowers the chance of Blink adopting the WebWorker-specific APIs to draw on canvas/WebGL contexts that Mozilla is working on. David [1] https://groups.google.com/a/chromium.org/d/msg/blink-dev/Z5OzwYh3Wfk/IWooaY5FZowJ [2] http://www.chromium.org/developers/design-documents/oop-iframes ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: Progress Events
On Wednesday 2013-12-18 12:50 +, Anne van Kesteren wrote: On Mon, Dec 16, 2013 at 6:23 PM, Kyle Huey m...@kylehuey.com wrote: Should we be explicitly voting in favor of this one too? I suppose. We implement it :-) OK, I've done so (without further comments). -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
