Re: Proposal: Stop using Object.freeze/Object.seal on most of our Javascript Objects
You could also potentially use a Proxy object: https://gist.github.com/hildjj/1ac6e3d52e4e0d23f6289d73c1840a5a > On Nov 20, 2017, at 9:00 AM, Richard Newman wrote: > > Are there alternative ways we could achieve the same without the (or with > low) complexity/overhead? > > If I'm understanding correctly what you're trying to do, the typical > suggestion here is to not use global singletons. That way you don't need to > dig into the guts of a globally visible object in order to test it; you can > pass your own part-mocked Object instance into whatever mechanism is trying > to call `Object.foo`. > > In your `foo`/`bar` case, you'd pass a `MockObject` to `bar`, and verify that > `MockObject.foo` was called. We do this all the time in codebases that use > less dynamic languages (e.g., Fennec and Firefox for iOS). > > This doesn't help you to test existing singleton-based JS code… but then, if > that code is already using Object.freeze, then you already can't, and you'll > be having to change _something_. > > I mostly agree with Nicolas's sentiment; poking at the guts of code outside > your own module (or even in your own module!) isn't really a kind of software > development that I feel we should encourage. If we find that gut-poking is > the only good way to write tests for a component, then I would rather we > revisit the design of the component instead of making it mutable. Refactoring > for testability is A-OK in my book. > ___________ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev — Joe Hildebrand ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Phabricator Update, July 2017
I'm responding at the top of the thread here so that I'm not singling out any particular response. We didn't make clear in this process how much work Mark and his team did ahead of the decision to gather feedback from senior engineers on both Selena and my teams, and how deeply committed the directors have been in their support of this change. Seeing a need for more modern patch reviewing at Mozilla, Laura Thomson's team did an independent analysis of the most popular tools available on the market today. Working with the NSS team to pilot their selected tool, they found that Phabricator is a good fit for our development approach (coincidentally a good enough fit that the Graphics team was also piloting Phabricator in parallel). After getting the support of the Engineering directors, they gathered feedback from senior engineers and managers on the suggested approach, and tweaked dates and features to match up with our release cycles more appropriately. Although there may be other risks that weren't identified in our approach, I'm personally satisfied that what we have in front of us is strictly better than where we are today. Of course, we'll have to sand and fill a little bit to perfect the new Phabricator approach, and deal with our transition away from existing systems such as Splinter and MozReview. However, that tweaking would be required no matter what tool we chose, or when we chose to make a change. Therefore, I would appreciate that if you feel the need to further comment on this thread, we focus on what can be done to make this transition successful, rather than appearing to be standing in the way of progress. For example, "I'm concerned about X; I wonder if we could do Y to mitigate that concern?" is a much more powerful approach than "X!" at this point. — Joe Hildebrand > On Jul 11, 2017, at 2:41 PM, Mark Côté wrote: > > Hi all, here's a brief update on the project to deploy and integrate > Phabricator at Mozilla: > > * Development Phabricator instance is up at > https://mozphab.dev.mozaws.net/, authenticated via > bugzilla-dev.allizom.org. > > * Development, read-only UI for Lando (the new automatic-landing > service) has been deployed. > > * Work is proceeding on matching viewing restrictions on Phabricator > revisions (review requests) to associated confidential bugs. > > * Work is proceeding on the internals of Lando to land Phabricator > revisions to the autoland Mercurial branch. > > * Pre-release of Phabricator, without Lando, targeted for mid-August. > > * General release of Phabricator and Lando targeted for late September or > early October. > > * MozReview and Splinter turned off in early December. > > I have a blog post up with many more details: > https://mrcote.info/blog/2017/07/11/phabricator-update/ > > More to come! > > Mark > > ___ > 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: Visual Studio Code recommended extensions
I also like vscode. > On Feb 23, 2017, at 9:48 AM, Marco Bonardo wrote: > > My current list: > // Trim only touched lines. > "NathanRidley.autotrim", > > // Hilight trailing whitespaces. > "ybaumes.highlight-trailing-white-spaces", This one seems a little aggressive. I'd use it on my code, but on old broken code, it would be really annoying. > // JS Babel ES6/ES7 syntax hilight. > "dzannotti.vscode-babel-coloring", > "dzannotti.theme-spacemacs", No themes, please. > // ESLint support. > "dbaeumer.vscode-eslint", > > // C/C++ language support. > "ms-vscode.cpptools", > > // Rust language support. > "saviorisdead.RustyCode" You might want some HTML and CSS stuff; the one I found in my local list is: "ecmel.vscode-html-css" — Joe Hildebrand ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: HTML5 element
> On Dec 20, 2016, at 6:25 PM, Xidorn Quan wrote: > >> So dialog.showModal() does not need to block script like other >> modal APIs? > > > Definitely not. I think this is designed to replace those blocking API. Why doesn't showModal() return a Promise? -- Joe Hildebrand ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: Webmention
> On Nov 4, 2016, at 9:29 AM, Tantek Çelik wrote: > >> There should be some mention of the prior art in this space. > > Why in the spec? (honestly interested to know what you think should be > in a spec without making it more wordy as Martin pointed out) Because there has been a lot of security work done on the prior protocols, particularly in terms of implementation detail in spam prevention. It's also just good karma to call out the giant upon whose shoulders you are standing. Informative links from the in the document will be nice decades from now when nobody remembers that those other protocols once existed. >> Pingbacks and trackbacks at least. > > https://indieweb.org/Webmention-faq#Why_webmention_instead_of_pingback Agree that this is much simpler than either. That likely makes it easier for spammers and other attackers to abuse. >> Section 4.5 "Limit access to protected resources" points out that this >> protocol is an attractive nuisance. Anyone who deploys it is likely to make >> their infrastructure more insecure by mistake. > > Could you expand on this? How? Definitely interested in any and all > security concerns. Nobody is going to remember to sandbox the network connection of the process that is checking the targets. I send you a webmention whose target is "https://intranet/";, your process requests that URL, and you post a synopsis of what you found as a comment on the blog entry I put in the source. Yes, there are protections you can put in place for that, but I can't think of any that can be coded generically into a piece of open source software that doesn't open up your internal resources by default. Even requiring CORS (with the origin as "something interesting", like a constant) on the target would be a step toward making this better. >> If there's a good reason to publish this that isn't obvious, I might be more >> excited about it. > > It's interoperably implemented across double-digit implementations, > and deployed an interoperably in use across tens of thousands of > websites. That's a good enough reason. -- Joe Hildebrand ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: W3C Proposed Recommendation: Webmention
The JSON reference really needs to be to RFC 7159, not 4627. (blocking, but trivial issue) There should be some mention of the prior art in this space. Pingbacks and trackbacks at least. Please differentiate this approach from them, so we have an idea if we need to do this also. Many Wordpress sites get nuked pretty quickly when they leave pingbacks on; pointing out the linkage is important so that the industry at least learns from some of the attacks that have worked in the past. Section 4.5 "Limit access to protected resources" points out that this protocol is an attractive nuisance. Anyone who deploys it is likely to make their infrastructure more insecure by mistake. If there's a good reason to publish this that isn't obvious, I might be more excited about it. > On Nov 3, 2016, at 7:25 PM, L. David Baron wrote: > > A W3C Proposed Recommendation is available for the membership of W3C > (including Mozilla) to vote on, before it proceeds to the final > stage of being a W3C Recomendation: > > Webmention > W3C TR draft: https://www.w3.org/TR/webmention/ > W3C Editor's draft: https://webmention.net/draft/ > deadline: Wednesday, November 30 (23:59 in UTC-05:00) > > If there are comments you think Mozilla should send as part of the > review, 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) > _______ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform -- Joe Hildebrand ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
