Upcoming on Bugzilla: reorganized & redesigned bug page

Hello, As you know, bugzilla.mozilla.org has evolved to meet the needs of various projects, and the current bug detail page seems cluttered with so many fields. Making changes to a familiar UI may confuse some of you, but we feel like it’s time to get it

Re: Intent to ship: Add wildcard to Access-Control-Expose-Headers, Access-Control-Allow-Methods, and Access-Control-Allow-Headers

Hi Ehsan, Thanks for correcting this. Yes, this should be shipped in Firefox 70. Regards, Kershaw On Sat, Jul 20, 2019 at 2:40 AM Ehsan Akhgari wrote: > Thanks Kershaw for fixing this. I was curious why you expect this to ship > in Firefox 71 but not 70? > > On Tue, Jul 16, 2019 at 1:56 PM

Re: Intent to ship: accumulating most JS scripts' data as UTF-8, then directly parsing as UTF-8 (without inflating to UTF-16)

On 7/20/19 4:41 PM, Nicholas Nethercote wrote: > This is excellent news. Do you have any measurements showing perf effects? Perf changes should have first become visible with the landing of bug 1554362. There was one quasi-automatically-reported perf improvement, on the Sheets raptor test:

Re: non-const reference parameters in new and older code

I could grudgingly get on board with that, though I feel that there are sort of two levels of mutability I use: casual and essential. Essential is protected by constness, whereas casual is sort of everyday minor changes, but changes I don't want to allow in `const` code, thus don't want `mutable`.

Re: NotNull and pointer parameters that may or may not be null

FWIW RefPtr already behaves as MaybeNull for assert-on-deref, making them functionally Maybe. (though they don't represent a contract that it's nullable) For non-outvar-args, I tend to use references to document non-null, though I do so even for many non-const uses. (balancing what is and isn't

Re: cross-language LTO enabled on nightly for all platforms

Thanks! Nathan also clarified on IRC that this runs only on the "shippable" variant of CI builds. On Mon, Jul 22, 2019 at 8:58 AM Nathan Froyd wrote: > On Mon, Jul 22, 2019 at 11:45 AM Bobby Holley > wrote: > > Can you confirm which types of builds enable this? Does --enable-release > turn it

Re: cross-language LTO enabled on nightly for all platforms

On Mon, Jul 22, 2019 at 11:45 AM Bobby Holley wrote: > Can you confirm which types of builds enable this? Does --enable-release turn > it on? If you really want to build this locally, you can add `export MOZ_LTO=cross` in your mozconfig. `--enable-release` does not automatically enable LTO

Re: cross-language LTO enabled on nightly for all platforms

Thanks for the hard work getting this over the line! Can you confirm which types of builds enable this? Does --enable-release turn it on? On Mon, Jul 22, 2019 at 6:56 AM Nathan Froyd wrote: > Hi all, > > We now have link-time optimization (LTO) between Rust and C++ code > enabled on Nightly

Re: non-const reference parameters in new and older code

I believe in least surprise for the caller of an API. This seems to match with the Google style, as you describe it: any parameter which may be mutated in any manner should be passed as pointer, rather than reference. Cheers, David On 22/07/2019 08:43, Karl Tomlinson wrote: >

[desktop] Bugs logged by Desktop Release QA in the last 7 days

Hello, Here's the list of new issues found and filed by the Desktop Release QA team in the last 7 days. Additional details on the team's priorities last week, as well as the plans for the current week are available at: https://tinyurl.com/y49fgq3g. Bugs logged by Desktop Release QA in the

cross-language LTO enabled on nightly for all platforms

Hi all, We now have link-time optimization (LTO) between Rust and C++ code enabled on Nightly for all platforms (bug 1486042 [1]). There have been some concerns about potential slowdowns when crossing the C++ <=> Rust boundary due to non-inlineable function calls, and Stylo needed to implement

Re: Intent to ship: Blocking Worker/SharedWorker with non-JS MIME type

On 7/22/19 6:22 AM, Tom Schuster wrote: This was also discussed at https://github.com/whatwg/html/issues/3255. It seems like Chrome does NOT plan on shipping this at the moment. Does "at the moment" mean they are open to shipping it in the future if we ship it and don't run into web compat

Intent to ship: Blocking Worker/SharedWorker with non-JS MIME type

In Firefox 70 we plan to start blocking Worker and SharedWorker scripts served with non-JavaScript MIME types. We have similarly been blocking importScripts() since version 67. Bug to turn on by default: https://bugzilla.mozilla.org/show_bug.cgi?id=1523706 Pref:

NotNull and pointer parameters that may or may not be null

Google style requires pointers for parameters that may be mutated by the callee, which provides that the potential mutation is visible at the call site. Pointers to `const` types are permitted, but recommended when "input is somehow treated differently" [1], such as when a null value may be

non-const reference parameters in new and older code

https://google.github.io/styleguide/cppguide.html#Reference_Arguments has a simple rule to determine when reference parameters are permitted: "Within function parameter lists all references must be const." This is consistent with Mozilla's previous coding style: "Use pointers, instead of