Re: Automatic changes during the dev workflow [was: Re: Upcoming changes to our C++ Coding Style]

[Ehsan Akhgari]

On Mon, Dec 17, 2018 at 1:22 PM Steve Fink  wrote:

> In theory, I would definitely prefer if all the code were auto-formatted
> during regular development(*), but in practice the performance means
> it's not as transparent as it needs to be -- I have noticed that since
> enabling the format-source extension, rebasing my patch stacks is
> significantly slower.
>

Please if you see performance issues, file them with some steps to
reproduce and CC Andi, he may be able to help.  We should definitely not
have to avoid running our tools due to performance issues.  :-)

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

Re: Automatic changes during the dev workflow [was: Re: Upcoming changes to our C++ Coding Style]

[Ehsan Akhgari]

On Fri, Dec 14, 2018 at 4:55 PM Kartikaya Gupta  wrote:

> On Fri, Dec 14, 2018 at 1:58 PM Sylvestre Ledru 
> wrote:
> > We have more and more tools at review phase (clang-format, flake8,
> eslint, clang-tidy, codespell, etc) which propose some auto-fixes.
>
> Honestly I find it quite annoying when I'm trying to review a patch
> and the phabricator diff is filled up with bot comments about
> formatting. As a reviewer, I shouldn't have to think about formatting,
> and it shouldn't fill up my screen and prevent me from looking at the
> actual code.
>
> > Currently, the turn around time of the tools is 14m on average which is
> usually faster than the reviewer looking at the patch.
>
> Usually, but not always. And 14 minutes is still long enough that the
> person writing the patch has context-switched away and is in the
> middle of doing something else when the bot comes a-knocking.
>

What if we *rejected* misformatted patches in Phabricator as opposed to
just comment on them?  That is, what if the bot would mark the reviews as
"Request Changes" when it found any problems, IOW it would review the patch
alongside with normal reviewers.  As Sylvestre mentioned the diffs on
individual lines is about to go away, but this way we'd also make sure that
misformatting caught at review time would actually block the landing of the
patch.


> > If Phabricator provides the capability, we could have the bot
> automatically proposing a new patchset on top on the normal one.
> > The reviewer would look at the updated version.
>
> This would be fine for the reviewer, but...
>
> > The main drawback would be that developer would have to retrieve the
> updated patch
> > before updating it.
>
> That's a chore too. For the developer writing the patch I feel like
> there should be a way to just say "please format this patch in-place
> for me" (basically what I expected `./mach clang-format` to do, except
> it doesn't quite - see bug 1514279) and even that should be opt-in.
> IMO the default behaviour should just be to automatically apply
> formatting prior to submission, without anybody having to think about
> it except in cases where the developer needs to apply "//clang-format
> off" blocks.
>

Right.  I think the ideal state would be for everyone to use editor
integration and local VCS hooks.  The VCS hooks we can enable in ./mach
bootstrap but editor integration is something people will need to opt into
turning on.  Once we get there, then I think formatting will be mostly
taken care of transparently for you without needing to think about it
consciously.

Doing things like rejecting misformatted code at review time may
incentivize people updating their local configuration.  I'm thinking of
reasons why that may break people's workflow but can't think of any right
now, curious to know if anyone else can?

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

Re: Automatic changes during the dev workflow [was: Re: Upcoming changes to our C++ Coding Style]

[Steve Fink]

In theory, I would definitely prefer if all the code were auto-formatted 
during regular development(*), but in practice the performance means 
it's not as transparent as it needs to be -- I have noticed that since 
enabling the format-source extension, rebasing my patch stacks is 
significantly slower. That's turning out to be a problem because it 
tends to take long enough to trigger a context switch, which is 
especially problematic when attempting to land something, wandering off 
during the rebase, and then realizing that too much time has elapsed and 
I'm going to need to start over and pull again because new changes have 
come in. (Maybe this just means I should get friendly with Lando, but 
even then I tend to have quite a few rebases that I want to tend to 
manually while in the testing/debugging phase.)


I know we collect build time statistics when running `mach build` that 
we can opt into uploading; would it be possible to collect timings for 
eg `hg rebase` operations? Some fancy new gps extension? :-) You 
probably shouldn't trust my gut "it feels slower" impressions too far.


 - sfink


(*) Now that we've taken the hit of uglifying the code, it seems like we 
should get as much mileage as we can out of it.


(I still think it was the right decision to go to a single style, and it 
was better to just pick one rather than blocking on arguing it down to a 
some "globally optimal" style first.)



On 12/14/2018 10:57 AM, Sylvestre Ledru wrote:
I think we should aim at option b) (updated automatically by bots 
after submission to Phabricator)


We have more and more tools at review phase (clang-format, flake8, 
eslint, clang-tidy, codespell, etc) which propose some auto-fixes.


Currently, the turn around time of the tools is 14m on average which 
is usually faster than the reviewer looking at the patch.
If Phabricator provides the capability, we could have the bot 
automatically proposing a new patchset on top on the normal one.

The reviewer would look at the updated version.

By doing that, we would save time for everyone. The main drawback 
would be that developer would have to retrieve the updated patch

before updating it.

Sylvestre


Le 13/12/2018 à 23:53, Ehsan Akhgari a écrit :
Previously I had shied away from ideas similar to (a) or (b) since I 
wasn't sure if that would be what developers would expect and accept, 
given that it would cause the change the reviewer sees to no longer 
match their local change, which could cause hicups e.g. when trying 
to find the code that a reviewer has commented on locally, or when 
rebasing on top of a newer version of mozilla-central after Lando has 
landed your patch (which may cause conflicts with your local patch 
due to formatting differences).


Do we think these types of issues aren't something we should be 
concerned about?


Thanks,
Ehsan

On Fri, Dec 7, 2018 at 3:09 PM Andrew Halberstadt > wrote:


    I think we should implement a) and do the formatting prior to
    submission. This prevents us from wasting reviewer time on format
    issues, and also makes sure that "what you see in phab, is what
    gets landed".

    On Fri, Dec 7, 2018, 2:04 PM Gregory Szorc, mailto:g...@mozilla.com>> wrote:

    On Fri, Dec 7, 2018 at 1:57 PM Botond Ballo
    mailto:bba...@mozilla.com>> wrote:

    > On Fri, Dec 7, 2018 at 11:36 AM Sylvestre Ledru
    mailto:sle...@mozilla.com>>
    > wrote:
    > > In the meantime, we will be running a bot weekly to
    reformat the
    > > mistakes and add the changeset into the ignore lists.
    > > But in the long run this won’t be sustainable, so once we 
gain

    > > confidence that a good number of developers have
    successfully integrated
    > > clang-format into their local workflow, we will look into
    enabling a
    > > Mercurial hook on hg.mozilla.org 
    to reject misformatted code upon push
    > > time.  That will be the ultimate solution to help ensure
    that our code
    > > will be properly formatted at all times.
    >
    > Have you considered something like running clang-format
    automatically
    > during landing (i.e. as part of what Lando does to the
    patch)? That
    > seems like it would achieve the best of both worlds, by not
    placing
    > any requirements on what developers do locally, while also
    ensuring
    > the tree is always properly formatted without cleanup commits.
    >

    I chatted with Sylvestre earlier today. While I don't want to
    speak for
    him, I believe we both generally agree that the formatting
    should happen
    "automagically" as part of the patch review and landing
    lifecycle, even if
    the client doesn't have their machine configured for
    formatting on save.
    This would mean that patches are either:

    a) auto-formatted 

Re: The upcoming C/C++ coding style change

[Ehsan Akhgari]

On Sun, Dec 16, 2018 at 9:08 PM Makoto Kato  wrote:

> Hi,
>
> Is Objective-C++ (*.mm) still old format?  Or Should I file a bug for it?
>

We didn't include Objective-C++ in the initial reformatting of the tree
mostly to avoid scope creep, but clang-format is well capable of formatting
it.  Please file a bug for it now, it should be a very simple change
(Adding ".mm" here: <
https://searchfox.org/mozilla-central/rev/1a4a7745fd4a14402a0de0e9abc040724d4fcf8f/python/mozbuild/mozbuild/mach_commands.py#1650>)
to include it.

Thanks,
Ehsan


>
> On Thu, Nov 29, 2018 at 9:38 PM Sylvestre Ledru 
> wrote:
>
> > Hello,
> >
> > As Ehsan announced recently, we are going to reformat Friday 30 November.
> > In order to mitigate the impact on the uplifts process, we choose this
> > date before the merge day.
> >
> > In term of execution, we will close the trees Friday around 8am
> > Paris/Berlin time (11pm PST).
> > We will then merge autoland and inbound into mozilla-central.
> > We are planning to land the big patch around 12am (3am PST).
> >
> > The experimentation with dom/media highlighted that we need an efficient
> > way to automatically rebase patches before the merge.
> > To achieve this, we updated the bootstrap process to include an extension
> > called hg formatsource.
> > This extension will automatically rebase the local changes to avoid
> > conflicts.
> > Please note that it is important that the extension is installed before
> > the pulling a revision including the reformatted sources.
> >
> > More information on:
> >
> >
> https://docs.google.com/document/d/13AwAsvKMhH0mflDlfatBqn6LmZHiQih76oxM4zfrPl4/edit
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1507711
> >
> > Sylvestre, Ehsan and Andi
> >
> > ___
> > 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
>


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

Re: Upcoming changes to our C++ Coding Style

[Ehsan Akhgari]

On Mon, Dec 17, 2018 at 9:33 AM Kartikaya Gupta  wrote:

> Local commit hooks are even better, thanks! Are there instructions
> somewhere on how to set up the hooks and make sure they run properly?
>

We've yet to document these hooks but enabling them is very similar to
enabling the lint hooks which are documented here: <
https://firefox-source-docs.mozilla.org/tools/lint/usage.html#using-a-vcs-hook>.
The only difference is that you should use hooks_clang_format.py as the
file name.


> On Mon, Dec 17, 2018 at 9:22 AM Ehsan Akhgari 
> wrote:
> >
> > On Fri, Dec 14, 2018 at 7:20 AM Kartikaya Gupta 
> wrote:
> >>
> >> Personally I would prefer if we rewrote the commits locally to be
> >> formatted prior to submitting it into Phabricator. That way everything
> >> stays in sync. Also usually clang-formatting a patch is the last thing
> >> I want to do before submission anyway. And doing it now is kind of
> >> annoying if you have a multi-patch stack because by default it only
> >> operates on uncommitted changes so formatting a patch that's not the
> >> topmost means doing some patch juggling/rebasing.
> >
> >
> > Right.  I think that is the thinking behind the plan of enabling local
> commit hooks (provided in bug 1507007) if I understand your point
> correctly.  That will ensure that anything that is committed will be
> formatted properly, and as such it should ensure that code will be
> formatted before being submitted for review, as well as making sure that
> scenarios such as rebasing will also not mess up the formatting of the
> commits in your local queue.
> >
> >>
> >>
> >> On Thu, Dec 13, 2018 at 5:54 PM Ehsan Akhgari 
> wrote:
> >> >
> >> > Previously I had shied away from ideas similar to (a) or (b) since I
> wasn't sure if that would be what developers would expect and accept, given
> that it would cause the change the reviewer sees to no longer match their
> local change, which could cause hicups e.g. when trying to find the code
> that a reviewer has commented on locally, or when rebasing on top of a
> newer version of mozilla-central after Lando has landed your patch (which
> may cause conflicts with your local patch due to formatting differences).
> >> >
> >> > Do we think these types of issues aren't something we should be
> concerned about?
> >> >
> >> > Thanks,
> >> > Ehsan
> >> >
> >> > On Fri, Dec 7, 2018 at 3:09 PM Andrew Halberstadt 
> wrote:
> >> >>
> >> >> I think we should implement a) and do the formatting prior to
> submission. This prevents us from wasting reviewer time on format issues,
> and also makes sure that "what you see in phab, is what gets landed".
> >> >>
> >> >> On Fri, Dec 7, 2018, 2:04 PM Gregory Szorc,  wrote:
> >> >>>
> >> >>> On Fri, Dec 7, 2018 at 1:57 PM Botond Ballo 
> wrote:
> >> >>>
> >> >>> > On Fri, Dec 7, 2018 at 11:36 AM Sylvestre Ledru <
> sle...@mozilla.com>
> >> >>> > wrote:
> >> >>> > > In the meantime, we will be running a bot weekly to reformat the
> >> >>> > > mistakes and add the changeset into the ignore lists.
> >> >>> > > But in the long run this won’t be sustainable, so once we gain
> >> >>> > > confidence that a good number of developers have successfully
> integrated
> >> >>> > > clang-format into their local workflow, we will look into
> enabling a
> >> >>> > > Mercurial hook on hg.mozilla.org to reject misformatted code
> upon push
> >> >>> > > time.  That will be the ultimate solution to help ensure that
> our code
> >> >>> > > will be properly formatted at all times.
> >> >>> >
> >> >>> > Have you considered something like running clang-format
> automatically
> >> >>> > during landing (i.e. as part of what Lando does to the patch)?
> That
> >> >>> > seems like it would achieve the best of both worlds, by not
> placing
> >> >>> > any requirements on what developers do locally, while also
> ensuring
> >> >>> > the tree is always properly formatted without cleanup commits.
> >> >>> >
> >> >>>
> >> >>> I chatted with Sylvestre earlier today. While I don't want to speak
> for
> >> >>> him, I believe we both generally agree that the formatting should
> happen
> >> >>> "automagically" as part of the patch review and landing lifecycle,
> even if
> >> >>> the client doesn't have their machine configured for formatting on
> save.
> >> >>> This would mean that patches are either:
> >> >>>
> >> >>> a) auto-formatted on clients as part of being submitted to
> Phabricator
> >> >>> b) updated automatically by bots after submission to Phabricator
> >> >>> c) auto-formatted by Lando as part of landing
> >> >>>
> >> >>> Lando rewrites/rebases commits as part of landing, so commit hashes
> already
> >> >>> change. So if auto-formatting magically occurs and "just works" as
> part of
> >> >>> the review/landing process, there should be little to no developer
> >> >>> inconvenience compared to what happens today. i.e. developers don't
> need to
> >> >>> do anything special to have their patches land with proper
> formatting.
> >> >>> 

Re: Upcoming changes to our C++ Coding Style

[Kartikaya Gupta]

Local commit hooks are even better, thanks! Are there instructions
somewhere on how to set up the hooks and make sure they run properly?

On Mon, Dec 17, 2018 at 9:22 AM Ehsan Akhgari  wrote:
>
> On Fri, Dec 14, 2018 at 7:20 AM Kartikaya Gupta  wrote:
>>
>> Personally I would prefer if we rewrote the commits locally to be
>> formatted prior to submitting it into Phabricator. That way everything
>> stays in sync. Also usually clang-formatting a patch is the last thing
>> I want to do before submission anyway. And doing it now is kind of
>> annoying if you have a multi-patch stack because by default it only
>> operates on uncommitted changes so formatting a patch that's not the
>> topmost means doing some patch juggling/rebasing.
>
>
> Right.  I think that is the thinking behind the plan of enabling local commit 
> hooks (provided in bug 1507007) if I understand your point correctly.  That 
> will ensure that anything that is committed will be formatted properly, and 
> as such it should ensure that code will be formatted before being submitted 
> for review, as well as making sure that scenarios such as rebasing will also 
> not mess up the formatting of the commits in your local queue.
>
>>
>>
>> On Thu, Dec 13, 2018 at 5:54 PM Ehsan Akhgari  
>> wrote:
>> >
>> > Previously I had shied away from ideas similar to (a) or (b) since I 
>> > wasn't sure if that would be what developers would expect and accept, 
>> > given that it would cause the change the reviewer sees to no longer match 
>> > their local change, which could cause hicups e.g. when trying to find the 
>> > code that a reviewer has commented on locally, or when rebasing on top of 
>> > a newer version of mozilla-central after Lando has landed your patch 
>> > (which may cause conflicts with your local patch due to formatting 
>> > differences).
>> >
>> > Do we think these types of issues aren't something we should be concerned 
>> > about?
>> >
>> > Thanks,
>> > Ehsan
>> >
>> > On Fri, Dec 7, 2018 at 3:09 PM Andrew Halberstadt  wrote:
>> >>
>> >> I think we should implement a) and do the formatting prior to submission. 
>> >> This prevents us from wasting reviewer time on format issues, and also 
>> >> makes sure that "what you see in phab, is what gets landed".
>> >>
>> >> On Fri, Dec 7, 2018, 2:04 PM Gregory Szorc,  wrote:
>> >>>
>> >>> On Fri, Dec 7, 2018 at 1:57 PM Botond Ballo  wrote:
>> >>>
>> >>> > On Fri, Dec 7, 2018 at 11:36 AM Sylvestre Ledru 
>> >>> > wrote:
>> >>> > > In the meantime, we will be running a bot weekly to reformat the
>> >>> > > mistakes and add the changeset into the ignore lists.
>> >>> > > But in the long run this won’t be sustainable, so once we gain
>> >>> > > confidence that a good number of developers have successfully 
>> >>> > > integrated
>> >>> > > clang-format into their local workflow, we will look into enabling a
>> >>> > > Mercurial hook on hg.mozilla.org to reject misformatted code upon 
>> >>> > > push
>> >>> > > time.  That will be the ultimate solution to help ensure that our 
>> >>> > > code
>> >>> > > will be properly formatted at all times.
>> >>> >
>> >>> > Have you considered something like running clang-format automatically
>> >>> > during landing (i.e. as part of what Lando does to the patch)? That
>> >>> > seems like it would achieve the best of both worlds, by not placing
>> >>> > any requirements on what developers do locally, while also ensuring
>> >>> > the tree is always properly formatted without cleanup commits.
>> >>> >
>> >>>
>> >>> I chatted with Sylvestre earlier today. While I don't want to speak for
>> >>> him, I believe we both generally agree that the formatting should happen
>> >>> "automagically" as part of the patch review and landing lifecycle, even 
>> >>> if
>> >>> the client doesn't have their machine configured for formatting on save.
>> >>> This would mean that patches are either:
>> >>>
>> >>> a) auto-formatted on clients as part of being submitted to Phabricator
>> >>> b) updated automatically by bots after submission to Phabricator
>> >>> c) auto-formatted by Lando as part of landing
>> >>>
>> >>> Lando rewrites/rebases commits as part of landing, so commit hashes 
>> >>> already
>> >>> change. So if auto-formatting magically occurs and "just works" as part 
>> >>> of
>> >>> the review/landing process, there should be little to no developer
>> >>> inconvenience compared to what happens today. i.e. developers don't need 
>> >>> to
>> >>> do anything special to have their patches land with proper formatting.
>> >>> ___
>> >>> dev-platform mailing list
>> >>> dev-platform@lists.mozilla.org
>> >>> https://lists.mozilla.org/listinfo/dev-platform
>> >
>> >
>> >
>> > --
>> > Ehsan
>
>
>
> --
> Ehsan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Upcoming changes to our C++ Coding Style

[Ehsan Akhgari]

On Fri, Dec 14, 2018 at 7:20 AM Kartikaya Gupta  wrote:

> Personally I would prefer if we rewrote the commits locally to be
> formatted prior to submitting it into Phabricator. That way everything
> stays in sync. Also usually clang-formatting a patch is the last thing
> I want to do before submission anyway. And doing it now is kind of
> annoying if you have a multi-patch stack because by default it only
> operates on uncommitted changes so formatting a patch that's not the
> topmost means doing some patch juggling/rebasing.
>

Right.  I think that is the thinking behind the plan of enabling local
commit hooks (provided in bug 1507007) if I understand your point
correctly.  That will ensure that anything that is committed will be
formatted properly, and as such it should ensure that code will be
formatted before being submitted for review, as well as making sure that
scenarios such as rebasing will also not mess up the formatting of the
commits in your local queue.


>
> On Thu, Dec 13, 2018 at 5:54 PM Ehsan Akhgari 
> wrote:
> >
> > Previously I had shied away from ideas similar to (a) or (b) since I
> wasn't sure if that would be what developers would expect and accept, given
> that it would cause the change the reviewer sees to no longer match their
> local change, which could cause hicups e.g. when trying to find the code
> that a reviewer has commented on locally, or when rebasing on top of a
> newer version of mozilla-central after Lando has landed your patch (which
> may cause conflicts with your local patch due to formatting differences).
> >
> > Do we think these types of issues aren't something we should be
> concerned about?
> >
> > Thanks,
> > Ehsan
> >
> > On Fri, Dec 7, 2018 at 3:09 PM Andrew Halberstadt 
> wrote:
> >>
> >> I think we should implement a) and do the formatting prior to
> submission. This prevents us from wasting reviewer time on format issues,
> and also makes sure that "what you see in phab, is what gets landed".
> >>
> >> On Fri, Dec 7, 2018, 2:04 PM Gregory Szorc,  wrote:
> >>>
> >>> On Fri, Dec 7, 2018 at 1:57 PM Botond Ballo 
> wrote:
> >>>
> >>> > On Fri, Dec 7, 2018 at 11:36 AM Sylvestre Ledru 
> >>> > wrote:
> >>> > > In the meantime, we will be running a bot weekly to reformat the
> >>> > > mistakes and add the changeset into the ignore lists.
> >>> > > But in the long run this won’t be sustainable, so once we gain
> >>> > > confidence that a good number of developers have successfully
> integrated
> >>> > > clang-format into their local workflow, we will look into enabling
> a
> >>> > > Mercurial hook on hg.mozilla.org to reject misformatted code upon
> push
> >>> > > time.  That will be the ultimate solution to help ensure that our
> code
> >>> > > will be properly formatted at all times.
> >>> >
> >>> > Have you considered something like running clang-format automatically
> >>> > during landing (i.e. as part of what Lando does to the patch)? That
> >>> > seems like it would achieve the best of both worlds, by not placing
> >>> > any requirements on what developers do locally, while also ensuring
> >>> > the tree is always properly formatted without cleanup commits.
> >>> >
> >>>
> >>> I chatted with Sylvestre earlier today. While I don't want to speak for
> >>> him, I believe we both generally agree that the formatting should
> happen
> >>> "automagically" as part of the patch review and landing lifecycle,
> even if
> >>> the client doesn't have their machine configured for formatting on
> save.
> >>> This would mean that patches are either:
> >>>
> >>> a) auto-formatted on clients as part of being submitted to Phabricator
> >>> b) updated automatically by bots after submission to Phabricator
> >>> c) auto-formatted by Lando as part of landing
> >>>
> >>> Lando rewrites/rebases commits as part of landing, so commit hashes
> already
> >>> change. So if auto-formatting magically occurs and "just works" as
> part of
> >>> the review/landing process, there should be little to no developer
> >>> inconvenience compared to what happens today. i.e. developers don't
> need to
> >>> do anything special to have their patches land with proper formatting.
> >>> ___
> >>> dev-platform mailing list
> >>> dev-platform@lists.mozilla.org
> >>> https://lists.mozilla.org/listinfo/dev-platform
> >
> >
> >
> > --
> > Ehsan
>


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

Re: Automatic changes during the dev workflow [was: Re: Upcoming changes to our C++ Coding Style]

[Sylvestre Ledru]

Le 14/12/2018 à 22:55, Kartikaya Gupta a écrit :

On Fri, Dec 14, 2018 at 1:58 PM Sylvestre Ledru  wrote:

We have more and more tools at review phase (clang-format, flake8, eslint, 
clang-tidy, codespell, etc) which propose some auto-fixes.

Honestly I find it quite annoying when I'm trying to review a patch
and the phabricator diff is filled up with bot comments about
formatting. As a reviewer, I shouldn't have to think about formatting,
and it shouldn't fill up my screen and prevent me from looking at the
actual code.


We received this feedback from several folks and we agree (initially, we were 
showing the diff itself but it wasn't
bringing much).
This is fixed in staging and the fix should go in the next release of the 
platform (Dec 22nd)

Cheers

S


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

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

[Mihai Boldan]

Hello,

Here's the list of new issues found and filed by the Desktop Release QA 
team last two weeks.
Additional details on the team's priorities last week, as well as the 
plans for the current week are available at: https://tinyurl.com/y8yjg3vj

Bugs logged by Desktop Release QA in the last 7 days:

Firefox: General
NEW - https://bugzil.la/1514250 - Firefox doesn't restart after a crash 
if Browser Toolbox is opened


Firefox: New Tab Page
NEW - https://bugzil.la/1514178 - If a page is slowing down the browser, 
the new tab page content doesn't show


Core: Security: PSM
NEW - https://bugzil.la/1512962 - BitDefender is not adding it's 
certificate on Non-ASCII profiles and the https webpages are displaying 
a "connection is not secured" error


Toolkit: Crash Reporting
NEW - https://bugzil.la/1513554 - The "finger pointer" is not displayed 
for several about:crashes buttons


Toolkit: Performance Monitoring
NEW - https://bugzil.la/1513475 - [Touch] Closing a tab in 
about:performance automatically selects the next element with the X 
button selected


Toolkit: Performance Monitoring
NEW - https://bugzil.la/1513491 - NVDA or VoiceOver does not read 
several buttons on hover in about:performance section


Toolkit: Performance Monitoring
NEW - https://bugzil.la/1513525 - Private session and normal session 
tabs are displayed in the same task manager session without any delimitation


Toolkit: Performance Monitoring
NEW - https://bugzil.la/1513834 - No horizontal scrollbar is displayed 
inside the about:performance page after resizing the Firefox window


Toolkit: Performance Monitoring
NEW - https://bugzil.la/1513885 - User must be able to select multiple 
tabs in about:performance as well


Toolkit: Themes
NEW - https://bugzil.la/1514223 - [Edit Pop-Up Blocker] The text for 
"Remove Website" and "Remove All Websites" buttons are not centered


DevTools: CSS Rules Inspector
NEW - https://bugzil.la/1513223 - Track changes - \\characters are not 
properly picked up by the changes tab


DevTools: Inspector
NEW - https://bugzil.la/1512956 - Wikipedia's body overflow-x property 
re-appears on inspector tab swap


DevTools: Responsive Design Mode
NEW - https://bugzil.la/1513522 - [Win] Black flash instead of 
button+icon on hover on RDM/DevTools buttons


This is available as a Bugzilla bug list as well: 
https://tinyurl.com/ydcs3o3e


Regards,
Mihai Boldan
QC Engineer
Softvision

The content of this communication is classified as Softvision 
Confidential and Proprietary Information.


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