Re: How can I run Firefox programatically in fullscreen?

[Michael Cooper]

I'm not sure this is quite what you're looking for, but for Corsica (the
software powering the ambient displays around the office) we do this by
setting the pref full-screen-api.allow-trusted-requests-only to false. This
then allows the webpage we load (Corsica) to immediately request full
screen using the normal DOM methods.

On Mon, Jun 26, 2017 at 2:12 PM, Armen Zambrano Gasparnian <
arme...@mozilla.com> wrote:

> Asking around, looking on dxr or MDN did not yield something easily.
>
> I don't want to have to use Marionette in this specific automation context.
>
> Thanks in advance,
> Armen
> ___
> 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: How can I run Firefox programatically in fullscreen?

[Xidorn Quan]

On Tue, Jun 27, 2017, at 07:12 AM, Armen Zambrano Gasparnian wrote:
> Asking around, looking on dxr or MDN did not yield something easily.
> 
> I don't want to have to use Marionette in this specific automation
> context.

Firefox cannot / shouldn't start in full screen mode because it is
tricky to get everything work properly on all platforms with that.

You can always set window.fullScreen to true in the top level browser
document after it shows up, though.

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

How can I run Firefox programatically in fullscreen?

[Armen Zambrano Gasparnian]

Asking around, looking on dxr or MDN did not yield something easily.

I don't want to have to use Marionette in this specific automation context.

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

Re: Quantum Flow Engineering Newsletter #14

[Ehsan Akhgari]

On 06/26/2017 09:52 AM, Armen Zambrano Gasparnian wrote:

On Friday, 23 June 2017 10:05:42 UTC-4, Ehsan Akhgari  wrote:

On Fri, Jun 23, 2017 at 4:19 AM, Chris Peterson 
wrote:



On 6/23/17 12:17 AM, Ehsan Akhgari wrote:

But to speak of a more direct measurement of performance, let's look at
our progress on Speedometer V2
.

Ehsan, were you comparing against http://speedometer2.benj.me?

I used this instance for these measurements.

Or this http://browserbench.org/Speedometer/?

This is still Speedometer V1, FWIW.

Or using the AWFY code? (It uses local proxy)


Today, I measured our progress so far on this benchmark by comparing
Firefox 53, 54, 55.0b3 (latest beta as of this writing) and the latest
Nightly, all x64 builds, on the reference hardware
.  This is the result (numbers are
the reported benchmark score, higher is better):

[image: Speedometer improvements]


How do these Speedometer V2 scores map to the results on AWFY? AWFY shows
many Speedometer sub-tests, but no score in the range of 70.21. AWFY
machine #36 is the reference hardware.

https://arewefastyet.com/#machine=36&view=breakdown&suite=speedometer-misc


Armen has been investigating the difference.  The Speedometer benchmark is
extremely sensitive to anything else that is going on on the machine at the
time you are running the tests, see for example
https://bugzilla.mozilla.org/show_bug.cgi?id=1373396#c3 where he discovered
that turning off the "Shut off display after 15 minutes" setting improves
our benchmark score by about 10 points or so!  I think there are other
investigations ongoing to dig into the remaining difference as well.


Currently, machine #36 is testing against non-PGO builds from inbound (to catch 
regressions).
I'm looking into adding mozilla-central PGO builds to the mix.
I assume PGO builds can run slightly faster than non-PGO builds.

Once we have PGO builds we will be able to see if there are anymore machine 
configration changes required (I doubt it).

Direct link to the speedometer score on machine #36:
https://arewefastyet.com/#machine=36&view=single&suite=speedometer-misc&subtest=score


(Also note that there is a speed difference on Speedometer between Nightly
and Beta, where Nightly with the same code will be a bit slower than Beta
since some Nightly specific features do show up in Speedometer profiles
currently, for example things like bug 1375568 are currently Nightly only,
and there are also debugging checks like <
https://searchfox.org/mozilla-central/rev/3291398f10dcbe192fb52e74974b172616c018aa/ipc/chromium/src/base/pickle.h#26>
that show up a bit in profiles as well.  I think that explains why 55.0b3
is scoring so high comparing to 56.0a1 there.)

Cheers,
--
Ehsan

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


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

Re: Quantum Flow Engineering Newsletter #14

[Armen Zambrano Gasparnian]

On Friday, 23 June 2017 10:05:42 UTC-4, Ehsan Akhgari  wrote:
> On Fri, Jun 23, 2017 at 4:19 AM, Chris Peterson 
> wrote:
> 
> >
> >
> > On 6/23/17 12:17 AM, Ehsan Akhgari wrote:
> >
> > But to speak of a more direct measurement of performance, let's look at
> > our progress on Speedometer V2
> > .

Ehsan, were you comparing against http://speedometer2.benj.me?
Or this http://browserbench.org/Speedometer/?
Or using the AWFY code? (It uses local proxy)

> > Today, I measured our progress so far on this benchmark by comparing
> > Firefox 53, 54, 55.0b3 (latest beta as of this writing) and the latest
> > Nightly, all x64 builds, on the reference hardware
> > .  This is the result (numbers are
> > the reported benchmark score, higher is better):
> >
> > [image: Speedometer improvements]
> >
> >
> > How do these Speedometer V2 scores map to the results on AWFY? AWFY shows
> > many Speedometer sub-tests, but no score in the range of 70.21. AWFY
> > machine #36 is the reference hardware.
> >
> > https://arewefastyet.com/#machine=36&view=breakdown&suite=speedometer-misc
> >
> 
> Armen has been investigating the difference.  The Speedometer benchmark is
> extremely sensitive to anything else that is going on on the machine at the
> time you are running the tests, see for example
> https://bugzilla.mozilla.org/show_bug.cgi?id=1373396#c3 where he discovered
> that turning off the "Shut off display after 15 minutes" setting improves
> our benchmark score by about 10 points or so!  I think there are other
> investigations ongoing to dig into the remaining difference as well.
> 

Currently, machine #36 is testing against non-PGO builds from inbound (to catch 
regressions).
I'm looking into adding mozilla-central PGO builds to the mix.
I assume PGO builds can run slightly faster than non-PGO builds.

Once we have PGO builds we will be able to see if there are anymore machine 
configration changes required (I doubt it).

Direct link to the speedometer score on machine #36:
https://arewefastyet.com/#machine=36&view=single&suite=speedometer-misc&subtest=score

> (Also note that there is a speed difference on Speedometer between Nightly
> and Beta, where Nightly with the same code will be a bit slower than Beta
> since some Nightly specific features do show up in Speedometer profiles
> currently, for example things like bug 1375568 are currently Nightly only,
> and there are also debugging checks like <
> https://searchfox.org/mozilla-central/rev/3291398f10dcbe192fb52e74974b172616c018aa/ipc/chromium/src/base/pickle.h#26>
> that show up a bit in profiles as well.  I think that explains why 55.0b3
> is scoring so high comparing to 56.0a1 there.)
> 
> Cheers,
> -- 
> Ehsan

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

Re: Switching to per-channel profiles

[Gijs Kruitbosch]

On 26/06/2017 14:03, Ben Hearsum wrote:

On 2017-06-23 06:43 PM, Dave Townsend wrote:

TL;DR: We should make each Firefox channel use its own profile data
allowing you to run multiple channels at the same time.

Running multiple channels of Firefox is currently harder than it needs to
be. You can't start more than one channel at a time and either you use 
the

same profile data for each channel running the risk of hitting bugs with
downgrades or you have to create custom shortcuts to use different 
profiles
for each channel. The exception to this is the developer edition which 
uses
its own profile data by default. This turned out to be what most 
developers

wanted and matches Chrome's behaviour. So we should do the same thing for
the other channels.

The technical details of how to do this are a little challenging so 
here is

a proposal that hopes to limit the impact of the change:

* Release will continue to work as it does today. The default profile
listed in profiles.ini will be loaded and used as normal.
* When Nightly and Beta first start they will look for a profile to use:
** First choice will be determined by a new flag in profiles.ini for each
channel.
** Second choice will be a profile with a specific name which will be
different for each channel. We do this because if the user runs an older
build of Firefox it will blow away the new flags we use above.
** Finally if no profile has been found a new profile will be created 
with

the appropriate name.
* Throughout, if the command line includes --profile or -P to choose a
specific profile then we respect that.

 >
 > The developer edition already does effectively the above just without 
 > the

 > custom flag which allows you to rename your profile (
 > https://bugzilla.mozilla.org/show_bug.cgi?id=1098986). As part of 
this > we would upgrade developer edition to support this too.


I've noticed that Firefox Developer Edition doesn't respect the "Use the 
selected profile without asking at startup" button (eg: if I select my 
non-devedition profile with that checked, it still starts with the 
DevEdition profile next time). If we're enabling similar logic across 
all channels, we should probably fix this or get rid of the button 
(since it will serve no function AFAICT).


- Ben


This is https://bugzilla.mozilla.org/show_bug.cgi?id=1098986 .

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

Re: Switching to per-channel profiles

[Ben Hearsum]

On 2017-06-23 06:43 PM, Dave Townsend wrote:

TL;DR: We should make each Firefox channel use its own profile data
allowing you to run multiple channels at the same time.

Running multiple channels of Firefox is currently harder than it needs to
be. You can't start more than one channel at a time and either you use the
same profile data for each channel running the risk of hitting bugs with
downgrades or you have to create custom shortcuts to use different profiles
for each channel. The exception to this is the developer edition which uses
its own profile data by default. This turned out to be what most developers
wanted and matches Chrome's behaviour. So we should do the same thing for
the other channels.

The technical details of how to do this are a little challenging so here is
a proposal that hopes to limit the impact of the change:

* Release will continue to work as it does today. The default profile
listed in profiles.ini will be loaded and used as normal.
* When Nightly and Beta first start they will look for a profile to use:
** First choice will be determined by a new flag in profiles.ini for each
channel.
** Second choice will be a profile with a specific name which will be
different for each channel. We do this because if the user runs an older
build of Firefox it will blow away the new flags we use above.
** Finally if no profile has been found a new profile will be created with
the appropriate name.
* Throughout, if the command line includes --profile or -P to choose a
specific profile then we respect that.

>
> The developer edition already does effectively the above just without 
> the

> custom flag which allows you to rename your profile (
> https://bugzilla.mozilla.org/show_bug.cgi?id=1098986). As part of 
this > we would upgrade developer edition to support this too.


I've noticed that Firefox Developer Edition doesn't respect the "Use the 
selected profile without asking at startup" button (eg: if I select my 
non-devedition profile with that checked, it still starts with the 
DevEdition profile next time). If we're enabling similar logic across 
all channels, we should probably fix this or get rid of the button 
(since it will serve no function AFAICT).


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

[Firefox Desktop] Issues found: June 19th to June 23rd

[Florin Mezei]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA Team 
last week, June 19 - June 23 (week #25).

Additional details on the team's priorities last week as well as the plans for 
the current week are available at:
https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus

RELEASE CHANNEL
none

BETA CHANNEL


ID

Summary

Product

Component

Is a regression

Assigned to


1374662  

Thumbnails disappear from "about:newtab" when adding a new thumbnail

Firefox

New Tab Page

NO

NOBODY


NIGHTLY CHANNEL 

none

 

ESR CHANNEL
none

 

Regards,

Florin.

Desktop Release QA

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