Heads up: small Fission experiment starting in 88 Beta

The Fission team plans to start a small Fission experiment in 88 Beta, which will likely run through 89 Beta. The experiment will be just 10% (5% Fission + 5% control). I know 89 is the Proton MR1 release. I've confirmed with the Proton PMs that they do not mind Fission running an experiment

Re: C++ PSA: Use [[nodiscard]] instead of MOZ_MUST_USE

change would touch so many files, it's probably not worth the trouble. Bug 1628542 On 12/21/2020 4:20 PM, Chris Peterson wrote: Now that Firefox is compiled as C++17 (bug 1560664), you can use C++17's [[nodiscard]] attribute [1] instead of the MOZ_MUST_USE macro (defined using clang and gcc

Re: User-facing benefits from UA exposure of Android version and Linux CPU architecture

On 2/18/2021 3:51 AM, Henri Sivonen wrote: As for the CPU architecture on Linux, on Mac and Windows we don't expose aarch64 separately. (On Windows, consistent with Edge, aarch64 looks like x86. On Mac, aarch64 looks like x86_64 which itself doesn't differ from what x86 looked like.) As an

C++ PSA: Use [[nodiscard]] instead of MOZ_MUST_USE

Now that Firefox is compiled as C++17 (bug 1560664), you can use C++17's [[nodiscard]] attribute [1] instead of the MOZ_MUST_USE macro (defined using clang and gcc's non-standard __attribute__((warn_unused_result))). I have been slowly replacing MOZ_MUST_USE with [[nodiscard]] in my free time

Re: Improvement to build times through cleanup of C++ include dependencies

On 12/14/2020 3:23 AM, Simon Giesecke wrote: I was using some tools to support this, notably ClangBuildAnalyzer [2] and include-what-you-use [3]. ClangBuildAnalyzer helped to detect headers that are expensive to parse throughout the build, and direct efforts to reduce those specifically. But

Re: Please don't use functions from ctype.h and strings.h

On 8/27/2018 7:00 AM, Henri Sivonen wrote: I think it's worthwhile to have a lint, but regexps are likely to have false positives, so using clang-tidy is probably better. A bug is on file:https://bugzilla.mozilla.org/show_bug.cgi?id=1485588 On Mon, Aug 27, 2018 at 4:06 PM, Tom Ritter wrote:

Reimplementing MOZ_ALWAYS_TRUE() using MOZ_DIAGNOSTIC_ASSERT() instead of MOZ_ASSERT()

Heads up: In 77 Nightly, I plan to reimplement MOZ_ALWAYS_TRUE() using MOZ_DIAGNOSTIC_ASSERT() instead of MOZ_ASSERT(). This is bug 1620152. MOZ_ALWAYS_TRUE(X) and friends [1] are like MOZ_ASSERT(X), except they also evaluate the expression X in release builds. This is useful for silencing

Fission meetings at the Berlin All Hands

The Fission team will be hosting a few meetings at the Berlin All Hands to help Firefox frontend and Gecko engineers convert their code to Fission's async APIs. Step 1: attend the "Introduction to Fission Engineering" presentation to get an overview and code examples of Fission: * Sched:

Re: Coding style  : `int` vs `intX_t` vs `unsigned/uintX_t`

On 7/5/2019 10:39 AM, Gijs Kruitbosch wrote: FWIW once in a while I have come across bugs caused by truncation of integers where someone picked a specific size that was too small also, e.g. storing an offset into a text node in a 16-bit integer.  I think that's maybe something that's hiding

Re: Using Google styling of #define guards

On 7/3/2019 11:37 AM, Bryce Seager van Dyk wrote: I wanted to clarify, and discuss if needed, our styling of #define guards. My understanding is that we are now using Google's style in regards to #define guards (https://google.github.io/styleguide/cppguide.html#The__define_Guard). I believe

Re: Running C++ early in shutdown without an observer

On 6/7/2019 9:36 AM, Kris Maglione wrote: On Fri, Jun 07, 2019 at 09:18:38AM +0300, Henri Sivonen wrote: For late shutdown cleanup, we have nsLayoutStatics::Shutdown(). Do we have a similar method for running things as soon as we've decided that the application is going to shut down? (I know

Re: Remove browser and OS architecture from Firefox's User-Agent string?

On 5/14/2019 9:53 AM, Tom Ritter wrote: On Tue, May 14, 2019 at 4:26 PM L. David Baron wrote: So I think there's may be value in removing these distinctions from the User-Agent header we send over HTTP even if they're still accessible from Javascript (and useful there for sites offering

Re: Remove browser and OS architecture from Firefox's User-Agent string?

On 5/11/2019 8:59 AM, Henri Sivonen wrote: "Mozilla/5.0 (Windows NT 10.0; rv:66.0) Gecko/20100101 Firefox/66.0" Would there be significant downsides to hard-coding the Windows version to "10.0" in order to put Windows 7 and 8.x users in the same anonymity set with Windows 10 users? ... >

Re: Remove browser and OS architecture from Firefox's User-Agent string?

On 5/11/2019 4:11 AM, j.j. wrote: < "Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0" > "Mozilla/5.0 (Windows NT 10.0; rv:66.0) Gecko/20100101 Firefox/66.0" Note that "navigator.oscpu" returns "Windows NT 6.1; Win64; x64" or similar. This needs to change

Remove browser and OS architecture from Firefox's User-Agent string?

Hello, UA string fans! I propose that Firefox's UA string on Windows and Linux omit the browser and OS architectures to reduce UA fingerprinting entropy (and save a few header bytes). I have tentative thumbs up from some webcompat and privacy people, but as there is no official module owner

Re: Fennec moving to extended support

On 4/28/2019 12:40 PM, Dirkjan Ochtman wrote: As a nightly Fennec user, I'd much rather start running Fenix nightlies at some point soon. Is there any tentative ETA when Fenix nightlies will become available for dogfooding on the Play Store, with regular updates? I don't know when Fenix

Re: PSA: Min clang / libclang requirement was updated not long ago...

Seems like mach bootstrap should have a clobber flag so anyone updating build tool dependencies can force people to re-run mach bootstrap (and save many people frustration). On 2/26/2019 10:00 AM, David Major wrote: Does configure warn about this? The link between this error and needing to

Re: Type-based alias analysis and Gecko C++

On 2/17/2019 11:40 PM, Henri Sivonen wrote: Out of curiosity: Do we know if WebKit and Chromium compile with or without strict-aliasing? Chromium disabled strict aliasing in 2010 [1] and then in 2013 WONTFIX'd the bug that would re-enable strict aliasing[2]. The WONTFIX discussion [3]

Re: Intent to Implement: css-scroll-anchoring

This is great news! In a recent study of Fennec's perceived performance, users ranked 16 criteria for evaluating mobile browser responsiveness. #1 was "Not having the page jump around when scrolling". For a point of reference for just how important that is, "Loading a website" was only #3. :)

Re: Announcing new test platform "Android 7.0 x86"

On 2018-11-01 3:06 PM, Nicholas Alexander wrote: Like the existing "Android 4.2" and "Android 4.3" test platforms, these tests run in an Android emulator running in a docker container (the same Ubuntu-based image used for linux64 tests). The new platform runs an x86 emulator using kvm

Re: Intent to Ship: Shadow DOM and Custom Elements

On 2018-08-15 9:04 AM, smaug wrote: Why does https://caniuse.com/#feat=shadowdomv1 show Firefox 63 show not supported by default? No idea. I don't know who maintains caniuse and when the they update it. Please report to them that they may want to update the page. The caniuse data is

Re: Intent to ship '-webkit-appearance' and changes to '-moz-appearance' values

Awesome! This should fix some common webcompat issues for Firefox/GeckoView on Android. What are the criteria for letting -webkit-appearance ride the trains? The GeckoView team is eager to ship mobile webcompat fixes, so they might be willing to accept more risk than Firefox desktop. Are

Re: Using clang-cl to ship Windows builds

How does the performance of clang-cl builds compare to MSVC builds on benchmarks like Speedometer? On 2018-07-10 1:29 PM, David Major wrote: Bug 1443590 is switching our official Windows builds to use clang-cl as the compiler. Please keep an eye out for regressions and file a blocking bug

Re: Upcoming C++ standards meeting in Rapperswil, Switzerland

On 2018-05-23 1:35 PM, Botond Ballo wrote: There is also work being done in this area outside the formal standards process, in the form of the C++ Core Guidelines [2] (some of which can be checked statically) and the accompanying Guideline Support Library [3], and in the form of Microsoft's

Re: PSA: C++ virtual function declarations should specify only one of virtual, final, or override

On 2018-02-16 12:54 PM, Ben Kelly wrote: Are we supposed to just use override or final on methods that are overriden when the class itself is marked final? Personally writing final again seems redundant with the class level final and the override keyword seems more informative. You could use

Re: PSA: C++ virtual function declarations should specify only one of virtual, final, or override

On 2018-02-16 1:07 PM, L. David Baron wrote: virtual void Bad1() final I think there might be some legitimate use cases for this one, when a function needs to be virtual because it's required for the calling convention (as part of a binary plugin API or binary embedding API, for example),

PSA: C++ virtual function declarations should specify only one of virtual, final, or override

Mozilla's C++ style guide [1] says (since 2015) virtual function declarations should specify only one of `virtual`, `final`, or `override`. Over the weekend, I will land a mach lint check (bug 1436263) that will warn about some virtual style violations such as: virtual void Bad1() final

Chrome will start marking HTTP pages as "Not secure"

Chrome will start marking HTTP pages as "Not secure" in July 2018 (Chrome 68): https://security.googleblog.com/2018/02/a-secure-web-is-here-to-stay.html Firefox has a similar insecure HTTP warning icon, currently disabled by the `security.insecure_connection_icon.enabled` pref added in bug

Re: PSA: Avoid invoking Debug formatters in release-mode Rust

On 2018-01-12 9:07 PM, Bobby Holley wrote: The most common way this seems to happen is in panic!() messages, where it can be tempting to include a stringified value to make the message more informative. Just a friendly reminder: panic messages that are parameterized to include debug data

Re: Nightly Start Time and Daylight Savings

On 2017-11-06 9:46 AM, Justin Wood wrote: Now with Taskcluster the start time is anchored in UTC so doesn't move along with Daylight Savings, currently anchoring at 10am and 10pm UTC. How long do the Nightly builds typically take? If the builds are started at 10am and 10pm UTC (2am and 5pm

Re: We need better canaries for JS code

On 2017-10-18 4:51 AM, Mark Banner wrote: I expect that this will find a number of lurking errorsy, so we may want to migrate code progressively, using a directive, say "use strict moz-platform" and static analysis to help encourage using this directive. It would definitely be interesting to

Re: Changes to tab min-width

On 2017-10-03 2:18 PM, Boris Zbarsky wrote: Right now, at 60px, I can see 7-10 chars in a tab title.  This is sometimes (but not always) enough for me to make sense of what I'm looking at when the favicon is not helpful.  For example, for bugzilla bugs I can see the whole bug number. In the

Re: test-verify now running as tier 2

This is very cool, Geoff! People have been talking about this idea for a long, so it is great to see it actually running. I'm glad to see chaos mode being tested, too. On 2017-10-02 10:11 AM, Geoffrey Brown wrote: Today the test-verify test task will start running as a tier 2 job. Look for

Re: Coding style: Placement of binary operators when breaking a long line

On 2017-09-06 8:06 PM, Ehsan Akhgari wrote: The interesting points to consider is the data that Nick alluded to in the previous discussion about the existing prevalent style. Also, the point you up about the pragmatic aspect of the need to be able to use automated tools in order to manage our

Re: Device Memory header and JS API

On 2017-09-06 11:48 AM, Tom Ritter wrote: Steam's hardware survey shows the following distribution percentages. Less than 512 MB 0.00% 512 Mb to 999 MB 0.03% 1 GB 0.52% 2 GB 3.30% 3 GB 6.27% 4 GB 14.96% 5 GB 0.66% 6 GB 3.23% 7 GB 2.33% 8 GB 42.77% 9 GB 0.04% 10 GB 0.29% 11 GB 0.18% 12

Re: Stylo now the default configuration for mozilla-central

On 2017-09-05 1:10 PM, J. Ryan Stinnett wrote: Assuming bug 1330412 sticks, Stylo will be the default configuration for mozilla-central for all platforms except Android. Thanks to everyone involved with Stylo that helped us reach this stage! Awesome! Thanks for flipping the switch, Ryan.

Re: Stylesheet wait timeout?

not have stylo enabled per about:support ("false (disabled by default)"). Dustin 2017-08-31 13:45 GMT-04:00 Chris Peterson <cpeter...@mozilla.com>: Gerv, do you have Stylo enabled? Even if you did not flip the pref (layout.css.servo.enabled), you might be in the Stylo experiment f

Re: Stylesheet wait timeout?

Gerv, do you have Stylo enabled? Even if you did not flip the pref (layout.css.servo.enabled), you might be in the Stylo experiment for Nightly users. Check about:support for "Stylo". On 2017-08-31 10:24 AM, Gervase Markham wrote: On 18/08/17 12:11, Gervase Markham wrote: Whereas what I

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

On 2017-08-21 5:31 PM, Eric Rahm wrote: I'm not sure how much backing that has -- we'd be going from nsString => String which is pretty close to std::string -- it would be interesting to get some feedback. Or follow Rust's precedent and use type name `Str`. That would avoid confusion with

Re: 64-bit Firefox progress report: 2017-07-18

ms wrong. The chart shows more like a 60% improvement instead of a 39% improvement. Perhaps we should just replace this graphic with an up-arrow for security and a down-arrow for crashes? Anyway, sorry to be pedantic, but misleading charts are kind of a pet peeve. Thanks. Ben On Wed, Jul 19, 20

Re: how to make your local --enable-optimize builds compile Rust faster

Matt Brubeck just a patch to disable Rust LTO on local Firefox builds, so you no longer need to manually apply Nathan's patch to disable LTO locally. https://bugzilla.mozilla.org/show_bug.cgi?id=1386371#c34 On 2017-08-09 11:49 AM, Nathan Froyd wrote: TL; DR: apply

Re: CodeCoverage! Monthly Update

Kyle, do you know if Rust code coverage is blocked on any remaining Rust toolchain issues? chris On 2017-08-10 11:31 AM, Kyle Lahnakoski wrote: Did you have that sense you were missing something? Well, you were right: You were missing your ... # *Monthly CodeCoverage! update!  \o/ *

Re: 64-bit Firefox progress report: 2017-07-18

only 1% of Win64 OS users. As we are preparing to migrate Beta users to 64-bit, we see the minimum memory requirement adds new complexity to both the client and server components of the update process and extra QA for this one-time migration event. On Mon, Aug 7, 2017 at 5:51 PM, Ch

Re: 64-bit Firefox progress report: 2017-07-18

On 2017-08-06 11:26 PM, Henri Sivonen wrote: On Thu, Jul 20, 2017 at 10:42 AM, Chris Peterson<cpeter...@mozilla.com> wrote: Users with only 2 GB and 5 minute browser sessions would probably have a faster user experience with 32-bit Firefox than with 64-bit, but how do we weigh that expe

Re: sccache as ccache

On 2017-08-05 10:49 AM, ISHIKAWA, Chiaki wrote: However, I am not sure if the cache is working correctly. With ccache, we can specify a log file in the environment variable CCACHE_LOGFILE to specify. We can study the log file to see if the cache is indeed working (hits, etc). Is there an

Re: Heads up! Building Stylo in local developer builds

t for mach bootstrap to run xcode-select automatically. On 2017-07-28 1:04 AM, Chris Peterson wrote: Stylo support (pref'd off) has been built in automation builds for a couple weeks. Ralph Giles just landed bug 1384258 to also build Stylo support (pref'd off) in local developer builds, too.

Re: Heads up! Building Stylo in local developer builds

' and cannot be re-added You can fix this problem by running: rustup default stable-x86_64-pc-windows-msvc On 2017-07-28 1:04 AM, Chris Peterson wrote: Stylo support (pref'd off) has been built in automation builds for a couple weeks. Ralph Giles just landed bug 1384258 to also build Stylo support (pref'd

Heads up! Building Stylo in local developer builds

Stylo support (pref'd off) has been built in automation builds for a couple weeks. Ralph Giles just landed bug 1384258 to also build Stylo support (pref'd off) in local developer builds, too. You should rerun `mach bootstrap` to make sure you have the latest versions of the Stylo and Rust

Re: Keyboard APZ has landed on Inbound

On 2017-07-21 11:05 PM, Ryan Hunt wrote: The patch to enable async keyboard scrolling in nightly (for all platforms except Android) has landed on inbound. Once this is merged to central, key scrolling will be done by the compositor instead of on the main thread in most cases. This should bring

Re: 64-bit Firefox progress report: 2017-07-18

On 2017-07-19 6:58 PM, Mike Hommey wrote: I don't understand why that would be, but if so it should show in crashstats as fewer small OOMs on these devices. Does the data actually show that? I don't know. Can that be filtered? I'm not sure I'm answering the right question, but searching

Re: 64-bit Firefox progress report: 2017-07-18

On 2017-07-19 10:18 AM, Mike Hoye wrote: On 2017-07-19 3:58 AM, Chris Peterson wrote: On 2017-07-19 12:01 AM, Mike Hommey wrote: What's the plan for eligible people that still want to keep 32-bit Firefox? Outside of our QA team (or others orgs, I guess?) do we have a set of use cases

Re: 64-bit Firefox progress report: 2017-07-18

On 2017-07-19 12:01 AM, Mike Hommey wrote: What's the plan for eligible people that still want to keep 32-bit Firefox? Are they going to have to stop auto upgrades, which would get them automatically on 64-bits and upgrade manually? This is especially going to be a problem for users with less

64-bit Firefox progress report: 2017-07-18

We are on track to make 64-bit Firefox the default build for Win64 OS, bringing improved ASLR and fewer OOM crashes to the 70% of Windows Firefox users running Win64. PLANS: * In Firefox 55 (August 8), the Windows stub installer will default to 64-bit Firefox for eligible users (Win64 and 2+

Re: More Rust code

On 7/10/17 4:48 PM, Xidorn Quan wrote: The first thing comes to my mind is crash reports. It currently doesn't always include useful panic message from Rust, see for example [1] and [2]. Also for Stylo, we generate lots of code (including using bindgen and mako template system, bindgen is

Re: Linting for common causes of oranges in mochitests (need ideas)

On 7/6/17 11:47 AM, Andrew Halberstadt wrote: # Are there additional things not listed on that page that we could lint for? Do we want to discourage tests from using Date (`new Date` or `Date.now()`) for measuring time? Dates are affected by time zones, DST, and clock skew issues jumping

FYI: Questions about the Gecko Profiler? Drop by the #flow IRC channel.

Just a reminder: if you or engineers on your team have questions about using the Gecko Profiler (https://perf-html.io/), you can ask for help in the #flow IRC channel. ___ dev-platform mailing list dev-platform@lists.mozilla.org

Re: Quantum Flow Engineering Newsletter #14

On 6/23/17 12:17 AM, Ehsan Akhgari wrote: But to speak of a more direct measurement of performance, let's look at our progress on Speedometer V2 . Today, I measured our progress so far on this benchmark by

Re: Profiling nightlies on Mac - what tools are used?

On 6/21/17 8:06 AM, Boris Zbarsky wrote: On 6/21/17 10:44 AM, Ehsan Akhgari wrote: It seems like that we have an answer now in the bug! https://bugzilla.mozilla.org/show_bug.cgi?id=1338651#c129 Just for clarity, so people don't have to read the whole bug, changing the _path_ the build is at

Re: Intent to unship: HTML scoped style sheets (

On 6/20/17 2:14 AM, Cameron McCormack wrote: Cameron, what bug should this one block (iiuc chrome support will be removed a bit later, so we have some time, do you already have a bug for that part?) Actually, let me backtrack a little. I might be misremembering our plans for Stylo in

Re: JSBC: JavaScript Start-up Bytecode Cache

Nicolas, when JSBC is enabled by default, should we change our test procedure for our various page load tests (Talos and Softvision's manual testing)? Since the first page load will be slower than subsequent page loads (as you noted in the bug [1]), should we throw away the first page load

Re: Linux builds now default to -O2 instead of -Os

On 6/6/17 10:33 AM, Boris Zbarsky wrote: On 6/1/17 9:04 PM, Mike Hommey wrote: Ah, forgot to mention that. No, it doesn't affect *our* shipped builds (because PGO uses a different set of optimization flags). But it does affect downstream builds that don't PGO. Based on the jump I see on June

Re: Improving visibility of compiler warnings

On 2017-05-25 5:31 AM, Ehsan Akhgari wrote: On 05/19/2017 02:44 PM, Gregory Szorc wrote: `mach build` attempts to parse compiler warnings to a persisted "database." You can view a list of compiler warnings post build by running `mach warnings-list`. The intent behind this feature was to make it

Re: Changing our thread APIs for Quantum DOM scheduling

The Quantum DOM doc says only content processes will get cooperative threading. How will cooperative threading work with multiple content processes (e10s-multi)? Will there be inter-process scheduling? For example, if content process #1 has one or more foreground tabs (from multiple windows)

Re: Quantum Flow Engineering Newsletter #9

On 2017-05-12 9:55 AM, Ehsan Akhgari wrote: This reminded me of https://bugzilla.mozilla.org/show_bug.cgi?id=1332680 (and https://bugzilla.mozilla.org/show_bug.cgi?id=1332682 ) Adding -Wsuggest-final-types and -Wsuggest-final-methods and looking at the output seems pretty low-effort to find a

Re: QF bug whiteboard tags

On 2017-05-10 1:05 PM, Jim Mathies wrote: The quantum flow project has been filing a lot of bugs lately. I'm curious about two specific whiteboard tags I've seen - [qf:p1] and [qf], can someone explain the differences between these two tags and how this impact the priority of these bugs?

Re: CodeCoverage Monthly Update

On 2017-05-03 8:44 PM, Kyle Lahnakoski wrote: * Daily coverage reports on coveralls.io [1] and on codecov.io[2]. Which do you like? Does coveralls.io have a top-down coverage view like codecov.io? That view seems more useful for both people that want a global view and developers that

Re: Quantum Flow Engineering Newsletter #6

btw, Nathan Froyd is working to add Gecko Profiler support for Stylo's Rust code and rayon threads in bug 1322656. On 2017-04-21 8:50 AM, Ehsan Akhgari wrote: On 04/21/2017 03:12 AM, Nicholas Nethercote wrote: Judging from the incoming flow of bug reports, the number of people using the

Re: Quantum Flow Engineering Newsletter #5

On 2017-04-18 4:22 PM, Ehsan Akhgari wrote: The last time I checked with the graphics team, at this point it's completely unclear whether Quantum Render is going to make it, and as such, it's not reasonable for us to depend on anything that WebRender provides for Photon, because if QR wouldn't

Re: e10s-multi on Aurora

On 2017-04-11 10:31 PM, Salvador de la Puente wrote: How does this relate with Project Down and the end of Aurora channel? Will be multi-e10s enabled when shifting from nightly to beta? There is no connection between Project Dawn and enabling multiple e10s content processes in the Aurora

Re: Quantum Flow Engineering Newsletter #4

On 2017-04-07 9:11 AM, Ehsan Akhgari wrote: - DOM. In the DOM team there are several plans and projects under way which will hopefully bring various performance improvements to the browser. Probably the largest one is the upcoming plans for cooperative scheduling of tasks, which

Re: windows build anti-virus exclusion list?

On 3/17/2017 1:45 AM, Honza Bambas wrote: I have a very similar setup, with even way more exceptions added, but none of them has the desired effect. Unfortunately, the only way to make MsMpEng shut up is to disable run-time protection completely for the time of the build. I think it's a bug in

Re: Sheriff Highlights and Summary in February 2017

e code. I think, and this is my next area to investigate, is the 1 bug per push (the autoland model) could be helping with the percentage of backouts being lower. David On 7 March 2017 at 21:29, Chris Peterson <cpeter...@mozilla.com> wrote: On 3/7/2017 3:38 AM, Joel Maher wrote: One large di

Re: Is there a way to improve partial compilation times?

On 3/7/2017 11:19 AM, Steve Fink wrote: I have at times spun off builds into their own cgroup. It seems to isolate the load pretty well, when I want to bother with remembering how to set it up again. Perhaps it'd be a good thing for mach to do automatically. Then again, if dropping the -j count

Re: Quantum Render builds now on m-c

Awesome news! Building Quantum Render in mozilla-central and running even a subset of our regular tests is a big step towards shipping. chris On 2/10/2017 1:11 PM, Kartikaya Gupta wrote: (cross-posted to dev-platform and dev-tech-gfx) This is just a heads up that earlier today we merged the

Re: Intent to implement and ship: only allow Flash on HTTP/HTTPS sites

On 2/7/2017 1:15 PM, Benjamin Smedberg wrote: I intend to ship a change which will prevent Flash from loading from file:, ftp:, or any other URL scheme other than http: or https:. The purpose of this change is to increase security and limit Flash to well-tested configuraitons. Do you want to

Re: A reminder about MOZ_MUST_USE and [must_use]

On 1/19/2017 3:13 PM, Nicholas Nethercote wrote: On Fri, Jan 20, 2017 at 10:01 AM, wrote: > And the next step would be to make must-use the default, and have > MOZ_CAN_IGNORE for the rest. ;-) > I actually tried this with all XPIDL methods. After adding several hundred

Re: Intent to Implement and Ship: Large-Allocation Header

On 1/18/2017 12:21 PM, Michael Layzell wrote: Games implemented on the web platform using WASM or asm.js use large contiguous blocks of allocated memory as their backing store for game memory. For complex games, these allocations can be quite large, sometimes as large as 1GB. In 64-bit builds,

Re: Intent to unship: navigator.getBattery (Battery Status API)

WebKit implemented the battery API, though Safari didn't expose the API to web content. Yesterday the WebKit team proposed removing the API, too: https://bugs.webkit.org/show_bug.cgi?id=164213 https://lists.webkit.org/pipermail/webkit-dev/2016-October/028468.html On 10/31/2016 1:24 AM, Chris

Re: Intent to unship: navigator.getBattery (Battery Status API)

On 10/31/2016 11:23 AM, nicjan...@gmail.com wrote: Boomerang is an open-source library [1] for collecting performance telemetry. You're correct that it currently captures the battery level and other device characteristics. While Boomerang was not designed for the purpose of fingerprinting

Intent to unship: navigator.getBattery (Battery Status API)

As proposed earlier on the dev-platform list [1], I made the Battery Status API chrome-only in Firefox Nightly 52 (bug 1313580 [2]). The battery code and tests remain, available to Gecko code and Firefox add-ons. There should be little risk of web compat regressions. The battery API was never

Re: Removing navigator.buildID?

On 10/30/2016 2:27 AM, Pascal Chevrel wrote: IMO the builID is important for our community of nightly testers that report bug and need to indicate precisely in which build they found a regression, so keeping that information available via about:support and extensions such as Nightly Testers

Re: Removing the Battery Status API?

On 10/26/2016 9:21 AM, Boris Zbarsky wrote: So I decided to see what sites were doing with it. I set a breakpoint in getBattery() and tried browsing. The first site I tried loading was cnn.com, and it hit the breakpoint. It's hitting it because it's using the "boomerang" library from

Removing the Battery Status API?

What is the use case for the Battery Status API [0], navigator.getBattery()? Can we remove the Battery API or perhaps restrict it to non-web content like browser extensions or privileged web apps? Chrome and Firefox support the Battery API, but neither Edge nor WebKit have signaled an intent

Re: Intent to restrict to secure contexts: navigator.geolocation

On 10/25/2016 11:43 AM, Eric Rescorla wrote: Setting aside the policy question, the location API for mobile devices generally gives a much more precise estimate of your location than can be obtained from the upstream network provider. For instance, consider the case of the ISP upstream from

Re: Intent to restrict to secure contexts: navigator.geolocation

On 10/25/2016 6:26 AM, Ehsan Akhgari wrote: FWIW, and to the extent that my opinion matters on the topic, I strongly disagree that breaking the websites that people use silently is the right thing to do. Let's ignore the HTTPS Everywhere part of the thread, and instead pay more attention to

Re: Intent to restrict to secure contexts: navigator.geolocation

On 10/21/2016 3:11 PM, Tantek Çelik wrote: > Does this mean that we'd be breaking one in 5 geolocation requests as a > result of this? That seems super high. :( Agreed. For example, my understanding is that this will break http://www.nextbus.com/ (and thus http://www.nextmuni.com/ ) location

Increasing usage of 64-bit Firefox on Windows

Matt Howell will soon land stub installer support for 64-bit Windows in Nightly 52 (bug 797208), as part of an effort to move more Firefox users to 64-bit. About 66% of our Windows users are running 32-bit Firefox on 64-bit Windows. They're missing out on potential optimizations and fewer OOM

Re: Removal of B2G from mozilla-central

On 9/29/2016 11:46 AM, Sebastian Hengst wrote: as has been announced earlier https://groups.google.com/forum/#!topic/mozilla.dev.fxos/FoAwifahNPY the Boot 2 Gecko (B2G) code will be removed from mozilla-central. Is Gonk used anywhere besides B2G? Can we remove all Gonk code, e.g.

Re: Chrome's Interventions Quarterly Newsletter: 2016 Q2-Q3

On 8/17/2016 5:03 PM, Karl Dubost wrote: Chris, Le 18 août 2016 à 02:21, Chris Peterson <cpeter...@mozilla.com> a écrit : Here is a status report from the Chrome team about their current and future "interventions": https://docs.google.com/doc

Chrome's Interventions Quarterly Newsletter: 2016 Q2-Q3

Here is a status report from the Chrome team about their current and future "interventions": https://docs.google.com/document/d/1vqM_Dbi-V7LtdOwb2IGjgor9Fvl5k_FvO2DJGr4CaSQ/ An intervention is when a user agent decides to deviate slightly from a standardized behavior in order to provide a

Re: Reproducible builds

On 7/18/16 11:56 AM, Gregory Szorc wrote: A significant obstacle to even comparable builds is "private" data embedded within Firefox. e.g. Google API Keys. I /think/ we're also shipping some DRM blobs. Mozilla does not ship any DRM blobs with Firefox. The Adobe Primetime and Google Widevine

Re: The Whiteboard Tag Amnesty

On 6/8/16 4:03 PM, Jason Duell wrote: Could we dig into details a little more here? I assume we could add a database index for the whiteboard field if performance is an issue. Do we give keywords an enum value or something (so bugzilla can index/search them faster)? I'm not clear on what a

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

On 5/30/16 11:22 PM, Nicholas Nethercote wrote: #2 is unannotated MOZ_CRASH() calls, i.e. there is no string argument given. These are mostly OOMs, though there are a few others in there. These ones should be annotated so they show up separately. MOZ_CRASH()'s explanation string parameter is

Re: Updating 32-bit Windows users to 64-bit Windows builds?

Yes. Flash and Silverlight both have 64-bit plugins that work in 64-bit Firefox. Streaming video services will likely move their Firefox users from Silverlight to Widevine this year, so Silverlight usage will decline by EOY. On 5/12/16 1:10 PM, Ryan VanderMeulen wrote: Flash installs the

Re: libstdc++ debug mode enabled in debug builds

Similarly, quite a few third-party libraries do not use the standard DEBUG and assert() macros. When integrating new third-party code, be sure to check whether you must define any extra macros to enable assertions in debug builds. For example, to enable assertions in the ffvp9 decoder, we had

Re: Intent to deprecate: MacOS 10.6-10.8 support

On 5/5/16 8:23 PM, sfbay.mapfi...@gmail.com wrote: The best option, from my perspective (supporting a wide array of users, OS versions, hardware), is to make the final 10.6-10.8 version be (or become) the next ESR with a startup page providing them with the choice and action buttons/links.

Re: Reverting to VS2013 on central and aurora

On 5/5/16 9:26 PM, Gregory Szorc wrote: I'll try to stand up automation to ensure central remains buildable with VS2015. This will add extra work and strain on automation and likely make writing C++ that remains compatible with multiple Visual Studio versions slightly harder. This is

Re: Intent to deprecate: MacOS 10.6-10.8 support

On 5/3/16 3:11 AM, Xidorn Quan wrote: > Then we should plan to drop Universal builds in the same release, > because without supporting 10.6 or 32-bit NPAPI plugins, the 32-bit half > of the build is just cruft. That doesn't mean we can't remove 32-bit NPAPI support on OS X sooner than 53.

Re: Intent to deprecate: MacOS 10.6-10.8 support

On 5/2/16 5:18 PM, Gregory Szorc wrote: On Mon, May 2, 2016 at 5:12 PM, Chris Peterson <cpeter...@mozilla.com> wrote: On 5/2/16 4:10 PM, Gregory Szorc wrote: So where does that leave us on Universal OS X builds? IIRC our blocker is the need to support 32-bit Silverlight in the

Re: Intent to deprecate: MacOS 10.6-10.8 support

On 5/2/16 4:10 PM, Gregory Szorc wrote: So where does that leave us on Universal OS X builds? IIRC our blocker is the need to support 32-bit Silverlight in the plugin container so various streaming services using it don't break. Where are we on that front? (Reminder: killing Universal OS X

  1   2   3   >