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

[Jared Wein (Mozilla)]

I'd like to second Mike's note. Congratulations to Doug, Emma, and everyone
else who worked tirelessly on this feature to improve perceived
performance. Your work will have a lasting effect and is a big step forward
in Firefox's story as the fastest browser in the market.

- Jared

On Thu, Jan 7, 2021 at 10:55 AM Mike Conley  wrote:

> 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
>


-- 
Jared Wein
Senior Staff Software Engineer, Firefox
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Dogfooding Warp

[Jared Wein (Mozilla)]

Hi Jan,

Thanks for the update and congratulations on reaching this milestone.

Would you like to add Warp to the list of experimental features in
about:preferences? When a feature is listed there, it will appear in crash
stats and about:support, and also give users an easy way to enable/disable.
Feel free to contact me off-list if you are interested. I'm happy to help.

Thanks,
Jared

On Tue, Sep 15, 2020 at 8:58 AM Jan de Mooij  wrote:

> Hi all,
>
> The SpiderMonkey (JS) team has been working on a significant update to
> our JITs called WarpBuilder (or just Warp) [0,1]. Before we enable
> Warp by default in Nightly (hopefully next cycle in 83) we need your
> help dogfooding it.
>
> Warp improves performance by reducing the amount of internal type
> information that is tracked, optimizing for a broader spectrum of
> cases, and by leveraging the same CacheIR optimizations used by last
> year’s BaselineInterpreter work [2]. As a result, Warp has a much
> simpler design and improves responsiveness and page load performance
> significantly (we're seeing 5-15% improvements on many visual metrics
> tests). Speedometer is about 10% faster with Warp. The JS engine also
> uses less memory when Warp is enabled.
>
> To enable Warp in Nightly:
>
> 1. Update to a recent Nightly
> 2. Go to about:config and set the "javascript.options.warp" pref to true
> 3. Restart the browser
>
> We're especially interested in stability issues and real-world
> performance problems. Warp is currently slower on various synthetic JS
> benchmarks such as Octane (which we will continue investigating in the
> coming months) but should perform well on web content.
>
> If you find any issues, please file bugs blocking:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=1613592
>
> If you notice any improvements, we'd love to hear about those too.
>
> Finally, we want to thank our amazing contributors André Bargull and
> Tom Schuster for their help implementing and porting many
> optimizations.
>
> Turning Warp on is only our first step, and we expect to see a lot of
> new optimization work over the next year as we build on this. We are
> excited for what the future holds here.
>
> Thanks!
> The Warp team
>
> [0] WarpBuilder still utilizes the backend of IonMonkey so we don't
> feel it has earned the WarpMonkey name just yet.
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1613592
> [2]
> https://hacks.mozilla.org/2019/08/the-baseline-interpreter-a-faster-js-interpreter-in-firefox-70/
> _______
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>


-- 
Jared Wein
Staff Software Engineer, Firefox
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Experimental Features in about:preferences

[Jared Wein (Mozilla)]

Thanks Sebastian. I intend to have the features listed on that webpage
reflected in the new about:preferences#experimental page.

Cheers,
Jared

On Sat, Jun 27, 2020 at 5:35 PM Sebastian Zartner <
sebastianzart...@gmail.com> wrote:

> I'd like to point out that there is also an MDN page listing experimental
> features:
>
> https://developer.mozilla.org/docs/Mozilla/Firefox/Experimental_features
>
> Maybe that page could be linked to from the new section? And maybe other
> features listed there could be added to the section?
>
> Best regards,
>
> Sebastian
>
> On Friday, June 26, 2020 at 6:14:23 AM UTC+2, Jared Wein (Mozilla) wrote:
> > Hello,
> >
> > The Firefox Preferences (about:preferences) is gaining a new section
> called
> > "Firefox Experiments" ("Nightly Experiments" on Nightly builds). This
> > section will list features that are in-development or otherwise awaiting
> > some kind of feedback before being enabled by default.
> >
> > Experimental features can be displayed based on release channel (Nightly,
> > DevEdition, Beta, Release) and platform (Windows, macOS, Linux). This
> work
> > is based on FeatureGates[1] as implemented by the Normandy team.
> >
> > As of bug 1648223 this work is now enabled by default in Firefox Nightly
> > builds, and may ship with Firefox 79 though could be held back to Firefox
> > 80 if we want to get a larger list of experimental features.
> >
> > If you have a feature that you would like wider testing of, please file a
> > bug in Firefox::Preferences and add your feature to
> > toolkit/components/featuregates/Features.toml. See the documentation[1]
> for
> > details on feature definitions. Bug 1648223 is on autoland now and
> includes
> > some updates to the documentation.
> >
> > A new section, "Experimental Features", has been added to about:support
> to
> > list the state of the features to help with bug reports. Bug 1644544 is
> on
> > autoland to annotate crash-stats with the state of the enabled
> Experimental
> > Features and there is planned work to allow engineers to optionally
> disable
> > their features when in Safe Mode.
> >
> > Thank you for reading this far. Please let me know if you have any
> > questions,
> > Jared
> >
> > [1]
> >
> https://firefox-source-docs.mozilla.org/toolkit/components/featuregates/featuregates/index.html
> >
> > --
> > Jared Wein
> > Staff Software Engineer, Firefox
> > Mozilla Corporation
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>


-- 
Jared Wein
Staff Software Engineer, Firefox
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Experimental Features in about:preferences

[Jared Wein (Mozilla)]

Hello,

The Firefox Preferences (about:preferences) is gaining a new section called
"Firefox Experiments" ("Nightly Experiments" on Nightly builds). This
section will list features that are in-development or otherwise awaiting
some kind of feedback before being enabled by default.

Experimental features can be displayed based on release channel (Nightly,
DevEdition, Beta, Release) and platform (Windows, macOS, Linux). This work
is based on FeatureGates[1] as implemented by the Normandy team.

As of bug 1648223 this work is now enabled by default in Firefox Nightly
builds, and may ship with Firefox 79 though could be held back to Firefox
80 if we want to get a larger list of experimental features.

If you have a feature that you would like wider testing of, please file a
bug in Firefox::Preferences and add your feature to
toolkit/components/featuregates/Features.toml. See the documentation[1] for
details on feature definitions. Bug 1648223 is on autoland now and includes
some updates to the documentation.

A new section, "Experimental Features", has been added to about:support to
list the state of the features to help with bug reports. Bug 1644544 is on
autoland to annotate crash-stats with the state of the enabled Experimental
Features and there is planned work to allow engineers to optionally disable
their features when in Safe Mode.

Thank you for reading this far. Please let me know if you have any
questions,
Jared

[1]
https://firefox-source-docs.mozilla.org/toolkit/components/featuregates/featuregates/index.html

-- 
Jared Wein
Staff Software Engineer, Firefox
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing the XUL grid implementation

[Jared Wein (Mozilla)]

Congrats! This is a major accomplishment and required a lot of work. Nice
job to all!

On Fri, Apr 24, 2020 at 1:34 PM Tim Nguyen  wrote:

> Hello folks,
>
> After a year of work, all XUL grid usages have been removed from Firefox!
> The Thunderbird team also has been doing a lot of hard work on their side.
>
> This means the XUL grid implementation can now be removed:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1525737
>
> I'm planning to remove the XUL grid implementation at the beginning of the
> Firefox 78 cycle to leave time to address potential regressions from the last
> removal <https://bugzilla.mozilla.org/show_bug.cgi?id=1583696> and for
> the Thunderbird team to remove their last usage
> <https://bugzilla.mozilla.org/show_bug.cgi?id=1632451>.
>
> Thanks to everyone who reviewed my grid removal patches and to Daniel
> Holbert and Emilio Cobos Àlvarez for the platform work that made this
> possible!
>
> Please let me know if you have any questions or concerns.
>
> Cheers,
> Tim
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>


-- 
Jared Wein
Staff Software Engineer, Firefox
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New Lockwise Password Manager UI now on autoland

[Jared Wein]

On Fri, Jul 19, 2019 at 1:30 PM Simon Sapin  wrote:

> On 19/07/2019 19:14, Nicolas B. Pierron wrote:
> > How does that work for migrating password from the current password
> manager?
>
> As far as I understand Lockwise-in-Firefox *is* the current password
> manager, only with a new UI similar to the Lockwise standalone Android
> app. Storage and sync are the same as before.
>
>
That is correct. The storage and sync engines are unchanged.

- Jared


> --
> Simon Sapin
> ___
> 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

New Lockwise Password Manager UI now on autoland

[Jared Wein]

Hi folks,

I have just landed patches in bug 1560431 to enable the new Lockwise
Password Manager by default in Nightly builds. We are planning to ship the
feature in Firefox 70 and will enable it by default for all branches in bug
1560433 once QA has signed off on it.

If you are a current user of Lockwise the UI should feel familiar.

This UI will be the future landing place for Firefox Monitor integration
where we will be able to surface breach alerts in Firefox desktop.

The meta bug for this project is bug 1549799
.

The feature is controlled by two prefs:
signon.management.page.enabled = true
signon.management.overrideURI = "about:logins?filter=%DOMAIN%"

Please try out the new UI and file bugs as you encounter them, marking them
as blocking bug 1549799 and with [passwords:management] in the whiteboard.
You can reach out to the team on IRC in #passwords and on Slack in
#lockwise. Any extra help is greatly appreciated.

Thank you to those who have submitted patches to this work!

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

Re: Improving our usage of Bugzilla

[Jared Wein]

One of the things that I have liked about Bugzilla is the lack of needing
to set something as a "bug" or an "enhancement". It seems this bug vs.
feature debate wastes unnecessary time. I have always liked thinking that
if Firefox is missing some feature, that in of itself is a bug. To me, it
keeps the bikeshedding away from at least one other topic of discussion
(ironic, I know :) ).

- Jared

On Tue, Mar 12, 2019 at 1:53 PM Kohei Yoshino 
wrote:

> The User Story field will be soon removed from the new bug page.
> https://bugzilla.mozilla.org/show_bug.cgi?id=1525376
>
> -Kohei
>
> On 2019-03-12 1:47 p.m., Daniel Veditz wrote:
> > The "User Story" field can be (ab?)used for all those things. If the bug
> is
> > not an "enhancement" it's likely blank and just waiting to be filled
> with a
> > good summary.
> ___
> 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: Please use ChromeUtils.generateQI for JS QueryInterface methods

[Jared Wein]

Great! :)

On Fri, May 18, 2018 at 2:58 PM Kris Maglione <kmagli...@mozilla.com> wrote:

> Already done. :) https://bugzil.la/1460092
>
> On Fri, May 18, 2018 at 02:48:20PM -0400, Jared Wein wrote:
> >Have you looked in to adding an eslint rule for this? The eslint rule[1]
> >that recommends usage of ChromeUtils.defineModuleGetter instead of
> >XPCOMUtils.defineLazyModuleGetter has been very useful.
> >
> >[1]
> >
> https://searchfox.org/mozilla-central/rev/da499aac682d0bbda5829327b60a865cbc491611/tools/lint/eslint/eslint-plugin-mozilla/lib/rules/use-chromeutils-import.js#2
> >
> >Thanks,
> >Jared
> >
> >
> >On Tue, May 8, 2018 at 3:26 PM Kris Maglione <kmagli...@mozilla.com>
> wrote:
> >
> >> Bug 1456035 added a ChromeUtils.generateQI helper to create
> >> QueryInterface methods for JS objects. The QueryInterface methods
> >> generated by this function are highly optimized, and have a fast path
> >> for calls from XPConnect.
> >>
> >> Which is to say, please use this method rather than manually writing
> >> your QueryInterface functions, or using XPCOMUtils.generateQI.
> >> QueryInterface methods tend to be very hot code, and all of the extra
> >> overhead from JS implementations adds up fast.
> >>
> >> -Kris
> >> ___
> >> firefox-dev mailing list
> >> firefox-...@mozilla.org
> >> https://mail.mozilla.org/listinfo/firefox-dev
> >>
>
> --
> Kris Maglione
> Senior Firefox Add-ons Engineer
> Mozilla Corporation
>
> The first principle is that you must not fool yourself — and you are
> the easiest person to fool.
> --Richard Feynman
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: Please use ChromeUtils.generateQI for JS QueryInterface methods

[Jared Wein]

Have you looked in to adding an eslint rule for this? The eslint rule[1]
that recommends usage of ChromeUtils.defineModuleGetter instead of
XPCOMUtils.defineLazyModuleGetter has been very useful.

[1]
https://searchfox.org/mozilla-central/rev/da499aac682d0bbda5829327b60a865cbc491611/tools/lint/eslint/eslint-plugin-mozilla/lib/rules/use-chromeutils-import.js#2

Thanks,
Jared


On Tue, May 8, 2018 at 3:26 PM Kris Maglione  wrote:

> Bug 1456035 added a ChromeUtils.generateQI helper to create
> QueryInterface methods for JS objects. The QueryInterface methods
> generated by this function are highly optimized, and have a fast path
> for calls from XPConnect.
>
> Which is to say, please use this method rather than manually writing
> your QueryInterface functions, or using XPCOMUtils.generateQI.
> QueryInterface methods tend to be very hot code, and all of the extra
> overhead from JS implementations adds up fast.
>
> -Kris
> ___
> 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: New Policy: Marking Bugzilla bugs for features riding behind a pref

[Jared Wein]

I have a bug that will introduce a pref/feature-flag, but that is just one
bug that blocks a meta bug. The meta bug covers the whole feature.

Should these flags get set on the meta bug or on the bug that introduces
the pref? Testing the specific bug that introduces the pref won't provide
much coverage, but setting the flag on the meta bug may be confusing since
there will be no patches landed on that bug.

I also agree that updating the Trello tracking board is inconvenient (and I
also don't know where to find it). Could we just have a Bugzilla query for
this information?

Thanks,
Jared

On Thu, May 3, 2018 at 4:45 PM, Jonathan Kew  wrote:

> On 03/05/2018 00:57, Emma Humphries wrote:
>
> To summarize, when you are releasing a feature that "rides behind a flag",
>> on the bug for the feature:
>>
>> * set the behind-pref flag to +
>> * set the qa-verify flag to ?
>> * note the bug in the Firefox Feature Trello board
>>
>> We expect qa-verify to be set to + before enabling prefs on features.
>>
>
> I don't see a flag "qa-verify" in bugzilla; was this possibly a typo for
> "qe-verify"?
>
> Thanks,
>
> JK
> ___
> 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

Photon Engineering Newsletter #13

[Jared Wein]

(via
https://msujaws.wordpress.com/2017/08/18/photon-engineering-newsletter-13/ )

This week I’m taking over for Dolske

as he takes a vacation to view the eclipse. This is issue #13
 of the Photon Engineering
Newsletter.

This past week the Nightly team has had some fun with the Firefox icon.
We’ve seen the following icons grace Nightly builds in the past week:

The icon in the top-left was created in 2011 by Sean Martell
. The icon in the
top-right was the original Phoenix icon. Phoenix was later renamed
Firebird, and then the name was later changed to Firefox
.
The icon in the bottom right was the first “Firefox” icon, designed by
Steven Garrity

in 2003. The icon in the bottom-right, well it is such logo with much
browser , we couldn’t help ourselves to
not share it.
Recent Changes Menus/structure:

The Report Site Issue button has been moved to the Page Action menu
 in Nightly and Dev
Edition. This button doesn’t ship to users on Beta or Release.

https://msujaws.files.wordpress.com/2017/08/2017-08-18_1554.png is a
screenshot of the Page Action menu.

Probably the biggest visual change this week is that we now have spacers in
the toolbar . These
help to separate the location bar from the other utility buttons, and also
keep the location bar relatively centered within the window. We have also
replaced the bookmarks menu button with the Library button (it’s the icon
that looks like books on a shelf).

https://msujaws.files.wordpress.com/2017/08/2017-08-18_1557.png is a
screenshot of the Nightly window with the spacers in place.

We also widened various panels
 to help fit more
text in them.
Animation:

The Pin to Overflow animation has also been tweaked
 to not move as far.
This will likely be the final adjustment to this animation (seen on the
left). The Pocket button has moved to the location bar and the button
expands when a page is saved
 to Pocket (seen on
the right).

Pin to Overflow animation:
https://msujaws.files.wordpress.com/2017/08/overflow.gif

Pocket animation: https://msujaws.files.wordpress.com/2017/08/pocket.gif
Preferences:

Preferences has continued to work towards their own visual redesign for
Firefox 57. New icons were landed for the various categories
 within Preferences,
and some borders  and
margins  have been
adjusted.
Visual redesign:

The tab label is no longer centered on Mac
. This now brings
Linux, Mac, and Windows to all have the same visual treatment for tabs.

Changing to Compact density within Customize mode changes the toolbar
buttons to now use less horizontal space. The following GIF shows the theme
changing from Compact to Normal to Touch densities.

Changing densities animation:
https://msujaws.files.wordpress.com/2017/08/density.gif
Onboarding:

New graphics for the onboarding tour
 have landed.


Performance:

Two of the main engineers focusing on Performance were on PTO this past
week so we don’t have an update from them.

​


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

Re: Intent to unship: HTML scoped style sheets (

[Jared Wein]

I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1375224 and
attached a patch to remove our dependency on 

Re: Quantum Flow Engineering Newsletter #5

[Jared Wein]

But what we *can* do is have communications with the WebRender devs to see
that our approaches (which have been mostly vetted by graphics and layout
people already) will continue to perform well (and possibly better) in
WebRender.

On Tue, Apr 18, 2017 at 1:53 PM, Justin Dolske  wrote:

>
>
> On Tue, Apr 18, 2017 at 1:19 AM, Jack Moffitt  wrote:
>
>> > Another really nice effort that is starting to unfold and I'm super
>> excited
>> > about is the new Photon performance project
>> > , which is a
>> focused
>> > effort on the front-end performance.  This includes everything from
>> > engineering the new UI with things like animations running on the
>> > compositor in mind from the get-go, being laser focused on guaranteeing
>> > good performance on key UI interactions such as tab opening and closing,
>> > and lots of focused measurements and fixes to the browser front-end.
>>
>> I think the order of operations here is unfortunate. What we'd prefer
>> is that WebRender land first, and then Photon be designed around what
>> is possible in the GPU-backed world.
>
>
> That's a complete non-starter. Photon work is already underway, and
> there's a _ton_ of work to do for the 57 release.
>
> Blocking Photon on another major project landing first would mean
> canceling Photon for 57.
>
> Justin
>
> ___
> 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: Startup JS debugging (sometimes) possible via Browser Toolbox

[Jared Wein]

Yes, we support watches in the new debugger UI now. The new debugger UI is
used by default in the Browser Content Toolbox, and it is pretty nice and
shiny.

Cheers,
Jared

On Mon, Mar 13, 2017 at 12:50 PM, Gijs Kruitbosch 
wrote:

> On 13/03/2017 16:48, J. Ryan Stinnett wrote:
>
>
> On Thu, Mar 9, 2017 at 2:18 AM, Panos Astithas  wrote:
>
>> You almost completely resolved the 4-year-old bug 814298, yay! I now
>> wonder if this makes it easier to improve mochitest debugging per bug
>> 929535.
>
>
> Thanks for the pointers to these bugs.
>
> Bug 814298 stills needs breakpoint persistence to be fully resolved, but
> this will hopefully appear soon in the new debugger UI.
>
> The new debugger UI isn't enabled for chrome debugging, though. What's
> blocking that? (And do we support watches in the new debugger UI yet? :-) )
>
> ~Gijs
>
> ___
> 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: Startup JS debugging (sometimes) possible via Browser Toolbox

[Jared Wein]

This is very useful! Thank you for adding this!

On Wed, Mar 8, 2017 at 2:11 PM, Dave Townsend  wrote:

> This is awesome, thanks for implementing this!
>
> On Wed, Mar 8, 2017 at 11:09 AM, J. Ryan Stinnett 
> wrote:
>
>> With bug 1275942 in Firefox 55, a new Firefox CLI option was added:
>> `--wait-for-jsdebugger`.
>>
>> Example usage:
>>
>> 1. Add "debugger;" to top of browser/base/content/browser.js
>> 2. $ ./mach run --jsdebugger --wait-for-jsdebugger
>> 3. Browser Toolbox opens, pausing Firefox startup at the added line
>>
>> This triggers Firefox to wait until the debugger connects, which makes it
>> possible to debug some Firefox startup JS code paths. (Some startup paths
>> might run before the DevTools command line handler, so for the moment they
>> won't pause. This could be improved in the future by moving the CLI handler
>> earlier in startup.)
>>
>> (If you're wondering why an extra flag was added, this mode makes the
>> Browser Toolbox use a different default window in the Inspector, which
>> might confuse people if it was the default.)
>>
>> Let me know if it's useful and / or you see room for improvement.
>>
>> - Ryan
>>
>> ___
>> 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

Re: Visual Studio Code recommended extensions

[Jared Wein]

Does the ESLint support hook in to the mozilla-eslint configuration? Can
you please update https://developer.mozilla.org/en-US/docs/ESLint or
https://wiki.mozilla.org/DevTools/CodingStandards#JS_linting_with_ESLint
with any steps required to configure this plugin?

Thanks!

- jared

On Thu, Feb 23, 2017 at 11:48 AM, Marco Bonardo 
wrote:

> Hi,
> I recently started testing VS Code as a replacement for Sublime Text or
> Atom, and so far the experience has been better than I was expecting. I
> suspect others of you are doing the same.
>
> In bug 1341585, I'm adding .vscode/settings.json to the ignore lists, so
> that everyone can create his own workspace settings file.
>
> Additionally, I'd like to provide an extensions.json that contains a list
> of extensions "recommended" to newcomers. The purpose is to help new
> contributors setting up their editor if they'd ever decide to use VS Code.
> These extensions are suggested the first time the worskspace (src root
> dir) is opened, and can be reached at any time through the Show Recommended
> Extensions for this Workspace menu. they are only suggested, not installed
> by default.
>
> I'd like you to help me figuring out this list of extensions. Please
> provide feedback about the ones I picked, and suggest others that you are
> using for your everyday work.
>
> My current list:
> // Trim only touched lines.
> "NathanRidley.autotrim",
>
> // Hilight trailing whitespaces.
> "ybaumes.highlight-trailing-white-spaces",
>
> // JS Babel ES6/ES7 syntax hilight.
> "dzannotti.vscode-babel-coloring",
> "dzannotti.theme-spacemacs",
>
> // ESLint support.
> "dbaeumer.vscode-eslint",
>
> // C/C++ language support.
> "ms-vscode.cpptools",
>
> // Rust language support.
> "saviorisdead.RustyCode"
>
> Thank you
>
> ___
> 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: Should &&/|| really be at the end of lines?

[Jared Wein]

After dealing with bugs that only happen in PGO builds, I would be worried
about bugs in the code-formatting-rewriter. The value doesn't seem worth
the risk to me.

- jared

On Fri, Feb 17, 2017 at 5:44 PM,  wrote:

> On Saturday, February 18, 2017 at 9:29:06 AM UTC+11, Bobby Holley wrote:
> > On Fri, Feb 17, 2017 at 2:18 PM,  wrote:
> >
> > > Hi again Nick,
> > >
> > > Someone made me realize that I didn't fully read your message, sorry
> for
> > > that.
> > >
> > > I now see that as well as &&/||, you have grepped for other operators,
> and
> > > shown that the overwhelming usage is to put all of them at the end of
> lines!
> > >
> > > In light of this, and from what others here have discussed,
> I'm
> > > now thinking that we probably should indeed just update our coding
> style
> > > with whatever is used the most out there, and model our "Official
> > > Formatter" on it.
> > >
> > >
> > > Another thought, if technically possible:
> > > If our main repository is going to always be under the control of some
> > > official clang-format style, it should be possible for anybody to pull
> the
> > > repository, and use a different formatter locally with their favorite
> > > style. And when pushing, their modified code could be automatically
> > > reformatted with the official formatter -- Everybody feels good when
> > > programming! :-)
> > >
> >
> > Please no. That would make reviewing a nightmare.
>
> Not sure what your concern is:
> - People who stick with the official parser will only ever see that
> (pushing to mozreview will reformat everything to the official style).
> - People who prefer a different style at home will have to adapt to the
> different style when reviewing others' code, or when their code gets review
> comments in a different style -- the formatter shouldn't change things so
> wildly that it would be so hard to find the corresponding location in their
> local repo.
>
> So it's everybody's choice to avoid a nightmare, or deal with it. ;-)
>
>
> > > Cheers,
> > > Gerald
> > >
> > >
> > > On Friday, February 17, 2017 at 5:16:42 PM UTC+11, Nicholas Nethercote
> > > wrote:
> > > > I personally have a strong preference for operators at the end of
> lines.
> > > > The codebase seems to agree with me, judging by some rough grepping
> > > ('fff'
> > > > is an alias I have that's roughly equivalent to rgrep):
> > > >
> > > > $ fff "&&$" | wc -l
> > > >   28907
> > > > $ fff "^ *&&" | wc -l
> > > >3751
> > > >
> > > > $ fff "||$" | wc -l
> > > >   26429
> > > > $ fff "^ *||" | wc -l
> > > >2977
> > > >
> > > > $ fff " =$" | wc -l
> > > >   39379
> > > > $ fff "^ *= " | wc -l
> > > > 629
> > > >
> > > > $ fff " +$" | wc -l
> > > >   31909
> > > > $ fff "^ *+$" | wc -l
> > > > 491
> > > >
> > > > $ fff " -$" | wc -l
> > > >2083
> > > > $ fff "^ *-$" | wc -l
> > > >  52
> > > >
> > > > $ fff " ==$" | wc -l
> > > >   1501
> > > > $ fff "^ *== " | wc -l
> > > >   161
> > > >
> > > > $ fff " !=$" | wc -l
> > > >   699
> > > > $ fff "^ *!= " | wc -l
> > > >   129
> > > >
> > > > They are rough regexps and probably have some false positives, but
> the
> > > > numbers aren't even close; operators at the end of the line clearly
> > > > dominate.
> > > >
> > > > I will conform for the greater good but silently weep inside every
> time I
> > > > see it.
> > > >
> > > > Nick
> > > >
> > > > On Fri, Feb 17, 2017 at 8:47 AM,  wrote:
> > > >
> > > > > Question of the day:
> > > > > When breaking overlong expressions, should &&/|| go at the end or
> the
> > > > > beginning of the line?
> > > > >
> > > > > TL;DR: Coding style says 'end', I think we should change it
> to
> > > > > 'beginning' for better clarity, and consistency with other
> operators.
> > > > >
> > > > >
> > > > > Our coding style reads:
> > > > > "Break long conditions after && and || logical connectives. See
> below
> > > for
> > > > > the rule for other operators." [1]
> > > > > """
> > > > > Overlong expressions not joined by && and || should break so the
> > > operator
> > > > > starts on the second line and starts in the same column as the
> start
> > > of the
> > > > > expression in the first line. This applies to ?:, binary arithmetic
> > > > > operators including +, and member-of operators (in particular the .
> > > > > operator in JavaScript, see the Rationale).
> > > > >
> > > > > Rationale: operator at the front of the continuation line makes for
> > > faster
> > > > > visual scanning, because there is no need to read to end of line.
> Also
> > > > > there exists a context-sensitive keyword hazard in JavaScript; see
> bug
> > > > > 442099, comment 19, which can be avoided by putting . at the start
> of a
> > > > > continuation line in long member expression.
> > > > > """ [2]
> > > > >
> > > > >
> > > > > I initially focused on the rationale, so I thought *all* operators
> > > should
> > > > > go at the front of the line.
> > > > >
> > > > > But it 

Re: Who loves multiple selection feature in editor?

[Jared Wein]

We currently use multiple selections for highlighting the domain in the
location bar, as well as find-in-page "highlight all". What would you
recommend we do if this is removed? I don't see how we would implement
"highlight all" without it.

Thanks,
Jared

On Mon, Dec 19, 2016 at 3:52 PM, Johnny Stenback  wrote:

> Unless we get clear buy-in from other browsers to support this I would vote
> for removing this complexity out of Gecko.
>
>
> - jst
>
> On Mon, Dec 19, 2016 at 10:36 AM, Frederik Braun 
> wrote:
>
> > On 19.12.2016 17:19, glazou wrote:
> > > Le jeudi 15 décembre 2016 10:47:28 UTC+1, masayuki nakano a écrit :
> > >
> > >> So, it might be better to stop supporting multiple selection only in
> > >> editor if the feature is not so loved by users.
> > >
> > > We were already discussing this issue at Netscape 15 years ago but
> could
> > not come up with a good solution at that time. Thanks for bringing it
> back,
> > this could be the right time to finally solve it.
> > >
> > > Some existing use cases:
> > >
> > > 1. this is absolutely needed for table cell selection. Everyone
> > extensively using tables uses multiple selection at some point.
> > >
> >
> > I'm generally all for removing complexity and I hate to be a spoilsport.
> >  But table cell selection is pretty useful (e.g., a full row, a full
> > column and the possibility of removing a few here and there)
> >
> >
> > > 2. Microsoft Word on all platforms and in general all commercial
> > Whysiwyg Text editors allow multiple selection.
> > >
> > > 3. multiple selection is really cool if you think of images
> representing
> > videoframes you select to edit/crop a video.
> > >
> > > 4. "search a text" often ends with a multiple selection of all
> > occurrences of the pattern in the document
> > >
> > > On another hand, I think selection would benefit from a boolean
> > attribute saying if the rendering engine allows or not multiple selection
> > and if it does not, having shortcut mechanisms allowing to get rid of the
> > onmipresent and painful getRangeAt(0). We do quite equivalent things when
> > the selection is collapsed.
> > >
> > > 
> > > ___
> > > dev-platform mailing list
> > > dev-platform@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-platform
> > >
> >
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: What if you could reinvent Firefox theming?

[Jared Wein]

uests from users who require larger icons and improved
readability of the browser's user interface for improved accessibility. Not
far behind, and ironically next in the order of responses, were requests
for a smaller browser UI (2%). These users generally want to maximize the
amount of screen space that web pages can use. Both "dark themes" and
"themes not breaking with future releases" got 2% of responses. In our last
group of responses at or above 1% was themes that could change based on
external factors (time of day, season, month, web color, or a very slow
animation), restartless and easy to trial, ability to apply multiple themes
to create a "mash-up", and to lighten the tab bar.

What parts of Firefox are most important to you to be able to change the
appearance of? Why?
Almost 20% of the respondents can not make a choice between the parts of
Firefox and thus want to customize the app in its entirety. Following
closely with 16% is the group of respondents that think the tabs area is
the most important part for themes, while half that number choose toolbars,
(toolbar)button icons and the area above the tabs, including the window
decoration and window controls. Interestingly, the wish to be able to theme
in-content pages is as strong as that of the Awesomebar and respective
navigation controls: 6.8%. Changing the colors, palette and fonts used for
the UI are the other most notable choices from the community of respondents
at 6.4% and 4%, respectively.

Are there theme-related features from other browser or apps that you would
like to see incorporated into Firefox?
An overwhelming majority of the respondents insist that we don't need to
change a thing and that other apps don't offer grand alternatives at 36.5%,
or simply can't think of any. The Vivaldi browser came up in our
preliminary research and also takes a prominent position as device of
inspiration for theming features at 11.2%. A dark theme like other apps
already offer in their package (5.9%), applying tints of color on SVG icons
and background masks (2.9%) on UI elements - most notably the titlebar -
and take Opera's about:newtab theming capabilities (2.4%). A notable
response from 2.9% of respondents was to introduce a live theme editor in
Firefox with sharing capabilities, so that theme creators can take existing
themes to tweak to their own liking and (re-)share with others.

Thanks,
Jared Wein and Mike de Boer on behalf of the Firefox engineering team

On Fri, Sep 2, 2016 at 11:48 AM, Jared Wein <jw...@mozilla.com> wrote:

> (cc'ing dev-platform, please reply to firefox-dev)
>
> What if you could reinvent Firefox theming? What would it look like, what
> would its capabilities be?
>
> We want users to have fun customizing Firefox and make it feel like their
> own. We hope to make it easier to create the type of themes that people
> have always wanted to make.
>
> Today Firefox has both "complete themes" and "themes". "Complete themes"
> are harder to make but provide unlimited theming power, whereas "themes"
> are easier to make but limit the theme author to just setting a background
> image and some text colors. We would like to merge these into a single
> system that provides the right amount of balance while also easier to use
> than what we already have.
>
> Can you help us out by filling out the following survey?
>
> https://goo.gl/forms/qUqQ4cAJ3oJueD5c2
>
> Thanks,
> Mike de Boer and Jared Wein on behalf of the Firefox engineering team
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

What if you could reinvent Firefox theming?

[Jared Wein]

(cc'ing dev-platform, please reply to firefox-dev)

What if you could reinvent Firefox theming? What would it look like, what
would its capabilities be?

We want users to have fun customizing Firefox and make it feel like their
own. We hope to make it easier to create the type of themes that people
have always wanted to make.

Today Firefox has both "complete themes" and "themes". "Complete themes"
are harder to make but provide unlimited theming power, whereas "themes"
are easier to make but limit the theme author to just setting a background
image and some text colors. We would like to merge these into a single
system that provides the right amount of balance while also easier to use
than what we already have.

Can you help us out by filling out the following survey?

https://goo.gl/forms/qUqQ4cAJ3oJueD5c2

Thanks,
Mike de Boer and Jared Wein on behalf of the Firefox engineering team
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Rust 1.10 (to be) required to build Firefox with --enable-rust

[Jared Wein]

On Wed, Aug 10, 2016 at 2:13 PM, Gregory Szorc  wrote:

> On Wed, Aug 10, 2016 at 10:54 AM, Stefan Sitter 
> wrote:
>
> > On 10.08.2016 17:28, Gregory Szorc wrote:
> >
> >> I'll be marking that bug wontfix as soon as I get in front of a
> >> computer with my BMO credentials. We plan to have no more releases of
> >> MozillaBuild.
> >>
> >
> > What will be the new way to get all build dependencies and tools for
> > Windows platform when MozillaBuild is discontinued?
>
>
> Yes.
>

"Yes" ??? I'm not sure you understood the question here? Stefan, and myself
included, are curious what the new way to get all build deps after
MozillaBuild is discontinued.

Will the new procedure be to install Mercurial and Python, open the Windows
console, then clone mozilla-central, then run `mach bootstrap` ? Asking
users to install mercurial and python by themselves seems like a regression
to me.

Thanks,
Jared


> ___
> 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: Checkin-needed requests - Please include complete information in the commit message :)

[Jared Wein]

Do we need autoland to land each patch independently? If I have three
disparate patches that I can land right now, should I use mozreview to land
them and use 3x the infra or use checkin-needed and their checkin will
likely be coalesced?

This is the position that I face often and is why I choose to use
checkin-needed. Along with jesup, I've waited hours for tryserver results
in the past and I want to be a "good citizen" and not increase infra
demands.

Am I in the wrong here? Ideally autoland would have some heuristic for
coalescing requests so we can be polite to the build system and the people
waiting on it.

On Mon, Jul 11, 2016 at 1:57 PM, Andrew McCreight 
wrote:

> On Sun, Jul 10, 2016 at 7:29 PM, Martin Thomson  wrote:
>
> > Is now the right time to start talking about retiring checkin-needed,
> > or is it still heavily used?
> >
>
> It is useful for anybody who doesn't use MozReview. FWIW I see 14 bugs with
> it set right now.
>
>
>
>
>
>
> >
> > On Sat, Jul 9, 2016 at 4:58 AM, Gregory Szorc  wrote:
> > > On Fri, Jul 8, 2016 at 11:39 AM, Felipe G  wrote:
> > >
> > >> Is there a way to make the checkin-needed flag generate a template
> > comment
> > >> (like the approval-* ones do) with something like this? (Or encourage
> > >> people to use the per-patch checkin? flag)
> > >>
> > >> """
> > >> Has this patch been through try? [ Yes / No, I believe it's not
> > necessary ]
> > >> Does this patch contain the correct author / commit message? [ Yes
> > >> (preferred) / No, but I'm providing it here: ]
> > >> Are there any other dependencies that should be landed together? [
> Yes,
> > ...
> > >> / No ]
> > >> """
> > >>
> > >> Probably just asking if the information is present will reduce the
> > number
> > >> of requests made without it
> > >>
> > >
> > > My knee jerk reaction is we shouldn't bother: MozReview handles most of
> > > this "validation" and usage of MozReview has been steadily increasing.
> > > We're trending towards a world where the only patches on Splinter are
> for
> > > security-sensitive bugs (MozReview can't handle those yet) and the
> people
> > > submitting patches to security bugs tend to know what they're doing so
> I
> > > don't think these added checks will help.
> > >
> > >
> > >>
> > >> On Fri, Jul 8, 2016 at 10:47 AM, Ryan VanderMeulen 
> > >> wrote:
> > >>
> > >> > FWIW, there's also an MDN page that documents a lot of this as well:
> > >> >
> > >> >
> > >>
> >
> https://developer.mozilla.org/en-US/docs/Mercurial/Using_Mercurial#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F
> > >> >
> > >> > -Ryan
> > >> >
> > >> >
> > >> > On 7/8/2016 2:32 AM, Carsten Book wrote:
> > >> >
> > >> >> Hi,
> > >> >>
> > >> >> someone might not know that doing checkins for checkin-needed
> > request is
> > >> >> not automated yet and completely a fully human task :) (no we
> > Sheriffs
> > >> are
> > >> >> not bots ;)
> > >> >>
> > >> >> It would help us a lot if a checkin needed request would contain
> > >> complete
> > >> >> Author/Patch information like:
> > >> >>
> > >> >>
> > >> >>- Author (use the information from their Bugzilla account if
> > needed)
> > >> >>with Name *and *Emailadress.
> > >> >>- Bug number
> > >> >>- Commit message (keeping in mind that the commit message should
> > be a
> > >> >>brief description of what the patch is *doing*)
> > >> >>   - Format should be something like "Bug 123456 - Add a null
> > check
> > >> to
> > >> >>   XYZ to avoid a crash. r=somebody"
> > >> >>
> > >> >>
> > >> >> And also if there is a specific sequence/dependency you want to
> > checkin
> > >> >> the
> > >> >> patches it would help also a lot  if you could make a short comment
> > in
> > >> the
> > >> >> Bug like please checkin part x then patch y or like first bug 123
> > then
> > >> >> this
> > >> >> bug and then bug 8910.
> > >> >>
> > >> >> This would help us a lot :)
> > >> >>
> > >> >> Thanks!
> > >> >>
> > >> >> - Tomcat
> > >> >>
> > >> >>
> > >> > ___
> > >> > dev-platform mailing list
> > >> > dev-platform@lists.mozilla.org
> > >> > https://lists.mozilla.org/listinfo/dev-platform
> > >> >
> > >> ___
> > >> dev-platform mailing list
> > >> dev-platform@lists.mozilla.org
> > >> https://lists.mozilla.org/listinfo/dev-platform
> > >>
> > > ___
> > > dev-platform mailing list
> > > dev-platform@lists.mozilla.org
> > > https://lists.mozilla.org/listinfo/dev-platform
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

Re: 32-bit developer edition?

[Jared Wein]

On Fri, Jun 3, 2016 at 11:02 AM, Javaun Moradi  wrote:

> +Clarkbw, who runs Dev Edition.
>
> Expansion of 64 bit was on hold pending the release of 47, where we had
> some critical sandboxing issues fixed and (conveniently) the Widevine CDM
> also hit that timeframe for video support.
>
> It’s an interesting idea to hit developers, who are a bit savvier. We
> assume elimination of small OOM and JS performance gains, security overall
> will be a tradeoff.
>



> We need more users in-field before we start rolling win64 out by default
> to normal people. DevEdition is a potentially compelling hook. We were
> going to offer 64 selectively on the download page to some users in an A/B
> test to try to get numbers up. Ideally, we’d be able to sniff who could run
> it, since we don’t have a stub installer.
>

We shouldn't hold back on providing a link to 64-bit Dev Edition users en
masse. I worry that running an A/B test will slow down the full release
without telling us much of anything that we don't already know.

The user agent string says if the system is 64-bit, so sniffing is already
possible.

Ben, can you file the bug in Mozilla.org::webdev to get the link added to
the download page?

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

Re: PSA: Requiring annotations for test support files required by multiple test directories

[Jared Wein]

Is the goal moving forward to have "support-files" annotations alongside
the test that requires them instead of global to the manifest file?

Will this allow a further optimization of only installing the support-file
for tests are being requested?

Thanks,
Jared

On Tue, Mar 29, 2016 at 12:55 PM, Christopher Manchester <
chmanches...@gmail.com> wrote:

> As you may know, manifestparser test manifests (mochitest.ini, browser.ini
> and co.) contain a "support-files" field informing the build system certain
> files in the tree or generated at build time are required by tests. These
> files are currently installed to the objdir for some test flavors and
> incorporated into test archives.
>
> Currently, every support and test file is installed whenever tests are
> run, and many tests rely on support files in far away corners of the tree.
> We're working to improve our granularity here, so going forward we need to
> annotate a support file required by a test if that support file is in a
> different directory.
>
> I've prepared a patch to annotate existing dependencies, which I intend to
> land in bug 1242051. For details on the syntax used, please see that bug
> and the corresponding update to our in-tree documentation.
>
> Chris
>
> ___
> 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: #include sorting: case-sensitive or -insensitive?

[Jared Wein]

We need to be careful with shuffling around #includes as there can be
ordering dependencies that are not obvious at a glance.

Further, I don't think this is something worthwhile until we have a script
that enforces said ordering.

Thanks,
Jared

On Mon, Mar 28, 2016 at 5:20 PM, Nicholas Alexander 
wrote:

> On Mon, Mar 28, 2016 at 1:28 PM, David Keeler  wrote:
>
> > (Everyone, start your bikesheds.)
> >
> > The style guidelines at
> >
> >
> https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Coding_Style
> > indicate that #includes are to be sorted. It does not say whether or not
> > to consider case when doing so (and if so, which case goes first?). That
> > is, should it be:
> >
> > #include "Foo.h"
> > #include "bar.h"
> >
> > or
> >
> > #include "bar.h"
> > #include "Foo.h"
> >
> > Based on the "Java practices" section of that document, I'm assuming
> > it's the former, but that's just an assumption and in either case it
> > would be nice to document the accepted style for C/C++.
> >
>
> Not a comprehensive argument, but could we do what moz.build does for file
> names?  I believe that is case insensitive, and foo.h sorts before foox.h.
>
> Nick
> ___
> 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

[Jared Wein]

If a patch only touches JS and CSS, could tryserver use the archive build
implementation to generate faster try builds?

On Fri, Jan 22, 2016 at 2:16 AM, Gregory Szorc  wrote:

> On Thu, Jan 21, 2016 at 10:37 PM, David Rajchenbach-Teller <
> dtel...@mozilla.com> wrote:
>
>> That sounds like it's going to break stuff.
>>
>> Reviewers frequently ask me to change stuff during reviews. I don't
>> re-run all the tests on all the platforms after every single round of
>> review. Once in a while, the changes end up breaking stuff which I need
>> to fix – generally trivial stuff that I can fix without requesting an
>> additional review.
>>
>> Also, I frequently ask for review without having run all the tests on
>> all the platforms. Every so often, I get r+ and only then realize that
>> it doesn't build under Windows, or it breaks an entirely unrelated test.
>>
>> In either case, if the reviewer takes the habit to land my patches
>> without asking me,  we'll end up with much more breakage.
>>
>
> Ultimate goal is to have a 100% linear history with no backouts due to
> automation failures. This means no merge commits and no integration
> repositories. The way we do this is effectively push everything to Try
> before it lands. This will be automatic. It shouldn't be possible for your
> busted patch to land.
>
> We need to make automation complete faster before we can do this, as I'm
> sure a lot of people would not appreciate an extra few hours of delay
> between initiating landing and it making it through Try to the final
> landing repository. I don't know if we'll get there in 2016.
>
>
>>
>> On 22/01/16 03:35, Gregory Szorc wrote:
>> > If you have level 3 source code access (can push to central, inbound,
>> > fx-team) and have pushed to MozReview via SSH, as of a few weeks ago you
>> > can now land commits from the "Automation" drop down menu on MozReview.
>> > (Before only the review request author could trigger autoland.)
>> >
>> > This means that anyone [with permissions] can land commits with a few
>> > mouse clicks! It will even rewrite commit messages with "r=" annotations
>> > with the review state in MozReview. So if someone does a drive-by
>> > review, you don't have to update the commit message to reflect that
>> > reviewer. Neato!
>> >
>> > I've gotten into the habit of just landing things if I r+ them and I
>> > think they are ready to land. This has startled a few people because it
>> > is a major role reversal of how we've done things for years. (Typically
>> > we require the patch submitter to do the landing.) But I think
>> > reviewer-initiated landing is a better approach: code review is a gate
>> > keeping function so code reviewers should control what goes through the
>> > gate (as opposed to patch authors [with push access] letting themselves
>> > through or sheriffs providing a support role for people without push
>> > access). If nothing else, having the reviewer land things saves time:
>> > the ready-to-land commit isn't exposed to bit rot and automation results
>> > are available sooner.
>> >
>> > One downside to autoland is that the rebase will happen remotely and
>> > your local commits may linger forever. But both Mercurial and Git are
>> > smart enough to delete the commits when they turn into no-ops on rebase.
>> > We also have bug 1237778 open for autoland to produce obsolscence
>> > markers so Mercurial will hide the original changesets when you pull
>> > down the rebased versions. There is also potential for some Mercurial or
>> > Git command magic to reconcile the state of MozReview with your local
>> > repo and delete local commits that have been landed. This is a bit
>> > annoying. But after having it happen to me a few times, I think this is
>> > a minor annoyance compared to the overhead of pulling, rebasing,
>> > rewriting commit messages, and pushing locally, possibly hours or days
>> > after review was granted.
>> >
>> > I encourage my fellow reviewers to join me and "just autoland it" when
>> > granting review on MozReview.
>> >
>> > gps
>> >
>> >
>> > ___
>> > 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

Re: APZ enabled on Fennec nightly

[Jared Wein]

Nice feedback on Reddit about the changes. Great job!

https://www.reddit.com/r/firefox/comments/3wo4rm/nightlyandroid_scroll_speed_is_improving/

- jared

On Wed, Dec 2, 2015 at 12:39 PM, Kartikaya Gupta  wrote:

> Thanks for trying it out and reporting these issues! I've filed them
> as separate bugs - bug 1229840, bug 1229839, and bug 1229841. We
> should be able to address 2 and 3 by tuning some prefs, 1 will take a
> bit more investigation.
>
> Cheers,
> kats
>
> On Wed, Dec 2, 2015 at 11:31 AM,   wrote:
> > Thanks for hard the work on this! I'm happy you're working on improving
> the scrolling.
> >
> >
> > Since the change, I've noticed a few things:
> >
> > 1. Reader mode's toolbar now sometimes seems to jump up and down several
> times.
> >
> > 2. Deceleration takes too long to happen (the page seems to just float
> for far too long after flings happen, especially for slower, smaller
> flings). It's much slower than other apps, and it also feels much slower
> than I remember for Firefox before the update.
> >
> > 3. Quick flings don't jump up or down on the page as quickly as they
> previously did, making more work to get back up to the top of a page, or to
> quickly jump down to read the summary paragraph of an article.
> >
> >
> > This is all on a Nexus 6P running stock Android Marshmallow, by-the-way.
> It might feel different on other devices.
> >
> >
> > Again, thanks for working on this! I know it's a WIP in Nightly it's
> probably subject to change a little with a few tweaks.
> >
> > Cheers,
> > Garrett
> > ___
> > 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: Voting in BMO

[Jared Wein]

DevTools does something like this with UserVoice. I don't think we should
get rid of voting unless we replace it with something else (UserVoice is a
good alternative).

There are plenty of people that recommend others to vote on bugs that
they want prioritized, and us removing voting will make it look to the
outsider that Mozilla is becoming more closed.

Cheers,
Jared

On Thu, Jun 11, 2015 at 2:13 PM, Steve Fink sf...@mozilla.com wrote:

 I agree. While it is certainly true that prioritizing work based on how
 many noisy people are campaigning for it is not a good idea, I reject the
 notion that the only useful goal here is to prevent bugspam, as that
 implies that user input is worthless.

 me too/+1 comments on bugs are clearly not the way to collect user
 input. Votes aren't a whole lot better. input.mozilla.org is good for
 certain things, but the SNR is too low to use it raw and the cost of
 meaningful processing is high.

 If I were to handwave up a new mechanism to replace bug comments + voting,
 I'd probably want a feature/bug page with

  - upvote/downvote counts (3 vs 100 is useful information, even if it
 doesn't decide anything on its own)
  - list of *distinct* reasons for wanting it
  - counterarguments and data (eg web compat info)
  - pointer to the appropriate discussion forum and threads

 The idea is that if someone merely wants to support a feature request but
 doesn't have any new arguments for why, they can upvote it and be done. But
 if someone *does* have a novel argument, they can add it to the list. Or
 expand/clarify an existing reason instead of just appending.

 Come to think of it, that sounds like a wiki talk page with a fixed
 format. Perhaps we could just throw up a template page on wiki.m.o and find
 a good namespace for these, and redirect voters there?


 On 06/11/2015 10:22 AM, Michael Verdi wrote:

 Here's something to consider. I've seen my friend Jen Simmons encourage
 people to use voting as a way to tell us that it's important to them for
 Firefox to support a particular html or css feature. Here's a recent
 example https://twitter.com/jensimmons/status/601184865732534272 - the
 bug
 mentioned has 41 votes on it. I just did a little looking around and other
 than adding a comment to the relevant bug the only other method of giving
 us feedback seems to be to dump it in
 https://input.mozilla.org/feedback/firefox

 Maybe it's moot because we're not influenced by votes but if you're not a
 mozilla insider how do express support for something without spamming the
 bug?

 - Michael

 On Thu, Jun 11, 2015 at 11:33 AM, Gervase Markham g...@mozilla.org
 wrote:

  On 09/06/15 23:07, Mark Côté wrote:

 I would ask, then, what the purpose of the feature is.  If we know it
 isn't used to make decisions, why use it?  The only thing I can think of
 is as a sort of spam honeypot, to get people to not +1 or me too
 bugs, but this seems strange at best and actively misleading at worst.

 It used to do this job extremely well; I have no information on how true
 that is today, as developers seem rather free to say actually, we
 ignore votes...

 Gerv

 ___
 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: status-firefox41: affected

[Jared Wein]

Bugzilla has defaulted to marking new bugs as status-firefoxXX: affected.
I'm not sure when it started but this is why.

Hope that helps,
Jared

On Sat, May 30, 2015 at 11:58 AM, Philip Chee philip.c...@gmail.com wrote:

 Why are these SeaMonkey bugs flagged status-firefox41: affected

 https://bugzilla.mozilla.org/buglist.cgi?f1=cf_status_firefox41list_id=12290852o1=anyexactquery_format=advancedf2=OPv1=affectedproduct=SeaMonkey

 Why are these SeaMonkey bugs flagged status-firefox40: affected

 https://bugzilla.mozilla.org/buglist.cgi?f1=cf_status_firefox40list_id=12290852o1=anyexactquery_format=advancedf2=OPv1=affectedproduct=SeaMonkey

 Thunderbird:

 https://bugzilla.mozilla.org/buglist.cgi?j_top=ORlist_id=12290869o1=equalsv1=affectedf1=cf_status_firefox40o3=equalsv3=affectedquery_format=advancedf3=cf_status_firefox40f2=OPproduct=MailNews
 Coreproduct=Thunderbird

 History doesn't show anyone manually marking these bugs
 status-firefox40/status-firefox41

 Some filter rule going bonkers?

 Phil

 --
 Philip Chee phi...@aleytys.pc.my, philip.c...@gmail.com
 http://flashblock.mozdev.org/ http://xsidebar.mozdev.org
 Guard us from the she-wolf and the wolf, and guard us from the thief,
 oh Night, and so be good for us to pass.
 ___
 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: Treeherder UI performance much worse in Nightly vs Chrome

[Jared Wein]

How was the performance when APZ + e10s was turned on the other day? I
imagine that will have a big impact on scrolling performance for treeherder
since it's a pretty heavy JS page.

On Thu, Apr 23, 2015 at 11:16 AM, Mike Hoye mh...@mozilla.com wrote:

 On 2015-04-23 10:43 AM, Ed Morley wrote:

 Scrolling fluidity/general app responsiveness of Treeherder is massively
 worse in Nightly compared to Chrome. eg try this in both:
 https://treeherder.mozilla.org/#/jobs?repo=mozilla-central

  I asked some volunteers from the Reps to do an advocacy/evangelism
 experiment last quarter: ask people to try Firefox for two weeks, see if
 they stick with it, see what motivated them to switch back. Perceived
 performance on Windows machines was one of the main reasons people went
 back to Chrome. Scrolling jank was remarked on specifically.


 - mhoye

 ___
 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 Silk on Desktop

[Jared Wein]

Within the small circle of Mozilla contributors it may feel spammy or
repetitive, but I wouldn't be surprised for people outside of the Mozilla
project to think of b2g and Firefox desktop as both separate userbases and
separate impacts.

On Thu, Mar 12, 2015 at 6:59 PM, Mason Chang mch...@mozilla.com wrote:

 Yeah it is, but I don’t really want to do another PR run when lots of
 people have already read about Silk on b2g. Feels spammy to me to do
 another one just a month after the previous one, but that’s my 2 cents.

 Mason

  On Mar 12, 2015, at 3:17 PM, Robert O'Callahan rob...@ocallahan.org
 wrote:
 
  On Fri, Mar 13, 2015 at 5:28 AM, Mason Chang mch...@mozilla.com
 mailto:mch...@mozilla.com wrote:
  Hi Mike,
 
   This sounds like a massive improvement to our rendering pipeline,
 definitely worth of some PR effort! Is that being considered?
 
  We’ve had a PR effort before when Silk landed on b2g. It hit hacker news
 and received over 10K views IIRC on mozilla hacks, so I’m not keen on doing
 another one.
 
  Isn't hackernews and 10K views on h.m.o a *good * thing?
 
  Rob
  --
  oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
  owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
  osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
 owohooo
  osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o
 o‘oRoaocoao,o’o oioso
  oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
 owohooo
  osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
 ooofo
  otohoeo ofoioroeo ooofo ohoeololo.

 ___
 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 QE-Verify Flag in Bugzilla

[Jared Wein]

Hi Marc,

Can you shed some background on the change in name from QA to QE? Does QE stand 
for Quality Engineering, whereas QA is Quality Assurance? What are the 
differences between the two? Do we now have two different teams/departments?

Thanks,
Jared

- Original Message -
 From: Marc Schifer mschi...@mozilla.com
 To: dev-quality dev-qual...@lists.mozilla.org
 Cc: firefox...@mozilla.org, dev-platform dev-platform@lists.mozilla.org, 
 firefox-...@mozilla.org
 Sent: Thursday, August 14, 2014 5:45:52 PM
 Subject: New QE-Verify Flag in Bugzilla
 
 A short while ago we had a discussion about how to stream line some QA
 processes (Desktop QA - Bugzilla keywords: Proposal on dev-quality) and
 reduce the bug spam generated by setting keywords and whiteboard tags
 (Bugspam generated by the new process on firefox-dev). The final resolution
 of this discussion was to have a new Bugzilla flag created, qe-verify, that
 would replace the current use of QA+/- whiteboard tags and the verifyme
 keyword. This will give you the ability to easily filter out any activity on
 the flag instead of needing to have multiple filters for keywords and
 whiteboard activity as well simplify our queries for tracking work to be
 done in QE. The use of other keywords (qawanted, qaurgent, steps-wanted,
 regression-window-wanted, testcase-wanted) will remain the same.
 
 Currently this is only implemented for Firefox QE, other teams are more then
 welcome to adopt if so desired.
 
 Details:
  New Flag: qe-verify[?|+|-]
   qe-verify[?] = triage request
   qe-verify[+] = bug to be verified
   qe-verify[-] = bug will not/can not be verified
 
  Deprecate use of:
   Whiteboard tag: QA[?|+|-]
   Keyword   : verifyme
 
  The component list the flag can be set for is:
 
   Core   -- Any --
   Firefox-- Any --
   Firefox for Android-- Any --
   Firefox for Metro  -- Any --
   Firefox Health Report  -- Any --
   Firefox OS -- Any --
   Loop   Client
   Loop   General
   Mozilla Localizations  -- Any --
   Mozilla QA Mozmill Tests
   Mozilla Services   -- Any --
   NSPR   -- Any --
   NSS-- Any --
   Plugins-- Any --
   Snippets   -- Any --
   Toolkit-- Any --
 
 If there is a component that I missed please let me or the bugzilla team know
 so we can fix it.
 
 This message was posted to dev-quality and has been crossposted to on
 firefox-dev and dev-platform. Please follow up on dev-quality.
 
 Thank You.
  Marc S.
 Firefox Q.E. Manager
 
 ___
 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: Extending the text-overflow/overflow property to support fading out

[Jared Wein]

- Original Message -
 From: Jared Wein jw...@mozilla.com
 To: dev-platform@lists.mozilla.org
 Sent: Tuesday, May 28, 2013 5:58:34 PM
 Subject: Re: Extending the text-overflow/overflow property to support fading  
 out
 
 - Original Message -
  From: Robert O'Callahan rob...@ocallahan.org
  To: Jonathan Watt jw...@jwatt.org
  Cc: dev-platform@lists.mozilla.org
  Sent: Wednesday, May 22, 2013 10:11:55 PM
  Subject: Re: Extending the text-overflow/overflow property to
  support fading  out
  
  I'm pretty sure an unconditional mask with a linear gradient on the
  right-hand-end of the text could be achieved using 'mask-box-image'
  and
  slicing appropriately:
  http://www.w3.org/TR/css-masking/#the-mask-box-image.
  That's not currently implemented in Gecko, but it's worth
  implementing.
 
 This seems like it would do the job and it wouldn't require us to
 create a new specification. Can this get on someone's radar to
 implement support for it?

I filed bug 877294 for this.

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

Re: Extending the text-overflow/overflow property to support fading out

[Jared Wein]

- Original Message -
 From: Robert O'Callahan rob...@ocallahan.org
 To: Jonathan Watt jw...@jwatt.org
 Cc: dev-platform@lists.mozilla.org
 Sent: Wednesday, May 22, 2013 10:11:55 PM
 Subject: Re: Extending the text-overflow/overflow property to support fading  
 out
 
 I'm pretty sure an unconditional mask with a linear gradient on the
 right-hand-end of the text could be achieved using 'mask-box-image'
 and
 slicing appropriately:
 http://www.w3.org/TR/css-masking/#the-mask-box-image.
 That's not currently implemented in Gecko, but it's worth
 implementing.

This seems like it would do the job and it wouldn't require us to create a new 
specification. Can this get on someone's radar to implement support for it?

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

Notice of browser and toolkit theme renamings

[Jared Wein]

Hi,

I wanted to let you all know about bug 842913, of which I just landed the patch 
for on mozilla-inbound.

The goal of the bug is to make the process of working with the /browser and 
/toolkit themes easier for new contributors. The previous names of 
{winstripe,pinstripe,gnomestripe} were never exposed in the product and were 
unclear to new users as to which platforms/environments they targeted.

In toolkit:
/toolkit/themes/winstripe/ becomes /toolkit/themes/windows/
/toolkit/themes/pinstripe/ - /toolkit/themes/osx/
/toolkit/themes/gnomestripe/ - /toolkit/themes/linux/
/toolkit/themes/pmstripe/ - /toolkit/themes/os2/
/toolkit/themes/faststripe/ - (unchanged)

In browser:
/browser/themes/winstripe/ becomes /browser/themes/windows/
/browser/themes/pinstripe/ - /browser/themes/osx/
/browser/themes/gnomestripe/ - /browser/themes/linux/

Most of the work to complete the patches is based on |hg rename|, but some 
files that reference paths needed to be updated manually. This may affect 
SeaMonkey, Thunderbird, and any other toolkit-based applications.

This work builds on top of bug 838244 (shared theme resources for /browser), 
and upcoming work in bug 844412 (shared theme resources for /toolkit). These 
three bugs should help to make our theme implementations easier and more 
intuitive for both experienced and inexperienced contributors.

One issue that is still remaining is the non-obvious way that the linux-toolkit 
theme is generated using the windows-toolkit theme as a base. The work in bug 
844412 should help to reduce some of this confusion. Overall, there was a 
consensus that the net-wins of this rename are worth it even though it doesn't 
solve the theme-derivation situation.

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