Intent to unship: Some Shadow DOM v0 APIs
Hi, In bug 1535438 I intend to remove three Shadow DOM v0 APIs that slipped through when we shipped Shadow DOM v1: * ShadowRoot.getElementsByTagName * ShadowRoot.getElementsByTagNameNS * ShadowRoot.getElementsByClassName These were implemented in bug 806506 as part of the initial Shadow DOM v0 implementation by William Chen, and they remained there as we updated to v1, looks like :) No other browser is shipping these, so the earlier we remove it the better, but let me know if you disagree. The code implementing them remains untouched, since it's the same for ShadowRoot and Document, so resurrecting them should we need that would be trivial. -- Emilio ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
W3C Proposed Recommendation: Pointer Events Level 2
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: Pointer Events Level 2 https://www.w3.org/TR/pointerevents2/ https://w3c.github.io/pointerevents/ Deadline for responses: Thursday, March 21, 2019 If there are comments you think Mozilla should send as part of the review, please say so in this thread. Ideally, such comments should link to github issues filed against the specification. (I'd note, however, that there have been previous opportunities to make comments, so it's somewhat bad form to bring up fundamental issues for the first time at this stage.) (I'm not sure to what extent we implement the revisions that are in level 2. Knowing that would be helpful. If it's something we implement, then we should probably explicitly support it unless we have 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: PGP signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improving our usage of Bugzilla
I am not worried about this potential problem. It doesn't have to be perfect, some folks (release managers, qa, etc) will check that the values are correctly set. In parallel, you probably noticed that we have a bot (autonag) which automatically set/update a bunch of values. @Felipe: yeah, the team classified by hand a lot of bugs to evaluate that. This is the main case for which it is hard to differenciate task & enhancement. However, don't think it is a big deal (as long as they aren't marked as defects). Le mar. 12 mars 2019 à 20:56, Dan Mosedale a écrit : > I've looked at the UX spec and Sylvestre's announcement, and I have > some relevant experience here working on teams which have used the > "enhancement" value of the "severity" field with the intent of using > that information to monitor our rate of defect introduction. > > That workflow has turned out to have a footgun that has polluted our > usage, which appears to me to be replicated here, and which I think > has a simple fix. I'd be curious to hear thoughts: > > In particular, the severity field defaults to "normal", which we'd > like to use to mean a "normally severe defect". Unfortunately, > because the default is set to "normal" and because Bugzilla has such a > large number of fields, what it actually means in practice is either > "normally severe defect" or "bug-filer was in a hurry or not paying > attention", with no easy way to tell the difference. And that happens > a non-trivial amount of the time. > > Some fields in bugzilla have a "---" value (including severity, but > it's not the default). This can be used to mean "not-entered" or > "untriaged", completely eliminating the "hard-to-detect-bad-data > issue". > > I'm concerned that the Type field as currently proposed (i.e. no --- > field as default) has effectively the same footgun, which will make > the data we gather with it less useful. > > Thoughts? > > Dan > > Am Di., 12. März 2019 um 12:10 Uhr schrieb Felipe G : > > > > Does performance work count as "enhancement" or "task"? > > On one hand, it's not strictly refactoring.. On the other hand, it is not > > development of a new feature, per the proposed description of > enhancement. > > > > On Tue, Mar 12, 2019 at 3:20 PM Onno Ekker wrote: > > > > > On 12/03/2019 18:59, Sylvestre Ledru wrote: > > > > Le 12/03/2019 à 17:48, Andrew McCreight a écrit : > > > >> > > > >> Secondly, to bikeshed a little, could there be some name besides > > > >> "task" for > > > >> that third category? Like I said above, everything we work as > > > >> developers is > > > >> a developer task. "Refactor" seems like a clearer name, though maybe > > > >> it is > > > >> a little limiting. "Side grade"? :) > > > > > > > > This is more than just refactoring. It is more "as an engineer, here > is > > > > what I have to do". > > > > > > Maybe call it "Engineering"? "Maintenance"? > > > ___ > > > 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 > ___ > 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: Intermediate CA Preloading is enabled for desktop Nightly users
On Fri, Mar 15, 2019 at 4:47 PM J.C. Jones wrote: > That's a good argument for us never "optimizing" it to avoid re-downloading > already-known certs. Just download the whole set once, everywhere - the > bandwidth savings are limited. Yes and No. As ekr pointed out to me offline, there are so many myriad of ways that Mozilla can correlate you that trying to solve any individual one without an overall survey and consensus-building effort for future development isn't really worth the headache and time... -tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intermediate CA Preloading is enabled for desktop Nightly users
On Thu, Mar 14, 2019 at 3:26 PM Nicholas Alexander wrote: > J.C. -- I don't think this answers Tom's question, but perhaps it does. In > that case I'll ask what I think is the same question: Actually, what I was worried about was Mozilla being able to track users based on what the client sends. "I've got 100-200, send me some more" "I've got 100-300, send me some more" and so on It sounds like The client says something more like "Send me 200-300", "Send me 300-400". Which is not _that_ much different, but it slightly better I think... -tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Duplicate dependency policy for Rust in mozilla-central?
On 15/03/2019 14:31, Xidorn Quan wrote: Servo has a policy banning duplicate dependencies with a whitelist, and such list currently has: This exact allow-list is not part of Servo’s policy, but is constantly evolving. If you can reduce it (typically by updating some intermediate dependencies to versions that use e.g. log 0.4 instead of 0.3), this is great and we love you. If you add a new exception to the allow-list, in review we will ask that you make some effort to avoid doing so. If the effort turns out to be disproportionate (for example: many intermediate dependencies are affected, and they in turn would affect other crates in the graph) or if we want to avoid waiting too long on upstream (because a patch is at risk of bitrotting, or blocks other work, or…) then we may accept growing the list. The important part is that machine-verification avoids accidentally adding new duplications. On 15/03/2019 15:38, Andreas Tolfsen wrote: It is my experience that far too many dependencies are defined on exact version numbers, e.g. "log = 0.3.9", which effectively forces us to vendor that exact version in-tree. It does not force that. Specifying `log = "0.3.9"` in Cargo.toml’s [dependencies] section is equivalent to `log = "^0.3.9"` which is equivalent to `log = ">=0.3.9 < 0.4.0"`. So if a project uses crates A with the above and crate B with `log = "0.3.12"`, then version 0.3.15 is acceptable to satisfy both dependencies. What would force an exact version is `log = "=0.3.9"`. (Note that the first equal sign is TOML syntax for key/value pairs, while the second one is part of the version specification string, inside the quotes.) See https://doc.rust-lang.org/cargo/reference/specifying-dependencies.html -- Simon Sapin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
On Fri, Mar 15, 2019 at 11:35 AM Tom Ritter wrote: > Thanks for more details on the use case. > > On Wed, Mar 6, 2019 at 1:35 AM wrote: > > > > On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote: > > > To add to Dan's comments here... > > > > > > Assuming that I'm reading this correctly [1], the fingerprinting risks > are > > > pretty extreme here. In the touch spec, we have a monotonically > increasing > > > counter that doesn't appear to be origin-bound in any way. What is the > > > purpose of this identifier? In the light spec, we have full RGB > control > > > over the light. Does the light change back to a default state when the > > > origin is no longer the primary input focus? > > > > > > Implementing specs of a private GitHub account is fine for the > purposes of > > > getting feedback, but I think that we want a clearer signal that this > is an > > > accepted approach before we ship something like this. When you > consider > > > the potential for security and privacy implications, this is > particularly > > > important. > > > > > > > > > > Hi Martin, > > > > Sorry for reply late. > > We will restrict theses APIs to secure contexts to help it be more > secure. Regarding to the touchId, the reason we wanna make it monotonically > increasing is order to recognize if fingers have been released after the > last touch. Let me give you two examples. > > > > Example 1: Let’s say touchId is currently set to 0 and no fingers are > touching the touchpad. When a finger touches the touchpad, touchId of this > event would be 1. As that finger moves around the touchpad, new touch > events are added with updated coordinates, however, the touchId is still 1 > to denote that the finger has not been lifted from the touchpad. If the > finger is released and touches again, the touchId would then be 2. > > > > Example 2: In the case of multi touch, the first finger that touches the > touchpad would have a touchId of 1. The next finger that touches the > touchpad before the first finger is released would have a touchId of 2. If > the first touch finger is released and touches again, that touchId would be > 3. This way, the application can distinguish between different touches > that have or haven’t been removed from the touchpad. > > > In this situation, it seems like the actual value of the field doesn't > matter, only that it is increasing relative to the last value. So it > should be possible to have separate values based on the origin. > I assume you mean the origin of the top-level page here. As far as I can tell from the current spec, we can implement this restriction based on the current spec but since we are the first engine to ship this it seems prudent to change the spec as well in order to ensure all future implementations would implement this in a privacy-preserving manner. > Not doing so creates a cross-origin tracking and fingerprinting vector. > > > > In terms of lightColor, we would give the default color to [0, 0, 0] if > there is no one set it yet or when it is just plugged in. Then, the > application is allowed to set the controller's lightbar color whenever they > want. I have reached the author and ask him add this description into his > proposal. > > It appears that one can set but cannot read the lightColor, so that's good. > > GamepadPose gives me a lot of concern as well. If I have a gamepad > resting on my desk, I don't want every website to get a persistent > identifier about me because of the pose it's resting in. I think/hope > that there's something in the main gamepad spec where you can't > enumerate gamepads until the user has interacted with them, but I > don't recall for sure. > There is: https://w3c.github.io/gamepad/#dom-navigator-getgamepads. But note that with resist fingerprinting mode we always return an empty array from navigator.getGamepads(). > I am very opposed to shipping this spec without addressing these concerns. > > -tom > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform > Thanks, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Duplicate dependency policy for Rust in mozilla-central?
On Fri, Mar 15, 2019, 15:39 Andreas Tolfsen wrote: > However, I want to talk a little bit about _why_ we see so many > duplicate crates and what causes it. It is my experience that far > too many dependencies are defined on exact version numbers, e.g. > "log = 0.3.9", which effectively forces us to vendor that exact > version in-tree. > While I initially thought the same thing, this is not how Cargo's dependencies work: 0.3.9 in this context means "everything semver-compatible with 0.3.9", so 0.3.10 would be accepted in this instance. However, 0.4.0 by definition is semver-incompatible with 0.3.x (that is, the normal incompatibility between 1.x and 2.y is moved one component to the right if the first component is 0). > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement and ship: Gamepad Extensions `multi touch` and `light indicator`
Thanks for more details on the use case. On Wed, Mar 6, 2019 at 1:35 AM wrote: > > On Monday, February 25, 2019 at 4:17:29 PM UTC-8, Martin Thomson wrote: > > To add to Dan's comments here... > > > > Assuming that I'm reading this correctly [1], the fingerprinting risks are > > pretty extreme here. In the touch spec, we have a monotonically increasing > > counter that doesn't appear to be origin-bound in any way. What is the > > purpose of this identifier? In the light spec, we have full RGB control > > over the light. Does the light change back to a default state when the > > origin is no longer the primary input focus? > > > > Implementing specs of a private GitHub account is fine for the purposes of > > getting feedback, but I think that we want a clearer signal that this is an > > accepted approach before we ship something like this. When you consider > > the potential for security and privacy implications, this is particularly > > important. > > > > > > Hi Martin, > > Sorry for reply late. > We will restrict theses APIs to secure contexts to help it be more secure. > Regarding to the touchId, the reason we wanna make it monotonically > increasing is order to recognize if fingers have been released after the last > touch. Let me give you two examples. > > Example 1: Let’s say touchId is currently set to 0 and no fingers are > touching the touchpad. When a finger touches the touchpad, touchId of this > event would be 1. As that finger moves around the touchpad, new touch events > are added with updated coordinates, however, the touchId is still 1 to denote > that the finger has not been lifted from the touchpad. If the finger is > released and touches again, the touchId would then be 2. > > Example 2: In the case of multi touch, the first finger that touches the > touchpad would have a touchId of 1. The next finger that touches the > touchpad before the first finger is released would have a touchId of 2. If > the first touch finger is released and touches again, that touchId would be > 3. This way, the application can distinguish between different touches that > have or haven’t been removed from the touchpad. In this situation, it seems like the actual value of the field doesn't matter, only that it is increasing relative to the last value. So it should be possible to have separate values based on the origin. Not doing so creates a cross-origin tracking and fingerprinting vector. > In terms of lightColor, we would give the default color to [0, 0, 0] if > there is no one set it yet or when it is just plugged in. Then, the > application is allowed to set the controller's lightbar color whenever they > want. I have reached the author and ask him add this description into his > proposal. It appears that one can set but cannot read the lightColor, so that's good. GamepadPose gives me a lot of concern as well. If I have a gamepad resting on my desk, I don't want every website to get a persistent identifier about me because of the pose it's resting in. I think/hope that there's something in the main gamepad spec where you can't enumerate gamepads until the user has interacted with them, but I don't recall for sure. I am very opposed to shipping this spec without addressing these concerns. -tom ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Duplicate dependency policy for Rust in mozilla-central?
Also sprach Xidorn Quan: > Should we have some kind of policy to address duplicate dependencies > in Gecko as well? Maybe I'm missing something but I don't think I'm > aware of any previous discussion about this. Deduplicating crate dependencies has so far been a mostly heroic undertaking done by individuals such as eijebong, so having a policy built in to "./mach vendor rust" that prevents duplication is probably a good idea! However, I want to talk a little bit about _why_ we see so many duplicate crates and what causes it. It is my experience that far too many dependencies are defined on exact version numbers, e.g. "log = 0.3.9", which effectively forces us to vendor that exact version in-tree. In some cases we see this reproduce throughout a crate’s dependency chain, where different crates depend on minutely different versions of crate D (v0.4.0, v0.3.9, v0.3.7) causing us to have to vendor and compile all of them, even as part of a single build: A |-- B v1.2.0 | |-- C v2.0.1 | |-- D v0.4.0 | |-- C v2.0.0 | |-- D v0.3.9 | |-- E v0.2 | |-- D v0.3.7 As kats points out, unravelling this spider web is not trivial. You often run into cases where some crate depends on a particular version of something, but you can’t upgrade that because something else depends on a too specific version, and you can’t upgrade that again because it would cause an API change or behaviour change that requires specialist peer review in an unrelated component. In conclusion, my plead to Rust crate maintainers is to be generous with what version range you tolerate for dependencies. As most crates respect semantic versioning you can be somewhat confident that relying on v1.2 rather than v1.2.1 will keep your program working when v1.2.2 is released. The most common argument I hear against tolerating a wider dependency range for dependencies is “reproducible builds”. Well, for binaries it is recommended you check in the Cargo.lock file, and for Gecko we do that for all components, including libraries. We additionally vendor the source code, allowing us to do hermetically sealed builds. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Improving our usage of Bugzilla
Hello Yes, it will be the same as block/depend in term of notification. Sylvestre Le 12/03/2019 à 19:12, David Major a écrit : Will setting the "regressed by" field send mail to the subscribers of the earlier bug? This was a useful aspect of the blocks/depends field. On Tue, Mar 12, 2019 at 1:59 PM Sylvestre Ledru wrote: Le 12/03/2019 à 17:48, Andrew McCreight a écrit : On Tue, Mar 12, 2019 at 3:55 AM Sylvestre Ledru wrote: With this change, we are going to extend Bugzilla to add a new field with three new values: - Defect - an issue in one of our products - Enhancement - a new feature or an improvement - Task - a developer task. For example: refactor code foo. Could please you explain more what these three values are supposed to represent, possibly with some examples? It feels like there's a lot of overlap between them. For instance, isn't any task I work on as a developer a developer task? Isn't refactoring both a task and an improvement (and thus also an enhancement)? * Defects are trivial. Examples: Crashes, intermittent, glitches, features not working as expecting, features worked but no longer works, etc. This is mostly for users of our products (including ourself). Triaged by eng triage owners. We decided NOT to call that bug as this word is super-overloaded at Mozilla. * Enhancement is a development of a new feature. Examples: Add a new avatar for sync, implement feature foo in Javascript, add bar property in css 42, etc This is mostly coming from users and us. Should be triagged by product and triage owners. * Task is mostly development work. Examples: Refactor function foo, remove function bar, improve function plop, etc. Almost of them should be coming from engineering. Now, we will have cases for which a ticket will be both a task and an enhancement. Example: https://bugzilla.mozilla.org/show_bug.cgi?id=1528330 "Deliver acceptable GeckoView performance for Firefox Reality in H1" But I am sure you will agree that this new state will still be an improvement over the current state. Now, a more concrete example, I have want to implement a new feature in Firefox. I will create (or reuse) a bug with the "enhancement" value (probably as a meta bug). Then, to develop the feature, I will create various "tasks" which will be marking as blocking the meta bug. Because I am a bad developer, I will make mistakes and user will fill bugs which will have the "defect" value (and I will use the regressed_by field). Secondly, to bikeshed a little, could there be some name besides "task" for that third category? Like I said above, everything we work as developers is a developer task. "Refactor" seems like a clearer name, though maybe it is a little limiting. "Side grade"? :) This is more than just refactoring. It is more "as an engineer, here is what I have to do". About bikeshed, you can have a look here https://bugzilla.mozilla.org/show_bug.cgi?id=1522342 Where we did that. Thirdly, what category should "organizational" bugs like meta bugs be assigned to? I guess if you have a meta bug for a bunch of enhancements, it would be an enhancement? Yeah, "it depends" ;) Probably... 3) Adding a new field called “Regressed by” This is great! The weird encoding of "regressed by" in the "depends on" field is one of the more confusing aspects of Bugzilla, given how important it is. I spend a ton of time setting regressions for bugs, and even still I have to stop occasionally to make sure I'm doing it the right way. Same here ;) S ___ 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: Duplicate dependency policy for Rust in mozilla-central?
On Fri, Mar 15, 2019 at 9:32 AM Xidorn Quan wrote: > Should we have some kind of policy to address duplicate dependencies in Gecko > as well? Maybe I'm missing something but I don't think I'm aware of any > previous discussion about this. I remember IRC discussions about this, but there were some concerns that banning duplicates would result in slowing people down. I understand the concern, but I'm not sure how much of a problem it would be in practice. I personally am in favor of banning duplicates. We would need a Servo-like list of crates that can be duplicated because there are several crates that are difficult to move forward. -Nathan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA on MOZ_LOG entries in profiles
A short PSA about MOZ_LOG() messages: In Bug 1518030 back in January, I landed support for mirroring MOZ_LOG() messages into profiles captured with the Gecko Profiler (https://profiler.firefox.com/ formerly https://perf-html.io/). You can now add "profilermarkers" to you MOZ_LOG env variable to cause log messages to be mirrored as profiler Markers in profiles. I would suggest being a little careful about enabling excessive number of log messages when using this, and it does allocate memory for each marker so the overhead may be more than normal (a bit). That said, you can probably throw a lot of logs at it safely. You can find them in the Marker Chart or Marker Table when viewing a profile. Now back to your regularly scheduled programming ;-) -- Randell Jesup, Mozilla Corp remove "news" for personal email ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Duplicate dependency policy for Rust in mozilla-central?
FWIW there often ad-hoc attempts to deduplicate Rust dependencies, and they often run into nontrivial blockers. Currently there's a few things blocked on bug 1530448. On Fri, Mar 15, 2019 at 9:32 AM Xidorn Quan wrote: > > Hi all, > > Recently I tried to build Firefox on cloud, and noticed that building Rust > dependencies is now a significant part of it. Another thing I noticed is > that, we have lots of duplicate Rust dependencies. > > I scanned Cargo.lock in the root and found that we have: > * 2 versions of block-buffer (0.3.3, 0.7.0) > * 2 versions of byte-tools (0.2.0, 0.3.0) > * 2 versions of crossbeam-deque (0.2.0, 0.3.1) > * 2 versions of crossbeam-epoch (0.3.1, 0.4.3) > * 3 versions of crossbeam-utils (0.2.2, 0.3.2, 0.6.3) > * 2 versions of digest (0.7.6, 0.8.0) > * 2 versions of generic-array (0.9.0, 0.12.0) > * 2 versions of lazycell (0.4.0, 0.6.0) > * 2 versions of log (0.3.9, 0.4.6) > * 2 versions of memchr (1.0.2, 2.0.1) > * 2 versions of memmap (0.5.2, 0.6.2) > * 2 versions of nom (3.2.1, 4.1.1) > * 2 versions of num-traits (0.1.43, 0.2.6) > * 2 versions of proc-macro2 (0.3.5, 0.4.24) > * 2 versions of quote (0.5.2, 0.6.10) > * 2 versions of rand (0.3.22, 0.4.3) > * 2 versions of regex (0.2.2, 1.0.0) > * 2 versions of regex-syntax (0.4.1, 0.6.0) > * 2 versions of semver (0.6.0, 0.9.0) > * 2 versions of sha2 (0.7.1, 0.8.0) > * 2 versions of slab (0.3.0, 0.4.1) > * 2 versions of strsim (0.6.0, 0.7.0) > * 3 versions of syn (0.13.1, 0.14.6, 0.15.24) > * 2 versions of uuid (0.6.5, 0.7.1) > * 2 versions of winapi (0.2.8, 0.3.6) > > Although these duplicate dependencies may not go into the final binary, they > are still things which can slow down the build. In this list, I would suspect > crates like nom, regex, and syn could take significant time to build for each > version. > > Servo has a policy banning duplicate dependencies with a whitelist, and such > list currently has: > * base64 > * block-buffer > * byte-tools > * crossbeam-deque > * crossbeam-epoch > * crossbeam-utils > * digest > * generic-array > * rand > * unicase > * winapi > and they had a tradition (in my opinion) to help pushing the ecosystem > forward using new versions of dependencies. > > Should we have some kind of policy to address duplicate dependencies in Gecko > as well? Maybe I'm missing something but I don't think I'm aware of any > previous discussion about this. > > - Xidorn > ___ > 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
Duplicate dependency policy for Rust in mozilla-central?
Hi all, Recently I tried to build Firefox on cloud, and noticed that building Rust dependencies is now a significant part of it. Another thing I noticed is that, we have lots of duplicate Rust dependencies. I scanned Cargo.lock in the root and found that we have: * 2 versions of block-buffer (0.3.3, 0.7.0) * 2 versions of byte-tools (0.2.0, 0.3.0) * 2 versions of crossbeam-deque (0.2.0, 0.3.1) * 2 versions of crossbeam-epoch (0.3.1, 0.4.3) * 3 versions of crossbeam-utils (0.2.2, 0.3.2, 0.6.3) * 2 versions of digest (0.7.6, 0.8.0) * 2 versions of generic-array (0.9.0, 0.12.0) * 2 versions of lazycell (0.4.0, 0.6.0) * 2 versions of log (0.3.9, 0.4.6) * 2 versions of memchr (1.0.2, 2.0.1) * 2 versions of memmap (0.5.2, 0.6.2) * 2 versions of nom (3.2.1, 4.1.1) * 2 versions of num-traits (0.1.43, 0.2.6) * 2 versions of proc-macro2 (0.3.5, 0.4.24) * 2 versions of quote (0.5.2, 0.6.10) * 2 versions of rand (0.3.22, 0.4.3) * 2 versions of regex (0.2.2, 1.0.0) * 2 versions of regex-syntax (0.4.1, 0.6.0) * 2 versions of semver (0.6.0, 0.9.0) * 2 versions of sha2 (0.7.1, 0.8.0) * 2 versions of slab (0.3.0, 0.4.1) * 2 versions of strsim (0.6.0, 0.7.0) * 3 versions of syn (0.13.1, 0.14.6, 0.15.24) * 2 versions of uuid (0.6.5, 0.7.1) * 2 versions of winapi (0.2.8, 0.3.6) Although these duplicate dependencies may not go into the final binary, they are still things which can slow down the build. In this list, I would suspect crates like nom, regex, and syn could take significant time to build for each version. Servo has a policy banning duplicate dependencies with a whitelist, and such list currently has: * base64 * block-buffer * byte-tools * crossbeam-deque * crossbeam-epoch * crossbeam-utils * digest * generic-array * rand * unicase * winapi and they had a tradition (in my opinion) to help pushing the ecosystem forward using new versions of dependencies. Should we have some kind of policy to address duplicate dependencies in Gecko as well? Maybe I'm missing something but I don't think I'm aware of any previous discussion about this. - Xidorn ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
MathML Refresh Heads up
Hello Mozilla developers, As some of you may know, Igalia is working on MathML support in Chromium this year [1]. As part of that effort we joined a new MathML Refresh Community Group [2] and one goal is to focus on a core spec for browser implementations [3] to: - Remove deprecated/uncommon/duplicate math features that could be implemented by polyfills (relying on MathML core and other web technologies). - Add more detailed algorithms (based on TeX/OpenType/CSS layout) to help implementation and conformance testing. - Align MathML with CSS/HTML (parsing, layout...), introducing new web platform features (CSS, fonts...) for math if necessary. We expect that this effort will improve browser interoperability and reduce complexity of current implementations. This is just a heads up to say that some work is likely to happen to update/remove/add MathML features. The appropriate "Intents" will be sent later to these mailing lists. Frédéric and Rob, [1] https://mathml.igalia.com/ [2] https://mathml-refresh.github.io/ [3] https://mathml-refresh.github.io/mathml-core/ ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
