Improving our usage of Bugzilla

[Sylvestre Ledru]

Bugzilla is one of the key tools used for the development of Firefox since the 
Netscape era. Even though this tool is serving us well, after interviewing a 
bunch of people at every level inside the company, we realized that we need to 
go the extra step.


Therefore, we decided to focus on improving Bugzilla itself but also, as a next 
step, improve the workflows we have on bugs.


To start with, we are coming with a set of three major changes to make our life 
better and easier.


1) Enforcing the usage of the priority field


As described in this schema , we are now asking triage owners to set the priority field according to the priority definition . The main goal 
is to make sure that every bug has been looked at and a priority has been set in accordance with the priority definitions.


A bot will automatically needinfo the triage owner (or a member of the team if 
it uses a round robin triage method).

We have been experimenting with this for several components and the results 
look great!


2) Bug type - new field

Firefox development requires a bug for every change in the Firefox code base. 
It doesn’t matter if this is used to fix a defect in the product, to implement 
a new feature or to refactor some code.


For years, we have been using bugzilla keywords to classify them. However, as 
they are not mandatory, the metadata can be missing, unmaintained, or 
inconsistent.


With this change, we are going to extend Bugzilla to add a new field with three 
new values:

 *

   Defect - an issue in one of our products

 *

   Enhancement - a new feature or an improvement

 *

   Task - a developer task. For example: refactor code foo.


Since we don’t want to increase the confusion for new users, the default value will 
be defectand, to the best of our ability, existing bugs will be moved 
under one of these 
categories.


With this information, we will be able to more precisely measure the quality of 
our products, as we will not mix defects together with feature-related work.


We have a development instance of Bugzilla 
where the changes can be evaluated, we are 
planning to go live in the new few weeks.


More information https://bugzilla.mozilla.org/1522340


3) Adding a new field called “Regressed by”

Currently, we misuse the blocks/depends fields to mark bugs causing 
regressions. However, they can be confusing and aren’t used consistently by 
developers. Moreover, since we are using bugs for defects, enhancements or 
tasks, it can be very hard to pinpoint the changes which introduced a 
regression.

Being able to pinpoint changes which introduced regressions will make it easier 
to build tools to help with assessing the riskiness of changes.


Therefore, we will add a new field in bugzilla which will clearly identify 
which bug caused a regression.

More:

http://bugzilla.mozilla.org/1461492


Last but not least, nothing is written in stone and we have other improvements 
(bug workflow, improved search, regression field, etc) coming. Sylvestre

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

CookieSettings

[Andrea Marchesini]

Since the beginning of this week, we have CookieSettings in our codebase.
CookieSettings is a snapshot of cookie policy and cookie permissions in a
precise moment of time. This object is used by top-level documents to have
a consistent cookie configuration also in case the user changes it. New
cookie configurations will apply only to new top-level documents.

I wrote a long comment describing how this object is created, used and
propagated:
https://searchfox.org/mozilla-central/rev/8ff2cd0a27e3764d9540abdc5a66b2fb1e4e9644/netwerk/cookie/CookieSettings.h#20-100

CookieSettings has been introduced by bug 1525245 after the discussion
about "Cookie policy/permission in live documents". See
https://groups.google.com/d/msg/mozilla.dev.platform/qO6MserGVmk/vYHcDMdPCgAJ

Please, don't check the cookie behavior pref or cookie permissions directly
but use CookieSettings instead. This is available from Document,
WorkerPrivate and nsILoadInfo.

An interesting aspect of CookieSettings is that is propagated and used
everywhere (as I said, documents, workers and network channels). This makes
it a good candidate to bring more prefs and more permissions into it and,
maybe, change them for specific contexts.  Below I shortly describe 2 ideas:

- change the network settings when the URL-Classifier flags a document's
channel. This would allow us, for instance, to have custom network proxy
configuration for trackers. I have a proof of concept for this idea.
- custom audio settings: origin A is muted by default, origin B has volume
set to 0.5. See:
https://searchfox.org/mozilla-central/rev/8ff2cd0a27e3764d9540abdc5a66b2fb1e4e9644/dom/interfaces/base/nsIDOMWindowUtils.idl#1746-1757

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

Re: CookieSettings

[Johann Hofmann]

Hi Baku,

thank you for all the work on this. For completeness sake I would like to
mention that we are adapting to this new (and finally explicit!) cookie
preferences user experience in
https://bugzilla.mozilla.org/show_bug.cgi?id=1526075, where users are given
the choice to reload their tabs so that the new CookieSettings can be
picked up.

And, just to clarify, CookieSettings is not for use in browser front-end
code, right? So, about:preferences for example would still continue to flip
prefs and CookieSettings would reflect those prefs per document?

Thanks!

Johann

On Tue, Mar 12, 2019 at 12:17 PM Andrea Marchesini 
wrote:

> Since the beginning of this week, we have CookieSettings in our codebase.
> CookieSettings is a snapshot of cookie policy and cookie permissions in a
> precise moment of time. This object is used by top-level documents to have
> a consistent cookie configuration also in case the user changes it. New
> cookie configurations will apply only to new top-level documents.
>
> I wrote a long comment describing how this object is created, used and
> propagated:
>
> https://searchfox.org/mozilla-central/rev/8ff2cd0a27e3764d9540abdc5a66b2fb1e4e9644/netwerk/cookie/CookieSettings.h#20-100
>
> CookieSettings has been introduced by bug 1525245 after the discussion
> about "Cookie policy/permission in live documents". See
>
> https://groups.google.com/d/msg/mozilla.dev.platform/qO6MserGVmk/vYHcDMdPCgAJ
>
> Please, don't check the cookie behavior pref or cookie permissions directly
> but use CookieSettings instead. This is available from Document,
> WorkerPrivate and nsILoadInfo.
>
> An interesting aspect of CookieSettings is that is propagated and used
> everywhere (as I said, documents, workers and network channels). This makes
> it a good candidate to bring more prefs and more permissions into it and,
> maybe, change them for specific contexts.  Below I shortly describe 2
> ideas:
>
> - change the network settings when the URL-Classifier flags a document's
> channel. This would allow us, for instance, to have custom network proxy
> configuration for trackers. I have a proof of concept for this idea.
> - custom audio settings: origin A is muted by default, origin B has volume
> set to 0.5. See:
>
> https://searchfox.org/mozilla-central/rev/8ff2cd0a27e3764d9540abdc5a66b2fb1e4e9644/dom/interfaces/base/nsIDOMWindowUtils.idl#1746-1757
>
> b
> ___
> 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: Improving our usage of Bugzilla

[Honza Bambas]

Hi, replying privately, because I want to expose some crazy idea I had a 
long time and this seems like a good opportunity.


I miss two things in bugzilla from the developer point of view:
- when I use it as a tool to look into the code's history (understand 
changes made in the past)

- and be able to quickly assess the state of a bug

I wanted to suggest (but never done that) to have specific fields (text 
areas) in the bug form for following information:

- explanation of the cause of the defect or rational for the bug
- overview explanation of the fix for the defect (why this way); don't 
interchange this with commit messages, this would be more of an overview 
explanation

- steps to reproduce the defect

and maybe things like:
- known workaround

Each with its own history, perhaps.  This allows one to quickly overlook 
status (e.g. when a field is empty it means "we don't know yet") and 
quickly understand the reason why the fix was made the way it was.


Right now one has to look for this in comments and its hard. Sometimes 
explanations are even missing and then we are stepping into darkness 
when we need to change something or simply understand some older code.


Having these fields would invite people to write these explanations and 
sometimes doing it may (from my own experience) even help to produce 
better patches.



That's it

Thanks :)
-hb-

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

Re: Improving our usage of Bugzilla

[Honza Bambas]

Damn you, reply-to field :)  Sorry for spam everyone!  Intended to 
Sylvestre only.

-hb-

On 2019-03-12 12:50, Honza Bambas wrote:
Hi, replying privately, because I want to expose some crazy idea I had 
a long time and this seems like a good opportunity.


I miss two things in bugzilla from the developer point of view:
- when I use it as a tool to look into the code's history (understand 
changes made in the past)

- and be able to quickly assess the state of a bug

I wanted to suggest (but never done that) to have specific fields 
(text areas) in the bug form for following information:

- explanation of the cause of the defect or rational for the bug
- overview explanation of the fix for the defect (why this way); don't 
interchange this with commit messages, this would be more of an 
overview explanation

- steps to reproduce the defect

and maybe things like:
- known workaround

Each with its own history, perhaps.  This allows one to quickly 
overlook status (e.g. when a field is empty it means "we don't know 
yet") and quickly understand the reason why the fix was made the way 
it was.


Right now one has to look for this in comments and its hard. Sometimes 
explanations are even missing and then we are stepping into darkness 
when we need to change something or simply understand some older code.


Having these fields would invite people to write these explanations 
and sometimes doing it may (from my own experience) even help to 
produce better patches.



That's it

Thanks :)
-hb-



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

Re: CookieSettings

[Andrea Marchesini]

>
>
> And, just to clarify, CookieSettings is not for use in browser front-end
> code, right? So, about:preferences for example would still continue to flip
> prefs and CookieSettings would reflect those prefs per document?
>
>
Correct.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Running different instances of Firefox side-by-side

[Randell Jesup]

>-no-remote and -new-instance still exist. Right now they do the same thing,
>they make Firefox not look for existing instances and not listen for
>remoting from future instances. They are pretty pointless now though, the
>only case where they would have an effect is when a second instance is
>trying to use a profile that is already used by an existing instance ... at
>which point we'll show the profile locked dialog on startup and refuse to
>startup anyway.
[snip]
>The other thing that might be confusing is that the version or install of
>Firefox you try to launch doesn't affect which version or install of
>Firefox you might end up remoting to. This has always been the case on
>Windows and normally the case on Linux, unless you pass an extra command
>line argument though so I'm not too concerned here.

-no-remote is still quite useful when debugging; if I build in one of my
dev repos, and then ./firefox -P test -no-remote, it will warn me if I
have another instance using that profile (quite possibly from a
different repo/directory) instead of silents loading it in that other
instance - which can be very confusing if you're trying to test a fix.
("I *swear* I made that change; why didn't it take?")

>Hopefully this all makes sense. I'd like to hear if folks think that this
>is the wrong way to support this and if you spot any issues with it that I
>haven't.

Thanks for doing this; the current system kinda fell out of various
needs mostly around 20+ years ago and hadn't been revisted since then
really.

-- 
Randell Jesup, Mozilla Corp
remove "news" for personal email
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving our usage of Bugzilla

[Andrew McCreight]

On Tue, Mar 12, 2019 at 3:55 AM Sylvestre Ledru 
wrote:

> With this change, we are going to extend Bugzilla to add a new field with
> three new values:
>
>-
>
>Defect - an issue in one of our products
>-
>
>Enhancement - a new feature or an improvement
>-
>
>Task - a developer task. For example: refactor code foo.
>
>
Could please you explain more what these three values are supposed to
represent, possibly with some examples? It feels like there's a lot of
overlap between them. For instance, isn't any task I work on as a developer
a developer task? Isn't refactoring both a task and an improvement (and
thus also an enhancement)?

Maybe the idea is something like:
* Defect: the current implementation does not match the current intended
behavior, and the former should be changed to match the latter.
* Enhancement: the current intended behavior should be changed (and the
implementation changed to match the new intended behavior).
* Task: the current implementation should be changed, but the intended
behavior remains the same.

This breakdown is guided by what I remember of advice from I think David
Baron on how to structure a review: you need to review what a patch intends
to do (this being the "intended behavior" above), and also review whether
the patch actually does what it intends to do (this being the
"implementation" above). Maybe there's a better phrase than "intended
behavior".

Secondly, to bikeshed a little, could there be some name besides "task" for
that third category? Like I said above, everything we work as developers is
a developer task. "Refactor" seems like a clearer name, though maybe it is
a little limiting. "Side grade"? :)

Thirdly, what category should "organizational" bugs like meta bugs be
assigned to? I guess if you have a meta bug for a bunch of enhancements, it
would be an enhancement?

3) Adding a new field called “Regressed by”
>

This is great! The weird encoding of "regressed by" in the "depends on"
field is one of the more confusing aspects of Bugzilla, given how important
it is. I spend a ton of time setting regressions for bugs, and even still I
have to stop occasionally to make sure I'm doing it the right way.

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

Re: Improving our usage of Bugzilla

[Daniel Veditz]

On Tue, Mar 12, 2019 at 3:55 AM Sylvestre Ledru 
wrote:

> 2) Bug type - new field
> 3) Adding a new field called “Regressed by”
>

Will the new fields be searchable using quicksearch?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving our usage of Bugzilla

[Daniel Veditz]

On Tue, Mar 12, 2019 at 4:50 AM Honza Bambas  wrote:

> I wanted to suggest (but never done that) to have specific fields (text
> areas) in the bug form for following information:
> - explanation of the cause of the defect or rational for the bug
> - overview explanation of the fix for the defect (why this way); don't
> interchange this with commit messages, this would be more of an overview
> explanation
> - steps to reproduce the defect
>
> and maybe things like:
> - known workaround
>

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.

-Dan Veditz





>
> Each with its own history, perhaps.  This allows one to quickly overlook
> status (e.g. when a field is empty it means "we don't know yet") and
> quickly understand the reason why the fix was made the way it was.
>
> Right now one has to look for this in comments and its hard. Sometimes
> explanations are even missing and then we are stepping into darkness
> when we need to change something or simply understand some older code.
>
> Having these fields would invite people to write these explanations and
> sometimes doing it may (from my own experience) even help to produce
> better patches.
>
>
> That's it
>
> Thanks :)
> -hb-
>
> ___
> 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: Improving our usage of Bugzilla

[Kohei Yoshino]

Yes! You can use “type” like this:

https://bugzilla.allizom.org/buglist.cgi?quicksearch=type:defect
https://bugzilla.allizom.org/buglist.cgi?quicksearch=type:enhancement
https://bugzilla.allizom.org/buglist.cgi?quicksearch=type:task

And “regressed_by” and “regressions” should also work.

-Kohei


On 2019-03-12 1:43 p.m., Daniel Veditz wrote:

On Tue, Mar 12, 2019 at 3:55 AM Sylvestre Ledru 
wrote:


2) Bug type - new field
3) Adding a new field called “Regressed by”



Will the new fields be searchable using quicksearch?

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

Re: Improving our usage of Bugzilla

[Kohei Yoshino]

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

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: Improving our usage of Bugzilla

[Sylvestre Ledru]

Le 12/03/2019 à 17:48, Andrew McCreight a écrit :

On Tue, Mar 12, 2019 at 3:55 AM Sylvestre Ledru 
wrote:


With this change, we are going to extend Bugzilla to add a new field with
three new values:

-

Defect - an issue in one of our products
-

Enhancement - a new feature or an improvement
-

Task - a developer task. For example: refactor code foo.



Could please you explain more what these three values are supposed to
represent, possibly with some examples? It feels like there's a lot of
overlap between them. For instance, isn't any task I work on as a developer
a developer task? Isn't refactoring both a task and an improvement (and
thus also an enhancement)?


* Defects are trivial. Examples:
Crashes, intermittent, glitches, features not working as expecting, features 
worked
but no longer works, etc.

This is mostly for users of our products (including ourself). Triaged by eng 
triage owners.

We decided NOT to call that bug as this word is super-overloaded at Mozilla.

* Enhancement is a development of a new feature.  Examples:
Add a new avatar for sync, implement feature foo in Javascript,
add bar property in css 42, etc

This is mostly coming from users and us. Should be triagged by product and 
triage owners.

* Task is mostly development work. Examples:
Refactor function foo, remove function bar, improve function plop, etc.

Almost of them should be coming from engineering.

Now, we will have cases for which a ticket will be both a task and an 
enhancement.
Example: https://bugzilla.mozilla.org/show_bug.cgi?id=1528330
"Deliver acceptable GeckoView performance for Firefox Reality in H1"
But I am sure you will agree that this new state will still be an improvement 
over the current state.


Now, a more concrete example, I have want to implement a new feature in Firefox.
I will create (or reuse) a bug with the "enhancement" value (probably as a meta 
bug).
Then, to develop the feature, I will create various "tasks" which will be 
marking as
blocking the meta bug.

Because I am a bad developer, I will make mistakes and user will fill bugs which
will have the "defect" value (and I will use the regressed_by field).



Secondly, to bikeshed a little, could there be some name besides "task" for
that third category? Like I said above, everything we work as developers is
a developer task. "Refactor" seems like a clearer name, though maybe it is
a little limiting. "Side grade"? :)


This is more than just refactoring. It is more "as an engineer, here is what I have 
to do".

About bikeshed, you can have a look here 
https://bugzilla.mozilla.org/show_bug.cgi?id=1522342
Where we did that.


Thirdly, what category should "organizational" bugs like meta bugs be
assigned to? I guess if you have a meta bug for a bunch of enhancements, it
would be an enhancement?


Yeah, "it depends" ;) Probably...




3) Adding a new field called “Regressed by”
This is great! The weird encoding of "regressed by" in the "depends on"
field is one of the more confusing aspects of Bugzilla, given how important
it is. I spend a ton of time setting regressions for bugs, and even still I
have to stop occasionally to make sure I'm doing it the right way.


Same here ;)


S


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

Re: Improving our usage of Bugzilla

[David Major]

Will setting the "regressed by" field send mail to the subscribers of
the earlier bug? This was a useful aspect of the blocks/depends field.

On Tue, Mar 12, 2019 at 1:59 PM Sylvestre Ledru  wrote:
>
> Le 12/03/2019 à 17:48, Andrew McCreight a écrit :
> > On Tue, Mar 12, 2019 at 3:55 AM Sylvestre Ledru 
> > wrote:
> >
> >> With this change, we are going to extend Bugzilla to add a new field with
> >> three new values:
> >>
> >> -
> >>
> >> Defect - an issue in one of our products
> >> -
> >>
> >> Enhancement - a new feature or an improvement
> >> -
> >>
> >> Task - a developer task. For example: refactor code foo.
> >>
> >>
> > Could please you explain more what these three values are supposed to
> > represent, possibly with some examples? It feels like there's a lot of
> > overlap between them. For instance, isn't any task I work on as a developer
> > a developer task? Isn't refactoring both a task and an improvement (and
> > thus also an enhancement)?
>
> * Defects are trivial. Examples:
> Crashes, intermittent, glitches, features not working as expecting, features 
> worked
> but no longer works, etc.
>
> This is mostly for users of our products (including ourself). Triaged by eng 
> triage owners.
>
> We decided NOT to call that bug as this word is super-overloaded at Mozilla.
>
> * Enhancement is a development of a new feature.  Examples:
> Add a new avatar for sync, implement feature foo in Javascript,
> add bar property in css 42, etc
>
> This is mostly coming from users and us. Should be triagged by product and 
> triage owners.
>
> * Task is mostly development work. Examples:
> Refactor function foo, remove function bar, improve function plop, etc.
>
> Almost of them should be coming from engineering.
>
> Now, we will have cases for which a ticket will be both a task and an 
> enhancement.
> Example: https://bugzilla.mozilla.org/show_bug.cgi?id=1528330
> "Deliver acceptable GeckoView performance for Firefox Reality in H1"
> But I am sure you will agree that this new state will still be an improvement 
> over the current state.
>
>
> Now, a more concrete example, I have want to implement a new feature in 
> Firefox.
> I will create (or reuse) a bug with the "enhancement" value (probably as a 
> meta bug).
> Then, to develop the feature, I will create various "tasks" which will be 
> marking as
> blocking the meta bug.
>
> Because I am a bad developer, I will make mistakes and user will fill bugs 
> which
> will have the "defect" value (and I will use the regressed_by field).
>
>
> > Secondly, to bikeshed a little, could there be some name besides "task" for
> > that third category? Like I said above, everything we work as developers is
> > a developer task. "Refactor" seems like a clearer name, though maybe it is
> > a little limiting. "Side grade"? :)
>
> This is more than just refactoring. It is more "as an engineer, here is what 
> I have to do".
>
> About bikeshed, you can have a look here 
> https://bugzilla.mozilla.org/show_bug.cgi?id=1522342
> Where we did that.
>
> > Thirdly, what category should "organizational" bugs like meta bugs be
> > assigned to? I guess if you have a meta bug for a bunch of enhancements, it
> > would be an enhancement?
>
> Yeah, "it depends" ;) Probably...
>
>
> >
> > 3) Adding a new field called “Regressed by”
> > This is great! The weird encoding of "regressed by" in the "depends on"
> > field is one of the more confusing aspects of Bugzilla, given how important
> > it is. I spend a ton of time setting regressions for bugs, and even still I
> > have to stop occasionally to make sure I'm doing it the right way.
>
> Same here ;)
>
>
> S
>
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Searchfox now indexing m-beta, m-release, m-esr60

[Kartikaya Gupta]

Due to popular demand, searchfox now also has
mozilla-{beta,release,esr60} repos. Text search only for now; blame
should appear within a couple of days or so. Follow along on bug
1282123 or just mash F5 periodically to find out when exactly.
Rust/C++ indexing for beta and release will happen sometime after bug
1533801 arrives on those branches via the code train. Choo-choo!

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

Re: Searchfox now indexing m-beta, m-release, m-esr60

[Dave Townsend]

Thank you thank you thank you thank you thank you thank you thank you thank
you thank you thank you.

(I appreciate this)

On Tue, Mar 12, 2019 at 11:15 AM Kartikaya Gupta  wrote:

> Due to popular demand, searchfox now also has
> mozilla-{beta,release,esr60} repos. Text search only for now; blame
> should appear within a couple of days or so. Follow along on bug
> 1282123 or just mash F5 periodically to find out when exactly.
> Rust/C++ indexing for beta and release will happen sometime after bug
> 1533801 arrives on those branches via the code train. Choo-choo!
>
> Cheers,
> kats
> ___
> 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: Improving our usage of Bugzilla

[Onno Ekker]

On 12/03/2019 18:59, Sylvestre Ledru wrote:
> Le 12/03/2019 à 17:48, Andrew McCreight a écrit :
>> 
>> Secondly, to bikeshed a little, could there be some name besides
>> "task" for
>> that third category? Like I said above, everything we work as
>> developers is
>> a developer task. "Refactor" seems like a clearer name, though maybe
>> it is
>> a little limiting. "Side grade"? :)
> 
> This is more than just refactoring. It is more "as an engineer, here is
> what I have to do".

Maybe call it "Engineering"? "Maintenance"?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Searchfox now indexing m-beta, m-release, m-esr60

[Kris Maglione]

Huzzah!

On Tue, Mar 12, 2019 at 02:15:16PM -0400, Kartikaya Gupta wrote:

Due to popular demand, searchfox now also has
mozilla-{beta,release,esr60} repos. Text search only for now; blame
should appear within a couple of days or so. Follow along on bug
1282123 or just mash F5 periodically to find out when exactly.
Rust/C++ indexing for beta and release will happen sometime after bug
1533801 arrives on those branches via the code train. Choo-choo!

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


--
Kris Maglione
Senior Firefox Add-ons Engineer
Mozilla Corporation

For every complex problem there is an answer that is clear, simple,
and wrong.
--H. L. Mencken

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

Re: Searchfox now indexing m-beta, m-release, m-esr60

[Onno Ekker]

Op 12-3-2019 om 19:15 schreef Kartikaya Gupta:
> Due to popular demand, searchfox now also has
> mozilla-{beta,release,esr60} repos. Text search only for now; blame
> should appear within a couple of days or so. Follow along on bug
> 1282123 or just mash F5 periodically to find out when exactly.
> Rust/C++ indexing for beta and release will happen sometime after bug
> 1533801 arrives on those branches via the code train. Choo-choo!
> 
> Cheers,
> kats
> 

This is great, although it would be even more great if dxr would work
again for all products and branches...

See unassigned bug https://bugzil.la/1527889 - comm-central files are
out of date.

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

Re: Improving our usage of Bugzilla

[Felipe G]

Does performance work count as "enhancement" or "task"?
On one hand, it's not strictly refactoring.. On the other hand, it is not
development of a new feature, per the proposed description of enhancement.

On Tue, Mar 12, 2019 at 3:20 PM Onno Ekker  wrote:

> On 12/03/2019 18:59, Sylvestre Ledru wrote:
> > Le 12/03/2019 à 17:48, Andrew McCreight a écrit :
> >> 
> >> Secondly, to bikeshed a little, could there be some name besides
> >> "task" for
> >> that third category? Like I said above, everything we work as
> >> developers is
> >> a developer task. "Refactor" seems like a clearer name, though maybe
> >> it is
> >> a little limiting. "Side grade"? :)
> >
> > This is more than just refactoring. It is more "as an engineer, here is
> > what I have to do".
>
> Maybe call it "Engineering"? "Maintenance"?
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to Ship: Ignore custom cursors over 32 pixels intersecting UI

[Emilio Cobos Álvarez]

Hi, just some email I forgot to send a while ago.

Summary: Block cursor images larger than 32 pixels wide that intersect
the Browser UI, by falling back to the default cursor (as if no cursor
image could be loaded).

This prevents malware sites from hijacking the cursor and look as if the
cursor was on top of the browser UI. See the bug for test-cases and
examples.

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

Link to standard: N/A (this is more of an intervention)

Platform coverage: All desktop platforms.

Estimated target release: 67

Preference behind which this will be implemented: Two prefs control this
behavior. `layout.cursor.block.enabled` controls whether we block
cursors at all. `layout.cursor.block.max-size` controls the maximum size
in either axis that the cursor can have without being blocked.

Devtools bug: I don't think any particular devtools support is needed.

web-platform-tests: Can't really test this.

Do other browser engines implement this? Blink is doing the same change
in https://bugs.chromium.org/p/chromium/issues/detail?id=880863.

Their data estimates that 0.1% of page visits hit this, and they're
going with the same cursor size of 32 (I was going initially for 64, see
bug for discussion).

I made sure that should any surprise come up turning this off this is
trivial, but I think it's worth doing, and the change has been in
Nightly for quite a while without any surprise.

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

Re: Improving our usage of Bugzilla

[Dan Mosedale]

I've looked at the UX spec and Sylvestre's announcement, and I have
some relevant experience here working on teams which have used the
"enhancement" value of the "severity" field with the intent of using
that information to monitor our rate of defect introduction.

That workflow has turned out to have a footgun that has polluted our
usage, which appears to me to be replicated here, and which I think
has a simple fix.  I'd be curious to hear thoughts:

In particular, the severity field defaults to "normal", which we'd
like to use to mean a "normally severe defect".  Unfortunately,
because the default is set to "normal" and because Bugzilla has such a
large number of fields, what it actually means in practice is either
"normally severe defect" or "bug-filer was in a hurry or not paying
attention", with no easy way to tell the difference.  And that happens
a non-trivial amount of the time.

Some fields in bugzilla have a "---" value (including severity, but
it's not the default).  This can be used to mean "not-entered" or
"untriaged", completely eliminating the "hard-to-detect-bad-data
issue".

I'm concerned that the Type field as currently proposed (i.e. no ---
field as default) has effectively the same footgun, which will make
the data we gather with it less useful.

Thoughts?

Dan

Am Di., 12. März 2019 um 12:10 Uhr schrieb Felipe G :
>
> Does performance work count as "enhancement" or "task"?
> On one hand, it's not strictly refactoring.. On the other hand, it is not
> development of a new feature, per the proposed description of enhancement.
>
> On Tue, Mar 12, 2019 at 3:20 PM Onno Ekker  wrote:
>
> > On 12/03/2019 18:59, Sylvestre Ledru wrote:
> > > Le 12/03/2019 à 17:48, Andrew McCreight a écrit :
> > >> 
> > >> Secondly, to bikeshed a little, could there be some name besides
> > >> "task" for
> > >> that third category? Like I said above, everything we work as
> > >> developers is
> > >> a developer task. "Refactor" seems like a clearer name, though maybe
> > >> it is
> > >> a little limiting. "Side grade"? :)
> > >
> > > This is more than just refactoring. It is more "as an engineer, here is
> > > what I have to do".
> >
> > Maybe call it "Engineering"? "Maintenance"?
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving our usage of Bugzilla

[Daniel Veditz]

On Tue, Mar 12, 2019 at 10:53 AM 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


Without a replacement that would be unfortunate.  People have been asking
for what Honza described for more than 20 years (bug 540 and many
duplicates), and the current comment-editing feature--welcome though it
is--is not that. Abusing the User Story is a hack, but so is using "Depends
on" to also track "regressions". Something is better than nothing.

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

Re: Searchfox now indexing m-beta, m-release, m-esr60

[Tom Ritter]

On Tue, Mar 12, 2019, 1:18 PM Dave Townsend  wrote:

> Thank you thank you thank you thank you thank you thank you thank you thank
> you thank you thank you.
>

+11

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

Re: Intent to Ship: Ignore custom cursors over 32 pixels intersecting UI

[florian]

Given that this is not merely setting a limit because you find that 
implementation more convenient, but actually a case of considering it desirable 
to ignore large cursors in certain cases (and for security reasons even), I 
wonder if this is something that we should consider including in the 
specification. What do you tink?

—Florian

On Wednesday, March 13, 2019 at 4:50:01 AM UTC+9, Emilio Cobos Álvarez wrote:
> Hi, just some email I forgot to send a while ago.
> 
> Summary: Block cursor images larger than 32 pixels wide that intersect
> the Browser UI, by falling back to the default cursor (as if no cursor
> image could be loaded).
> 
> This prevents malware sites from hijacking the cursor and look as if the
> cursor was on top of the browser UI. See the bug for test-cases and
> examples.
> 
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1445844
> 
> Link to standard: N/A (this is more of an intervention)
> 
> Platform coverage: All desktop platforms.
> 
> Estimated target release: 67
> 
> Preference behind which this will be implemented: Two prefs control this
> behavior. `layout.cursor.block.enabled` controls whether we block
> cursors at all. `layout.cursor.block.max-size` controls the maximum size
> in either axis that the cursor can have without being blocked.
> 
> Devtools bug: I don't think any particular devtools support is needed.
> 
> web-platform-tests: Can't really test this.
> 
> Do other browser engines implement this? Blink is doing the same change
> in https://bugs.chromium.org/p/chromium/issues/detail?id=880863.
> 
> Their data estimates that 0.1% of page visits hit this, and they're
> going with the same cursor size of 32 (I was going initially for 64, see
> bug for discussion).
> 
> I made sure that should any surprise come up turning this off this is
> trivial, but I think it's worth doing, and the change has been in
> Nightly for quite a while without any surprise.
> 
>  -- Emilio

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

Re: Intent to Ship: Ignore custom cursors over 32 pixels intersecting UI

[Emilio Cobos Álvarez]

On 13/03/2019 00:22, flor...@rivoal.net wrote:
> Given that this is not merely setting a limit because you find that 
> implementation more convenient, but actually a case of considering it 
> desirable to ignore large cursors in certain cases (and for security reasons 
> even), I wonder if this is something that we should consider including in the 
> specification. What do you tink?

I think a note or such in the spec would be nice, yeah. FWIW some
platforms already had pre-existing cursor limits for similar reasons[1]
since forever.

I probably wouldn't bother specifying a concrete limit, though not sure
how you feel about that. Seems like depending how big the browser's UI
is, a browser could make different tradeoffs without compromising security.

 -- Emilio

[1]:
https://searchfox.org/mozilla-central/rev/89414a1df52d06cfc35529afb9a5a8542a6e4270/widget/gtk/nsWindow.cpp#1465

> —Florian
> 
> On Wednesday, March 13, 2019 at 4:50:01 AM UTC+9, Emilio Cobos Álvarez wrote:
>> Hi, just some email I forgot to send a while ago.
>>
>> Summary: Block cursor images larger than 32 pixels wide that intersect
>> the Browser UI, by falling back to the default cursor (as if no cursor
>> image could be loaded).
>>
>> This prevents malware sites from hijacking the cursor and look as if the
>> cursor was on top of the browser UI. See the bug for test-cases and
>> examples.
>>
>> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1445844
>>
>> Link to standard: N/A (this is more of an intervention)
>>
>> Platform coverage: All desktop platforms.
>>
>> Estimated target release: 67
>>
>> Preference behind which this will be implemented: Two prefs control this
>> behavior. `layout.cursor.block.enabled` controls whether we block
>> cursors at all. `layout.cursor.block.max-size` controls the maximum size
>> in either axis that the cursor can have without being blocked.
>>
>> Devtools bug: I don't think any particular devtools support is needed.
>>
>> web-platform-tests: Can't really test this.
>>
>> Do other browser engines implement this? Blink is doing the same change
>> in https://bugs.chromium.org/p/chromium/issues/detail?id=880863.
>>
>> Their data estimates that 0.1% of page visits hit this, and they're
>> going with the same cursor size of 32 (I was going initially for 64, see
>> bug for discussion).
>>
>> I made sure that should any surprise come up turning this off this is
>> trivial, but I think it's worth doing, and the change has been in
>> Nightly for quite a while without any surprise.
>>
>>  -- Emilio
> 
> ___
> 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: Ignore custom cursors over 32 pixels intersecting UI

[florian]

On Wednesday, March 13, 2019 at 8:36:17 AM UTC+9, Emilio Cobos Álvarez wrote:
> On 13/03/2019 00:22, Florian Rivoal wrote:
> > Given that this is not merely setting a limit because you find that 
> > implementation more convenient, but actually a case of considering it 
> > desirable to ignore large cursors in certain cases (and for security 
> > reasons even), I wonder if this is something that we should consider 
> > including in the specification. What do you tink?
> 
> I think a note or such in the spec would be nice, yeah. FWIW some
> platforms already had pre-existing cursor limits for similar reasons[1]
> since forever.
> 
> I probably wouldn't bother specifying a concrete limit, though not sure
> how you feel about that. Seems like depending how big the browser's UI
> is, a browser could make different tradeoffs without compromising security.

Could you raise it to the CSSWG, and we can see there what's appropriate, 
taking into account what others browsers do?

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