Re: PSA (Windows): Startup Skeleton UI Enabled on Nightly

[Mike Conley]

dthayer,

Congratulations to you and emalysz for getting this enabled in Nightly! I
know it's been a long slog, but I think this is going to make a very
perceivable improvement to our startup responsiveness.

-Mike

On Thu, 7 Jan 2021 at 07:20, Sebastian Zartner 
wrote:

> On Wednesday, January 6, 2021 at 10:55:22 PM UTC+1, Doug Thayer wrote:
> > On 1/6/2021 1:51 PM, Mike Hommey wrote:
> >
> > > On Wed, Jan 06, 2021 at 01:46:52PM -0800, Doug Thayer wrote:
> > >> On 1/6/2021 1:44 PM, Mike Hommey wrote:
> > >>
> > >>> On Wed, Jan 06, 2021 at 01:30:00PM -0800, Doug Thayer wrote:
> >  On Wed, Jan 6, 2021 at 1:23 PM Mike Hommey 
> wrote:
> > 
> > > On Wed, Jan 06, 2021 at 11:57:18AM -0800, Doug Thayer wrote:
> > >> If you don't spend any time on Nightly in Windows 10, please feel
> free to
> > >> disregard this.
> > >>
> > >> tl;dr: we're sometimes creating the first window differently than
> usual,
> > > so
> > >> be on the lookout for breakages.
> > >>
> > >> On 2021-01-05, a change landed in Nightly which enabled the
> pre-XUL
> > > skeleton
> > >> UI [1]. This is a feature which allows us to create the first
> window and
> > >> populate it with a non-interactive placeholder UI before we load
> > > xul.dll. On
> > >> some systems, this can mean we can give visual indication of
> Firefox
> > >> launching as much as 15 seconds sooner than normal (loading
> xul.dll can
> > > take
> > >> a while). We're hoping this could be a big win for users who
> experience
> > > very
> > >> slow startups, and we also hope it will improve the overall
> snappiness of
> > >> startup even on fast systems.
> > > What does the placeholder UI look like?
> > >
> >  Colors and layout can vary, but the basic look is this:
> >  [image: image.png]
> > >>> The image attachment didn't quite work.
> > >> Woops. Here is a link: https://i.imgur.com/R4ynXW5.png
> > > Does the placement and the size of that window vary?
> > It does. It uses values persisted to the registry based on the most
> > recent run of the default profile, scoped by the path to the executable.
> > The registry values can be found at
> > HKEY_CURRENT_USER\SOFTWARE\Mozilla\Firefox\PreXULSkeletonUISettings.
>
> I am running Nightly 86.0a1 (2021-01-07) 64bit on Windows 10 on a freshly
> created profile and checked that the browser.startup.preXulSkeletonUI
> preference is set to true, though instead of seeing the UI I get a blank
> white window. I remember, I tested this feature like a month or two ago and
> it did work before. Is that expected? If not, please let me know what
> information is needed to track this down and I'll file a bug for it.
>
> Also, regarding the registry values, I only see one for the theme with a
> key referring to the path of the Nightly executable. How will you handle
> different profiles?
>
> Besides those issues, I'm really happy to see this coming. It improves
> perceived start up speed a lot, especially on less powerful machines.
>
> Sebastian
> ___
> 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: Improvement to build times through cleanup of C++ include dependencies

[Mike Conley]

Thank you so much for investing time and effort into this area!
Improvements to build times are always always welcome.

I seem to recall we collect opt-in Telemetry on things like build times. If
so, have we noticed any changes in those graphs?

-Mike

On Mon, 14 Dec 2020 at 11:11, Botond Ballo  wrote:

> Hey Simon,
>
> Thanks a lot for working on this! It's hard to notice the effect of
> individual changes in this area, but in aggregate they can add up to a
> significant build speed improvement.
>
> Botond
>
> On Mon, Dec 14, 2020 at 6:23 AM Simon Giesecke 
> wrote:
> >
> >  tl;dr Build times on all platforms, in particular for incremental
> builds,
> > have decreased in the last weeks by landing several cleanups to C++
> include
> > dependencies that reduce the aggregated number of included files by about
> > 30%.
> >
> > Hi,
> >
> > Did you notice a reduction in build times lately? This might not be a
> > coincidence. In this mail, I want to provide some details on the
> > improvements made. I want to thank everyone who contributed to this
> through
> > up-front discussions and reviews.
> >
> > Recently I landed a number of patches on Bug 1676346 [1] that in various
> > ways clean up C++ include directives in our codebase. Some landed ca. 3
> > weeks ago, some landed last week. Overall, these reduce the aggregated
> > number of included non-system header files in a full build by about 30%
> on
> > Linux. I don't have numbers for other platforms, but they should benefit
> as
> > well. On my machine, this reduced the time for a clobber build by about
> > 10%. While that might go unnoticed, incremental builds are often sped up
> > even a lot more, since the number of translation units that need to be
> > rebuilt decreases. E.g. the number of translation units that include
> > dom/base/Document.h reduced by ca. 52%, resulting in a build time
> reduction
> > of 48% on my machine after modifying that. Your mileage may vary.
> >
> > While this might not spare you from buying new hardware, it will make
> > builds faster regardless of the hardware you are running on, and
> hopefully
> > increase productivity. If you want to share your experiences with me,
> > please get in touch!
> >
> > You might be curious what I did to achieve that, or how you can
> contribute
> > to reducing build times yourself. It's a combination of things, most
> > importantly three things:
> > 1. Remove unused include directives
> > 2. Split some headers
> > 3. Use forward declarations more
> > 4. Hide definitions to allow using forward declarations even more
> >
> > About 1: I found there are several include directives that are not needed
> > at all. They could simply be removed. However, the majority of cases
> were a
> > bit more complex, because of a lot of missing include directives. When
> > removing an include for X.h from a header file Y.h that doesn't need it,
> > another file that included Y.h might need X.h. Or, Y.h itself might need
> > something from a header indirectly included from X.h. Or similar cases.
> > This meant quite a lot of more include directives for more basic things
> > needed to be added to ensure the build doesn't break.
> >
> > About 2: Some headers have a lot of dependencies, but only relatively few
> > users of that header need them. One example was IPCMessageUtils.h, which
> is
> > included by all files generated by IPDL, which also contained a lot of
> > specializations of the ParamTraits template that are needed only by few
> > files. Apart from some very basic specializations, these were moved to
> the
> > new EnumSerializers.h and IPCMessageUtilsSpecializations.h as well as
> some
> > existing headers, so that the remaining IPCMessageUtils.h header has only
> > much more limited dependencies.
> >
> > About 3: Our coding style favors forward declarations over inclusion of
> the
> > full definition of types where possible. I replaced the inclusion of
> header
> > files containing full definitions of types by forward declarations at a
> > number of places where this is sufficient, e.g. because they are only
> used
> > in function signatures. It's worth noting that there were also a number
> of
> > cases where a forward declaration was present, but actually the full
> > definition is required, e.g. when a type is used as a base class or as
> the
> > value type of a data member, or an inline function body dereferences
> into a
> > member.
> >
> > About 4: As mentioned in the last point, inline function bodies often
> > require the inclusion of additional headers because they dereference into
> > types of which otherwise only forward declarations were necessary.
> Similar
> > considerations apply to private (nested) classes. Some of those were
> moved
> > to the corresponding implementation files to hide these dependencies, and
> > reduce the number of necessary includes in the header files.
> >
> > I was using some tools to support this, notably ClangBuildAnalyzer [2]
> and
> > include-what-you-use [3]. 

Re: Faster compilers available in bootstrap

[Mike Conley]

Yes, this is wonderful, thank you so much! Improvements to build times are
a force-multiplier. 5%-15% improvements in our build times is no joke!

On Thu, 9 Apr 2020 at 13:09, Botond Ballo  wrote:

> Thanks, compile time improvements are always good news!
>
> Out of curiosity, does this impact builds targeting Android on Linux or
> Windows?
>
> Thanks,
> Botond
>
> On Thu, Apr 9, 2020 at 12:52 PM David Major  wrote:
> >
> > As of bug 1326486, our clang toolchains for Linux and Windows are built
> > with PGO. (Apologies to Mac users: that toolchain is cross-compiled.)
> >
> > Under optimal conditions (Spidermonkey build, touch mfbt) I've seen
> 10-15%
> > compile time improvements locally, but in more common scenarios the gains
> > will be diluted by other parts of the system. Perfherder measured 5-9%
> > improvements in CI.
> >
> > To pick up a new compiler: after the next time you update your tree, run
> > `./mach bootstrap` or `cd ~/.mozbuild && /path/to/mach artifact toolchain
> > --from-build linux64-clang`, or on Windows replace the last part with
> > `win64-clang-cl`.
> >
> > Happy compiling!
> > ___
> > 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: Intent to ship: -less RDM

[Mike Conley]

Thanks Micah, and everybody else who's been working on this! As someone
who's had to struggle at times with the special tunneling and frameloader
swapping that we do for the moziframe stuff for RDM, this is a very very
welcome change, and will allow us to get rid of some pretty confusing
front-end code. I've also heard from Fission / DOM folks that they'll be
happy when they can get rid of the mozbrowser iframe support altogether,
and this was the last consumer blocking its removal!

So great job and thanks again!

On Tue, 10 Mar 2020 at 14:29, Micah Tigley  wrote:

> Hi all,
>
> Later this week, we’ll be enabling a new version of the Responsive Design
> Mode tool that no longer relies on  as part of the
> initiative to make DevTools Fission-compatible. For now, the pref will only
> be enabled in Firefox Nightly as we work with QA to ensure the stability of
> the tool.
>
> This new version of RDM will be embedded inside the browser UI (rather
> than live in a tab like today) and website content will be rendered inside
> the  element just like normal. Users should not expect any
> significant difference between this version and the current one.
>
> Pref: devtools.responsive.browserUI.enabled
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1621306
>
> Tracking bug for RDM Fission:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1574885. We ask anyone
> finding anything wrong with the new tool once the pref is on to report bugs
> blocking this meta.
>
> - Micah
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Dispatching background tasks just got easier!

[Mike Conley]

Ahh this is great, and so refreshing. I'm so happy we're starting to
bring some order to our threading situation!

Thanks so much to you and your team!

On Mon, 16 Dec 2019 at 11:51, Kristen Wright  wrote:

> Hello!
> Now that Bug 1584568  just landed I wanted to
> mention the new background thread pool for general purpose and blocking IO
> runnables. Existing one-off threads, as well as new jobs that you may want
> to run async in the background, can go to the new background thread pool
> with NS_DispatchBackgroundTask(...)
> <
> https://searchfox.org/mozilla-central/rev/2f09184ec781a2667feec87499d4b81b32b6c48e/xpcom/threads/nsThreadUtils.h#1710
> >.
> If you've got something that cares about what order it runs in you would
> want to use NS_CreateBackgroundTaskQueue
> <
> https://searchfox.org/mozilla-central/rev/2f09184ec781a2667feec87499d4b81b32b6c48e/xpcom/threads/nsThreadUtils.h#1722
> >
> instead.
>
> In the past, we've sent a lot of general I/O jobs to the stream transport
> service. For a lot of cases, it's now possible to use the dedicated
> background threads instead. To access the I/O threads when dispatching to
> the pool or to a background task queue, use the NS_DISPATCH_EVENT_MAY_BLOCK
> <
> https://searchfox.org/mozilla-central/rev/923eec8d2fb8078ebc7a33a9e1ce73eac01f7446/xpcom/threads/nsIEventTarget.idl#63
> >
> flag, to ensure that blocking I/O goes to its dedicated thread pool.
>
> For a lot of cases, converting your existing async jobs or adding new ones
> is pretty straightforward. Some examples of using background dispatch can
> be found in Bug 1594858  for a basic background
> task, Bug 1595242  for some background I/O, and
> Bug
> 1594814  for one that needs to use a background
> task queue. Our tracking bug for this work is Bug 1595241
> .
> ___
> 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: Using MozPhab without Arcanist

[Mike Conley]

This is great, thank you zalun!

moz-phab has improved by leaps and bounds over the last few months. Great
job to you and the team hacking on it - it's a critical part of my toolset.

On Tue, 22 Oct 2019 at 11:26, Piotr Zalewa  wrote:

> Hi all,
>
> Since today MozPhab does not require Arcanist to submit patches in all
> supported VCS's. It's an optional and experimental feature. Add the
> `--no-arc` option to switch it on.
>
> Feel free to use it and report any bugs the usual way -
>
> https://bugzilla.mozilla.org/enter_bug.cgi?product=Conduit=moz-phab
>
> Let's all hope not using Arcanist will soon become the default.
> --
> Piotr Zalewa (zalun)
> Mozilla
> ___
> 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: Experimenting with JavaScript type safety in mozilla-central

[Mike Conley]

This is a great thing to start looking into. I myself have definitely been
burned in the past because something unexpected got coerced into something
equally unexpected, resulting in behaviour that is without-a-doubt
unexpected.

So thanks to the folks getting this off the ground!

On Mon, 7 Oct 2019 at 13:06, Dave Townsend  wrote:

> JavaScript powers a lot of Firefox but unlike the other languages that ship
> code in our product JavaScript uses a dynamic type system. Types for
> variables are decided at execution time and can change as new values are
> assigned to them. This leaves you open to accidentally passing the wrong
> kind of data around your code. Easy to do when APIs are changed on the
> other side of the tree.
>
> Flow and Typescript have gained prominence recently as tools that add
> static types on top of JavaScript giving you a build time check (note: no
> runtime checks) to see if the types you’re using look correct. A number of
> us have used these tools successfully in side projects and want to see if
> using a tool like this would be beneficial in Firefox.
>
> A first experiment towards understanding this has just landed (
> https://hg.mozilla.org/integration/autoland/rev/1dd081553a3a).
> Specifically
> Greg Tatum has added TypeScript  type
> annotations and configuration to the JavaScript code in the
> devtools/client/performance-new directory.
>
> The mode of TypeScript we’re testing involves annotating types with
> comments, the JavaScript code itself is just normal JavaScript. All of the
> TypeScript bits live in comments so there is no build step and we’re also
> not adding any automated tests to verify the types in CI for this
> experiment.
>
> For the time being the perf tools team will just be checking the types
> locally before committing. This will give us an idea of the benefits on
> real in-tree code without any impact outside of the team.
>
> If you have any concerns with this or want to know more please let us know.
>
>
> Dave
> ___
> 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: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

[Mike Conley]

Just a quick follow-up -

yzen got back to me - here's the bug that tracked disabling e10s in Firefox
60 for older screen readers:

https://bugzilla.mozilla.org/show_bug.cgi?id=1489605

On Tue, 23 Apr 2019 at 16:30, Mike Conley  wrote:

> Hey folks,
>
> For Desktop, I don't believe there are any normal conditions under which
> our users will have e10s disabled. [1] is where the decision gets made, and
> it looks like these days, the only thing that will disable e10s is if the
> user sets `browser.tabs.remote.autostart` to false themselves, or if a
> MOZ_FORCE_DISABLE_E10S environment variable is set. I don't think either of
> those are ever set by Mozilla these days.
>
> There was a case a few months back where e10s was disabled for users with
> certain screen readers back for Firefox 60. Since that time, those screen
> readers have updated to become more stable with e10s enabled.
> Unfortunately, I don't have a reference to the bug(s) where that occurred,
> but I spoke to yzen in #accessibility, and Firefox 60 ESR is the last
> supported version where this e10s-disabling occurs on Desktop.
>
> So, to sum, I'm reasonably confident that, outside of Firefox 60 ESR,
> e10s-disabled is not a mode that we ship to any of our users. We can
> trigger it by pref flips or environment variables, but that's it.
>
> Mobile is another story - according to the fine folks in #mobile, Fennec
> still runs Gecko in non-e10s mode.
>
> To circle back to Gijs's questions:
>
> 1. do we still consider running desktop Firefox with e10s disabled a
>> supported configuration?
>>
>
> Outside of Firefox 60 ESR, no, I don't believe so.
>
> 2. Will we need to turn it off on esr68 in the same circumstances where
>> that happens on esr60?
>>
>
> According to yzen from the Accessibility team, no, we won't.
>
> 3. If the answer to either of the previous 2 questions is 'yes', do we
>> think it's acceptable not to run desktop tests on the configuration?
>>
>
> Answers are no.
>
> 4. If the answer to both (1) and (2) is 'no', can we remove support for
>> the pref and running desktop Firefox without e10s ? Some of the
>> codepaths are not unified and so there is effectively dead code that
>> we're lugging around for what would be no reason. (Note: a significant
>> proportion isn't dead because even in e10s, we load some
>> browser-provided content in parent process, ie a tab's browser is not
>> always remote/non-same-process -- but even so, there's a bunch of stuff
>> that keys off gMultiProcessBrowser that could be removed.)
>>
>
> Yes, I believe that stuff is probably safe to remove at this point, as
> long those changes don't assume e10s support on Fennec.
>
> -Mike
>
> [1]:
> https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/toolkit/xre/nsAppRunner.cpp#4964-5002
>
> On Tue, 23 Apr 2019 at 13:35, Dave Townsend  wrote:
>
>> Is there still a configuration (ignoring hidden prefs) that can cause a
>> user to end up using non-e10s? If so we should turn these tests back on.
>>
>> On Tue, Apr 23, 2019 at 8:25 AM Joel Maher  wrote:
>>
>> > Here is where we initially turned on non-e10s tests for win7:
>> > https://bugzilla.mozilla.org/show_bug.cgi?id=1391371
>> >
>> > and then moved to linux32:
>> > https://bugzilla.mozilla.org/show_bug.cgi?id=1433276
>> >
>> > Currently mochitest-chrome and mochitest-a11y run as 1proc in-tree-
>> these
>> > run this way as they do not work with e10s=true.  I suspect the
>> > mochitest-chrome is by design and a11y is a bug.
>> >
>> > -Joel
>> >
>> >
>> > On Thu, Apr 18, 2019 at 5:47 PM Bobby Holley 
>> > wrote:
>> >
>> > > If we're not testing it, we shouldn't be shipping it to users. It
>> would
>> > be
>> > > great if someone familiar with the esr60 situation could confirm that
>> we
>> > > don't plan to repeat it for esr68. It would also be great if someone
>> > could
>> > > explain the rationale for running some, but not all of the suites in
>> > 1proc
>> > > mode.
>> > >
>> > > Separately, I know some engineers disable e10s locally as a hack to
>> > > simplify debugging (e.g [1]). The 1proc mochitest+xpcshell+reftest
>> jobs
>> > > currently on automation are probably sufficient to continue support
>> for
>> > > this use-case, but if we turn those off, we should consider this
>> workflow
>> > > and how much we're willing to do to preserve it.
>> > >
>> > > [1] https

Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

[Mike Conley]

Hey folks,

For Desktop, I don't believe there are any normal conditions under which
our users will have e10s disabled. [1] is where the decision gets made, and
it looks like these days, the only thing that will disable e10s is if the
user sets `browser.tabs.remote.autostart` to false themselves, or if a
MOZ_FORCE_DISABLE_E10S environment variable is set. I don't think either of
those are ever set by Mozilla these days.

There was a case a few months back where e10s was disabled for users with
certain screen readers back for Firefox 60. Since that time, those screen
readers have updated to become more stable with e10s enabled.
Unfortunately, I don't have a reference to the bug(s) where that occurred,
but I spoke to yzen in #accessibility, and Firefox 60 ESR is the last
supported version where this e10s-disabling occurs on Desktop.

So, to sum, I'm reasonably confident that, outside of Firefox 60 ESR,
e10s-disabled is not a mode that we ship to any of our users. We can
trigger it by pref flips or environment variables, but that's it.

Mobile is another story - according to the fine folks in #mobile, Fennec
still runs Gecko in non-e10s mode.

To circle back to Gijs's questions:

1. do we still consider running desktop Firefox with e10s disabled a
> supported configuration?
>

Outside of Firefox 60 ESR, no, I don't believe so.

2. Will we need to turn it off on esr68 in the same circumstances where
> that happens on esr60?
>

According to yzen from the Accessibility team, no, we won't.

3. If the answer to either of the previous 2 questions is 'yes', do we
> think it's acceptable not to run desktop tests on the configuration?
>

Answers are no.

4. If the answer to both (1) and (2) is 'no', can we remove support for
> the pref and running desktop Firefox without e10s ? Some of the
> codepaths are not unified and so there is effectively dead code that
> we're lugging around for what would be no reason. (Note: a significant
> proportion isn't dead because even in e10s, we load some
> browser-provided content in parent process, ie a tab's browser is not
> always remote/non-same-process -- but even so, there's a bunch of stuff
> that keys off gMultiProcessBrowser that could be removed.)
>

Yes, I believe that stuff is probably safe to remove at this point, as long
those changes don't assume e10s support on Fennec.

-Mike

[1]:
https://searchfox.org/mozilla-central/rev/ec489aa170b6486891cf3625717d6fa12bcd11c1/toolkit/xre/nsAppRunner.cpp#4964-5002

On Tue, 23 Apr 2019 at 13:35, Dave Townsend  wrote:

> Is there still a configuration (ignoring hidden prefs) that can cause a
> user to end up using non-e10s? If so we should turn these tests back on.
>
> On Tue, Apr 23, 2019 at 8:25 AM Joel Maher  wrote:
>
> > Here is where we initially turned on non-e10s tests for win7:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1391371
> >
> > and then moved to linux32:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1433276
> >
> > Currently mochitest-chrome and mochitest-a11y run as 1proc in-tree- these
> > run this way as they do not work with e10s=true.  I suspect the
> > mochitest-chrome is by design and a11y is a bug.
> >
> > -Joel
> >
> >
> > On Thu, Apr 18, 2019 at 5:47 PM Bobby Holley 
> > wrote:
> >
> > > If we're not testing it, we shouldn't be shipping it to users. It would
> > be
> > > great if someone familiar with the esr60 situation could confirm that
> we
> > > don't plan to repeat it for esr68. It would also be great if someone
> > could
> > > explain the rationale for running some, but not all of the suites in
> > 1proc
> > > mode.
> > >
> > > Separately, I know some engineers disable e10s locally as a hack to
> > > simplify debugging (e.g [1]). The 1proc mochitest+xpcshell+reftest jobs
> > > currently on automation are probably sufficient to continue support for
> > > this use-case, but if we turn those off, we should consider this
> workflow
> > > and how much we're willing to do to preserve it.
> > >
> > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1530977#c0
> > >
> > > On Wed, Apr 17, 2019 at 5:40 AM Gijs Kruitbosch <
> > gijskruitbo...@gmail.com>
> > > wrote:
> > >
> > >> Hello,
> > >>
> > >> Today it came to my attention that there are no 1proc (non-e10s)
> browser
> > >> mochitests running anymore.
> > >>
> > >> It appears they were disabled in
> > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1433276 in early 2018,
> > >> which is somewhat odd because it looks like the bug talks about
> linux32,
> > >> but removed the win7 non-e10s browser chrome tests. At the time,
> > >> linux64-jsdcov was still non-e10s, but that was changed in
> > >> https://bugzilla.mozilla.org/show_bug.cgi?id=1451849, a bit later in
> > >> 2018 .
> > >>
> > >> This was a surprise to me because there is still a bunch of in-tree
> > >> desktop browser frontend code that is supposed to work if e10s is
> turned
> > >> off using the relevant pref. But we apparently have no automated test
> > >> coverage for this [so one 

User-Initiated Picture-in-Picture enabled on Windows, Nightly only for now

[Mike Conley]

(cross-posted to firefox-dev and dev-platform - please send public replies
to the firefox-dev thread)

Hello all,

Just a heads up that in bug 1527925
, I've enabled
User-Initiated Picture-in-Picture by default on Windows, Nightly-only for
now.

This feature allows you to pull videos out of a page into an "always on
top" window that can be moved around and resized.

You can start Picture-in-Picture by one of two ways:

1. You can right-click on a video element, and toggle it via the context
menu
2. You can hover the video with your mouse, and click on the blue
"Picture-in-Picture" toggle that should appear on the right side of the
video.

The feature is still under heavy development, so expect bugs and glitches
while we sort that out. You can help us make this thing better by filing
bugs against this meta bug
.

You can also reach out and ask questions by responding to this thread (on
the firefox-dev list, please), or reaching out directly to myself
(Engineering), Dave Justice (Engineering), Emanuela Damian (UX) or Andreas
Bovens (Product).

Thanks,

-Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Announcing ./mach busted

[Mike Conley]

\o/

Thank you for this!

On 2019-04-11 12:11 p.m., Bobby Holley wrote:
> TL;DR - In bug 1543241 (alias 'mach-busted'), we now have a central
> clearinghouse of bugs for broken mozilla-central tooling. You can invoke
> |./mach busted| to get a list of known outstanding issues, and |./mach
> busted file| to report a new one.
> 
> 
> Few things burn up productivity quite like broken tooling. If a developer
> cannot build, launch, test, or debug the code, they cannot meaningfully
> work on it.
> 
> We’ve made significant progress in recent years towards tools that break
> less often. This work comes in various forms: making the tools more robust
> and automatic, testing them better, sandboxing them, and reducing the
> supported configuration matrix. This is great stuff - but voluminous
> technical debt and limited resources mean we aren’t yet at the doorstep of
> a world where tools never break.
> 
> In the short term though, we can substantially mitigate the impact of
> tooling breakage by reducing the average time spent getting people back on
> their feet. Historically, the developer experience in these situations
> tends to look like this: https://bholley.net/images/productivity.gif
> 
> This happens because we lack a reliable way to steer developers around
> known pitfalls while they’re being fixed. Filing a bug isn’t a good way to
> get immediate answers, and searching all of Bugzilla is hit-or-miss. An IRC
> ping often works, but one needs to guess which person got all the previous
> pings about this same issue and therefore knows the workaround. In
> practice, this results in a barrage of pings to a few catch-all experts,
> who then have less bandwidth to fix the tools.
> 
> My hope is that mach-busted can help by centralizing all the active
> showstoppers in a list that’s easy for both the users and maintainers of
> the tools to scan. This only works if the list stays small - so if the
> proper fix will take time, we should land a temporary fix to make the tool
> fail gracefully with a suggested workaround (see bug 1542862 for an
> example).
> 
> It also only works if developers record new problems they encounter with
> |./mach busted file|. You may have already tumbled into the lava, but you
> can save many future lemmings from the same fate.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Process Priority Manager enabled on Nightly for Windows (only)

[Mike Conley]

I filed bug 1523974 to track this class of problem.

On 2019-01-30 11:44 a.m., Gabriele Svelto wrote:
> On 30/01/19 17:26, Mike Conley wrote:
>> That's a good question. I haven't yet noticed any difference yet, but
>> I'm hoping people can keep an eye out to see if there's appreciable lag
>> when switching back to a tab with video, or if background audio starts
>> to stutter.
>>
>> (I suspect that even if we don't hear any reports, it might be better to
>> be safe than sorry, and mark any background tabs that are playing media
>> as "active" - I'll file a bug.)
> 
> The process priority manager already has a concept of "perceivable tabs"
> (i.e. ones that are playing some form of audio) and assigns them a
> higher priority compared to non-playing background ones. Unfortunately
> the Windows-specific mapping of those priorities lumps them together
> because Windows has only one background scheduling class. However if we
> run into problems like skipping or jittering audio it will be trivial to
> put them back in the normal priority class.
> 
>  Gabriele
> 



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Process Priority Manager enabled on Nightly for Windows (only)

[Mike Conley]

Hey Valentin,

That's a good question. I haven't yet noticed any difference yet, but
I'm hoping people can keep an eye out to see if there's appreciable lag
when switching back to a tab with video, or if background audio starts
to stutter.

(I suspect that even if we don't hear any reports, it might be better to
be safe than sorry, and mark any background tabs that are playing media
as "active" - I'll file a bug.)

-Mike

On 2019-01-30 11:24 a.m., Valentin Gosu wrote:
> On Tue, 29 Jan 2019 at 20:33, Mike Conley  <mailto:mcon...@mozilla.com>> wrote:
> 
> (cross-posted to dev-platform and firefox-dev)
> 
> Hi folks,
> 
> Just a heads up that in bug 1476981
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1476981>, I just
> autolanded a patch that, when hopefully merged, will enable the
> Process Priority Manager for Firefox Desktop on Nightly on Windows.
> 
> The Process Priority Manager lowers the OS-level process priority
> for any content processes that host /only/ background tabs. As soon
> as one tab in a content process is brought to the foreground, the
> priority is brought back to the normal level.
> 
> This should allow foreground tabs to get more CPU cycles dedicated
> to them, which we hope will let users get more things done more
> quickly in those foreground tabs.
> 
> The pref is holding on Nightly to help us shake out bugs. If you
> notice any, bug 1522879
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1522879> is the right
> metabug to block.
> 
> If you have questions or concerns, please respond to this thread on
> dev-platform (to centralize the conversation).
> 
> 
> Do we know if this will impact video or audio playing in the background
> tabs?



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Process Priority Manager enabled on Nightly for Windows (only)

[Mike Conley]

Hi itielandrh,

Is tab warming taken into account, so that when hovering a background tab,
> its process priority will go back to normal?
>

Yes, this was addressed in this bug
 by dthayer.

Love seeing your work Mike!
>

I'm glad this excites you! Thankfully, I wasn't working alone on this
effort - the Process Priority Manager is a component that we salvaged and
cleaned up from the B2G effort, so the B2G folk laid the groundwork.
dthayer did a bunch of the preparation work to get the feature working on
Windows and ready to test on Nightly. I just so happened to be the one to
flip the bits here right at the end. So thanks to everybody who's gotten us
here. :)

-Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Process Priority Manager enabled on Nightly for Windows (only)

[Mike Conley]

Hey Yoric,

Do we have any idea whether this has an impact on energy use?
>

I think it's plausible, but I don't think we have a super great way to
measure that out in automation or with Telemetry (we might be able to use
things like the Intel Power Gadget to measure locally).

The original intent, however, was not to improve battery life (although
that'd be a pleasant side-effect!), but rather to improve responsiveness
and page load time (the theory being that processes hosting only background
content tabs can't steal as many cycles from foreground tabs).
Responsiveness and page load time is what I'm hoping to pay attention to -
although if people see battery usage improvements, that's great too. :)

-Mike

On Tue, 29 Jan 2019 at 13:49, David Teller  wrote:

> This sounds like a very good thing to have!
>
> Do we have any idea whether this has an impact on energy use?
>
> On 29/01/2019 19:32, Mike Conley wrote:
> > (cross-posted to dev-platform and firefox-dev)
> >
> > Hi folks,
> >
> > Just a heads up that in bug 1476981
> > <https://bugzilla.mozilla.org/show_bug.cgi?id=1476981>, I just
> > autolanded a patch that, when hopefully merged, will enable the Process
> > Priority Manager for Firefox Desktop on Nightly on Windows.
> >
> > The Process Priority Manager lowers the OS-level process priority for
> > any content processes that host /only/ background tabs. As soon as one
> > tab in a content process is brought to the foreground, the priority is
> > brought back to the normal level.
> >
> > This should allow foreground tabs to get more CPU cycles dedicated to
> > them, which we hope will let users get more things done more quickly in
> > those foreground tabs.
> >
> > The pref is holding on Nightly to help us shake out bugs. If you notice
> > any, bug 1522879 <https://bugzilla.mozilla.org/show_bug.cgi?id=1522879>
> > is the right metabug to block.
> >
> > If you have questions or concerns, please respond to this thread on
> > dev-platform (to centralize the conversation).
> >
> > Thanks!
> >
> > -Mike
> >
> >
> > ___
> > firefox-dev mailing list
> > firefox-...@mozilla.org
> > https://mail.mozilla.org/listinfo/firefox-dev
> >
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Process Priority Manager enabled on Nightly for Windows (only)

[Mike Conley]

(cross-posted to dev-platform and firefox-dev)

Hi folks,

Just a heads up that in bug 1476981
, I just autolanded a
patch that, when hopefully merged, will enable the Process Priority Manager
for Firefox Desktop on Nightly on Windows.

The Process Priority Manager lowers the OS-level process priority for any
content processes that host *only* background tabs. As soon as one tab in a
content process is brought to the foreground, the priority is brought back
to the normal level.

This should allow foreground tabs to get more CPU cycles dedicated to them,
which we hope will let users get more things done more quickly in those
foreground tabs.

The pref is holding on Nightly to help us shake out bugs. If you notice
any, bug 1522879  is
the right metabug to block.

If you have questions or concerns, please respond to this thread on
dev-platform (to centralize the conversation).

Thanks!

-Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please enable build system telemetry

[Mike Conley]

Yes, thanks!

Out of curiosity, is there a dashboard somewhere where we can see
aggregates of the current measurements?

Thanks for your work,

-Mike

On Fri, Nov 9, 2018, 3:22 PM Doug Thayer  Hooray for data! This is great. Thank you!
>
> On Fri, Nov 9, 2018 at 11:55 AM Ted Mielczarek  wrote:
>
> > TL;DR: the next time you run `mach bootstrap` please answer yes to the
> > prompt to enable build system telemetry.
> >
> > Hello,
> >
> > Those of us who work on the build system realize that building Firefox is
> > not always a pleasant experience. We've done a lot of work over the years
> > to try to improve that situation but we have always relied on anecdotes
> > from individual developers to know when a problem exists and when things
> > have improved. Recently we've finished landing some work[1] to enable the
> > build system to submit telemetry and we're excited to start getting data
> > that we can use to prioritize future work and validate our results! The
> > schema of data we're collecting is available in the build system
> > documentation[2]. Additionally we care very much about your privacy and
> the
> > security of this data--build system telemetry data gets handled and
> stored
> > in the same systems that handle Firefox telemetry data.
> >
> > We've added a prompt to `mach bootstrap` that will let you opt-in to
> > enabling telemetry so we'd appreciate it if you would do that so we can
> get
> > a broad representative sample of the population of developers building
> > Firefox. If you'd rather enable it manually you can edit the file
> > ~/.mozbuild/machrc and add the contents:
> >
> > [build]
> > telemetry = true
> >
> > If you have any questions about this please feel free to ask here or in
> > #build on IRC.
> >
> > Regards,
> > -Ted
> >
> > 1. https://bugzilla.mozilla.org/show_bug.cgi?id=1237610
> > 2.
> > https://firefox-source-docs.mozilla.org/build/buildsystem/telemetry.html
> > ___
> > 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: A tool to put Phabricator and Bugzilla count into your browser toolbar

[Mike Conley]

>
> So if you've ever wanted your review queue to haunt you while you surf
> the web, you can have that now.
>

I wrote that mostly in jest, but burnout, overwork / workaholism are a real
thing, and I don't want to contribute to it.

I filed https://github.com/mikeconley/myqonly/issues/3 to add a "working
hours" feature so that you can disable the count outside of those hours.

-Mike

On Wed, 17 Oct 2018 at 10:09, Mike Conley  wrote:

> Hi folks,
>
> I wrote a WebExtension to put your total review count (Phabricator +
> Bugzilla) into your browser UI.
>
> So if you've ever wanted your review queue to haunt you while you surf
> the web, you can have that now.
>
> Here it is: https://addons.mozilla.org/en-US/firefox/addon/myqonly/
>
> The WebExtension uses good ol' page scraping to pull your Phabricator
> review count, and only works if you've got a live Phabricator session
> cookie. For Bugzilla, you need to supply an API token and put it in the
> add-on config in about:addons.
>
> Source: https://github.com/mikeconley/myqonly
>
> Issues, feature requests, pull requests and punnier names welcome.
>
> -Mike
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: A tool to put Phabricator and Bugzilla count into your browser toolbar

[Mike Conley]

I'm all for it. Tracking in this issue:
https://github.com/mikeconley/myqonly/issues/5

On 2018-10-17 12:38 p.m., Nicholas Alexander wrote:
> Mike,
> 
> On Wed, Oct 17, 2018 at 7:09 AM Mike Conley  <mailto:mcon...@mozilla.com>> wrote:
> 
> Hi folks,
> 
> I wrote a WebExtension to put your total review count (Phabricator +
> Bugzilla) into your browser UI.
> 
> So if you've ever wanted your review queue to haunt you while you surf
> the web, you can have that now.
> 
> Here it is: https://addons.mozilla.org/en-US/firefox/addon/myqonly/
> 
> The WebExtension uses good ol' page scraping to pull your Phabricator
> review count, and only works if you've got a live Phabricator session
> cookie. For Bugzilla, you need to supply an API token and put it in the
> add-on config in about:addons.
> 
> Source: https://github.com/mikeconley/myqonly
> 
> Issues, feature requests, pull requests and punnier names welcome.
> 
> 
> I haven't tried this and all I can say is THANK YOU THANK YOU THANK YOU.
> 
> Now, how do we add GH reviews as well?  It's ridiculous that my daily
> flow includes three systems with no plan (that I am aware of) to
> integrate them or even provide a dashboard, but here we are.
> 
> Nick



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

A tool to put Phabricator and Bugzilla count into your browser toolbar

[Mike Conley]

Hi folks,

I wrote a WebExtension to put your total review count (Phabricator +
Bugzilla) into your browser UI.

So if you've ever wanted your review queue to haunt you while you surf
the web, you can have that now.

Here it is: https://addons.mozilla.org/en-US/firefox/addon/myqonly/

The WebExtension uses good ol' page scraping to pull your Phabricator
review count, and only works if you've got a live Phabricator session
cookie. For Bugzilla, you need to supply an API token and put it in the
add-on config in about:addons.

Source: https://github.com/mikeconley/myqonly

Issues, feature requests, pull requests and punnier names welcome.

-Mike



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: nsISimpleEnumerator now works as a JS iterator

[Mike Conley]

Wow, this is a great improvement! Thank you!

On Thu, Aug 23, 2018, 6:26 PM Kris Maglione  wrote:

> Oh, and from C++, there's also now a range iterator wrapper with
> similar semantics:
>
>   for (auto& docShell : SimpleEnumerator(docShellEnum)) {
> ...
>   }
>
> On Thu, Aug 23, 2018 at 03:19:55PM -0700, Kris Maglione wrote:
> >As of bug 1484496, any C++-implemented nsISimpleEnumertor instance can
> >be used as a JS iterator. And, when used this way, the iterators now
> >have intrinsic type information, and therefore do not require QIing
> >their elements.
> >
> >Which is to say, now you can simply do:
> >
> > for (let window of Services.wm.getEnumerator("navigator:browser")) {
> >   ...;
> > }
> >
> > for (let docShell of docShellEnum) {
> >   ...;
> > }
> >
> >rather than:
> >
> > let winEnum = Services.wm.getEnumerator("navigator:browser");
> > while (winEnum.hasMoreElements()) {
> >   let window = winEnum.getNext();
> >   ...
> > }
> >
> > while (docShellEnum.hasMoreElements()) {
> >   let docShell = winEnum.getNext().QueryInterface(Ci.nsIDocShell);
> >   ...
> > }
> >
> >If you happen to be using an nsIArray from directly from JavaScript,
> >you unfortunately still need to specify the expected types, since
> >nsIArray has no idea what types it can contain:
> >
> > for (let thing of array.enumerate(Ci.nsIThing)) {
> >   ...
> > }
> >
> >Aside from being easier to maintain, these forms should also be
> >somewhat faster than the old protocol, since they only require one
> >XPConnect call per iteration rather than 3(+).
> >
> >-Kris
>
> --
> Kris Maglione
> Senior Firefox Add-ons Engineer
> Mozilla Corporation
>
> There is no greater mistake than the hasty conclusion that opinions
> are worthless because they are badly argued.
> --Thomas Huxley
>
> ___
> 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: CPOWs are now almost completely disabled

[Mike Conley]

This is great news! Thanks to everybody involved!

On Thu, 28 Jun 2018 at 09:16, Alex Gaynor  wrote:

> Outstanding! I love a good IPC attack surface reduction!
>
> Alex
>
> On Wed, Jun 27, 2018 at 6:54 PM Tom Schuster  wrote:
>
> > Since landing bug 1465911 [1], CPOWs [2] are only functional on our
> testing
> > infrastructure. In normal builds that we ship to users CPOWs can be
> > created, but no operations like property lookup can be performed on them.
> >
> > CPOWs continue to exist, because a lot of tests still depend on them. We
> > can't disable CPOW creation in user builds, because the context menu
> passes
> > them from the child to the parent and back like a token.
> >
> > This is a significant IPC attack surface reduction.
> >
> > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1465911
> > [2]
> >
> >
> https://developer.mozilla.org/en-US/Firefox/Multiprocess_Firefox/Cross_Process_Object_Wrappers
> > ___
> > 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: Intent to move Activity Stream into its own process

[Mike Conley]

Hi Alex,

Yes, I expect this to plug into the same process handling infrastructure
that we already have for now. I also expect that we'll find some room for
optimization while we're stomping around in this area.

-Mike

On Tue, 19 Jun 2018 at 09:13, Alex Gaynor  wrote:

> Do you have a sense of how this is going to be implemented? Is there going
> to be specialized code for this, or is it going to be handled by all the
> general navigation changes for process-switching when you change sites?
>
> Alex
>
> On Mon, Jun 18, 2018 at 5:02 PM Mike Conley  wrote:
>
>> >
>> > I am not sure about the specific AS work here, but for the general
>> case, I
>> > believe that Fission intends to cause a process switch anytime a tab
>> > navigates to an unrelated origin, so this will also increase the
>> frequency
>> > of process switching.
>> >
>>
>> Yep, this matches my understanding: we're going to be process flipping a
>> lot as we move from Activity Stream -> Web Page, and also as we move from
>> Web Page at Origin A to Web Page at Origin B. Our process flipping code is
>> going to get exercised pretty hard, so we'll certainly want to surface and
>> fix any serious problems there.
>>
>> If you have process-flipping bugs in mind that you think are particularly
>> bad, I recommend getting them into the bug 1451850 tree somehow. I'll
>> happily look over bugs with you (Gijs) if you have a list.
>>
>> -Mike
>>
>> On Mon, 18 Jun 2018 at 16:31, J. Ryan Stinnett  wrote:
>>
>> > On Mon, Jun 18, 2018 at 3:20 PM Gijs Kruitbosch <
>> gijskruitbo...@gmail.com>
>> > wrote:
>> >
>> > > If it *would* mean a process switch, we may want to take another look
>> at
>> > > some of the bugs relating to those (process switches are currently
>> > > relatively rare) and re-prioritize them.
>> > >
>> >
>> > I am not sure about the specific AS work here, but for the general
>> case, I
>> > believe that Fission intends to cause a process switch anytime a tab
>> > navigates to an unrelated origin, so this will also increase the
>> frequency
>> > of process switching.
>> >
>> > So, it would seem that any issues around process switching would be
>> good to
>> > triage again, either because of the AS work or the more general Fission
>> > plans.
>> >
>> > - Ryan
>> > ___
>> > 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: Intent to move Activity Stream into its own process

[Mike Conley]

>
> I am not sure about the specific AS work here, but for the general case, I
> believe that Fission intends to cause a process switch anytime a tab
> navigates to an unrelated origin, so this will also increase the frequency
> of process switching.
>

Yep, this matches my understanding: we're going to be process flipping a
lot as we move from Activity Stream -> Web Page, and also as we move from
Web Page at Origin A to Web Page at Origin B. Our process flipping code is
going to get exercised pretty hard, so we'll certainly want to surface and
fix any serious problems there.

If you have process-flipping bugs in mind that you think are particularly
bad, I recommend getting them into the bug 1451850 tree somehow. I'll
happily look over bugs with you (Gijs) if you have a list.

-Mike

On Mon, 18 Jun 2018 at 16:31, J. Ryan Stinnett  wrote:

> On Mon, Jun 18, 2018 at 3:20 PM Gijs Kruitbosch 
> wrote:
>
> > If it *would* mean a process switch, we may want to take another look at
> > some of the bugs relating to those (process switches are currently
> > relatively rare) and re-prioritize them.
> >
>
> I am not sure about the specific AS work here, but for the general case, I
> believe that Fission intends to cause a process switch anytime a tab
> navigates to an unrelated origin, so this will also increase the frequency
> of process switching.
>
> So, it would seem that any issues around process switching would be good to
> triage again, either because of the AS work or the more general Fission
> plans.
>
> - Ryan
> ___
> 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

Intent to move Activity Stream into its own process

[Mike Conley]

(posted on both dev-platform and firefox-dev. Please send replies to
dev-platform)

Hello all,

Just sending a quick note to let you know that I've filed bug 1469072[1] to
move Activity Stream into its own content process.

This is something that Fission needs, but we're hoping to squeeze some
performance benefits out of it as well by reducing, reusing and recycling
various Activity Stream things since they'll all be contained within a
single process. It might also allow us to cache more Activity Stream
scripts in ScriptPreloader[2], since we can reasonably assume only trusted
JavaScript will be running within the Activity Stream content process.

This work is going to be handled by my intern, Jay Lim. If you have any
concerns with this plan, please bring them to my attention - commenting in
the bug, emailing me, or responding to this thread on dev-platform is fine.

Thanks!

-Mike

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1469072
[2]: I wrote about ScriptPreloader on my blog here:
https://mikeconley.ca/blog/2018/05/30/firefox-performance-update-9/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Hey! Can you please briefly try this test build...

[Mike Conley]

Solid tip from Xidorn. For the lazy, that command is:

./mach mozregression --launch b5a512aaef49 --repo try

On 2018-04-20 9:53 AM, Xidorn Quan wrote:
> FWIW, I always find that the easiest way to run some build is using 
> mozregression's "Run a single build", which would take care of downloading, 
> unpacking, and creating a new profile for it.
> 
> In this case, you'd want to choose "try" and input changeset "b5a512aaef49".
> 
> - Xidorn
> 
> On Fri, Apr 20, 2018, at 6:12 PM, Carl Corcoran wrote:
>>  Hello everyone! I need some help gathering some real-world data about DLLs
>> that get loaded into Firefox on Windows (re bug 1435827). I have created a
>> test build that outputs runtime DLL information to a text file on disk, and
>> I'd like to see what results you get on your machine(s).
>>
>> If you have already helped me with this, no need to do it again.
>>
>> So when you have a moment, can you please:
>>
>>1. Make sure you have a c:\temp directory
>>2. Download target.zip from either of the links below, extract, & run
>>firefox.exe
>>   - for 64-bit, https://treeherder.mozilla.org/logviewer.html#?job_id=
>>   174270831=try
>>   - for 32-bit, https://treeherder.mozilla.org/logviewer.html#?job_id=
>>   174270829=try
>>3. Run it at least for a while. The idea is to get a profile of DLLs
>>that are loaded into the process.
>>4. Find the results at c:\temp\ffmodules.txt, and email them to me at
>>ccorco...@mozilla.com
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
> 



signature.asc
Description: OpenPGP digital signature
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: CPU core count game!

[Mike Conley]

Thanks for drawing attention to this, sfink.

This is likely to become more important as we continue to scale up our
parallelization with content processes and threads.

On 21 March 2018 at 14:54, Steve Fink  wrote:

> Just to drive home a point, let's play a game.
>
> First, guesstimate what percentage of our users have systems with 2 or
> fewer cores.
>
> Then visit https://hardware.metrics.mozilla.com/#goto-cpu-and-memory to
> check your guess.
>
> (I didn't say it was a *fun* game.)
>
>
> ___
> 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: new code to help with cross-process windows/workers (and Clients API)

[Mike Conley]

This all sounds great!

>> I personally think this would be useful, and will (probably) only happen if
>> you do it now, before you move on to the next thing.  +1 for documentation!

I concur.

___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: --verify option added to mochitest, reftest, xpcshell test harnesses

[Mike Conley]

This is super cool! Thanks Geoffrey!

On 2017-10-02 1:08 PM, Geoffrey Brown wrote:
> The mochitest, reftest, and xpcshell test harnesses now support a
> --verify option. For example:
> 
>   mach mochitest
> docshell/test/test_anchor_scroll_after_document_open.html --verify
> 
> In verify mode, the requested test is run multiple times, in various
> "modes", in hopes of quickly finding any intermittent failures. Once
> tests are complete, a summary of results is printed:
> 
> :::
> ::: Test verification summary for:
> :::
> ::: docshell/test/test_anchor_scroll_after_document_open.html
> :::
> ::: 1. Run each test 10 times in one browser. : Pass
> ::: 2. Run each test 5 times in a new browser each time. : Pass
> ::: 3. Run each test 10 times in one browser, in chaos mode. : Pass
> ::: 4. Run each test 5 times in a new browser each time, in chaos mode. : Pass
> :::
> ::: Test verification PASSED
> :::
> 
> There's no flexibility in the number of times the test is run in each
> mode and that's by design: I wanted a simple, standard way of checking
> "Is this test likely to produce a frequent intermittent failure"?
> 
> Verify mode was developed for the test-verify task (announcement
> coming soon!) but it may also be a convenient addition to your local
> testing.
> 
> More info at [1]. Bug and enhancement requests welcomed: please file
> bugs blocking bug 1357513.
> 
> [1] https://developer.mozilla.org/en-US/docs/Test_Verification
> ___
> 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: Quantum Flow Engineering Newsletter #25

[Mike Conley]

d foundation that we have built so far, and
>> continually
>> monitor and measure the performance of the various aspects of the browser
>> to make sure regressions are caught and fixed in time, and new
>> features are
>> developed with performance in mind from early on.   And to do so, we need
>> to continue our investment in the tooling around performance, perfherder
>> <https://treeherder.mozilla.org/perf.html>, AWFY
>> <https://arewefastyet.com/>,
>> Profiler <https://perf-html.io/>,  arewesmoothyet
>> <https://arewesmoothyet.com/>, and perhaps more tools in the future.
>>
>> Continuing the QF project into the future is an area of active
>> planning.  I
>> expect more details about the next steps for this project will be
>> shared as
>> the plans continue to shape up.
>> On QF Newsletters
>>
>> The idea of starting to write an ongoing newsletter about the Quantum
>> Flow
>> project was first suggested to me by Bill McCloskey.  Our first goal
>> was to
>> find a way to increase the visibility into what the QF project is, and
>> highlight people's contributions to the effort, because we felt like
>> due to
>> the speed at which the project was spun up and the vast scope of the
>> project, it may be difficult for a lot of people to understand in detail
>> what actually happens under the hood.
>>
>> Over time, I tried to shed light into the most important aspects of the
>> work that happened in the project, and document the history of the
>> technical work that happened throughout the past seven months or so.  At
>> its lowest level, Quantum Flow consisted of many performance bug fixes
>> all
>> over the place.  I think it was important to highlight that fact, but
>> also
>> explain to some extent how and why some classes of bugs were investigated
>> in-depth.  But it's also possible to not see the forest when looking
>> at the
>> trees, so at times I also tried to highlight some of the ongoing higher
>> level efforts in addition to listing the individual fixes landing each
>> week.
>>
>> Another super important goal of mine was to give credit where it's due.
>> What we have accomplished for Quantum Flow (and Firefox 57) so far
>> couldn't
>> have been accomplished without the help of many wonderful people in the
>> community.  I often think that we need to take more opportunities to
>> thank
>> people for the hard work that they are doing, and I took these
>> newsletters
>> as my opportunity to do just that!
>>
>> Also, I have always wanted to read newsletters like this myself about
>> what
>> happens in projects and teams that I'm not actively involved in myself.
>> I'm extremely happy that there are now a
>> <https://wiki.mozilla.org/SecurityEngineering/Newsletter> number
>> <https://mozillagfx.wordpress.com/category/wr-newsletter/> of
>> <https://mozilla.github.io/firefox-browser-architecture/posts/2017-08-24-browser-architecture-newsletter-2.html>
>>
>> newsletters <https://dolske.wordpress.com/category/photonupdate/> that
>> people have started writing recently, and I look forward to seeing even
>> more of them!  Writing about what we work on is important, it helps share
>> knowledge across Mozilla and keeps people informed and engaged.  I urge
>> more people to write about what they do, and I'll try to continue to
>> do so
>> myself.
>>
>> Before closing, it is time to give credits where it's due one last
>> time in
>> these series.  Firstly, I would like to thank Jan de Mooij, Mike Conley,
>> and Florian Quèze who helped me with collecting the credits section at
>> the
>> end of the newsletters in the past few months!  Also, I would like to
>> extend to thank the following people who helped land the last performance
>> improvements for Firefox 57:
>>
>>   - Andrew McCreight enabled the single-compartment for all JSMs
>>   <https://bugzilla.mozilla.org/show_bug.cgi?id=1381961>! This reduces
>> the
>>   memory overhead
>>   <https://treeherder.mozilla.org/perf.html#/alerts?id=9496> incurred by
>>   each JSM, and also side-step the “compartment crossing” performance
>> penalty
>>   when JSMs access objects in one another. Here’s our ts_paint
>> performance
>>   test (time to first window paint in ms) - that fall off around
>> September 16
>>   was caused by this work!
>>   [image: ts_paint graph around Sep 16 for Windows32/64, Linux64 and Mac]
>>  
>> <http://ehsanakhgari.org/wp-content/uploads/2017/09/Screenshot-from-2017-09-21-15-37-21.png>
>>
>>   - Jim Chen enabled the single-compartment JSMs for Android
>>   <https://bugzilla.mozilla.org/show_bug.cgi?id=1400886>!  This brought
>>   some nice speed
>>   <https://treeherder.mozilla.org/perf.html#/alerts?id=9542> and memory
>>   usage <https://treeherder.mozilla.org/perf.html#/alerts?id=9586>
>> wins on
>>   Android like desktop above.
>>   - Olli Pettay fixed a recent regression
>>   <https://bugzilla.mozilla.org/show_bug.cgi?id=1398605> from one of my
>>   patches <https://bugzilla.mozilla.org/show_bug.cgi?id=1392891> which
>> was
>>   caused by creating nsContentList objects too eagerly.
>>
>>
>>
>> Cheers,
>> -- 
>> Ehsan
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

TabChild visibility

[Mike Conley]

Hello dev-platform,

TL;DR: TabChild's don't seem to care about the nsIBaseWindow visibility
attribute that they implement. In fact, they often lie about it.

What should we do about that? What's the best way to detect and tell the
TabChild that it's visible or invisible?

Also, what's the difference between DocShell visibility and activeness?


Longer story:

In bug 1353013, I'm dealing with a permanent failure that I've tracked down
to Marionette's listener.js causing focus to be pulled in the hidden,
preloaded about:newtab that is running in the content process.

With e10s disabled, nsGlobalWindow::Focus bails out early, because the
function checks its visibility (via the nsIBaseWindow interface), and
determines that it is invisible (because of this function[1] that sees if
the frame is in the selected frame of a deck).

With e10s enabled, visibility seems to be a lot less useful - TabChild
implements nsIBaseWindow, and ignores attempts to set visibility[2] and
always reports that it is visible[3]. This means that nsGlobalWindow::Focus
decides that focus is indeed something that the preloaded about:newtab can
do, and that causes my test failures.

It seems to me that a TabChild always reporting that it's visible isn't
amazing. For a browser window with a number of tabs open, it's the case
that only one of those tabs really is visible, naturally; so the rest of
those TabChild's are straight-up lying. I have no idea what the
ramifications of that lying are. Perhaps we're doing more work than we need
to because we're skipping some "don't do it if we're invisible"
optimizations. I'm not sure.

At any rate, it seems to me that the solution to my problem is to have the
TabChild report the truth about whether or not it's visible. Using a sync
IPC message to ask the parent is asking for trouble, so instead, I suspect
we'll want the TabChild to be _told_ when it's made visible and invisible.

What is the best way of doing that? Is there a clean way of having the
nsFrameLoader / TabParent be told when they've been set as the active frame
in a deck or not? Or is this something that the front-end needs to take
responsibility for (like we do for DocShell active-ness) and we need to
have tabbrowser.xml tell the TabChild that it has become visible?

Or, alternatively, should I tie the activeness of the TabChild's DocShell
to its visibility? That would be a change in behaviour between e10s and
non-e10s; in non-e10s, it appears to be possible to have a non-visible but
active DocShell (despite the documentation [4]). Perhaps somebody here can
shed some light on the relationship (or lack thereof) between active-ness
and visibility?

Thanks,

-Mike

[1]:
http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a4131452459241010701e0/layout/generic/nsFrame.cpp#405-409
[2]:
http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a4131452459241010701e0/dom/ipc/TabChild.cpp#936-942
[3]:
http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a4131452459241010701e0/dom/ipc/TabChild.cpp#929-934
[4]:
http://searchfox.org/mozilla-central/rev/d08b24e613cac8c9c5a4131452459241010701e0/docshell/base/nsIDocShell.idl#659-664
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal: Unified Bootstrap Stages for Gecko

[Mike Conley]

Hey gandalf,

Using WICG for browser start-up makes sense to me.

We should also consider adding a milestone for the "hero element" for
the browser. There's some discussion fragments in bug 1369417 about this
(which I see you're already involved in! Great!), captured from a very
caffeinated discussion with jmaher, florian and a few other folks in SF
this past all-hands.

At any rate, this all sounds strictly better than what ts_paint
currently captures. We just need to ensure that we measure paint times
when they're presented to the user (so after composite), and using the
timestamps on the MozAfterPaint events themselves[1] (and not taking a
timestamp at the event-servicing time, as this adds noise and padding to
the timestamp).

So, uh, thumbs up from me. :)

-Mike

[1]:
http://searchfox.org/mozilla-central/rev/f2a1911ad310bf8651f342d719e4f4ca0a7b9bfb/dom/webidl/NotifyPaintEvent.webidl#36

On 2017-08-31 6:51 PM, zbranie...@mozilla.com wrote:
> Gecko has a pretty substantial number of metrics used for measuring startup 
> performance.
> 
> We have probes in Telemetry [0], StartupTimeline [1], various uses of 
> MozAfterPaint, both in talos tests [2] and in production code [3][4].
> We also have first paint in compositor [5], before-first-paint [6], 
> timeToNonBlankPaint [7] which should not be confused with firstNonBlankPaint 
> [8] and probably a number of other probes that register different timestamps 
> and are used all around to mean different things. Some measure layout, others 
> composition. Many of them are misused by capturing the timestamp in the 
> callback to event listener fired asynchronously post-event.
> We end up seeing huge swings in some "first-paint" [9] that are not 
> reproducible in another "first-paint" [10], and we know that things like 
> WebRender may not affect some of our "first-paint" because it measures only 
> part of paint that WebRender doesn't affect[11].
> 
> It doesn't help that some of them are chrome-only while others are available 
> in content.
> 
> I believe that, while we can recognize the complexity of the systems in play 
> and how this complexity explains why different probes ended up being 
> constituted, this situation is counter productive to our ability to 
> understand the performance implication of our changes in product.
> 
> I'd like to suggest establishing a single set of timestamps with unique names 
> to represent various stages of the product launch.
> Those timestamps would be described based on the user-perceived results and 
> as such serve us as best-effort approximations of the impact of any change on 
> the user-perceived experience.
> 
> In particular, my proposal is based on WICG Paint Timing proposal [12] and 
> establishes the 5 major timestamps to be executed at the latest event that 
> contributes to the user-perceived outcome.
> For example, when selecting when to mark "xPaint" event, we will use the 
> consumer notion of the term "paint" and mark it after *all* operations 
> required for the paint to happen are done - layout, composition, rendering 
> and paint.
> 
> My proposal is also based on the work on negotiated performance milestones 
> established for Firefox OS project [13].
> 
> The proposed milestones are:
> 
> 1) firstPaint
> 
> This milestone happens when the first paint that is influenced by the data 
> for the measured object is completed by the engine (and likely submitted to 
> the graphic driver).
> 
> In the context of an HTML document, the first paint that is affected by the 
> document's background or title is completed.
> 
> 2) firstContentfulPaint
> 
> The first contentful paint of browser.xul happens when the first paint that 
> includes layout of DOM data from browser.xul is completed.
> 
> 3) visuallyCompletedPaint
> 
> This milestones is achieved after the first paint with the above-the-fold 
> part of the DOM ready is submitted. This event may require the document to 
> inform the engine that all the items in the visual field are ready, and the 
> next paint captures the timestamp.
> 
> 4) chromeInteractive
> 
> This milestone is achieved when the app reports the UI to be ready to be 
> interacted with. The definition of what constitutes of the UI being ready is 
> up to the app, and may just include the URL bar being ready to receive URL 
> input, or may wait for all core parts of the product to have event handlers 
> attached (urlbar, tabbar, main menu etc.)
> This milestone may be reached before (3), but not after (5).
> 
> 5) fullyLoaded
> 
> This milestone also may require data from the document and it should mark the 
> timestamp when all startup operations are completed.
> This should include delayed startup operations that may have waited for 
> previous stages to be achieved, but should not wait for non-startup delayed 
> operations like periodic updates of data from AMO etc.
> 
> The last milestone is a good moment to reliably measure memory consumption 
> (possibly after performing GC), take a 

Photon Engineering Newsletter #14

[Mike Conley]

(via https://mikeconley.ca/blog/2017/08/24/photon-engineering-newsletter-14/
- I suggest visiting that post directly if you want to see the animated
GIFs inline)

Just like jaws did last week
,
I'm taking over for dolske

this week to talk about stuff going on with Photon Engineering. So sit
back, strap in, and absorb Photon Engineering Newsletter #14
!

If you've got the release calendar
 at hand, you'll note that
Nightly 57 merges to Beta on September 20th. Given that there's usually a
soft-freeze before the merge, this means that there are *less than 4 weeks
remaining* for Photon development. That's right - in less than a month's
time, folks on the Beta channel who might not be following Nightly
development are going to get their first Photon experience. That'll be
pretty exciting!

So with the clock winding down, the Photon team has started to shift more
towards polish and bug-fixing. At this point, all of the major changes
should have landed, and now we need to buff the code to a sparkling sheen.

The first thing you may have noticed is that, after a solid run of dogefox
,
the icon has shifted again:
[image: The new Nightly icon]

The second big change are our new 60fps loading throbbers in the tabs,
coming straight to you from the Photon Animations team!
Here's an animated GIF!

Other recent changesMenus and structure

   - A “Bookmarking Tools” subview
    has been added to
   the Library button so you can easily get to the bookmarks toolbar, sidebar,
   and bookmarks menu button
  - Here's an animated GIF!
  

  - You might have noticed that the downloads button will only appear
   when downloads exist
    and isn't movable
   anymore. This is something we're still tinkering with, so stay tuned.
   - We made the sync animation prettier
   ! Check it out
   !

Animations

   - Did we mention the new tab loading throbber?

Preferences

   - All MVP work is completed! The team is now fixing polish bugs.
   Outstanding!

Visual redesign

   - The styles for the sidebar have been updated on WIndows
   !
  - [image: The bookmarks sidebar]
  - New icons have landed
    for a number of
    Firefox functions
   . Can you find
   them all?
   - The team also landed a slew of polish and bug fixes. Here's the full
   list
   

   !

Onboarding

   - The Firefox 57 tours have been enabled
   !
   - The PageAction UITour highlight style has been updated
    to be more
   consistent with the rest of Photon
  - [image: The PageAction menu in the URL bar opened with a single
  item highlighted by the UI Tour]
  - A bunch  of
    polish
    and
    bugfixes
    for
    the onboarding
   tour have landed!

Performance

   - The performance team quickly diagnosed a regression in the
   FX_NEW_WINDOW_MS Telemetry probe
    and the
   regressing patch has been backed out.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Quantum Flow Engineering Newsletter #18

[Mike Conley]

>
> Mike Conley ported scrollbox to use smooth scrolling instead of JS driven
> scrolling <https://bugzilla.mozilla.org/show_bug.cgi?id=1356705>.  This
> affects most importantly scrolling the tab bar, and should make it more
> smooth by removing a lot of slow code that used to run and off-loading that
> work to the compositor through CSS-based smooth scrolling!  He notes
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1356705#c67> on the bug
> that in order to achieve great performance some follow-ups may be needed.


Just to ensure credit is given where it's due - that was 95% Dão Gottwald's
work. I just helped push the last 5% over the line when he got focused on
getting square tabs landed. Thanks Dão!

On 4 August 2017 at 04:04, Ehsan Akhgari <ehsan.akhg...@gmail.com> wrote:

> Hi everyone,
>
> This has been a busy week.  A lot of fixes have landed, setting up the
> Firefox 57 cycle for a good start.  On the platform side, a notable change
> that will be in the upcoming Nightly is the fix for document.cookie using
> synchronous IPC.  This super popular API call slows down various web pages
> today in Firefox, and starting from tomorrow, the affected pages should
> experience a great speedup.  I have sometimes seen the slowdown caused by
> this one issue to amount to a second or more in some situations, thanks a
> lot to Amy and Josh for their hard work on this feature.  The readers of
> these newsletters know that the work on fixing this issue has gone on for a
> long time, and it's great to see it land early in the cycle.
>
> On the front-end side, more and more of the UI changes of Photon are
> landing in Nightly.  One of the overall changes that I have seen is that
> the interface is starting to feel a lot more responsive and snappy than it
> was around this time last year.  This is due to many different details.  A
> lot of work has gone into fixing rough edges in the performance of the
> existing code, some of which I have covered but most of which is under the 
> Photon
> Performance project <https://bugzilla.mozilla.org/show_bug.cgi?id=1363750>.
> Also the new UI is built with performance in mind, so for example where
> animations are used, they use the compositor and don't run on the main
> thread.  All of the pieces of this performance puzzle are nicely coming to
> fit in together, and it is great to see that this hard work is paying off.
>
> On the Speedometer front, things are progressing with fast pace.  We have
> been fixing issues that have been on our list from the previous findings,
> which has somewhat slowed down the pace of finding new issues to work on.
> Although the SpiderMonkey team haven't waited around
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1245279> and are
> continually finding new optimization opportunities out of further
> investigations.  There is still more work to be done there!
>
> I will now move own to acknowledge the great work of all of those who
> helped make Firefox faster last week.  I hope I am not mistakenly
> forgetting any names here!
>
>- Andrew McCreight got rid of some cycle collector overhead
><https://bugzilla.mozilla.org/show_bug.cgi?id=1385459> related to
>using QueryInterface to canonicalize the nsISupports pointers stored in the
>purple buffer, and similarly for pointers encountered during traversal
>of native roots <https://bugzilla.mozilla.org/show_bug.cgi?id=1385474>
>as well.
>- Kris Maglione added some utilities to BrowserUtils
><https://bugzilla.mozilla.org/show_bug.cgi?id=1383367> that should
>help our front-end devs avoid synchronous layout and style flushes.
>- Amy Chung got rid of the sync IPC messages in the cookie service
><https://bugzilla.mozilla.org/show_bug.cgi?id=1331680>! This was a
>substantial amount of work and should eliminate jank on a number of sites
>that get and set cookies frequently.
>- Jessica Jong made us check a boolean flag instead of doing a linear
>search looking for an attribute in order to determine whether an Element is
>required <https://bugzilla.mozilla.org/show_bug.cgi?id=1385478>.
>- André Bargull made String.prototype.toLower/UpperCase use direct VM
>calls, and also added specialized unicode::CanLower/UpperCase overloads for
>Latin1 characters
><https://bugzilla.mozilla.org/show_bug.cgi?id=1383647>.  He also added
>an Ion-inline path for Reflect.getPrototypeOf()
><https://bugzilla.mozilla.org/show_bug.cgi?id=1385802>.  Additionally,
>he made it possible to inline UnsafeGetReservedSlot when the object is
>typed as MIRType::Value
><https://bugzilla.mozilla.org/show_bug.cgi?id=1383645>.  Last but not
>

Re: Firefox startup code coverage (ts_paint talos test)

[Mike Conley]

This is great, thanks so much Marco! This will likely be a useful way
for us to find more opportunities to make start-up faster.

Thanks for your work!

On 2017-08-02 10:28 AM, Marco Castelluccio wrote:
> Hello all,
> at https://marco-c.github.io/ts_paint_startup_coverage_report/ you can
> find a (C/C++-only for now) code coverage report of Firefox startup. The
> report was generated using the ts_paint talos test, considering code
> executed until the "MozAfterPaint" event and after a setTimeout(, 0). It
> also contains the number of times a line was executed ("Line data" in
> the source view).
> 
> The report could be useful to identify code that is currently being
> executed at startup but shouldn't.
> 
> The build is a debug build with all optimizations disabled, to have more
> precise line coverage.
> 
> - Marco.
> 
> ___
> 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

The Joy of Profiling

[Mike Conley]

(cross-posted between dev-platform and firefox-dev - please send responses
to the dev-platform list).

TL;DR: New show on AirMo - Joy of Profiling, examining Profiles:
https://air.mozilla.org/search/?q=the+joy+of+profiling . Want your profile
up on the show? Submit it via
https://docs.google.com/a/mozilla.com/forms/d/e/1FAIpQLSePiq1ifvrY6EzDowEdqKdb-tGGm-AvgG86ivU9ipv7FsggKQ/viewform

Hello everybody,

I've started a new show on Air Mozilla called The Joy of Profiling. In this
show, I sit down with some volunteer engineers in Toronto, and we look at
performance profiles, and try to derive actions and meaning from them.

Here are the current set of episodes:
https://air.mozilla.org/search/?q=the+joy+of+profiling

The shows are short - usually less than an hour. They're pre-recorded and
not streamed. I don't do a whole lot of editing - it's pretty raw. I do
them on Friday afternoons, ET.

We take notes and post our findings here:
https://docs.google.com/document/d/1yp7nNXZPLCkPKKYU2I_0G--iiiqUOyaHicqTwSHyi3o/edit#heading=h.3sxnku1m6sjd

You might find this show interesting if Profiles and perf.html are a thing
you deal with.

Additionally, if you have a Profile that you'd like examined, consider
sending it to us to examine with this form:
https://docs.google.com/a/mozilla.com/forms/d/e/1FAIpQLSePiq1ifvrY6EzDowEdqKdb-tGGm-AvgG86ivU9ipv7FsggKQ/viewform

Here's to making Firefox fast and smooth!

-Mike

PS: I'll hopefully find a way of integrating guests over Vidyo soon, so
that I can get folks outside of Toronto to help examine profiles as well.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Gecko Profiler Win64 stability

[Mike Conley]

Tremendous work here. Thank you so much, dmajor!

On 2017-05-18 3:04 PM, David Major wrote:
> Hi,
> 
> The Gecko Profiler used to be notoriously unstable on 64-bit Windows.
> (If you're curious: it's mostly because the unwinding rules for Win64
> require the system libraries to do a lot of synchronization, which our
> stack walker would often call in ways that could deadlock.)
> 
> Ever since the last Quantum Flow work week, I've been working on fixing
> these issues. As of this week's nightlies, all of the hangs that have
> been reported to me are resolved fixed. There might be some rare corner
> cases still remaining, but I'm confident that the most frequent problems
> have been addressed.
> 
> So my ask is: if you've previously been deterred from using the profiler
> on Win64 builds, please give it another try! Flag me on any issues you
> find and/or mark them blocking bug 1366030. I will treat these bugs with
> high priority since I want to keep Quantum activities unblocked.
> 
> Thanks!
> 
> 
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

window.find dialog feature broken in Firefox 53 (a.k.a., Late Intent to Unship: window.find's dialog support)

[Mike Conley]

Hello release-drivers (with dev-platform cc'd),

TL;DR: The non-standard window.find feature[1] has, historically, been
able to open up a dialog for the user to enter more strings to find on
the page[2]. It turns out that the dialog portion of that API has been
broken for all users with e10s enabled since e10s started shipping.
Starting with Firefox 53, we're breaking the dialog portion of the API
for non-e10s users as well. In bug 1348409[3], I have a patch cooking
that will disable the dialog functionality in a more deliberate way.

Longer version:

It appears that either bug 1182569 or bug 1232432 (or both) have broken
the part of the non-standard window.find API that can show a dialog to
the user, and that this breakage is about to go out in Firefox 53.

It also turns out that dialog feature has _never_ been supported with
e10s enabled.

The fact that we're only finding this out now says something about our
test coverage for this feature.

If it's any solace though, our documentation[1] spells it out pretty
clearly that this is a non-standard API, and that support varies widely
across browsers. My own testing indicates that the dialog is not shown
for IE 11, Edge, Safari 10.1, or Chrome 57 (on OS X). I have no idea if
they ever supported it in the past. IE and Edge don't seem to have
window.find support in general.

I have a patch cooking in bug 1348409 that disables the attempt at
opening the dialog. I'll go one of two ways - either returning false
from window.find as soon as we enter the case where we would have opened
a dialog, or just ignoring the dialog request entirely (this is what
Blink / WebKit seem to do, and what I'm leaning towards).

Anyhow, just a heads up. I hope I didn't ruin anybody's day.

-Mike

[1]: https://developer.mozilla.org/en-US/docs/Web/API/Window/find
[2]: http://www.javascripter.net/faq/find_dia.htm has a demo you can try
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1348409
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please write good commit messages before asking for code review

[Mike Conley]

Incidentally, MozReview now allows you to provide feedback on the commit
message in the diffviewer.

On Mar 9, 2017 2:47 PM, "Ehsan Akhgari"  wrote:

> I review a large number of patches on a typical day, and usually I have to
> spend a fair amount of time to just understand what the patch is doing.  As
> the patch author, you can do a lot to help make this easier by *writing
> better commit messages*.  Starting now, I'm going to try out a new practice
> for a while: I'm going to first review the commit message of all patches,
> and if I can't understand what the patch does by reading the commit message
> before reading any of the code, I'll r- and ask for another version of the
> patch.
>
> I thank you in advance for your cooperation by writing great commit
> messages.  Happy hacking!
>
> Cheers,
> --
> Ehsan
> ___
> 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: Project Stockwell - February 2017 update

[Mike Conley]

There's good feedback in here. Are some of these known, jmaher? Are any
intentional choices, or should we just start turning these into bugs to
get fixed?

On 08/02/2017 12:33 AM, Bill McCloskey wrote:
> Hi Joel,
> I spent about an hour tonight trying to debug a test failure, and I'm
> writing this email in frustration at how difficult it is. It seems like the
> process has actually gotten a lot worse over the last few years (although
> it was never good). Here's the situation I ran into:
> 
> A test is failing on try. I want to reproduce it. Assume that running the
> test by itself isn't sufficient. I would like to run whatever set of tests
> actually ran together on the test machine in a single Firefox invocation. I
> don't want any more tests to run than those. I can't figure out any way to
> do that.
> 
> I can pass a directory to |mach mochitest|. But that has a number of
> problems:
> - It also runs every subdirectory recursively inside that directory. Often
> that includes way more tests. I can't figure out any way to stop it from
> doing this. I tried the "--chunk-by-dir" option, but it complains that the
> argument is supposed to be an integer. What is this option for?
> - |mach mochitest| runs all flavor of tests even though I only want one.
> There is the --flavor option to disable that. But I have never figured out
> how to use it correctly. No matter what I do, some irrelevant devtools are
> a11y or plugin tests seem to run instead of what I want.
> - There is a --start-at option that should allow me to start running tests
> near the one that I want. But it never seems to work either. I'm not sure
> if it's confounded by the two problems above, or if it's just completely
> broken.
> 
> We could easily fix this by printing in the tinderbox log the mach command
> that you need to run in order to run the tests for a particular directory
> (and making that discoverable through treeherder).
> 
> I want to emphasize that, from a developer's perspective, this is the
> second most basic thing that I could ask for. (Simply running a test by
> itself is the most basic, and it works fine.) Running tests by directory in
> automation has been a huge improvement, but we're not really earning the
> dividends from it because it's so hard to get the same behavior locally.
> 
> Anyway, sorry about the rant. And sorry to pick on your email. But it's
> frustrating to see all these advanced ideas being proposed when we can't
> even get basic stuff right.
> 
> As an aside, I would also like to complain about the decision to strip a
> lot of the useful information out of test logs. I understand this was done
> to make the tests faster, and I can "just" check in a patch to add
> "SimpleTest.requestCompleteLog()" to the intermittent test. But why didn't
> we instead figure out why logging was so slow and fix that? Fundamentally,
> it doesn't seem like saving 50MB of log data to S3 should take very long.
> 
> -Bill
> 
> On Tue, Feb 7, 2017 at 9:40 AM,  wrote:
> 
>> This is the second update of project stockwell (first update:
>> https://goo.gl/1X31t8).
>>
>> This month we will be recommending and asking that intermittent failures
>> that occur >=30 times/week be resolved within 2 weeks of triaging them.
>>
>> Yesterday we had these stats:
>> Orange Factor: 10.75 (https://goo.gl/qvFbeB)
>> count(high_frequency_bugs): 61
>>
>> Last month we had these stats:
>> Orange Factor: 13.76 (https://goo.gl/o5XOof)
>> count(high_frequency_bugs): 42
>>
>> For more details of the bugs and what we are working on, you can read more
>> on this recent blog post:
>> https://elvis314.wordpress.com/2017/02/07/project-stockwell-february-2017/
>>
>> Thanks for helping out with intermittent test failures when we ping you
>> about them!
>> ___
>> 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: Content process launch time distribution

[Mike Conley]

> Also, is there a way to get numbers for the
>> time from process launch to the point when we start loading the first URL

I think there is. There's this "startup timeline" stuff that we record
timestamps for:
http://searchfox.org/mozilla-central/rev/848c29538ab007fb95dc6cff194f0e3d3809613d/toolkit/components/startup/StartupTimeline.h#6-21

one of those things is firstLoadURI, and I think that's what you want
here. It's recorded here:

http://searchfox.org/mozilla-central/rev/848c29538ab007fb95dc6cff194f0e3d3809613d/docshell/base/nsDocShell.cpp#1283-1286

It looks like we do gather this telemetry from the content process:

https://mzl.la/2lgY09x

And I believe the value along the X axis is "roughly number of
milliseconds since process start".

In some cases, it seems that our performance is not amazing on that
measurement either.

Coincidentally, blassey just landed bug 1303096, which gets rid of a
bunch of synchronous messages from content to parent on start-up. We
might see a shift in those numbers as that change rolls out on Nightly.

-Mike

On 07/02/2017 12:57 PM, Gabor Krizsanits wrote:
> Thanks a lot for these numbers! Also, is there a way to get numbers for the
> time from process launch to the point when we start loading the first URL
> in the new content process? We run a lot of frame and process scripts
> sooner than we would get there, and I'm afraid we would get even worse
> numbers that way, and that will affect user experience. (I'm not sure how
> to filter the related telemetry based on "if the new tab is starting up a
> new content process or not")
> 
> For a temporary workaround until we can speed up content process start up
> and initialization time, we might want to use the pre-allocated process
> manager for the e10s-multi case. Maybe even force to pick one from the
> existing processes unless there is one already available.
> 
> Gabor
> 
> On Tue, Feb 7, 2017 at 6:36 PM, Benjamin Smedberg 
> wrote:
> 
>> https://telemetry.mozilla.org/new-pipeline/dist.html#!
>> cumulative=0_date=2017-02-06=__none__!__none__!__
>> none___channel_version=aurora%252F53=CONTENT_
>> PROCESS_LAUNCH_TIME_MS_channel_version=null=
>> Firefox=1_keys=submissions_date=2017-
>> 01-26=0=1_submission_date=0
>>
>> This shows the distribution of times to launch a content process from the
>> time we initially ask for it to the time we get back the first
>> initialization message through IPDL. So this covers actual process launch
>> in the OS, XPCOM startup, and other bootstrap.
>>
>> At first glance, this appears worrying to me: almost 25% of content process
>> startups take more than 1 second, and the median is >700ms. And this is on
>> nightly/aurora, which users typically have faster computers.
>>
>> There's a lot of potential noise here: we don't know what else is going on
>> on the computer (maybe it's near boot and there's still a lot of system
>> churn). But this time definitely can have an impact on how quickly Firefox
>> is ready to load pages and therefore the impression that users have of its
>> total speed.
>>
>> Soliciting everyone's opinion, but Harald's in particular: is it important
>> to dive into this in more detail soon (before Firefox 57)?
>>
>> This metric is currently exploratory, and so I need guidance about whether
>> it's important to keep this metric around for e.g. a release-health
>> dashboard or to prevent regressions.
>>
>> --BDS
>> ___
>> 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: Intent to disable service workers and push in 52 ESR

[Mike Conley]

> I would expect not, though, since we are
>> still rolling it out to the full population.

I do believe the plan is to enable e10s on 52 ESR, but with the Firefox
50 restrictions (e10s enabled by default, disabled if a11y APIs used,
disabled if non-WebExtension, non-mpc=true add-ons enabled).

That was my most recent reckoning of it, anyhow.

-Mike

On 18/01/2017 11:38 AM, Ben Kelly wrote:
> On Wed, Jan 18, 2017 at 10:58 AM, Dirkjan Ochtman 
> wrote:
> 
>> On Wed, Jan 18, 2017 at 4:49 PM, Ben Kelly  wrote:
>>> While things have stabilized since then we are in process of making a
>> major
>>> architectural change in order to support multiple content processes
>>> (multi-e10s).  This will make it very difficult to uplift fixes.  Once
>> the
>>> new architecture has stabilized we should be able to enable SW in the
>> next
>>> ESR.
>>>
>>> Thoughts?
>>
>> Maybe I'm missing context, but I find the notion of not-shipping
>> things on ESR that are available on the normal release channel pretty
>> strange. Maybe this is because I'm incorrectly assuming that the
>> majority of Firefox usage in the wild is not on ESR? Alternatively, is
>> Service Workers the only thing getting major architectural changes for
>> multi-e10s? (I would assume not.) If not, are we withholding all those
>> other things from the ESR channel, too?
>>
> 
> Last I checked we do this all the time for new and potentially unstable
> things.  For example, AFAIK we do not enable e10s on ESR.  I have not heard
> if that will change for 52 ESR.  I would expect not, though, since we are
> still rolling it out to the full population.
> 
> I just don't think we can commit to providing stable security uplifts to
> ESR for a 9 months if our trunk version is completely different.
> 
> Ben
> ___
> 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: PSA: The return type of IPDL Recv* methods changed from bool to mozilla::ipc::IPCResult

[Mike Conley]

This is _fantastic_. Thank you Kanru!

On 16/11/2016 9:57 AM, Kan-Ru Chen wrote:
> Hello,
> 
> In bug 1314254 the return type of IPDL Recv* methods was changed from
> bool to mozilla::ipc::IPCResult in order to make crash reports to have
> better stack information. There are now three choices to return from a
> Recv* method:
> 
> 1. return IPC_OK(); where previously we return true
> 2. return IPC_FAIL_NO_REASON(this); where we previously return false
> 3. return IPC_FAIL(this, "a string explaining the failure");
> 
> All the existing methods are mass converted to either 1 or 2. New codes
> are encouraged to annotate the failing reason with 3. I'm sorry that
> some patches were backed out because they caused m-i to m-c merge
> conflict. Hopefully the conflicts should be very easy to fix.
> 
> Kanru
> 
> [bug]: https://bugzilla.mozilla.org/show_bug.cgi?id=1314254
> ___
> 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: Intent to make Form Autocomplete popups use richlistbox's instead of trees

[Mike Conley]

Resurrecting this old thread to let you all know that this autolanded last
night, and (if all goes well) should merge to mozilla-central soon. Thanks
to MattN for the reviews!

Dirty details are in https://bugzilla.mozilla.org/show_bug.cgi?id=1296638

On 20 August 2016 at 06:10, Gijs Kruitbosch <gijskruitbo...@gmail.com>
wrote:

> On 19/08/2016 16:25, Mike Conley wrote:
>
>> Summary says it all. See
>> https://bugzilla.mozilla.org/show_bug.cgi?id=1296638 for details and
>> rationale.
>>
>> I have a working version of this on my local machine, and will likely put
>> it up for review today or early next week.
>>
>
> I probably don't need to tell you this, but just in case: please make sure
> this continues to be accessible to users who need a11y tools to whatever
> extent it works today. Not sure how much the a11y reflection of that popup
> is tied to the current implementation. Marco Zehe can probably help with
> testing/feedback if necessary.
>
> ~ Gijs
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Requesting Help

[Mike Conley]

Hi Amila! Welcome!

We can absolutely help you out.

There are a _lot_ of things going on that you can contribute to,
depending on your current skillset, and also depending on what skills
you'd like to grow.

jdm wrote a tool to let you know about some of the things you might want
to contribute to: http://whatcanidoformozilla.org/

You mentioned contributing to Firefox, which suggests that you're primed
for some coding. jdm wrote yet another tool to help you find some bugs
to get started:

http://www.joshmatthews.net/bugsahoy/?

This tool lets you choose your interests, and then find mentored "good
first" bugs to work on. When a bug is mentored, it means that a
developer experienced in the code or problem that the bug is concerned
with will walk you through the process of getting a patch written, put
up for review, reviewed, and then landed into the tree to go out to our
users.

You might also enjoy some of these video tutorials on how to get
started: http://codefirefox.com/

There's also the @StartMozilla Twitter account that pumps out
interesting things to work on: https://twitter.com/StartMozilla

And finally, you could join the #introduction IRC[1] channel at
irc.mozilla.org if you'd like to get some help getting started.

If all else fails, you can also email me directly, and I can try to
point you in a decent direction.

I hope that helps! Thanks for reaching out,

-Mike

[1]: https://wiki.mozilla.org/IRC

On 15/09/2016 11:04 PM, Amila Indrajith wrote:
> . I'm kind of new to the open source projects and I need to know how can I 
> contribute for a Firefox in new feature or API.I need to working on something 
> else instead of bugs. can anyone help me out..? 
> ___
> 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: PSA: mozilla/unused.h renamed to mozilla/Unused.h

[Mike Conley]

Yes, thank you Kan-Ru!

On Aug 27, 2016 2:10 PM, "Nick Fitzgerald"  wrote:

> Thanks Kan-Ru! I've personally tried to include the header with the wrong
> case multiple times, so I appreciate this change a lot.
>
> On Fri, Aug 26, 2016 at 7:54 PM, Kan-Ru Chen  wrote:
>
> > Hello,
> >
> > In Bug 1297276 I landed a patch to rename mozilla/unused.h to
> > mozilla/Unused.h to make it more consistent with our other MFBT headers.
> > Normally rename a header shouldn't cause too much trouble, however this
> > rename is only changing the case so you might experience some problems
> > on case insensitive filesystem.
> >
> > As pointed out by Tim in
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1297276#c19 if you use
> > |git pull -f| to update local copy of gecko and git refuse to, you can
> > rm mfbt/unused.* first to make git happy.
> >
> > HPH
> > Kanru
> > ___
> > 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: Intent to make Form Autocomplete popups use richlistbox's instead of trees

[Mike Conley]

Hey Sebastian,

Great question. The reason I'm choosing richlistbox is mostly for speed
and convenience, because a binding already exists
(autocomplete.xml#autocomplete-rich-result-popup) that will do what I
want (with some minor CSS tweaks), and I didn't want to write something
new from scratch.

I'm all for rewriting stuff in HTML where possible. I'll touch base with
the devtools team to see if I can use anything they've built instead. I
know, for example, that debugger.html seems to be using some kind of
React-based tree[1], but I'm still reasonably certain that a tree is not
what we want to use from these popups. A simple (but styleable) list
popup API would suffice.

Thanks,

-Mike

[1]:
https://github.com/devtools-html/debugger.html/blob/2f62b57660e257f8c952ea6e627577a652357377/public/js/components/SourcesTree.js


On 19/08/2016 12:52 PM, Sebastian Zartner wrote:
> Hi Mike,
> 
> I'm not much into that topic, though I'm wondering why you don't try to
> switch to HTML already as the DevTools team started to do[1] recently.
> 
> Sebastian
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1263750
> 
> On 19 August 2016 at 17:25, Mike Conley <mcon...@mozilla.com
> <mailto:mcon...@mozilla.com>> wrote:
> 
> (Cross-posted to dev-platform and firefox-dev)
> 
> Hey folks,
> 
> If you don't work on front-endy things, you can safely ignore this.
> 
> Summary says it all. See
> https://bugzilla.mozilla.org/show_bug.cgi?id=1296638
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1296638> for details
> and rationale.
> 
> I have a working version of this on my local machine, and will
> likely put it up for review today or early next week.
> 
> Mostly doing this shout-out for the other XUL apps out there that
> might be making use of Form Autocomplete, and might have some
> tree-specific stuff. Hoping they can weigh in if there's a problem.
> Fennec should be unaffected. TB and SM might be affected.
> 
> If there are any concerns with this plan, please respond to this
> thread on dev-platform and we can hash it out.
> 
> Thanks!
> 
> -Mike
> 
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org <mailto:firefox-...@mozilla.org>
> https://mail.mozilla.org/listinfo/firefox-dev
> <https://mail.mozilla.org/listinfo/firefox-dev>
> 
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to make Form Autocomplete popups use richlistbox's instead of trees

[Mike Conley]

(Cross-posted to dev-platform and firefox-dev)

Hey folks,

If you don't work on front-endy things, you can safely ignore this.

Summary says it all. See
https://bugzilla.mozilla.org/show_bug.cgi?id=1296638 for details and
rationale.

I have a working version of this on my local machine, and will likely put
it up for review today or early next week.

Mostly doing this shout-out for the other XUL apps out there that might be
making use of Form Autocomplete, and might have some tree-specific stuff.
Hoping they can weigh in if there's a problem. Fennec should be unaffected.
TB and SM might be affected.

If there are any concerns with this plan, please respond to this thread on
dev-platform and we can hash it out.

Thanks!

-Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Increased number of e10s related crashes for firefox-ui-tests on mozilla-central and integration branches

[Mike Conley]

Might be unexpected fallout from bug 1261842 which landed on central on
Monday (July 25th). Does that correspond to your timeline of when this
started showing up?

I'm seeing this in the log for at least one of these:

"JavaScript error: chrome://marionette/content/listener.js, line 1017:
NS_ERROR_FAILURE: Component returned failure code: 0x80004005
(NS_ERROR_FAILURE) [nsIWebProgress.removeProgressListener]"

Which sounds related to some of the Marionette changes I made for bug
1261842. I'll continue investigation in bug 1290184.

On 29/07/2016 1:50 AM, Henrik Skupin wrote:
> Hi,
> 
> Over the last couple of days I noticed a spike of crashes specifically
> for our firefox-ui-tests as run on Taskcluster (Linux64, Ubuntu 12.04
> docker image). The crashes are completely related to our e10s jobs.
> There are a lot of different crash signatures, but mostly these are:
> 
> [@ libpthread-2.15.so + 0xbd84]
> [@ libc-2.15.so + 0xe7993]
> 
> https://treeherder.mozilla.org/#/jobs?repo=autoland=firefox%20ui%20e10s
> 
> Does anyone know if there were related changes for e10s which might have
> caused those crashes to appear? I'm afraid that we might have some
> unknown top crashers which would go to aurora by the merge early next week.
> 
> Thanks
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to measure performance impact of l10n on UI

[Mike Conley]

> If I understand correctly, firstPaint from getStartupInfo will tell me when 
> the first paint of the window occured.
> 
> But since I'm operating in a document (I'm working on about:support 
> document), I'm looking for the firstPaint of the document, not the whole 
> browser window.
> 
> So, what I'm looking for is something like "performance.timing.firstPaint" 
> for each document.
> 
> Am I missing something?

Ah, in that case, yes, firstPaint is definitely not what you want.
You're right - it's recording the time that the first top-level window
is painted.

> One hour of reading DXR later and I *think* I want to get the timestamp of 
> this: 
> https://dxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#3809
> 
> or something around it :)
> 
> 
> as this will tell me a couple of things:
> 
> 1) Things injected into DOM after this timestamp may/will cause reflow.
> 2) Things injected into DOM before this timestamp are unlikely to cause FOUC
> 3) If I change any code in ContentSink, HTMLParser, or if I'll inject a 
> MutationObserver that will be catching nodes as the Parser feeds the DOM and 
> modifying them, I should see this timestamp being affected and in result 
> performance being impacted.
> 
> Does it sound like what I'm looking for?
> 
> zb.

Possibly? It certainly looks like that'll get you the time before we
start a paint.

Can you point me to the test you've written so far? That might help me
to better understand what you're attempting to measure and how you're
going about it.

-Mike


On 22/07/2016 8:47 PM, zbranie...@mozilla.com wrote:
> On Friday, July 22, 2016 at 6:53:45 AM UTC-7, Mike Conley wrote:
>> Is the firstPaint timestamp in nsIAppStartup's getStartupInfo[1] not
>> sufficient? It's apparently recording the time that firstPaint occurred.
>> I think you're already aware of this, but I'm in the process of
>> modifying ts_paint to record the delta between the firstPaint timestamp
>> and the process start timestamp in bug 1287938.
>>
>> If it's not sufficient, I'd like to understand why.
> 
> If I understand correctly, firstPaint from getStartupInfo will tell me when 
> the first paint of the window occured.
> 
> But since I'm operating in a document (I'm working on about:support 
> document), I'm looking for the firstPaint of the document, not the whole 
> browser window.
> 
> So, what I'm looking for is something like "performance.timing.firstPaint" 
> for each document.
> 
> Am I missing something?
> 
> 
>>
>> As for MozAfterPaint firing all over the place - you might find this
>> useful:
>> https://groups.google.com/forum/#!searchin/mozilla.dev.platform/MozAfterPaint/mozilla.dev.platform/pCLwWdYc_GY/j9A-vWm3AgAJ
>>
>> See the second example I wrote in
>> https://developer.mozilla.org/en-US/docs/Web/Events/MozAfterPaint#Example
>>
>> Is any of that helpful?
> 
> That seems helpful!
> 
> If I understand correctly, I can take the transaction Id at DOMContentLoaded 
> (or DOMInteractive?) and assume that the first paint with the transaction ID 
> higher than that is the paint that flashed the document.
> 
> Then, if my code modifies DOM after that paint, I will reflow/flash.
> 
> Is that a correct assumption?
> 
> zb.
> ___
> 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: PSA - With e10s enabled, initial browser in new windows will soon be remote by default

[Mike Conley]

Hey bkelly,

Do we still kill the child process if the last content tab is closed?


Yes we do.

When a TabParent gets destroyed, it calls into here:
http://searchfox.org/mozilla-central/rev/336105a0de49f41a2cc203db7b7ee7266d0d558b/dom/ipc/ContentParent.cpp#2074

That code checks to see if any other tabs exist for the destroyed tabs
content process. If not, the content process is marked for destruction.

-Mike

On 25 July 2016 at 10:44, Ben Kelly <bke...@mozilla.com> wrote:

> Mike,
>
> Do we still kill the child process if the last content tab is closed?  For
> example, close all tabs in all windows except for an about:memory tab or
> something.  Or do we keep the child process alive as long as the
> browser.xul window is alive?
>
> Keeping the process alive would actually make a few things easier with our
> current service worker/push/devtools setup.
>
> Thanks.
>
> Ben
>
> On Mon, Jul 25, 2016 at 10:29 AM, Mike Conley <mcon...@mozilla.com> wrote:
>
>> After much toil, this has finally landed on central. Hopefully it sticks.
>>
>> Big thanks to all of my reviewers - especially smaug, who reviewed the
>> bulk
>> of the weirder stuff.
>>
>> -Mike
>>
>> On 9 June 2016 at 14:21, Mike Conley <mcon...@mozilla.com> wrote:
>>
>> > If you don’t write tests that open browser windows or work on the
>> > front-end of Firefox, you can probably ignore this.
>> >
>> > The initial browser in browser.xul is non-remote by default. This means
>> > that as soon as it browses to some URL that can be loaded in the content
>> > process (about:home, for example), we kick off the remoteness flipping
>> > machinery that swaps out that initial browser and puts a remote one
>> down in
>> > its place to load the content in the child process.
>> >
>> > In bug 1261842, I’m working on switching things around so that the
>> initial
>> > browser is remote as soon as possible (there’s still some set-up
>> required
>> > in JS, so I can’t just add the remote attribute to that initial
>> browser).
>> > Doing the flip sooner means we don’t have to set up the content viewer
>> for
>> > the non-remote browser (which gets immediately destroyed after the
>> > remoteness flip), which is good for window-opening performance.
>> >
>> > Normally, I wouldn’t bother these two mailing lists with this kind of
>> > information, but while working on these patches, I’ve had to fix a
>> bunch of
>> > tests that worked properly under the old assumption (initial browser is
>> > non-remote) but not under the new one (initial browser is remote), and I
>> > wanted to give a PSA on those writing tests that open windows.
>> >
>> > Here’s the deal: If you’re writing browser mochitests and you need to
>> open
>> > a window, please use BrowserTestUtils.openNewBrowserWindow. If you need
>> to
>> > trigger window openings via another mechanism (like window.open in
>> > content), but need to do things with the newly opened window, set up a
>> > Promise with BrowserTestUtils.waitForNewWindow. Both of these methods
>> are
>> > doing the right thing in terms of waiting for the new window to set
>> itself
>> > up and for the initial browser to be ready to do things with it.
>> >
>> > If you care - here’s why: without them, you run the risk of falling into
>> > the mistake I was seeing in a number of tests, which was opening a new
>> > window, waiting for its load event, telling the initial browser to load
>> > some URI, and then waiting for BrowserTestUtils.browserLoaded to resolve
>> > before proceeding. This technique will fail frequently, because
>> sometimes
>> > the message to load the URI will arrive at content after it has loaded
>> its
>> > initial about:blank, but before the parent has had an opportunity to
>> hear
>> > that the initial about:blank has been loaded. This means that the
>> > browserLoaded Promise will sometimes resolve even though the URI you
>> > requested hasn’t finished (or maybe even started) loading.
>> >
>> > Anyhow, with the patches in the bug, I appear to have fixed all of the
>> > tests that fall into this trap - but if you write a new test that’s
>> opening
>> > a window that’s failing frequently and you don’t know why, it might be
>> > because you need to use those BrowserTestUtils methods.
>> >
>> > Feel free to follow up with me in this thread or over IRC if there are
>> any
>> > questions or concerns regarding bug 1261842.
>> >
>> > Thanks,
>> >
>> > -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: PSA - With e10s enabled, initial browser in new windows will soon be remote by default

[Mike Conley]

After much toil, this has finally landed on central. Hopefully it sticks.

Big thanks to all of my reviewers - especially smaug, who reviewed the bulk
of the weirder stuff.

-Mike

On 9 June 2016 at 14:21, Mike Conley <mcon...@mozilla.com> wrote:

> If you don’t write tests that open browser windows or work on the
> front-end of Firefox, you can probably ignore this.
>
> The initial browser in browser.xul is non-remote by default. This means
> that as soon as it browses to some URL that can be loaded in the content
> process (about:home, for example), we kick off the remoteness flipping
> machinery that swaps out that initial browser and puts a remote one down in
> its place to load the content in the child process.
>
> In bug 1261842, I’m working on switching things around so that the initial
> browser is remote as soon as possible (there’s still some set-up required
> in JS, so I can’t just add the remote attribute to that initial browser).
> Doing the flip sooner means we don’t have to set up the content viewer for
> the non-remote browser (which gets immediately destroyed after the
> remoteness flip), which is good for window-opening performance.
>
> Normally, I wouldn’t bother these two mailing lists with this kind of
> information, but while working on these patches, I’ve had to fix a bunch of
> tests that worked properly under the old assumption (initial browser is
> non-remote) but not under the new one (initial browser is remote), and I
> wanted to give a PSA on those writing tests that open windows.
>
> Here’s the deal: If you’re writing browser mochitests and you need to open
> a window, please use BrowserTestUtils.openNewBrowserWindow. If you need to
> trigger window openings via another mechanism (like window.open in
> content), but need to do things with the newly opened window, set up a
> Promise with BrowserTestUtils.waitForNewWindow. Both of these methods are
> doing the right thing in terms of waiting for the new window to set itself
> up and for the initial browser to be ready to do things with it.
>
> If you care - here’s why: without them, you run the risk of falling into
> the mistake I was seeing in a number of tests, which was opening a new
> window, waiting for its load event, telling the initial browser to load
> some URI, and then waiting for BrowserTestUtils.browserLoaded to resolve
> before proceeding. This technique will fail frequently, because sometimes
> the message to load the URI will arrive at content after it has loaded its
> initial about:blank, but before the parent has had an opportunity to hear
> that the initial about:blank has been loaded. This means that the
> browserLoaded Promise will sometimes resolve even though the URI you
> requested hasn’t finished (or maybe even started) loading.
>
> Anyhow, with the patches in the bug, I appear to have fixed all of the
> tests that fall into this trap - but if you write a new test that’s opening
> a window that’s failing frequently and you don’t know why, it might be
> because you need to use those BrowserTestUtils methods.
>
> Feel free to follow up with me in this thread or over IRC if there are any
> questions or concerns regarding bug 1261842.
>
> Thanks,
>
> -Mike
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to measure performance impact of l10n on UI

[Mike Conley]

Is the firstPaint timestamp in nsIAppStartup's getStartupInfo[1] not
sufficient? It's apparently recording the time that firstPaint occurred.
I think you're already aware of this, but I'm in the process of
modifying ts_paint to record the delta between the firstPaint timestamp
and the process start timestamp in bug 1287938.

If it's not sufficient, I'd like to understand why.

As for MozAfterPaint firing all over the place - you might find this
useful:
https://groups.google.com/forum/#!searchin/mozilla.dev.platform/MozAfterPaint/mozilla.dev.platform/pCLwWdYc_GY/j9A-vWm3AgAJ

See the second example I wrote in
https://developer.mozilla.org/en-US/docs/Web/Events/MozAfterPaint#Example

Is any of that helpful?

-Mike

[1]:
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIAppStartup#getStartupInfo()

On 21/07/2016 11:38 PM, zbranie...@mozilla.com wrote:
> As part of the work we're doing to replace old l10n API (DTD for HTML/XUL and 
> StringBundle for JS) with new API, we're trying to measure the performance 
> cost of DTD, StringBundle and its replacements.
> 
> The challenge we encountered is that there doesn't seem to be a way to 
> measure something that I'd intuitively and naively would call "first paint".
> 
> By first paint, I mean the moment when the engine paints the UI for the first 
> time.
> 
> I'd expect there to be some way to get it via Performance API, or some 
> Mozilla-specific event, but everything I see does not seem to do this.
> 
> MozAfterPaint reports every paint, and it fires before DOMContentLoaded, 
> between DOMContentLoaded and window.onload, and after. It's impossible to 
> say, which one of them marks the event I'm after*.
> 
> bz created a POC of an API for us that pauses frame creation (**) and that's 
> awesome as it ensures that we will not cause FOUCs, but now we need to 
> measure when the "first paint" happens with our code vs. with DTD and I don't 
> know how to get the required event.
> There seems to be `widget-first-paint` event (***) but if I understand it 
> correctly it'll only mark when chrome window is painted for the first time, 
> now a document.
> 
> Can someone help us? If we have to add it, where?
> 
> Thanks,
> zb.
> 
> 
> *) And it's not the first. I can reliably modify visible DOM after first 
> MozAfterPaint and I will not have FOUC.
> **) https://bugzilla.mozilla.org/show_bug.cgi?id=1280260
> ***) 
> https://dxr.mozilla.org/mozilla-central/source/layout/base/nsPresShell.cpp#9157
> ___
> 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

PSA - With e10s enabled, initial browser in new windows will soon be remote by default

[Mike Conley]

 If you don’t write tests that open browser windows or work on the
front-end of Firefox, you can probably ignore this.

The initial browser in browser.xul is non-remote by default. This means
that as soon as it browses to some URL that can be loaded in the content
process (about:home, for example), we kick off the remoteness flipping
machinery that swaps out that initial browser and puts a remote one down in
its place to load the content in the child process.

In bug 1261842, I’m working on switching things around so that the initial
browser is remote as soon as possible (there’s still some set-up required
in JS, so I can’t just add the remote attribute to that initial browser).
Doing the flip sooner means we don’t have to set up the content viewer for
the non-remote browser (which gets immediately destroyed after the
remoteness flip), which is good for window-opening performance.

Normally, I wouldn’t bother these two mailing lists with this kind of
information, but while working on these patches, I’ve had to fix a bunch of
tests that worked properly under the old assumption (initial browser is
non-remote) but not under the new one (initial browser is remote), and I
wanted to give a PSA on those writing tests that open windows.

Here’s the deal: If you’re writing browser mochitests and you need to open
a window, please use BrowserTestUtils.openNewBrowserWindow. If you need to
trigger window openings via another mechanism (like window.open in
content), but need to do things with the newly opened window, set up a
Promise with BrowserTestUtils.waitForNewWindow. Both of these methods are
doing the right thing in terms of waiting for the new window to set itself
up and for the initial browser to be ready to do things with it.

If you care - here’s why: without them, you run the risk of falling into
the mistake I was seeing in a number of tests, which was opening a new
window, waiting for its load event, telling the initial browser to load
some URI, and then waiting for BrowserTestUtils.browserLoaded to resolve
before proceeding. This technique will fail frequently, because sometimes
the message to load the URI will arrive at content after it has loaded its
initial about:blank, but before the parent has had an opportunity to hear
that the initial about:blank has been loaded. This means that the
browserLoaded Promise will sometimes resolve even though the URI you
requested hasn’t finished (or maybe even started) loading.

Anyhow, with the patches in the bug, I appear to have fixed all of the
tests that fall into this trap - but if you write a new test that’s opening
a window that’s failing frequently and you don’t know why, it might be
because you need to use those BrowserTestUtils methods.

Feel free to follow up with me in this thread or over IRC if there are any
questions or concerns regarding bug 1261842.

Thanks,

-Mike
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Top crash list is odd right now

[Mike Conley]

I reviewed the patch. Currently, the feature is only enabled on Nightly,
Aurora and Beta. We originally wanted the beta unsubmitted crashes due
to the content process crashes we were getting there with e10s that we
didn't understand.

Now that we have a better handle on those content process crashes, I
think we're still trying to determine if letting this ride to beta makes
sense.

See bug 1269998 for context.

On 03/06/2016 11:45 AM, Lawrence Mandel wrote:
> Is the plan to prompt on release as well?
> 
> On Fri, Jun 3, 2016 at 11:33 AM, Andrew McCreight 
> wrote:
> 
>> blassey landed a patch to suggest that users submit unsubmitted crash
>> reports. This is going to make various kinds of crashes, like shutdown
>> crashes, grossly overrepresented in the crash-stats "Top Crashers" list.
>> You probably want to use "By build date" instead of the default "By report
>> date" for the next week or so until that settles out.
>>
>> Presumably the same thing will happen the first week or two of Aurora, on
>> that channel, and likewise with beta.
>> ___
>> 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: pushPrefEnv/popPrefEnv/flushPrefEnv now return Promises

[Mike Conley]

This is great, thank you!

On 19/05/2016 7:09 PM, Matthew N. wrote:
> Hello,
> 
> One of the reasons developers have been avoiding pushPrefEnv compared to
> the synchronous set*Pref (with a registerCleanupFunction) is because
> pushPrefEnv required using a callback function to wait for the
> preference change before moving on in the test file. This can make the
> test flow more complicated (especially when using add_task) and
> therefore harder to follow.
> 
> Bug 1197310[1] made pushPrefEnv/popPrefEnv/flushPrefEnv return a promise
> which resolves when the callbacks would have been called so now you can
> simply write test code like so:
> 
> add_task(function* setup() {
>   yield SpecialPowers.pushPrefEnv({"set": [["signon.debug", true]]});
>   …
> })
> 
> As a reminder, the nice thing about pushPrefEnv is that the pref changes
> are reverted at the end of the test file which avoids them leaking into
> other tests unintentionally.
> 
> There are various places in the tree which wrote their own Promise
> wrappers for pushPrefEnv so feel free to file follow-up bugs blocking
> bug 1197310 to remove them.
> 
> Cheers,
> Matthew N. (:MattN)
> 
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1197310
> 
> P.S. For those of you who didn't hear (since there was no announcement),
> you can use add_task in mochitest-plain and mochitest-chrome thanks to
> bug 1187701 if you load …/tests/SimpleTest/SpawnTask.js.
> ___
> 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: Moving XP to ESR?

[Mike Conley]

The people on this thread might find chutten's recent blog post interesting:

https://chuttenblog.wordpress.com/2016/04/19/firefoxs-windows-xp-users-upgrade-path/

Juicy chunk: "Between 40% and 53% of Firefox users running Windows XP
are Stuck"

-Mike

On 18/04/2016 9:04 AM, Henri Sivonen wrote:
> XP has now gone for two years without security patches from Microsoft.
> Additionally, as of its latest release, Chrome no longer supports XP.
> 
> When 46 ships, it would be a great time to make AUS advertise 45 ESR
> builds to XP (even on non-ESR) channel. This would keep XP supported
> through the ESR cycle but would put an end to the XP tax on trunk.
> 
> Are we already on track to doing this? If not, why not?
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Cancel your old Try pushes

[Mike Conley]

If I had to guess, I'd say that it's just consuming more and more memory as
more and more nodes are getting added to the DOM, and more AngularJS stuff
gets instantiated.

I would put good money on those multi-second pauses being attempts to GC /
CC


On 16 April 2016 at 05:50, Gijs Kruitbosch  wrote:

> On 16/04/2016 01:24, Steve Fink wrote:
>
>> Doesn't everyone keep a tab open to their try page? eg I have
>> https://treeherder.mozilla.org/#/jobs?repo=try=sf...@mozilla.com
>> open all the time.
>>
>
> No. Treeherder is too resource-intensive to keep open for long periods of
> time. I tend to see multi-second pauses on my regular browser (beta) on
> Windows. No idea what it does, but it's not good.
>
> ~ Gijs
>
> ___
> 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

On using MozAfterPaint properly

[Mike Conley]

Hello dev-platform,

TL;DR: MozAfterPaint and nsIDOMWindowUtils has been given some extra stuff
to make it easier to be sure that something you care about has been
painted. This is good, at the very least, for Talos tests.

Full-details:

I've recently made a change to MozAfterPaint that some of you might find
interesting. This is particularly interesting for people who work on or
with Talos tests where those tests are measuring how long until something
is presented to the user.

Traditionally, MozAfterPaint has been used by Talos tests[1] to "stop a
stopwatch" that's been ticking since some action started. For example, for
the tpaint Talos test[2], the stopwatch is started, and a new window is
opened up. Once the content in the new window sees the MozAfterPaint event,
we assume the content has been displayed to the user, and we stop the
stopwatch.

Note that MozAfterPaint is fired after both paint _and_ composition, so it
truly does mean "presented to the user"[3].

Now that we live in an OMTC world, there are complications. Specifically,
there are opportunities for a MozAfterPaint handler to hear a MozAfterPaint
that it doesn't actually care about.

Let me give you an example.

Suppose I'm writing a talos test that is measuring how long it takes for
something to paint after I've clicked some node with id="target". Normally,
I'd set up my MozAfterPaint handler, start the stopwatch, fire a click
event at the target, and wait for the MozAfterPaint in order to stop the
stopwatch. The problem is that there's the possibility that a composite was
underway while I was running my Talos script. That means that after I've
set my MozAfterPaint handler, I might hear a MozAfterPaint event before
layout and graphics have had a chance to react to my click on the target
element.

The fact that this is all kind of non-deterministic makes it a bit worse.
Sometimes we'll see the result we want, and sometimes, we'll see very short
results from our stopwatch due to an earlier composite that was in progress
when we ran our script.

To combat this, I've added the following:

1) An unsigned long long property to nsIDOMWindowUtils giving the last
transaction id that was sent to the compositor
2) An unsigned long long property on the MozAfterPaint event exposing which
transaction id this MozAfterPaint is for

To go back to our example, this means that what I should do is, before
starting the stopwatch, I should figure out what the lastTransactionId was
for the window I'm in, and remember it. When my MozAfterPaint event handler
runs, I should ensure that the transactionId on the event is _greater_ than
the lastTransactionId I had recorded earlier. It might not be exactly 1
value above. We just know it'll be greater. If it's greater, then we _know_
that whatever action we took when clicking the target, if it should cause a
paint, should have been included in this composite.

So that's that. Gory details are in bug 1264409. I've also filed bug
1264798 to investigate adding the composite end time in the MozAfterPaint
event for greater accuracy.

-Mike

[1]: It's also periodically used by front-end code to defer some activity
until something has been presented to the user.
[2]: https://wiki.mozilla.org/Buildbot/Talos/Tests#tpaint
[3]: The fact that it's called MozAfterPaint is probably for historical
reasons. It should probably be renamed to MozAfterPresented or something.
Meh.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Just Autoland It

[Mike Conley]

I respect everybody talking in this thread a great deal, but I thought I
might gently suggest that folks exercise a bit of empathy for what the
MozReview team[1] are trying to accomplish, and how difficult that work
actually is.

Trying to build a tool that satisfies such a wide spectrum of
preferences is extremely difficult - especially when (it seems to me)
most of the feedback is via negativa[2]. Having worked on front-end for
Firefox for a number of years, I believe I can speak with a certain
degree of authority about how difficult it is to satisfy users with UI
and workflow. It's a hard problem. Perhaps this can be alleviated by
putting some UX folks on the problem[3].

The good news is that this is Mozilla, which means that there are a
variety of ways of doing things, and nobody is really forcing you to use
MozReview. I see teams using GitHub pull requests, Reviewable, Opera
Critic, Reitveld, and Splinter in parallel with MozReview. Each have
their strengths. The thing with MozReview, however, is that we can more
easily mold it to suit our needs (once we can settle on what those needs
are - this is where filed bugs come in[4]).

Try MozReview. If it doesn't work for you, maybe use something else, and
try it again in a few months once the team has had a chance to address
the bugs you hopefully filed.

Again, I mean no disrespect here. I just want to gently suggest that we
exercise some restraint while hammering on the MozReview team, who are
trying to accomplish something extremely difficult.

-Mike

[1]: I'm not on the MozReview team, but I've been involved peripherally
from the outset, and I'm also a Review Board contributor.
[2]: This has different meanings for different people, but I'm using it
in the stage-theatre sense, where a director will not tell you what they
want, but every time you come out with something, they'll tell you what
you need to stop doing without telling you what you need to do. As an
actor, I always found this directing technique to be extremely frustrating.
[3]: There have been some casual consultations with folks like bwinton,
but I think that's about as far as it goes.
[4]: The MozReview team triages these biweekly (I believe), so they'll
get read and considered.

On 29/01/2016 9:22 AM, Andrew Halberstadt wrote:
> On 28/01/16 06:31 PM, Eric Rescorla wrote:
>> On Thu, Jan 28, 2016 at 10:58 AM, Gregory Szorc 
>> wrote:
>>
>>> I'd like to thank everyone for the feedback in this thread. However, the
>>> thread has grown quite long and has detoured from its original subject.
>>>
>>> Speaking on behalf of everyone who works on MozReview, we know the
>>> interface is lacking in areas and features are confusing or
>>> non-existent.
>>> We're working on it. We're trying to morph workflows that have been
>>> practiced at Mozilla for over a decade. We're playing a delicate
>>> balancing
>>> game between giving familiarity with existing workflows (e.g. Bugzilla
>>> integration) while trying to slowly nudge us towards more "modern"
>>> and more
>>> powerful workflows.
>>
>>
>> Frankly, I'm a little dismayed to hear that you think that one of the
>> goals
>> of Mozreview
>> is to modify people's workflows. The primary problem with our existing
>> review system
>> isn't that it doesn't involve some more "modern" review idiom (leaving
>> aside the question
>> of whether it is in fact more modern), but rather that the UI is bad and
>> that it's a lot
>> less powerful than existing review tools, including those that enact
>> basically the
>> same design (cf. Rietveld).
>>
>> Speaking purely for myself, I'd be a lot happier if mozreview involved
>> less
>> nudging
>> and morphing and more developing of basic functionality.
>>
>> -Ekr
> 
> Not speaking to review per se, but engineering productivity in general.
> The problem is there are so many unique and one-off workflows at Mozilla
> that it gets harder and harder to improve "basic functionality" across
> all of them. At some point, we hit vastly diminishing returns and get
> stretched too thin. We'd love to improve every existing workflow, but
> simply don't have the resources to do that.
> 
> Instead, we try to make one really nice workflow such that people want
> to switch. That being said it's a valid opinion to think that the carrot
> isn't sweet enough yet. If that's the case, filing bug reports like gps
> mentioned is very helpful to us.
> 
> -Andrew
> 
> 
>>> We're constantly surprised by all the one-off workflows and needs people
>>> have and the reactions to a seemingly benign change. It's been a
>>> humbling
>>> experience to say the least.
>>>
>>> The best venue for reporting bugs, UX paper cuts, and suggest
>>> improvements
>>> is Bugzilla. Developer Services :: MozReview. Or hop in #mozreview
>>> and chat
>>> with us.
>>>
>>> We get a lot of requests for changes that initially seem odd to us.
>>> So, if
>>> your bug report could articulate why you want something and how many
>>> people
>>> would benefit 

Re: Just Autoland It

[Mike Conley]

>> Since making the review requester feel crappy is not generally
>> considered good, most review requestees don't push back on MozReview
>> requests, even if they find it very frustrating to work with.  I think
>> this dynamic is at the heart of a lot of the angst about MozReview:
>> people just feel put upon.

That's a good point. From my observations and interactions with the
MozReview team over the months, I believe a great deal of the initial
effort has been to lower the ramp for the requestors, as opposed to the
requestees. The fact that we're seeing so many review requests go
through MozReview might be a sign of success in terms of that work.

Anecdotal evidence, along with the sentiments in threads like this (and
elsewhere) suggests that it would now probably be worth shifting the
emphasis on lowering the ramp for the requestees.

I do know that this sort of work has started to get attention from the
MozReview team. smaug, as the most prolific reviewer[1] recently filed a
bug about interdiffs being busted in particular cases, and it's getting
serious attention from the team.

So, I guess we need to show some empathy for the requestees as well. I
think[2] it's not always clear what the most critical thing to fix for
our requestees is. If folks have some wireframes, ascii diagrams,
napkins sketches, I'm certain the MozReview team would find that valuable.

[1]: All hail the mighty smaug!
[2]: Beyond obvious things like, "interdiffs are sometimes wrong", which
is clearly something to fix ASAP

On 29/01/2016 11:18 AM, Boris Zbarsky wrote:
> On 1/29/16 10:42 AM, Mike Conley wrote:
>> most of the feedback is via negativa[2]
> 
> That's definitely no good, I agree.
> 
> Attacking the MozReview team is also not ok, obviously.
> 
>> and nobody is really forcing you to use MozReview.
> 
> Well, sort of.  A review requester who uses Mozreview is forcing the
> review requestee to use MozReview to some extent.
> 
> That said, I've seen some review requestees blanket unset review flags
> on any MozReview request, in an attempt to get review requests they
> actually want to deal with.
> 
> Note that either way there is bad feeling here as a result: either the
> review requestee feels like the review requester is forcing them into a
> bad workflow, or the review requester feels like the review requestee is
> forcing them into a bad workflow.
> 
> Since making the review requester feel crappy is not generally
> considered good, most review requestees don't push back on MozReview
> requests, even if they find it very frustrating to work with.  I think
> this dynamic is at the heart of a lot of the angst about MozReview:
> people just feel put upon.
> 
>> I see teams using GitHub pull requests, Reviewable, Opera
>> Critic, Reitveld, and Splinter in parallel with MozReview.
> 
> This works well in reasonably isolated team.
> 
> As you might have noticed, the people who seem to be complaining about
> MozReview the most are the ones who (1) do a lot of reviews and (2) do
> them across a wide swath of the codebase.  Item (1) means they already
> have a well-worked out review workflow, and MozReview would initially be
> slower and more annoying even if the UI were perfect.  It also means
> that they represent a disproportionate portion of all the reviews
> done.[1]  Item (2) means they can't just ask all the potential review
> requesters to not use MozReview, because asking a review requester to
> remember the preferred review system on a per-requestee basis is nuts.
> 
> So there's some combination of "this is different" and "this is worse"
> here, and as usual disentangling them is a bit hard.  As you say,
> concrete bug reports are the way to go.
> 
>> are - this is where filed bugs come in[4]).
> 
> As a personal anecdote, in the last 5 months I've reported what looks
> like 7 bugs that significantly affect my ability to use MozReview
> effectively, and there is one more that I would have reported were it
> not reported already.  Of these, two have been addressed.  I'm not
> blaming the MozReview team here; they have limited resources, other
> commitments, and I can't be the only person reporting bugs!  But, again,
> we end up with a dynamic where people are effectively being told "use
> it; if you run into issues, file bugs and keep using it", but the bugs
> take a long time to address and in the meantime using it is frustrating.
>  Again, not the fault of the MozReview team, but that doesn't make the
> frustration less.
> 
> I agree that if people were not feeling forced into using it and could
> just report the bugs and then wait for them to be fixed while using
> something else, they would be a lot less worked up around this.
> 
&g

Re: Unsafe CPOWs are about to be outlawed in browser code

[Mike Conley]

The spaghetti was put in the machine last night - this work has now
landed on mozilla-central.

If you start seeing "unsafe CPOW usage forbidden" in the Browser Console
for various things, please mark them blocking bug 1233497.

Thanks all,

-Mike

On 20/01/2016 3:54 PM, Mike Conley wrote:
> (cross-posted to both dev-platform and firefox-dev)
> *
> *
> TL;DR: Shortly, I’ll be flipping a pref to outlaw unsafe CPOWs in almost
> all browser code. Unsafe CPOWs inside add-on scopes should continue to
> work properly. If you start seeing "unsafe CPOW usage forbidden” errors
> being throw for a feature you’re working on in the Browser Console, it’s
> because unsafe CPOWs have been outlawed and you should stop using them.
> Talk to me if you run into problems.
> 
> Details:
> 
> “unsafe” CPOWs[1][2] are CPOWs that are accessed when the other process
> is not currently blocked waiting for information from you. For example,
> if you access gBrowser.selectedBrowser.contentDocumentAsCPOW.body when
> the content process is garbage collecting, the parent will be blocked
> until the child decides that it has a moment to service the synchronous
> message and return the information that the parent needs. Unsafe CPOWS
> are generally pretty horrible for performance, especially because we
> cannot know what state the other process is in.
> 
> “safe” CPOWs are when the other process is in a known blocked state -
> for example, the content process sends a synchronous message to the
> parent asking for some information, and is blocked waiting for a
> response. The parent then accesses CPOWs in the content process safely,
> because the content process is in a known state. The only overhead here
> is the IPC traffic.
> 
> “unsafe” CPOWs are often used by add-ons to synchronously manipulate
> content. A year or so back, a bunch of browser code also used unsafe
> CPOWs in this way, but we’ve been slowly but surely weeding them out.
> We’re at the state now where we believe we’ve eliminated most of the
> in-browser unsafe CPOW uses[3].
> 
> Within the next day or so, I’m going to be landing bug 1233497[4] which
> will cause unsafe CPOW usage in non-addon browser code to throw. In the
> event that this breaks things horribly, there is a pref[5] that we can
> flip to turn unsafe CPOWs back on while we fix things.
> 
> Again, this work is occurring in bug 1233497[4]. If there are any major
> concerns, please bring them up here before I throw the spaghetti into
> the machine.
> 
> For more details on unsafe CPOWs, please read [1] and/or [2].
> 
> [1]: 
> https://mikeconley.ca/blog/2015/02/17/on-unsafe-cpow-usage-in-firefox-desktop-and-why-is-my-nightly-so-sluggish-with-e10s-enabled/
> 
> [2]: http://blog.lassey.us/2015/01/10/unsafe-cpow-usage/
> [3]: Outside of tests, and a few other little things that there are
> follow-ups for.
> [4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1233497
> [5]: dom.ipc.cpows.forbid-unsafe-from-browser
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Just Autoland It

[Mike Conley]

FWIW, adding r- abilities is bug 1197879[1]. There's a prototype patch
that adds the UI, but I believe the MozReview team was still trying to
sort out the best terminology to use.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1197879

On 26/01/2016 10:46 AM, Benjamin Smedberg wrote:
> 
> 
> On 1/26/2016 10:26 AM, Boris Zbarsky wrote:
>> On 1/26/16 7:38 AM, Axel Hecht wrote:
>>> Which is basically what I do whenever I want to do something. I have a
>>> clear idea and intention on what I want to show up on bugzilla, but not
>>> on what to do on reviewboard to get there. Which might just be a
>>> category of documentation that's not written yet.
>>
>> Not just.  For example, there is no way to "r-" in mozreview.  You can
>> only "r+" or remove the review request, in Bugzilla terms.
> 
> There is a pattern that some teams have been using where they never mark
> "r-" on a change. I think the rationale for this is that it feels
> negative and discouraging to receive the "review not granted" email,
> especially for new contributors. Instead, they will either clear the
> review or mark an f+ and ask for a new patch.
> 
> I don't like this practice: I encourage people to use the r- flag. It's
> important to make clear in bugzilla that something has already been
> reviewed and that the result is that something is not ready. Without r-
> or something very similar, it's difficult to distinguish between various
> important cases:
> 
>  * I'm too busy/not the right person to review this (clear the review
>or redirect it)
>  * I started the review and have a question (leave the r? flag, add a
>NEEDINFO)
>  * This isn't good enough (r-)
>  * I've looked this over and it's ok in general, but it still needs a
>detailed code review: mark f+, redirect the r? flag as appropriate
> 
> In addition, I've seen several contributors become confused receiving an
> f+ and not realizing that what it really meant is "not good enough,
> please make changes".
> 
> Our reviewboard tooling should support explicit r- and not just clearing
> review flags.
> 
> --BDS
> 
> ___
> 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: Just Autoland It

[Mike Conley]

I should point out that these interdiff issues are being actively worked on.

At least one of them, bug 1238000[1], already has a patch that's under
review to land in core[2].

Just be sure to file them. Having talked to the MozReview team about these
types of bugs, I do know that trust-worthiness of diffs and interdiffs is
very much a thing that we should be able to take for granted. Any bugs in
diff and interdiff trust-worthiness are high-priority to fix.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1238000
[2]: https://reviews.reviewboard.org/r/7874/

On 25 January 2016 at 11:28, Boris Zbarsky  wrote:

> On 1/23/16 9:48 PM, Mike Hommey wrote:
>
>> Note that if /other/ changes from other bugs have happened to the same
>> files between the last reviewed iteration and the rebase before landing,
>> the interdiff will show them without any kind of visual cues.
>>
>
> Ah, that's unfortunate.
>
> I agree that this is a hard problem, though (interdiff across rebases).  I
> guess that does mean that you can't really use the final attached thing for
> the "I want to see the interdiff" use case; need to push something to
> MozReview before rebasing to address that.
>
>
> -Boris
> ___
> 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: Proposed changes to Talos (performance) alerting

[Mike Conley]

>> 
>> As Joel mentioned, it's pretty easy to schedule profiling runs for talos
>> using trychooser. Scheduling a profiling run as part of the
>> regression-filing process is something we could consider doing, if
>> there's a broad consensus it would be useful (I'm always wary of putting
>> extra load on the machines for something that would be only useful in
>> 10%, say, of cases).

I think it would be very useful. Performance profiles are, imo, the best
first step in attempting to drill down into the main issue causing the
regression.

> (I'm always wary of putting
>>> extra load on the machines for something that would be only useful in
>>> 10%, say, of cases).

Note that for most cases you'd only need or want a single run (multiple
runs with profiling aren't generally useful unless you're looking for an
intermittent performance problem). You also wouldn't need to do a full
rebuild if you could trigger the single profiling run on the same builds
that we've been doing the retriggers on.

On 19/01/2016 10:06 AM, William Lachance wrote:
> On 2016-01-18 4:42 AM, Nicolas B. Pierron wrote:
>>
>> I agree, this should be the part of the developer to work that out, but
>> the TS Paint benchmark is out of the knowledge base of JS developers.  I
>> feel that the problem is reaching developers with a wording known by the
>> developers.
> 
> So we have a wiki page which describes each Talos test in detail, we
> link to these in all perf bugs, but it can be useful reading on its own.
> For example, ts_paint is described here:
> 
> https://wiki.mozilla.org/Buildbot/Talos/Tests#ts_paint
> 
> I'm sure some of the test descriptions could use some improvements, feel
> free to ask on #perf if anything's unclear.
> 
>> This is just a raw idea, but maybe this would make more sense to provide
>> a diff of profiles, and show what decreased / increased.  At least this
>> would make these benchmarks less obscure.
> 
> As Joel mentioned, it's pretty easy to schedule profiling runs for talos
> using trychooser. Scheduling a profiling run as part of the
> regression-filing process is something we could consider doing, if
> there's a broad consensus it would be useful (I'm always wary of putting
> extra load on the machines for something that would be only useful in
> 10%, say, of cases).
> 
> Will
> ___
> 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

Unsafe CPOWs are about to be outlawed in browser code

[Mike Conley]

 (cross-posted to both dev-platform and firefox-dev)

TL;DR: Shortly, I’ll be flipping a pref to outlaw unsafe CPOWs in almost
all browser code. Unsafe CPOWs inside add-on scopes should continue to work
properly. If you start seeing "unsafe CPOW usage forbidden” errors being
throw for a feature you’re working on in the Browser Console, it’s because
unsafe CPOWs have been outlawed and you should stop using them. Talk to me
if you run into problems.

Details:

“unsafe” CPOWs[1][2] are CPOWs that are accessed when the other process is
not currently blocked waiting for information from you. For example, if you
access gBrowser.selectedBrowser.contentDocumentAsCPOW.body when the content
process is garbage collecting, the parent will be blocked until the child
decides that it has a moment to service the synchronous message and return
the information that the parent needs. Unsafe CPOWS are generally pretty
horrible for performance, especially because we cannot know what state the
other process is in.

“safe” CPOWs are when the other process is in a known blocked state - for
example, the content process sends a synchronous message to the parent
asking for some information, and is blocked waiting for a response. The
parent then accesses CPOWs in the content process safely, because the
content process is in a known state. The only overhead here is the IPC
traffic.

“unsafe” CPOWs are often used by add-ons to synchronously manipulate
content. A year or so back, a bunch of browser code also used unsafe CPOWs
in this way, but we’ve been slowly but surely weeding them out. We’re at
the state now where we believe we’ve eliminated most of the in-browser
unsafe CPOW uses[3].

Within the next day or so, I’m going to be landing bug 1233497[4] which
will cause unsafe CPOW usage in non-addon browser code to throw. In the
event that this breaks things horribly, there is a pref[5] that we can flip
to turn unsafe CPOWs back on while we fix things.

Again, this work is occurring in bug 1233497[4]. If there are any major
concerns, please bring them up here before I throw the spaghetti into the
machine.

For more details on unsafe CPOWs, please read [1] and/or [2].

[1]:
https://mikeconley.ca/blog/2015/02/17/on-unsafe-cpow-usage-in-firefox-desktop-and-why-is-my-nightly-so-sluggish-with-e10s-enabled/
[2]: http://blog.lassey.us/2015/01/10/unsafe-cpow-usage/
[3]: Outside of tests, and a few other little things that there are
follow-ups for.
[4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1233497
[5]: dom.ipc.cpows.forbid-unsafe-from-browser
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Too many oranges!

[Mike Conley]

I would support scheduled time[1] to do maintenance[2] and help improve our
developer tooling and documentation. I'm less sure how to integrate such a
thing in practice.

[1]: A day, a week, heck maybe even a release cycle
[2]: Where maintenance is fixing oranges, closing out papercuts,
refactoring, etc.

On 21 December 2015 at 17:35,  wrote:

> On Monday, December 21, 2015 at 1:16:13 PM UTC-6, Kartikaya Gupta wrote:
> > So, I propose that we create an orangefactor threshold above which the
> > tree should just be closed until people start fixing intermittent
> > oranges. Thoughts?
> >
> > kats
>
> How about regularly scheduled test fix days where everyone drops what they
> are doing and spends a day fixing tests? mc could be closed to everything
> except critical work and test fixes. Managers would be able to opt
> individuals out of this as needed but generally everyone would be expected
> to take part.
>
> Jim
> ___
> 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: Too many oranges!

[Mike Conley]

You had me at "quality". :)

On 22/12/2015 11:16 AM, Douglas Turner wrote:
> Mike -- totally supportive of this. I would *love* to see a release
> cycle completely dedicated to quality.  We branch again on January 26. 
> We could use that cycle to focus on nothing but quality (fixing tests,
> bug triaging, no feature development at all).
> 
> Thoughts?
> 
> On Tue, Dec 22, 2015 at 7:41 AM Mike Conley <mcon...@mozilla.com
> <mailto:mcon...@mozilla.com>> wrote:
> 
> I would support scheduled time[1] to do maintenance[2] and help
> improve our
> developer tooling and documentation. I'm less sure how to integrate
> such a
> thing in practice.
> 
> [1]: A day, a week, heck maybe even a release cycle
> [2]: Where maintenance is fixing oranges, closing out papercuts,
> refactoring, etc.
> 
> On 21 December 2015 at 17:35, <jmath...@mozilla.com
> <mailto:jmath...@mozilla.com>> wrote:
> 
> > On Monday, December 21, 2015 at 1:16:13 PM UTC-6, Kartikaya Gupta
> wrote:
> > > So, I propose that we create an orangefactor threshold above
> which the
> > > tree should just be closed until people start fixing intermittent
> > > oranges. Thoughts?
> > >
> > > kats
> >
> > How about regularly scheduled test fix days where everyone drops
> what they
> > are doing and spends a day fixing tests? mc could be closed to
> everything
> > except critical work and test fixes. Managers would be able to opt
> > individuals out of this as needed but generally everyone would be
> expected
> > to take part.
> >
> > Jim
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org <mailto:dev-platform@lists.mozilla.org>
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org <mailto: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: SPS Profiles are now captured for entire subprocess lifetime

[Mike Conley]

Part of the way. The last bit is to de-duplicate all of the Profiler.js
scripts in talos, and get them to use the asynchronous mechanisms for
profile gathering and writing (since they're currently using
dumpProfileToFile, which prevents us from getting out-of-process profiles).

That'll be in bug 1182595, I think.

Almost there. :)



On 3 December 2015 at 17:27, Kartikaya Gupta <kgu...@mozilla.com> wrote:

> \o/
>
> Does this get us all the way to "profile talos runs with e10s
> enabled", or are there still pieces missing for that? IIRC this set of
> patches was a prerequisite for being able to do that.
>
> On Thu, Dec 3, 2015 at 4:52 PM, Mike Conley <mcon...@mozilla.com> wrote:
> > Just a heads up that there have been recent developments with regards to
> > gathering SPS profiles from multiple processes.
> >
> > Bug 1103094[1] recently landed in mozilla-central, which makes it so that
> > if a subprocess starts up _after_ profiling has already been started in
> the
> > parent, then the subprocess will start profiling as well using the same
> > features and settings as the parent.
> >
> > Bug 1193838[2], which is still on inbound, will make it so that if we are
> > profiling while a process exits, we will hold onto that profile until the
> > profiles are all requested by the parent process for analysis. Right now
> we
> > hold these "exit profiles" in a circular buffer that's hardcoded at an
> > arbitrary limit of 5 profiles.
> >
> > The upshot is that in many cases, if you start profiling, you'll not lose
> > any profiles for subprocesses that start or finish before you choose to
> > analyze the profiles. \o/
> >
> > Just wanted to point those out. Thanks to BenWa for the reviews! Happy
> > profiling,
> >
> > -Mike
> >
> > [1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1103094
> > [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1193838
> > ___
> > 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

SPS Profiles are now captured for entire subprocess lifetime

[Mike Conley]

Just a heads up that there have been recent developments with regards to
gathering SPS profiles from multiple processes.

Bug 1103094[1] recently landed in mozilla-central, which makes it so that
if a subprocess starts up _after_ profiling has already been started in the
parent, then the subprocess will start profiling as well using the same
features and settings as the parent.

Bug 1193838[2], which is still on inbound, will make it so that if we are
profiling while a process exits, we will hold onto that profile until the
profiles are all requested by the parent process for analysis. Right now we
hold these "exit profiles" in a circular buffer that's hardcoded at an
arbitrary limit of 5 profiles.

The upshot is that in many cases, if you start profiling, you'll not lose
any profiles for subprocesses that start or finish before you choose to
analyze the profiles. \o/

Just wanted to point those out. Thanks to BenWa for the reviews! Happy
profiling,

-Mike

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1103094
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1193838
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Faster Windows builds on Try

[Mike Conley]

This is the greatest! Thank you so much!

On 19/11/2015 3:23 PM, Chris AtLee wrote:
> Over the past months we've been working on migrating our Windows builds
> from the legacy hardware machines into Amazon.
> 
> I'm very happy to announce that we've wrapped up the initial work here, and
> all our Windows builds on Try are now happening in Amazon.
> 
> The biggest win from this is that our Windows builds are now nearly 30
> minutes faster than they used to be. As of today, windows builds on try
> generally take around 50 minutes to complete, down from 1h20 before. Our
> next step is to migrate the non-try builds onto Amazon as well.
> 
> Big thanks to Rob, Mark, and the rest of our Release Engineering and
> Operations team for making this possible!
> 
> Cheers,
> Chris
> 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1199267
> ___
> 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: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

[Mike Conley]

>> That makes no sense to me!

It might make no sense, but it's what Chromium has been shipping for (at
least) the last while. Not saying it's right, just saying that's where
it is.

I've updated my testcase[1] to demonstrate. There is now a click event
handler on the "Friday" , and the  defaults to showing
inline 's.

In Chrome, click Friday. Then toggle the "inline select" checkbox, and
then choose Friday from the dropdown. You'll only see the event handler
fire in the first case.

I guess this is what happens when the spec is unclear. :/

The easy path forward on bug 1090602 is to follow Chrome's approach. The
harder path is to try to maintain what we currently do (and fire events
with the dropdown and without).

So what should we do? Who makes the decision on this?

[1]: https://bug1090602.bmoattachments.org/attachment.cgi?id=8674977

On 2015-10-16 12:56 PM, Ehsan Akhgari wrote:
> On 2015-10-16 12:16 PM, Justin Dolske wrote:
>> On 10/16/15 7:20 AM, Ehsan Akhgari wrote:
>>> On 2015-10-15 5:00 PM, Mike Conley wrote:
>>>> Note that this should not affect Gecko’s behaviour when the  is
>>>> displayed “inline” (for example, when the  has a “multiple”
>>>> attribute, or a “size” attribute with a value greater than 1). I'm only
>>>> concerned with the dropdown case.
>>>
>>> Why should the behavior be different with non-drop-down select elements?
>>
>> It makes sense to me because in the drop-down case, the user is
>> interacting with chrome UI (as opposed to something actually in
>> content).  Same thing with context menus, autocomplete dropdowns, etc.
> 
> That sounds like justifying a specific behavior to me.  Here is the
> counter argument:
> 
> The author has a  in their app.  They are relying on
> receiving the events on the option elements.  Then they add a
> mySel.removeAttribute("size") call and suddenly their event handlers
> stop working?!
> 
> That makes no sense to me!
> 
> ___
> 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: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

[Mike Conley]

>> Why should the behavior be different with non-drop-down select elements?

The difference in behaviour is something that the other browsers _do_
seem to agree upon. When the  elements are inline (with the
multiple attribute, or size attribute set to > 1), it seems from my
testing that all browsers seem to fire events for mouseover, mousedown,
keyup, keydown, etc.

It's only the dropdown case that seems to be special for each browser -
likely due to the fact that the spec is vague for that case.

On 2015-10-16 10:20 AM, Ehsan Akhgari wrote:
> On 2015-10-15 5:00 PM, Mike Conley wrote:
>> Note that this should not affect Gecko’s behaviour when the  is
>> displayed “inline” (for example, when the  has a “multiple”
>> attribute, or a “size” attribute with a value greater than 1). I'm only
>> concerned with the dropdown case.
> 
> Why should the behavior be different with non-drop-down select elements?
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

[Mike Conley]

>> You should check what the HTML standard says and file an issue if it> 
>> doesn't match what you want browsers to do.

Unfortunately, the HTML standard doesn't say much with respect to what
events  elements are supposed to fire, and when.

Once we come to a conclusion here, perhaps I'll work with you to hammer
out that part of the spec.

On 2015-10-16 4:12 AM, Anne van Kesteren wrote:
> On Thu, Oct 15, 2015 at 11:00 PM, Mike Conley <mcon...@mozilla.com> wrote:
>> Are there any objections or thoughts about this plan?
> 
> You should check what the HTML standard says and file an issue if it
> doesn't match what you want browsers to do.
> 
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Proposal to converge with Chromium / Blink for not firing events on ’s from dropdowns

[Mike Conley]

 Hey dev-platform,

TL;DR: I want Gecko to stop firing events on ’s on 
dropdowns.

Context:

Bug 1090602 was filed way back in the day by someone who used the old
Treestatus app, because they noticed it was broken once e10s was flipped on
by default. The problem was that the old Treestatus app was putting a click
event listener on a  to detect changes to the  and update
some state somewhere. With e10s (where the  dropdown is actually
opening in the parent), we weren’t triggering events on the selected
 in the content process.

So I’ve been hemming and hawing about how best to solve this, and I even
started working on the machinery to capture and synthesize the events from
the parent-side [1]. This ended up looking like a big pile of
work.

That’s when I found out that event behaviour for ’s is not spec’d
out, and the way in which events are fired differs widely from browser to
browser.

I tested Firefox Nightly (non-e10s), Safari, Chrome, Internet Explorer and
Edge, and posted my findings at [2].

What I’m proposing is that we try to converge with Chrome / Blink’s
behaviour on these events, where we do not fire any events on ’s,
ever, whenever e10s is enabled by default.

That’d greatly simplify my work in bug 1090602 - it’d basically be a
WONTFIX.

Note that this should not affect Gecko’s behaviour when the  is
displayed “inline” (for example, when the  has a “multiple”
attribute, or a “size” attribute with a value greater than 1). I'm only
concerned with the dropdown case.

Are there any objections or thoughts about this plan? Are there more events
that I've not considered in my manual test case[3] that I should test?

-Mike

[1]: Yep, that’s currently how we show the  dropdowns. We know
there are still usability problems with e10s’s  dropdowns, but this
email is not regarding those usability problems.
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1090602#c27
[3]: https://bug1090602.bmoattachments.org/attachment.cgi?id=8674454
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to unship: dialog=1 for window.open from web content

[Mike Conley]

One of the arguments to window.open[1] is a “feature string” that is
used to do things like set the size of the newly opened window, to set
whether or not it is resizable, etc.

Gecko currently supports a “dialog” feature that is really only evident
on Windows platforms. This dialog feature essentially hides the
minimize, maximize and restore buttons in the window titlebar. It also
hides the “command” icon (that’s the program icon usually visible in the
top-left corner of a popup window on Windows). Note that it doesn’t
disable the minimizing / maximizing capabilities of the window, it just
hides the buttons. Right-clicking on the titlebar brings up a popup that
allows the user to control the window.

From what I can tell, this is a super old feature, and Gecko is the only
web engine to support it. All other engines just ignore that setting.

Bug 1095236 was filed because when an e10s-enabled Gecko encounters a
window.open with “dialog=1” or “dialog=yes” in the feature string, it
failed to open the window. I didn’t find enough cause for Gecko to keep
supporting the feature when I posted to dev-platform earlier in the
week[2], so I have prepared patches that cause Gecko to ignore the
feature as well for both e10s and non-e10s. This will allow this
window.open calls to work with e10s-enabled Gecko again.

Note that this does not disable the dialog=1 feature when window.open is
called from privileged code from the parent process.

Patches are available in the bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1095236

fxcompat has already put up a post:
https://www.fxsitecompat.com/en-US/docs/2015/dialog-option-for-window-open-is-no-longer-supported/

I’ll be landing these patches early next week in mozilla-central unless
I hear a really compelling argument not to.

-Mike

References:

[1]: https://developer.mozilla.org/en-US/docs/Web/API/Window/open
[2]:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/cDpULPod8nQ
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: dialog=1 for window.open from content

[Mike Conley]

Unfortunately, it looks like the kind of counter I would need is not yet
supported[1].

Even if some bank in the world is using dialog=1, what does it give
them? It doesn't change the behaviour of the window like showModalDialog
(which runs in a nested event loop), it just changes the buttons
available on the window chrome, and only on Windows. It also doesn't
necessarily prevent the user from accessing those functions, since
right-clicking on the titlebar allows the user to access a context menu
for minimizing, maximizing, etc.

So, to sum, dialog=1 seems to have a Windows-only cosmetic effect that
only Gecko supports, and if anything, I would argue that it weakens user
control by hiding functions that Windows user would expect on a popup.

I've posted a patch in bug 1095236 that causes us to ignore
dialog=1/dialog=yes from window.opens sent by content.

Am I skipping any kind of procedure here in essentially deprecating a
web feature? Is there an "intent to unship" thing that I need to do? Or
some kind of group that I need to get sr from?

-Mike

[1]: Bug 1175033

On 02/10/2015 4:34 AM, Mike Taylor wrote:
> 
> 
> On 10/2/15 2:53 AM, Ehsan Akhgari wrote:
>>> Before I go whole-hog trying to fix bug 1095236, I'm curious to know if
>>> we really want to continue supporting dialog=1 from content, or if it's
>>> safe to just ignore that feature like the other browser engines (which I
>>> think would be the fastest path towards fixing bug 1095236).
>>>
>>> Are there any really good arguments to keep supporting it?
>>
>> A good argument, no.  But these things can end up having a web compat
>> impact.  I personally think that the risk of web compat is not that high
>> here but if we want to be sure, we can add a use counter for the feature
>> and measure how much it's used in the release population, and decide
>> based on that.
> 
> I agree with Eshan here. Usually it's banks scattered around the world
> that depend on these obscure features. And banks are some of the
> trickiest sites to diagnose (people don't trust me with their online
> bank login details, weirdest thing) and *then* you have to convince the
> bank to update their sites.
> 
> But yeah, the guesswork goes away with a use counter.
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

dialog=1 for window.open from content

[Mike Conley]

Hello dev-platform,

I'm currently working on bug 1095236 - that's an e10s bug for us failing
to open any windows if the features string includes dialog=1 (or
dialog=yes).

According to [1], setting dialog=1 makes a popup window that removes the
min/max/restore buttons, and no "command" menu (the icon usually
appearing in the top left which opens the Restore, Move, Size, etc
options). Note that this is only really apparent on Windows, where we
default to having such buttons on popups.

Also according to [1], Gecko is the only web engine to support that feature.

Before I go whole-hog trying to fix bug 1095236, I'm curious to know if
we really want to continue supporting dialog=1 from content, or if it's
safe to just ignore that feature like the other browser engines (which I
think would be the fastest path towards fixing bug 1095236).

Are there any really good arguments to keep supporting it?

-Mike

[1]:
https://developer.mozilla.org/en-US/docs/Web/API/Window/open?redirectlocale=en-US=DOM%2Fwindow.open#Window_functionality_features
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is there any events before loading a URL to a docshell.

[Mike Conley]

Hey Yonggang,

You might find nsIWebProgressListener useful:
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/Reference/Interface/nsIWebProgressListener

Specifically the onLocationChange method. This is fired once we've
determined that we're going to load a new URI for a DOM Window.

From the passed in nsIWebProgress[1], you should be able to get at the
nsIDOMWindow, and from there, I *think* you can get to the nsIDocShell
by QI'ing the nsIWebProgress to an nsIInterfaceRequestor and then
GetInterface'ing nsIDocShell. I haven't tried this, but I'm reasonably
certain it will work.

-Mike

[1]:
https://dxr.mozilla.org/mozilla-central/rev/9ed17db42e3e46f1c712e4dffd62d54e915e0fac/uriloader/base/nsIWebProgress.idl#134

On 13/09/2015 8:17 AM, 罗勇刚(Yonggang Luo)  wrote:
> So that I know what's the docshell is and the URL is.
> 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Proposal to remove `aFoo` prescription from the Mozilla style guide for C and C++

[Mike Conley]

I suspect that knowing what things were passed into a method or function
is something that can be divined via static analysis.

Aren't there tools for our (admittedly varied) editors / IDEs to make
the readability that people are getting from aFoo readily available, but
that don't also require us to pack it into the actual name of the variable?

On 07/07/2015 11:44 AM, Boris Zbarsky wrote:
 On 7/7/15 11:36 AM, Jeff Muizelaar wrote:
 FWIW, I did a quick poll of the people in our Gfx daily. Here are the
 results:
 
 To add some more split opinions to the situation, I rather like the
 aArgument form precisely because it makes it easier to trace dataflow.
 Though the fact that some functions assign to the aArgument does make it
 harder.
 
 On the other hand, the last time we had this conversation (it just keeps
 happening, doesn't it?) roc pointed out that the aFoo convention makes
 it harder to refactor things into helper functions (or out of them):
 suddenly something that was a function local becomes an argument to the
 helper, and you have to rename it throughout the helper function body. I
 seem to recall that he also posited that this makes us less willing to
 refactor things into smaller functions than we should be.  I don't have
 a good counterargument for this; I think he's right about this drawback
 of the aFoo convention.
 
 -Boris
 ___
 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: Shutdown hangs are very common

[Mike Conley]

 Should fixing shutdown hangs be higher priority?

Starting and shutting down properly (and quickly), IMO, fall into the
core quality / no compromise / we have to get this right bucket.

So making it higher priority sounds aligned with the Three Pillars.

 And if so, should we allow features with shutdown hangs to be released?

Probably depends on the feature and how frequent / severe the shutdown
hangs are with it. Not sure we can make a blanket judgement right here
and now about it, unless we want to go hard-line on this.


On 06/07/2015 4:34 PM, Vladan D wrote:
 Should fixing shutdown hangs be higher priority?
 And if so, should we allow features with shutdown hangs to be released?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Is there an e10s plan for multiple content processes?

[Mike Conley]

 Is there a more detailed description of what the issues with multiple 
 content processes are that e10s itself doesn't suffer from?

I'm interpreting this as, What are the problems with multiple content
processes that single process does not have, from the user's perspective?

This is mostly unknown, simply because dom.ipc.processCount  1 is not
well tested. Most (if not all) e10s tests test a single content process.
As a team, when a bug is filed and we see that it's only reproducible
with dom.ipc.processCount  1, the priority immediately drops, because
we're just not focusing on it.

So the issues with dom.ipc.processCount are mostly unknown - although a
few have been filed:
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=processCountlist_id=12230722

 One of the extremely common cases where I used to get the spinner was when 
 my system was under load (outside of Firefox.)  I doubt that we're going to 
 be able to fix anything in our code to prevent showing the spinner in such 
 circumstances. 

Yes, I experience that too - I often see the spinner when I have many
tabs open and I'm doing a build in the background.

I think it's worth diving in here and investigating what is occurring in
that case. I have my suspicions that
https://bugzilla.mozilla.org/show_bug.cgi?id=1161166 is a big culprit on
OS X, but have nothing but profiles to back that up. My own experience
is that the spinner is far more prevalent in the many-tabs-and-build
case on OS X than on other platforms, which makes me suspect that we're
just doing something wrong somewhere - with bug 1161166 being my top
suspect.

 Another such common case would be one CPU hungry tab.

I think this falls more under the domain of UX. With single-process
Firefox, the whole browser locks up, and we (usually) show a modal
dialog asking the user if they want to stop the script. In other cases,
we just jank and fail to draw frames until the process is ready.

With a content process, the UI remains responsive, but we get this
bigass spinner. That's not an amazing trade-off - it's much uglier and
louder, IMO, than the whole browser locking up. The big spinner was just
an animation that we tossed in so that it was clear that a frame was not
ready (and to avoid just painting random video memory), but I should
emphasize that it was never meant to ship.

If we ship the current appearance of the spinner to our release
population... it would mean that my heels have been ground down to nubs,
because I will fight tooth and nail to prevent that from happening. I
suspect UX feels the same.

So for the case where the content process is being blocked by heavy
content, we might need to find better techniques to communicate to the
user what's going on and to give them options. I suspect / hope that bug
1106527 will carry that work.

Here's what I know:

1) Folks are reporting that they _never_ see the spinner when they crank
up dom.ipc.processCount  1. This is true even when they're doing lots
of work in the background, like building.

Here's what I suspect:

1) I suspect that given the same group of CPU heavy tabs, single-process
Firefox will currently perform better than e10s with a single content
process. I suspect we can reach parity here.

2) I suspect that OS X is where most of the pain is, and I suspect bug
1161166 is a big part of it.

Here's what I suggest:

1) Wait for Telemetry data to come in to get a better sense of who is
being affected and what conditions they are under. Hopefully, the
population who have dom.ipc.processCount  1 are small enough that we
have useful data for the dom.ipc.processCount = 1 case.

2) Send me profiles for when you see it.

3) Be patient as we figure out what is slow and iron it out. Realize
that we're just starting to look at performance, as we've been focusing
on stability and making browser features work up until now.

4) Trust that we're not going to ship The Spinner Experience, because
shipping it as-is is beyond ill-advised. :D

-Mike

On 05/05/2015 10:49 AM, Ehsan Akhgari wrote:
 On 2015-05-05 10:30 AM, Mike Conley wrote:
 The e10s team is currently only focused on getting things to work with a
 single content process at this time. We eventually want to work with
 multiple content processes (as others have pointed out, the exact number
 to work with is not clear), but we're focused on working with a single
 process because we believe this is a strictly easier backdrop to develop
 against.

 Once we've got single content process nailed down, we can then start
 exploring multiple content processes.
 
 I like roc and some other colleagues have also set the process count
 pref to 10 for a while and have not noticed any issues that were not
 present with one content process.  However, I realize that a few
 people's anecdotes cannot be a good enough reason to change what we're
 planning to do here.  :-)
 
 Is there a more detailed description of what the issues with multiple
 content processes are that e10s itself doesn't

Re: Is there an e10s plan for multiple content processes?

[Mike Conley]

Funny folks should bring this up - I recently wrote a blog post about this:

http://mikeconley.ca/blog/2015/05/04/electrolysis-and-the-big-tab-spinner-of-doom/

Funny how things cluster. :) I suggest reading that top to bottom before
you continue reading this post.

...

Welcome back! :D

The e10s team is currently only focused on getting things to work with a
single content process at this time. We eventually want to work with
multiple content processes (as others have pointed out, the exact number
to work with is not clear), but we're focused on working with a single
process because we believe this is a strictly easier backdrop to develop
against.

Once we've got single content process nailed down, we can then start
exploring multiple content processes.

We might revisit that decision as things stabilize, but in the meantime
I want to stress something: if you're cranking up dom.ipc.processCount
to avoid the spinner, I suspect you are probably wallpapering over the
issue, and robbing us of data. We've just landed Telemetry probes to get
tab switch and spinner times[1]. If you bump up dom.ipc.processCount to
avoid the spinner, we miss out on knowing when you _would_ have seen the
spinner. This makes it harder for us to know whether or not things are
improving or getting worse. It makes it harder for us to identify
patterns about what conditions cause the spinner to appear.

We are just starting to get to the point where we're looking at
performance, and I think what would be very valuable is for people to
set dom.ipc.processCount to 1, and give us profiles for when they see
the spinner. Upload the profiles, and paste a link to them in [2]. I
will happily look at them or forward them to people smarter than I to
look at them.

There's a video in my blog post demonstrating how to get and use the
profiler, if you've never used it before.

Profiling has already been fruitful! Just yesterday, we identified [3]
as a pretty brutal bottleneck for tab switching on OS X.

So don't just run away from the spinner - help us drive a flaming stake
through its heart with profiles. I think that'd be the best course of
action on this issue.

-Mike

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1156592
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1135719
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1161166

On 05/05/2015 6:53 AM, Ted Mielczarek wrote:
 On Tue, May 5, 2015, at 02:53 AM, Leman Bennett (Omega X) wrote:
 On 5/5/2015 12:23 AM, Robert O'Callahan wrote:
 On Tue, May 5, 2015 at 10:29 AM, Leman Bennett (Omega X) 
 Redacted.For.Spam@request.contact wrote:

 Inquiring minds would like to know.

 At the moment, e10s tabs is still somewhat slower than non-e10s. Multiple
 content processes would go a long way for more responsive navigation and
 less stalls on the one content process. That stall spinner is getting a LOT
 of hate at the moment.


 I don't know, but I've enabled multiple content processes, and I haven't
 noticed any problems --- and the spinner does seem to be shown a lot less.

 Rob


 The issue I've seen with dom.ipc.processCount beyond one process is that 
 they're not dynamic. Those instances will stay open for the entire 
 session and not unload themselves after a time which can mean double the 
 memory use.

 I heard that there was rumor of a plan to limit process count spawn to 
 per-domain. But I've not seen offhand of a bug filed for it or anything 
 else that relates to achieving more than one content process instance.
 
 There's a bug filed[1], but every time I've asked about it I've been
 told it's not currently on the roadmap. I, too, find that single-process
 e10s is worse for responsiveness, which is unfortunate. Last time I
 tried to use dom.ipc.processCount  1 I found that window.open was
 broken (and also target=_blank on links) which made actual browsing
 difficult, but I haven't tested it recently.
 
 I also filed a couple of bugs[2][3] about being smarter about multiple
 content processes which would make things a bit nicer.
 
 -Ted
 
 1. https://bugzilla.mozilla.org/show_bug.cgi?id=641683
 2. https://bugzilla.mozilla.org/show_bug.cgi?id=1066789
 3. https://bugzilla.mozilla.org/show_bug.cgi?id=1066792
 ___
 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: Is there an e10s plan for multiple content processes?

[Mike Conley]

 My question is: after a decent period of time picking the low-hanging 
 fruit, if there is still non-trivial spinner time for processCount=1, would 
 the team consider shifting efforts to getting processCount1 ship-worthy 
 instead of resorting to heroics to get processCount=1 ship-worthy?

I can't speak for the whole team, and I'm not really a shot-caller for
the project, but I would definitely consider this in the scenario you've
laid out.

On 05/05/2015 12:11 PM, Luke Wagner wrote:
 It definitely makes sense to start your performance investigation with
 processCount=1 since that will likely highlight the low-hanging fruit
 which should be fixed regardless of processCount.
 
 My question is: after a decent period of time picking the low-hanging
 fruit, if there is still non-trivial spinner time for processCount=1,
 would the team consider shifting efforts to getting processCount1
 ship-worthy instead of resorting to heroics to get processCount=1
 ship-worthy?
 
 On Tue, May 5, 2015 at 10:41 AM, Mike Conley mcon...@mozilla.com
 mailto:mcon...@mozilla.com wrote:
 
  Is there a more detailed description of what the issues with multiple 
 content processes are that e10s itself doesn't suffer from?
 
 I'm interpreting this as, What are the problems with multiple content
 processes that single process does not have, from the user's
 perspective?
 
 This is mostly unknown, simply because dom.ipc.processCount  1 is not
 well tested. Most (if not all) e10s tests test a single content process.
 As a team, when a bug is filed and we see that it's only reproducible
 with dom.ipc.processCount  1, the priority immediately drops, because
 we're just not focusing on it.
 
 So the issues with dom.ipc.processCount are mostly unknown - although a
 few have been filed:
 
 https://bugzilla.mozilla.org/buglist.cgi?quicksearch=processCountlist_id=12230722
 
  One of the extremely common cases where I used to get the spinner was 
 when my system was under load (outside of Firefox.)  I doubt that we're 
 going to be able to fix anything in our code to prevent showing the spinner 
 in such circumstances.
 
 Yes, I experience that too - I often see the spinner when I have many
 tabs open and I'm doing a build in the background.
 
 I think it's worth diving in here and investigating what is occurring in
 that case. I have my suspicions that
 https://bugzilla.mozilla.org/show_bug.cgi?id=1161166 is a big culprit on
 OS X, but have nothing but profiles to back that up. My own experience
 is that the spinner is far more prevalent in the many-tabs-and-build
 case on OS X than on other platforms, which makes me suspect that we're
 just doing something wrong somewhere - with bug 1161166 being my top
 suspect.
 
  Another such common case would be one CPU hungry tab.
 
 I think this falls more under the domain of UX. With single-process
 Firefox, the whole browser locks up, and we (usually) show a modal
 dialog asking the user if they want to stop the script. In other cases,
 we just jank and fail to draw frames until the process is ready.
 
 With a content process, the UI remains responsive, but we get this
 bigass spinner. That's not an amazing trade-off - it's much uglier and
 louder, IMO, than the whole browser locking up. The big spinner was just
 an animation that we tossed in so that it was clear that a frame was not
 ready (and to avoid just painting random video memory), but I should
 emphasize that it was never meant to ship.
 
 If we ship the current appearance of the spinner to our release
 population... it would mean that my heels have been ground down to nubs,
 because I will fight tooth and nail to prevent that from happening. I
 suspect UX feels the same.
 
 So for the case where the content process is being blocked by heavy
 content, we might need to find better techniques to communicate to the
 user what's going on and to give them options. I suspect / hope that bug
 1106527 will carry that work.
 
 Here's what I know:
 
 1) Folks are reporting that they _never_ see the spinner when they crank
 up dom.ipc.processCount  1. This is true even when they're doing lots
 of work in the background, like building.
 
 Here's what I suspect:
 
 1) I suspect that given the same group of CPU heavy tabs, single-process
 Firefox will currently perform better than e10s with a single content
 process. I suspect we can reach parity here.
 
 2) I suspect that OS X is where most of the pain is, and I suspect bug
 1161166 is a big part of it.
 
 Here's what I suggest:
 
 1) Wait for Telemetry data to come in to get a better sense of who is
 being affected and what conditions they are under. Hopefully, the
 population who have dom.ipc.processCount  1 are small enough that we
 have useful data

Cleopatra can take larger profiles now.

[Mike Conley]

Good news everybody!

TL;DR: Cleopatra used to have a limitation where it would only accept
profiles of around 10MB. We've now made it so that Cleopatra can accept
much, much larger profiles. This is going to become increasingly
important as more profile-able processes get added.

As an added bonus, uploads should be much smaller, resulting in faster
upload times.

Here's the nitty-gritty:

The storage system we use for profiles is hosted on Google AppEngine.
When a user uploads a profile, we used to do server-side compression -
but the machine would run out of memory while attempting to compress a
large profile, and the OS would kill the process.

We have now exposed an endpoint that accepts pre-compressed profiles,
and added some code[1] to Cleopatra to do the client-side gzip[2]
compression of profiles.

So if you were all bummed out because Cleopatra couldn't accept your
gargantuan profiles, rejoice!

Thanks to jrmuizel and mstange for their server-side work and reviews.

-Mike

[1]:
https://github.com/bgirard/cleopatra/commit/fd7a0e08e51472c3f9b76447e386c44323dc4cbc
[2]: Emscripten'd zlib! https://github.com/kripken/zee.js
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: How to use review-board to post a set of changes?

[Mike Conley]

Hey Yonggang,

Your best bet is push your changesets to the MozReview repo - it'll do the
job of creating your review requests for you.

There is a little bit of setup involved in order to make it possible,
however - you need to install a Mercurial extension, and you need to
configure Mercurial so that it knows about your Bugzilla account and IRC
nick.

Instructions are rooted here:
https://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview-user.html

I'd start with this document:
https://mozilla-version-control-tools.readthedocs.org/en/latest/mozreview/install.html

And come chat in #mozreview if you have any questions.

Thanks!

-Mike

On 19 April 2015 at 09:54, Yonggang Luo luoyongg...@gmail.com wrote:

 I means do not post a single diff,
 but multiple diff.
 The current command
 rbt command will automatically merge multiple changes as a
 single diff and submit, how to avoid this
 ___
 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: Press Me! Button

[Mike Conley]

A quick scan through DXR doesn't show any reference to Press Me! or
Press Me in our strings, except for a likely coincidental match in
some accessibility test[1].

Can you show us a screenshot of this button?

[1]:
http://dxr.mozilla.org/mozilla-central/source/accessible/tests/mochitest/jsat/test_explicit_names.html

On 31/07/2014 12:25 PM, Martin Thomson wrote:
 Did I miss the announcement about this feature?  Nightly just told me
 about an add-on that it thinks I might want.  Apparently because I
 download a lot of files.
 ___
 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: e10s startup?

[Mike Conley]

At least for xul:browser where remote=true, we behave as you
describe; namely, we use the remote-browser binding defined in
toolkit/content/widgets/remote-browser.xml, which on construction,
injects a browser-child.js frame script via the message manager.


On 29/07/2014 4:58 AM, Neil wrote:
 How do toolkit components in content processes start themselves up, does
 it all have to be done through content scripts loaded by the message
 manager?
 
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Update on sheriff-assisted checkin-needed bugs

[Mike Conley]

 I try to mentor as many bugs as possible. My ideal workflow would be to
 grant r+, suggest a try: string, and set checkin-needed in a single act,
 without having to determine whether the contributor has try access and/or
 editbugs. If we already have people scanning for checkin-needed and looking
 for try pushes, it seems pretty logical to have them just trigger any
 missing pushes.

Or, alternatively, attempt to automate this with Autoland
(https://bugzilla.mozilla.org/show_bug.cgi?id=657828).

I think we should lean on that for this use case, personally.

On 21/05/2014 3:29 PM, Bobby Holley wrote:
 On Wed, May 21, 2014 at 9:33 AM, Steve Fink sf...@mozilla.com wrote:
 
 On Wed 21 May 2014 08:42:28 AM PDT, Ryan VanderMeulen wrote:
 Level 1 - Try/User/Incubator Access
 Because this is all it gives, this sort of access can be given out
 generously to anyone who would find it convenient when helping us or
 working on a developer's personal project, without worrying about them
 affecting core code. In other words, the target audience for this sort of
 access might be defined as friends of and collaborators with Mozilla.

 At least to me, that reads as vouch early and vouch often!. Something
 something...teach a man to fish...something something... :)

 I think the quote you're looking for is, if you teach a man to fish,
 you'd better teach him how to gut and clean the fish at the same time.
 Otherwise you'll be forever stuck doing it for him.

 
 Is it really the most effective learning experience and use of everyone's
 time to make first-patch contributors get set up with try access?
 
 I try to mentor as many bugs as possible. My ideal workflow would be to
 grant r+, suggest a try: string, and set checkin-needed in a single act,
 without having to determine whether the contributor has try access and/or
 editbugs. If we already have people scanning for checkin-needed and looking
 for try pushes, it seems pretty logical to have them just trigger any
 missing pushes.
 
 bholley
 ___
 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: Recommendations on source control and code review

[Mike Conley]

Whoa, didn't expect to see a blog post I wrote in grad school to get
called out here. :) Interesting to see it show up on the radar.

Re-reading it, I think the most interesting thing about the Cohen study
that I absorbed was the value of reviewing my own code before requesting
review from other people. I've found that when I look at my own code
using Splinter or Review Board, my brain switches into critique mode,
and I'm able to notice and flag the obvious things.

This has the dual benefit of making the code better, and making it
easier for my reviewer to not get distracted by minor things that I
could have caught on my own. I almost made this a topic for my graduate
study research paper[1], but then did this[2] instead.

Always happy to talk about code review,

-Mike

[1]:
http://mikeconley.ca/blog/2010/03/04/research-proposal-1-the-effects-of-author-preparation-in-peer-code-review/
[2]:
http://mikeconley.ca/blog/2010/12/23/the-wisdom-of-peers-a-motive-for-exploring-peer-code-review-in-the-classroom/

On 11/04/2014 5:32 PM, Chris Peterson wrote:
 Code review tool company SmartBear published an interesting study [1] of
 the effectiveness of code reviews at Cisco. (They used SmartBear's
 tools, of course.) Mozillian Mike Conley reviewed SmartBear's study on
 his blog [2].
 
 The results are interesting and actionable. Some highlights:
 
 * Review fewer than 200-400 lines of code at a time.
 * Spend no more than 60-90 minutes per review session.
 * Authors should pre-review their own code before submitting a review
 request and add explanations and questions to guide reviewers.
 
 
 chris
 
 
 [1]
 http://smartbear.com/SmartBear/media/pdfs/WP-CC-11-Best-Practices-of-Peer-Code-Review.pdf
 
 
 [2]
 http://mikeconley.ca/blog/2009/09/14/smart-bear-cisco-and-the-largest-study-on-code-review-ever/
 
 
 
 
 
 On 4/11/14, 1:29 PM, Gregory Szorc wrote:
 I came across the following articles on source control and code review:

 *
 https://secure.phabricator.com/book/phabflavor/article/recommendations_on_revision_control/


 *
 https://secure.phabricator.com/book/phabflavor/article/writing_reviewable_code/


 *
 https://secure.phabricator.com/book/phabflavor/article/recommendations_on_branching/



 I think everyone working on Firefox should take the time to read them as
 they prescribe what I perceive to be a very rational set of best
 practices for working with large and complex code bases.

 The articles were written by a (now former) Facebooker and the
 recommendations are significantly influenced by Facebook's experiences.
 They have many of the same problems we do (size and scale of code base,
 hundreds of developers, etc). Some of the pieces on feature development
 don't translate easily, but most of the content is relevant.

 I would be thrilled if we started adopting some of the recommendations
 such as more descriptive commit messages and many, smaller commits over
 fewer, complex commits.
 
 ___
 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: Poll: What do you need in MXR/DXR?

[Mike Conley]

I love DXR for mozilla-central, and would love it if the UX branch 
(https://mxr.mozilla.org/projects-central/source/ux/) was indexed there 
as well!


Keep up the great work,

-Mike

On 02/10/2013 3:33 PM, Erik Rose wrote:

What features do you most use in MXR and DXR?

Over in the recently renamed Web Engineering group, we're working hard to 
retire MXR. It hasn't been maintained for a long time, and there's a lot of 
duplication between it and DXR, which rests upon a more modern foundation and 
has been developing like crazy. However, there are some holes we need to fill 
before we can expect you to make a Big Switch. An obvious one is indexing more 
trees: comm-central, aurora, etc. And we certainly have some bothersome UI bugs 
to squash. But I'd like to hear from you, the actual users, so it's not just me 
and Taras guessing at priorities.

What keeps you off DXR? (What are the MXR things you use constantly? Or the 
things which are seldom-used but vital?)

If you're already using DXR as part of your workflow, what could it do to make 
your work more fun?

Feel free to reply here, or attach a comment to this blog post, which talks 
about some of the things we've done recently and are considering for the future:

https://blog.mozilla.org/webdev/2013/09/30/dxr-gets-faster-hardware-vcs-integration-and-snazzier-indexing/

We'll use your input to build our priorities for Q4, so wish away!

Cheers,
Erik
___
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: Code Review Session

[Mike Conley]

Sounds like we're talking about code review.


But I want to qualify integration into bugzilla: I explicitly do not
want a tool that is tightly coupled to bugzilla.  In fact, I want a
tool that has as little to do with bugzilla as feasible.


I'm a contributor to the Review Board project[1], which is not coupled 
with Bugzilla whatsoever.


It also has an extension called ReviewBot[2], which can run patches 
through static analysis or automated tests, and inject the results 
automatically into the review request as a ReviewBot review.


It has support for teams / review groups, and multiple repositories 
(both private/public Github repos, as well as self-hosted hg repos).


I'm happy to answer questions about Review Board if anybody has any. If 
we're talking about considering new review tools, I think Review Board 
should be on the list of things to try.


Here are some pretty pictures: http://www.reviewboard.org/screenshots/

-Mike

[1]: http://www.reviewboard.org/
[2]: https://github.com/smacleod/ReviewBot

On 24/05/2013 10:50 AM, Justin Lebar wrote:

* I think we should experiment (again) with real pull-request integration
into bugzilla.


I'm totally in favor of better tools and real pull requests, and of
course the PRs need to be linked to bugzilla /somehow/.

But I want to qualify integration into bugzilla: I explicitly do not
want a tool that is tightly coupled to bugzilla.  In fact, I want a
tool that has as little to do with bugzilla as feasible.

I mean no disrespect to our bugzilla maintainers, who have an
impossible and largely thankless job, but bugzilla has so much baggage
from the '90s, my experience is that it ruins everything it touches.
Consider for example how much better harthur's fileit and dashboard
tools [1] [2] are than bugzilla's built-in equivalents.

We shouldn't conflate owning the PR data with integrating the PR tool
into bugzilla.  If we do, we risk ending up with yet another crappy
non-solution to a real problem (see bugzilla interdiff, splinter
integration, and so on).

-Justin

[1] http://harthur.github.com/fileit/
[2] http://harthur.github.io/bugzilla-todos/
___
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