Enable coalescing mousemove in Firefox Nightly builds

[sshih]

We plan to enable coalescing mousemove in Firefox Nightly builds within the 
next few days. With this enabled, we will coalesce all mousemove events to one 
per refresh driver tick. It is to reduce the cost of processing unnecessary 
mousemove events that have no visual effect to the users.

Related Bugs:
Bug 1392876 - Enable coalescing mouse events to be once per refresh cycle
Bug 1361067 - coalesce mouse events to be once per refresh cycle 
(requestAnimationFrame, rAF) (preffed off)

Link to standard:
NA

Platform coverage:
All

Target release:
TBD. We'd like to see if this helps some use cases. If not, we'd keep this 
switch off for FF57.

Preference behind which this is implemented:
dom.event.coalesce_mouse_move

Do other browser engines implement this?
Google shipped it in chrome 60.

Security & Privacy Concerns:
None
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implementing a Chrome DevTools Protocol server in Firefox

[James Graham]

On 31/08/17 02:14, Michael Smith wrote:

On 8/30/2017 15:56, David Burns wrote:
 > Do we know if the other vendors would see value in having this 
spec'ed properly so that we have true interop here? Reverse engineering 
seems like a "fun" project but what stops people from breaking stuff 
without realising?


Fortunately we're not reverse engineering here (for the most part), all 
protocol messages are specified in a machine-readable JSON format which 
includes inline documentation [0] --- this is what the cdp Rust library 
consumes. The spec is versioned and the authors do seem to follow a 
proper process of introducing new features as "experimental", 
stabilizing mature ones, and deprecating things before they're removed.


I think that the reverse engineering part is not the wire protocol, 
which is usually the most trivial part, but the associated semantics. It 
doesn't seem that useful to support the protocol unless we behave in the 
same way as Chrome in response to the messages. It's the specification 
of that behaviour which is — as far as I can tell — missing, and which 
seems likely to involve reverse engineering.


In general it seems unfortunate if we are deciding to implement a 
proprietary protocol rather than opting to either extend something that 
is already a standard (e.g. WebDriver) or perform standardisation work 
alongside the implementation. What alternatives have we considered here? 
Is it possible to extend existing standards with missing features? Or 
are the current tools using the protocol so valuable that we don't have 
any choice but to support them on their terms? If it's the latter, or we 
just think the Chrome protocol is so technically superior to the other 
options that we would be foolish to ignore it, can we work with Google 
to get it standardised? I think some meaningful attempt at 
standardisation should be a prerequisite to this kind of protocol 
implementation shipping in Firefox.

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

Re: Implementing a Chrome DevTools Protocol server in Firefox

[Ted Mielczarek]

On Wed, Aug 30, 2017, at 08:20 PM, Eric Rescorla wrote:
> I assume this is going to involve TLS (generally this is a requirement
> for
> H2). In Firefox, this is done with NSS. Does Tokio/Hyper cleanly separate
> out the TLS stack so that you can do that?

This was mostly answered in another reply, but just to be clear: yes,
Hyper allows plugging in alternate TLS stacks. This is very commonly
used with the `native-tls` crate[1] by way of `hyper-tls`[2], which uses
the native TLS stack on Windows/macOS, and OpenSSL on Linux.

1. https://github.com/sfackler/rust-native-tls
2. https://github.com/hyperium/hyper-tls
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: ./mach try fuzzy: A Try Syntax Alternative

[Andrew Halberstadt]

+to...@lists.mozilla.org

There have been a bunch of new features added here I'd like to highlight:

   - --artifact/--no-artifact: This works similarly to try syntax. If a
   local build with artifact builds is detected, --artifact will be used
   automatically. Unlike try syntax, this will change your treeherder symbols
   to 'Ba' to make it more obvious artifact builds are being used.
   - --env: You can now set environment variables in your tasks directly
   from the command line, e.g:
  - ./mach try fuzzy --env XPCOM_DEBUG_BREAK=stack --env
  MOZ_LOG="example_logger:3"|
   - --full: Populate the fuzzy interface with the "full" set of tasks.
   This will let you choose tasks that were previously hard to select (e.g
   nightlies, l10n, signing tasks, etc)
   - --save/--preset: Works the same as try syntax, using the --query
   argument. E.g:
  - ./mach try fuzzy --save reftest -q "!cov !pgo 'reftest !jsreftest"
  - ./mach try --preset reftest

See |mach try fuzzy --help| for more information.

At this point I consider |mach try fuzzy| to be superior to try syntax in
almost every way [1], and would encourage people to start using it by
default. To do this, create a ~/.mozbuild/machrc file (if you don't already
have one) and add:
[try]
default = fuzzy

Now when you run |mach try| it will default to the fuzzy interface instead
of try syntax. If you need to use try syntax for some reason, you can still
run |mach try syntax -b do ... |. By the end of Q3 I plan on writing up an
outline to deprecate try syntax (it'll likely never be removed completely)
in favour of 'try_task_config.json' mechanisms. Nothing major will change
anytime soon, but it's worth being aware that there are now better methods
for scheduling tasks and finding people willing to maintain try syntax is
going to be even harder than it was before.

-Andrew

[1] Try syntax still has a few benefits over fuzzy. You can specify paths,
use --rebuild and it will detect compiled tests and error out if you try to
use artifact builds. There are bugs on file to reach parity here.

On Wed, Aug 2, 2017 at 10:30 AM Andrew Halberstadt 
wrote:

> I'm pleased to announce an alternative method for scheduling tasks on try
> is now landed on mozilla-central. It makes use of the awesome fzf [1]
> project to filter down the list of all task labels with a fuzzy matching
> algorithm.
>
> It works both with mercurial or git. If using mercurial, you'll need to
> make sure you're updated to the latest version-control-tools:
>
> $ ./mach mercurial-setup --update
>
> To push to try, run:
>
> $ ./mach try fuzzy
>
> This will prompt you to install fzf. After bootstrapping is complete,
> it'll generate the task list. This takes around ~10-20 seconds, but will be
> cached so subsequent invocations won't incur this penalty again.
>
> Now you'll be in the fzf interface. Basic usage is to start typing to
> filter down the task list. You can use the arrow keys to move the cursor up
> or down,  to select a task,  to select all tasks and 
> to schedule the current selection (and their dependencies) on try.
>
> There are a ton more keyboard shortcuts and features you can use to tweak
> fzf just to your liking. For extra help, see:
>
> $ ./mach try fuzzy --help
> or
> $ man fzf
>
> For a demo and more information on implementation details, see:
> https://ahal.ca/blog/2017/mach-try-fuzzy/
>
> I expect this to work on all platforms including Windows for both
> mercurial (with push-to-try) and git (with git-cinnabar). But it's a new
> tool without a lot of real world testing, so a few bumps are likely. If you
> find any bugs or bad UX, please file a bug under Testing :: General and let
> me know (we should find a better component for this).
>
> Cheers,
> Andrew
>
> p.s When running the fzf bootstrap, you'll be prompted to install some
> shell extensions. These aren't necessary for |mach try fuzzy| to work so
> feel free to hit 'N' at each prompt. That being said, the fzf shell
> extensions are awesome. I highly encourage you to look into setting it up
> for your shell. The fzf vim plugin is also great. See the project [1] for
> more details.
>
> [1] https://github.com/junegunn/fzf
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New minimum Rust version policy for Firefox

[Kartikaya Gupta]

Do we have a policy on CI coverage for vendored rust libraries? I'm
concerned for example that we depend on a number of third-party rust
libraries that don't do CI builds against rust stable and so it's
possible they might break. I discovered that webrender CI for example
is currently only building against 1.17.0 and nightly. I don't think
we've actually encountered breakage from this but just wondering.

in third_party/rust$ find . -name ".travis.yml" | xargs grep -l
"rust:" | xargs grep -L -- "stable"
./cfg-if/.travis.yml
./dtoa/.travis.yml
./itoa/.travis.yml
./mime/.travis.yml
./num/.travis.yml
./ordered-float/.travis.yml
./semver-0.1.20/.travis.yml
./synstructure/.travis.yml
./thread-id/.travis.yml
./unicode-width/.travis.yml
./unicode-xid/.travis.yml
./uuid/.travis.yml

Cheers,
kats

On Tue, Aug 1, 2017 at 2:58 PM, Bobby Holley  wrote:
> This is great - thanks Ralph!
>
> On Tue, Aug 1, 2017 at 11:53 AM, Ralph Giles  wrote:
>
>> We've formalized a new plan for when we update the minimum-required Rust
>> version for building Firefox. Starting later this week we'll require the
>> latest stable Rust two weeks after it is released.
>>
>> This means we'll start requiring Rust 1.19.0 August 3rd. If you compile
>> mozilla-central and haven't run './mach bootstrap' recently, I suggest
>> doing so now to update.
>>
>> I've posted a full schedule
>> 
>> of when the minimum version will change for m-c, and what version of Rust
>> will be required to build each Firefox release. These are expectations to
>> aid in planning; we may delay particular bumps if there are issues or a
>> code freeze, but the expectation is that we'll need to update our
>> development environments by those dates.
>>
>> We expect ESR releases will stay on the Rust version of the corresponding
>> stable release.
>>
>> This change is based on several meetings and discussions with contributors
>> over the last two months. Rust is evolving quickly, and those working on
>> Rust code need to know what release to target. Previously we updated the
>> target version every few releases, whenever someone argued there was a
>> sufficiently compelling feature. Negotiating that every time was
>> distracting. Having a planned schedule lets everyone coordinate their work.
>> Updating Rust regularly helps us iterate and improve the language,
>> participating in the incredible momentum of the Rust developer community.
>>
>> Waiting two weeks gives contributors some time to update their
>> environments. This is especially relevant to those who don't always have a
>> fast network connection, or work on tier-3 targets where using upstream
>> Rust packages isn't possible.
>>
>> This doesn't affect our policy for official Firefox builds, just developer
>> builds and downstream packagers. I've written up details of the policy
>> , along with
>> motivation and considered alternatives. Please read that before responding
>> if you have concerns. I'll update the page next week in response to any
>> persuasive arguments and move the minimum-version proposal to the current
>> policy section.
>>
>> Thanks for you time, and let me know if you have any questions.
>>
>> Ralph Giles
>>
>> ___
>> dev-builds mailing list
>> dev-bui...@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-builds
>>
>>
> ___
> 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 minimum Rust version policy for Firefox

[Jack Moffitt]

Specifically for webrender (and anything else under the servo org on
GitHub), you can just file a bug and assign to edunham and we'll fix
that up.

jack.

On Thu, Aug 31, 2017 at 10:25 AM, Kartikaya Gupta  wrote:
> Do we have a policy on CI coverage for vendored rust libraries? I'm
> concerned for example that we depend on a number of third-party rust
> libraries that don't do CI builds against rust stable and so it's
> possible they might break. I discovered that webrender CI for example
> is currently only building against 1.17.0 and nightly. I don't think
> we've actually encountered breakage from this but just wondering.
>
> in third_party/rust$ find . -name ".travis.yml" | xargs grep -l
> "rust:" | xargs grep -L -- "stable"
> ./cfg-if/.travis.yml
> ./dtoa/.travis.yml
> ./itoa/.travis.yml
> ./mime/.travis.yml
> ./num/.travis.yml
> ./ordered-float/.travis.yml
> ./semver-0.1.20/.travis.yml
> ./synstructure/.travis.yml
> ./thread-id/.travis.yml
> ./unicode-width/.travis.yml
> ./unicode-xid/.travis.yml
> ./uuid/.travis.yml
>
> Cheers,
> kats
>
> On Tue, Aug 1, 2017 at 2:58 PM, Bobby Holley  wrote:
>> This is great - thanks Ralph!
>>
>> On Tue, Aug 1, 2017 at 11:53 AM, Ralph Giles  wrote:
>>
>>> We've formalized a new plan for when we update the minimum-required Rust
>>> version for building Firefox. Starting later this week we'll require the
>>> latest stable Rust two weeks after it is released.
>>>
>>> This means we'll start requiring Rust 1.19.0 August 3rd. If you compile
>>> mozilla-central and haven't run './mach bootstrap' recently, I suggest
>>> doing so now to update.
>>>
>>> I've posted a full schedule
>>> 
>>> of when the minimum version will change for m-c, and what version of Rust
>>> will be required to build each Firefox release. These are expectations to
>>> aid in planning; we may delay particular bumps if there are issues or a
>>> code freeze, but the expectation is that we'll need to update our
>>> development environments by those dates.
>>>
>>> We expect ESR releases will stay on the Rust version of the corresponding
>>> stable release.
>>>
>>> This change is based on several meetings and discussions with contributors
>>> over the last two months. Rust is evolving quickly, and those working on
>>> Rust code need to know what release to target. Previously we updated the
>>> target version every few releases, whenever someone argued there was a
>>> sufficiently compelling feature. Negotiating that every time was
>>> distracting. Having a planned schedule lets everyone coordinate their work.
>>> Updating Rust regularly helps us iterate and improve the language,
>>> participating in the incredible momentum of the Rust developer community.
>>>
>>> Waiting two weeks gives contributors some time to update their
>>> environments. This is especially relevant to those who don't always have a
>>> fast network connection, or work on tier-3 targets where using upstream
>>> Rust packages isn't possible.
>>>
>>> This doesn't affect our policy for official Firefox builds, just developer
>>> builds and downstream packagers. I've written up details of the policy
>>> , along with
>>> motivation and considered alternatives. Please read that before responding
>>> if you have concerns. I'll update the page next week in response to any
>>> persuasive arguments and move the minimum-version proposal to the current
>>> policy section.
>>>
>>> Thanks for you time, and let me know if you have any questions.
>>>
>>> Ralph Giles
>>>
>>> ___
>>> dev-builds mailing list
>>> dev-bui...@lists.mozilla.org
>>> https://lists.mozilla.org/listinfo/dev-builds
>>>
>>>
>> ___
>> 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

Firefox Nightly - now with twice as many builds a day!

[Chris AtLee]

Bug 1349227[1] landed a few days ago, which means we are now doing
"nightly" builds twice a day at 1000 and 2200 UTC.

The purpose of doing multiple nightlies is to get fixes out to users in
Europe, Africa and Asia sooner.

We have some concerns about possible impact to the build infrastructure, so
for now we're keeping an eye on load. We may need to revert if this causes
too much backlog.

In the meanwhile, enjoy a more up-to-date Nightly more often!

Please comment on the bug if there are other issues with doing multiple
nightlies a day.

Cheers,
Chris


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

Re: Coding style: Argument alignment

[Ehsan Akhgari]

On 08/30/2017 09:03 PM, Eric Rahm wrote:

Okay sounds like there's agreement on a).


Indeed.  I have edited the Style Guide to reflect this.


Thanks everyone!
-e

On Tue, Aug 29, 2017 at 11:40 PM, Martin Thomson > wrote:


On Wed, Aug 30, 2017 at 12:07 PM, L. David Baron
mailto:dba...@dbaron.org>> wrote:
> I think I do this because (b) has the disadvantage that more code
> changes require touching additional lines, which is both changes
> blame and is extra work (although it's not extra work if we're using
> clang-format tree-wide).  Option (b) is also more likely to lead to
> overly long lines that require wrapping.

NSS had a lot of option (b) and we agreed that it was bad for these
reasons.  You also have to agree not to do this, another thing that
NSS was infested with:

  nsresult ShortFunction(witharg, and another);
  void   Function2  (HasOnlyOne* arg);

Does clang-format even *do* this? AlignConsecutiveDeclarations is the
closest I could find to a directive that would do this sort of crazy
alignment, but that seems more likely to govern my example than
argument lists.  For the record, we should not enable that either.




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

Re: Stylesheet wait timeout?

[Gervase Markham]

On 18/08/17 12:11, Gervase Markham wrote:


Whereas what I meant to say was:

Have we changed the timeout recently regarding how long Firefox waits
for a stylesheet before rendering the page? In the past few weeks I've
seen many more instances of a page loading unstyled, then re-laying out
a second later with style. It happens for me quite a bit on xkcd.com,
but there are other pages too.

I think we may have set the timeout a bit low, because the result is ugly.

I'm using Nightly 57.0a1 (2017-08-30) (64-bit) on Ubuntu 16.04 LTS.

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

Re: Stylesheet wait timeout?

[Chris Peterson]

Gerv, do you have Stylo enabled? Even if you did not flip the pref 
(layout.css.servo.enabled), you might be in the Stylo experiment for 
Nightly users. Check about:support for "Stylo".




On 2017-08-31 10:24 AM, Gervase Markham wrote:

On 18/08/17 12:11, Gervase Markham wrote:


Whereas what I meant to say was:

Have we changed the timeout recently regarding how long Firefox waits
for a stylesheet before rendering the page? In the past few weeks I've
seen many more instances of a page loading unstyled, then re-laying out
a second later with style. It happens for me quite a bit on xkcd.com,
but there are other pages too.

I think we may have set the timeout a bit low, because the result is ugly.

I'm using Nightly 57.0a1 (2017-08-30) (64-bit) on Ubuntu 16.04 LTS.

Gerv



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

Re: Stylesheet wait timeout?

[Dustin Mitchell]

I've been seeing this, too, often on github pages.  I do not have
stylo enabled per about:support ("false (disabled by default)").

Dustin

2017-08-31 13:45 GMT-04:00 Chris Peterson :
> Gerv, do you have Stylo enabled? Even if you did not flip the pref
> (layout.css.servo.enabled), you might be in the Stylo experiment for Nightly
> users. Check about:support for "Stylo".
>
>
>
>
> On 2017-08-31 10:24 AM, Gervase Markham wrote:
>>
>> On 18/08/17 12:11, Gervase Markham wrote:
>> 
>>
>> Whereas what I meant to say was:
>>
>> Have we changed the timeout recently regarding how long Firefox waits
>> for a stylesheet before rendering the page? In the past few weeks I've
>> seen many more instances of a page loading unstyled, then re-laying out
>> a second later with style. It happens for me quite a bit on xkcd.com,
>> but there are other pages too.
>>
>> I think we may have set the timeout a bit low, because the result is ugly.
>>
>> I'm using Nightly 57.0a1 (2017-08-30) (64-bit) on Ubuntu 16.04 LTS.
>>
>> 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

Re: Stylesheet wait timeout?

[Chris Peterson]

Maybe this is stylesheet delay is related to Context Driven Priority 
(CDP) project that changes how network requests are prioritized?


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


On 2017-08-31 10:46 AM, Dustin Mitchell wrote:

I've been seeing this, too, often on github pages.  I do not have
stylo enabled per about:support ("false (disabled by default)").

Dustin

2017-08-31 13:45 GMT-04:00 Chris Peterson :

Gerv, do you have Stylo enabled? Even if you did not flip the pref
(layout.css.servo.enabled), you might be in the Stylo experiment for Nightly
users. Check about:support for "Stylo".




On 2017-08-31 10:24 AM, Gervase Markham wrote:


On 18/08/17 12:11, Gervase Markham wrote:


Whereas what I meant to say was:

Have we changed the timeout recently regarding how long Firefox waits
for a stylesheet before rendering the page? In the past few weeks I've
seen many more instances of a page loading unstyled, then re-laying out
a second later with style. It happens for me quite a bit on xkcd.com,
but there are other pages too.

I think we may have set the timeout a bit low, because the result is ugly.

I'm using Nightly 57.0a1 (2017-08-30) (64-bit) on Ubuntu 16.04 LTS.

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

Re: Stylesheet wait timeout?

[Boris Zbarsky]

On 8/31/17 1:24 PM, Gervase Markham wrote:

Have we changed the timeout recently regarding how long Firefox waits
for a stylesheet before rendering the page?


We do not have such a timeout at all.  Our wait is fairly deterministic. 
 We start layout as soon as:


A) Script requests layout information

or

B) We have seen  and all stylesheets whose loads started due to 
the parser inserting  elements are done loading.  (Note that this 
means we always wait for the  elements in , and may wait for 
the ones in , depending on whether we manage to start their loads 
before the ones from  finish loading.)


The symptoms you observe sound like (A) is happening, possible from an 
extension or our browser UI...  If you have a link to a specific url 
that reproduces for you, especially in a clean profile, that would be 
pretty useful.  This is usually pretty simple to debug when (A) happens: 
set a breakpoint on when we start layout and see what the JS stack is. 
The hard part is catching it happening.


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

Re: Stylesheet wait timeout?

[Simon Sapin]

On 31/08/2017 19:45, Chris Peterson wrote:

Gerv, do you have Stylo enabled? Even if you did not flip the pref
(layout.css.servo.enabled), you might be in the Stylo experiment for
Nightly users. Check about:support for "Stylo".


I’ve also seen many more "flashes of unstyled content" than usual lately 
on Nigthly. I’ve reproduced it both with and without Stylo.


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

Incoming JS module (JSM) / component loader changes

[Kris Maglione]

A quick heads-up on some incoming changes to the JS component loader 
that may affect some existing JSM or JS component code:


1) As of bug 1394556[1], all JS module and component scripts are 
automatically compiled in strict mode[2]. While I fixed all of the 
resulting issues that showed up in automated tests, new issues may turn 
up in code with incomplete test coverage. Please be on the lookout for 
errors like "TypeError: this is null", "TypeError: setting a property 
that has only a getter", and "ReferenceError: assignment to undeclared 
variable", and if you see any, file bugs blocking bug 1394556.


2) Andrew McCreight has been working on changing the component loader to 
load most modules and components into a single global[3], with each 
module still getting its own top-level variable scope (similar to a 
with() block). Most of the blockers for this have been resolved, and it 
should hopefully be ready to land within the next week.


This change will significantly reduce the memory overhead of JS modules, 
along with the performance overhead of creating dozens module globals at 
startup, and of creating thousands of cross-compartment object wrappers 
at runtime. 

But it does so at the cost of decreased isolation among module scripts. 
All (non-add-on) modules will now share prototypes for built-in objects. 
It will be possible to define objects on the shared global that affect 
all modules. getGlobalForObject will no longer return the root scope for 
a module. In short, it's possible we will see subtle issues as a 
result of this change (as we often saw on b2g, which its module loader 
differed from the desktop module loader), so please be on the look-out 
over the next few weeks.


Thanks.

-Kris

[1]: https://bugzil.la/1394556
[2]: 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode
[3]: https://bugzil.la/1186409
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implementing a Chrome DevTools Protocol server in Firefox

[Jim Blandy]

Definitely, yes. As Michael said, some core subset of the protocol is
already a de-facto standard. The process of actual specification, with
committees and processes and imprimaturs and all that, is getting started,
with interest from several major players, including Microsoft and Google.

On Wed, Aug 30, 2017 at 3:56 PM, David Burns  wrote:

> Do we know if the other vendors would see value in having this spec'ed
> properly so that we have true interop here? Reverse engineering  seems like
> a "fun" project but what stops people from breaking stuff without
> realising?
>
> David
>
> On 30 August 2017 at 22:55, Michael Smith  wrote:
>
> > Hi everyone,
> >
> > Mozilla DevTools is exploring implementing parts of the Chrome DevTools
> > Protocol ("CDP") [0] in Firefox. This is an HTTP, WebSockets, and JSON
> > based protocol for automating and inspecting running browser pages.
> >
> > Originally built for the Chrome DevTools, it has seen wider adoption with
> > outside developers. In addition to Chrome/Chromium, the CDP is supported
> by
> > WebKit, Safari, Node.js, and soon Edge, and an ecosystem of libraries and
> > tools already exists which plug into it, for debugging, extracting
> > performance data, providing live-preview functionality like the Brackets
> > editor, and so on. We believe it would be beneficial if these could be
> > leveraged with Firefox as well.
> >
> > The initial implementation we have in mind is an alternate target for
> > third-party integrations to connect to, in addition to the existing
> Firefox
> > DevTools Server. The Servo project has also expressed interest in adding
> > CDP support to improve its own devtools story, and a PR is in flight to
> > land a CDP server implementation there [1].
> >
> > I've been working on this project with guidance from Jim Blandy. We've
> > come up with the following approach:
> >
> > - A complete, typed Rust implementation of the CDP protocol messages and
> > (de)serialization lives in the "cdp" crate [2], automatically generated
> > from the protocol's JSON specification [3] using a build script (this
> > happens transparently as part of the normal Cargo compilation process).
> > This comes with Rustdoc API documentation of all messages/types in the
> > protocol [4] including textual descriptions bundled with the
> specification
> > JSON. The cdp crate will likely track the Chrome stable release for which
> > version of the protocol is supported. A maintainers' script exists which
> > can find and fetch the appropriate JSON [5].
> >
> > - The "tokio-cdp" crate [6] builds on the types and (de)serialization
> > implementation in the cdp crate to provide a server implementation built
> on
> > the Tokio asynchronous I/O system. The server side provides traits for
> > consuming incoming CDP RPC commands, executing them concurrently and
> > sending back responses, and simultaneously pushing events to the client.
> > They are generic over the underlying transport, so the same backend
> > implementation could provide support for "remote" clients plugging in
> over
> > HTTP/WebSockets/JSON or, for example, a browser-local client
> communicating
> > over IPDL.
> >
> > - In Servo, a new component plugs into the cdp and tokio-cdp crates and
> > acts on behalf of connected CDP clients in response to their commands,
> > communicating with the rest of the Servo constellation. This server is
> > disabled by default and can be started by passing a "--cdp" flag to the
> > Servo binary, binding a TCP listener to the loopback interface at the
> > standard CDP port 9222 (a different port can be specified as an option to
> > the flag).
> >
> > - The implementation we envision in Firefox/Gecko would act similarly: a
> > new Rust component, disabled by default and switched on via a command
> line
> > flag, which binds to a local port and mediates between Gecko internals
> and
> > clients connected via tokio-cdp.
> >
> > We chose to build this on Rust and the Tokio event loop, along with the
> > hyper HTTP library and rust-websocket which plug into Tokio.
> >
> > Rust and Cargo provide excellent facilities for compile-time code
> > generation which integrate transparently into the normal build process,
> > avoiding the need to invoke scripts by hand to keep generated artifacts
> in
> > sync. The Rust ecosystem provides libraries such as quote [7] and serde
> [8]
> > which allow us to auto-generate an efficient, typed, and self-contained
> > interface for the entire protocol. This moves the complexity of
> ingesting,
> > validating, and extracting information from client messages out of the
> > Servo- and Gecko-specific backend implementations, helps to ensure they
> > conform correctly to the protocol specification, and provides a
> structured
> > way of upgrading to new protocol versions.
> >
> > As for Tokio, the event loop and Futures-based model of concurrency it
> > offers maps well to the Chrome DevTools Protocol. RPC commands typically
> > execute simultaneously

Re: Stylesheet wait timeout?

[Honza Bambas]

On 8/31/17 8:00 PM, Chris Peterson wrote:
Maybe this is stylesheet delay is related to Context Driven Priority 
(CDP) project that changes how network requests are prioritized?


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


CSS preload requests (made by html parser when  is hit) are left 
as top priority loads, none of the bugs we have landed for CDP has 
changed this.

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

Re: Incoming JS module (JSM) / component loader changes

[Kris Maglione]

To clarify, this is about XPConnect JS modules (loaded by Cu.import[1]) and
components, not ES6 modules[2], which already work this way.

[1]: 
https://developer.mozilla.org/en-US/docs/Mozilla/JavaScript_code_modules/Using
[2]: https://hacks.mozilla.org/2015/08/es6-in-depth-modules/

On Thu, Aug 31, 2017 at 11:14:34AM -0700, Kris Maglione wrote:
A quick heads-up on some incoming changes to the JS component loader 
that may affect some existing JSM or JS component code:


1) As of bug 1394556[1], all JS module and component scripts are 
automatically compiled in strict mode[2]. While I fixed all of the 
resulting issues that showed up in automated tests, new issues may 
turn up in code with incomplete test coverage. Please be on the 
lookout for errors like "TypeError: this is null", "TypeError: setting 
a property that has only a getter", and "ReferenceError: assignment to 
undeclared variable", and if you see any, file bugs blocking bug 
1394556.


2) Andrew McCreight has been working on changing the component loader 
to load most modules and components into a single global[3], with each 
module still getting its own top-level variable scope (similar to a 
with() block). Most of the blockers for this have been resolved, and 
it should hopefully be ready to land within the next week.


This change will significantly reduce the memory overhead of JS 
modules, along with the performance overhead of creating dozens module 
globals at startup, and of creating thousands of cross-compartment 
object wrappers at runtime.


But it does so at the cost of decreased isolation among module 
scripts. All (non-add-on) modules will now share prototypes for 
built-in objects. It will be possible to define objects on the shared 
global that affect all modules. getGlobalForObject will no longer 
return the root scope for a module. In short, it's possible we will 
see subtle issues as a result of this change (as we often saw on b2g, 
which its module loader differed from the desktop module loader), so 
please be on the look-out over the next few weeks.


Thanks.

-Kris

[1]: https://bugzil.la/1394556
[2]: 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode
[3]: https://bugzil.la/1186409


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

For every prohibition you create you also create an underground.
--Jello Biafra

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

Re: Implementing a Chrome DevTools Protocol server in Firefox

[Jim Blandy]

Some possibly missing context: Mozilla Devtools wants to see this
implemented for our own use. After much discussion last summer in London,
the Firefox Devtools team decided to adopt the Chrome Debugging Protocol
for the console and the JavaScript debugger. (The cases for converting the
other tools like the Inspector are less compelling.)

Speaking as the designer of Firefox's protocol, the CDP is a de-facto
standard. The Firefox protocol really has not seen much uptake outside
Mozilla, whereas the Chrome Debugging Protocol is implemented with varying
degrees of fidelity by several different browsers. "Proprietary" is not the
right term here, but in the sense of "used nowhere else", one could argue
that it is Mozilla that is using the proprietary protocol, not Chrome. In a
real sense, it is more consistent with Mozilla's mission for us to join the
rest of the community, implement the CDP for the tools where it makes
sense, and participate in its standardization, than to continue to push a
protocol nobody else uses.

The devtools.html JavaScript debugger already implements the Chrome
protocol. We've implemented adapters like Valence that implement the
Firefox protocol in terms of the Chrome protocol. So while it's true that
not everything is documented at the standards of a WHATWG specification
(yet), in practical terms, there hasn't been much problem getting things
going.


On Thu, Aug 31, 2017 at 2:50 AM, James Graham 
wrote:

> On 31/08/17 02:14, Michael Smith wrote:
>
>> On 8/30/2017 15:56, David Burns wrote:
>>  > Do we know if the other vendors would see value in having this spec'ed
>> properly so that we have true interop here? Reverse engineering seems like
>> a "fun" project but what stops people from breaking stuff without realising?
>>
>> Fortunately we're not reverse engineering here (for the most part), all
>> protocol messages are specified in a machine-readable JSON format which
>> includes inline documentation [0] --- this is what the cdp Rust library
>> consumes. The spec is versioned and the authors do seem to follow a proper
>> process of introducing new features as "experimental", stabilizing mature
>> ones, and deprecating things before they're removed.
>>
>
> I think that the reverse engineering part is not the wire protocol, which
> is usually the most trivial part, but the associated semantics. It doesn't
> seem that useful to support the protocol unless we behave in the same way
> as Chrome in response to the messages. It's the specification of that
> behaviour which is — as far as I can tell — missing, and which seems likely
> to involve reverse engineering.
>
> In general it seems unfortunate if we are deciding to implement a
> proprietary protocol rather than opting to either extend something that is
> already a standard (e.g. WebDriver) or perform standardisation work
> alongside the implementation. What alternatives have we considered here? Is
> it possible to extend existing standards with missing features? Or are the
> current tools using the protocol so valuable that we don't have any choice
> but to support them on their terms? If it's the latter, or we just think
> the Chrome protocol is so technically superior to the other options that we
> would be foolish to ignore it, can we work with Google to get it
> standardised? I think some meaningful attempt at standardisation should be
> a prerequisite to this kind of protocol implementation shipping in Firefox.
>
> ___
> 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: Implementing a Chrome DevTools Protocol server in Firefox

[Josh Matthews]

On 8/30/17 6:14 PM, Michael Smith wrote:

On 8/30/2017 18:04, Josh Matthews wrote:
 > One clarification - while all of the Servo codebase exists in 
mozilla-central/servo/, only the dependencies used by Stylo are vendored 
in third-party/rust. That means that neither hyper nor tokio are 
vendored in mozilla-central at the moment, or part of any 
mozilla-central build.


Isn't it vendored into third_party/rust/hyper [4] on mozilla-central?


Ah, it turns out that it's brought in by the geckodriver crate rather 
than Servo.


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

Re: Stylesheet wait timeout?

[Michael Froman]

> On Aug 31, 2017, at 1:08 PM, Boris Zbarsky  wrote:
> 
> The symptoms you observe sound like (A) is happening, possible from an 
> extension or our browser UI...  If you have a link to a specific url that 
> reproduces for you, especially in a clean profile, that would be pretty 
> useful.  This is usually pretty simple to debug when (A) happens: set a 
> breakpoint on when we start layout and see what the JS stack is. The hard 
> part is catching it happening.
I’ve seen this behavior too on OSX.  I did a restart with all add-ons disabled 
and could not reproduce.  Restarted with all add-ons on, and can reproduce.  I 
narrowed it down to Ghostery.  If I disable Ghostery, it no long appears to 
happen for me.  YMMV.

-Michael.

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

Re: Stylesheet wait timeout?

[Dustin Mitchell]

I've seen it a few times now since this thread began.  I had Ghostery
installed but removed it a few days ago.  I only have whimsy
(disabled) and test pilot installed.

Dustin


2017-08-31 15:00 GMT-04:00 Michael Froman :
>
>> On Aug 31, 2017, at 1:08 PM, Boris Zbarsky  wrote:
>>
>> The symptoms you observe sound like (A) is happening, possible from an 
>> extension or our browser UI...  If you have a link to a specific url that 
>> reproduces for you, especially in a clean profile, that would be pretty 
>> useful.  This is usually pretty simple to debug when (A) happens: set a 
>> breakpoint on when we start layout and see what the JS stack is. The hard 
>> part is catching it happening.
> I’ve seen this behavior too on OSX.  I did a restart with all add-ons 
> disabled and could not reproduce.  Restarted with all add-ons on, and can 
> reproduce.  I narrowed it down to Ghostery.  If I disable Ghostery, it no 
> long appears to happen for me.  YMMV.
>
> -Michael.
>
> ___
> 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: Stylesheet wait timeout?

[Kris Maglione]

On Thu, Aug 31, 2017 at 02:00:49PM -0500, Michael Froman wrote:
I’ve seen this behavior too on OSX.  I did a restart with all 
add-ons disabled and could not reproduce.  Restarted with all 
add-ons on, and can reproduce.  I narrowed it down to Ghostery.  
If I disable Ghostery, it no long appears to happen for me.  
YMMV.


From a quick look at Ghostery, it apparently injects UI elements 
into content pages to notify you of things it's blocked, and to 
do that, it queries the page layout state (several times).

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

Re: Stylesheet wait timeout?

[Jet Villegas]

FWIW, reverting the fix for bug 1283302 (fixed in FF53) fixes this issue.
Before that fix, we would wait up to 250ms before painting, now we wait for
5ms. You may be running into the intersection of that change, plus several
performance fixes that make us paint much faster in FF57. When we fixed
1283302, it was after a lengthy user study that indicated a higher
perceived performance score when we paint sooner. We knew that FOUC (flash
of unstyled content) could happen more often, but perhaps it's happening
more often now that we paint faster.

--Jet

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

On Thu, Aug 31, 2017 at 10:24 AM, Gervase Markham  wrote:

> On 18/08/17 12:11, Gervase Markham wrote:
> 
>
> Whereas what I meant to say was:
>
> Have we changed the timeout recently regarding how long Firefox waits
> for a stylesheet before rendering the page? In the past few weeks I've
> seen many more instances of a page loading unstyled, then re-laying out
> a second later with style. It happens for me quite a bit on xkcd.com,
> but there are other pages too.
>
> I think we may have set the timeout a bit low, because the result is ugly.
>
> I'm using Nightly 57.0a1 (2017-08-30) (64-bit) on Ubuntu 16.04 LTS.
>
> 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

Re: Implementing a Chrome DevTools Protocol server in Firefox

[Jim Blandy]

On Thu, Aug 31, 2017 at 2:50 AM, James Graham 
wrote:

> In general it seems unfortunate if we are deciding to implement a
> proprietary protocol rather than opting to either extend something that is
> already a standard (e.g. WebDriver) or perform standardisation work
> alongside the implementation.


That would be unfortunate, I agree. I hope that's not what's happening
here. By adopting the CDP console and JS debugger protocols I think we are
doing exactly what Mozilla should do: encouraging the adoption and
formalization of de-facto standards.

What alternatives have we considered here?


The Devtools team had extensive discussions a year ago in London about
whether to continue to develop Firefox's own protocols, or whether to go
with what Chrome, Safari, and now Edge are using. We considered the
question on a tool-by-tool basis. Harald Kirschner has started to assemble
a list of the third-party tools that use the CDP.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Stylesheet wait timeout?

[Boris Zbarsky]

On 8/31/17 3:27 PM, Jet Villegas wrote:

FWIW, reverting the fix for bug 1283302 (fixed in FF53) fixes this issue.
Before that fix, we would wait up to 250ms before painting


To be clear, this is 250ms _after_ the layout-starting I described in my 
previous post.


The general point remains: if you're getting FOUC then either someone 
put s outside  or there's script querying layout.  And to 
the extent that said script is an add-on or our UI, that needs to be fixed.


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

Re: Implementing a Chrome DevTools Protocol server in Firefox

[James Graham]

On 31/08/17 19:42, Jim Blandy wrote:
Some possibly missing context: Mozilla Devtools wants to see this 
implemented for our own use. After much discussion last summer in 
London, the Firefox Devtools team decided to adopt the Chrome Debugging 
Protocol for the console and the JavaScript debugger. (The cases for 
converting the other tools like the Inspector are less compelling.)


Speaking as the designer of Firefox's protocol, the CDP is a de-facto 
standard. The Firefox protocol really has not seen much uptake outside 
Mozilla, whereas the Chrome Debugging Protocol is implemented with 
varying degrees of fidelity by several different browsers. "Proprietary" 
is not the right term here, but in the sense of "used nowhere else", one 
could argue that it is Mozilla that is using the proprietary protocol, 
not Chrome. In a real sense, it is more consistent with Mozilla's 
mission for us to join the rest of the community, implement the CDP for 
the tools where it makes sense, and participate in its standardization, 
than to continue to push a protocol nobody else uses.


I entirely agree that the current Firefox protocol is also proprietary. 
However I also assumed that it's considered an internal implementation 
detail rather than something we would expect people to interoperate 
with. If that wasn't the case then I apologise: I should have complained 
earlier :)


Going forward, if we implement a "de-facto" standard that is not 
actually standardised, we are assuming a large risk, in addition to the 
problems around our stated values. An obvious concern is that Google are 
free to change the protocol as they like, including in ways that are 
intentionally or accidentally incompatible with other implementations. 
We also know from past experience of implementing "de-facto" standards 
that implementation differences end up hardcoded into third party 
consumers (i.e. web pages in the case of DOM APIs), making it impossible 
to get interoperability without causing intolerable short-term breakage. 
This has prevented standardisation and compatibility of "de-facto" 
standards like innerText and contentEditable, which remain nominally 
equivalent but actually very different in all browsers.


If people are starting to standardise not just the protocol but also the 
semantics of CDP, that's great. But people tend to vastly underestimate 
how long standardisation will take, and overestimate the resources that 
they will find to work on it. So it would be good to see concrete 
progress before we are actually shipping.

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

Re: Implementing a Chrome DevTools Protocol server in Firefox

[Harald Kirschner]

On Thursday, August 31, 2017 at 2:51:41 AM UTC-7, James Graham wrote:
> On 31/08/17 02:14, Michael Smith wrote:
> > On 8/30/2017 15:56, David Burns wrote:
> >  > Do we know if the other vendors would see value in having this 
> > spec'ed properly so that we have true interop here? Reverse engineering 
> > seems like a "fun" project but what stops people from breaking stuff 
> > without realising?
> > 
> In general it seems unfortunate if we are deciding to implement a 
> proprietary protocol rather than opting to either extend something that 
> is already a standard (e.g. WebDriver) or perform standardisation work 
> alongside the implementation. What alternatives have we considered here? 
> Is it possible to extend existing standards with missing features? Or 
> are the current tools using the protocol so valuable that we don't have 
> any choice but to support them on their terms? If it's the latter, or we 
> just think the Chrome protocol is so technically superior to the other 
> options that we would be foolish to ignore it, can we work with Google 
> to get it standardised? I think some meaningful attempt at 
> standardisation should be a prerequisite to this kind of protocol 
> implementation shipping in Firefox.

For more history on executing on a de-facto standard; remotedebug.org was 
started as an effort to spec the protocol by representatives from Edge, Chrome 
and Firefox. Chrome committed to keeping the stable parts of the API stable, 
which so far worked. For comparison, WebDriver has gone a similar route, 
experimenting in the open while standardized the stable parts of the API.

To the idea of having one tool like Web Driver solving all remote debug needs: 
Having WebDriver focussed on Automation and not on matching CDP's more advanced 
use cases avoid reinventing the wheel.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implementing a Chrome DevTools Protocol server in Firefox

[Jim Blandy]

Google has indicated a willingness to participate in standardizing the
protocol.

If we switch from a devtools protocol used only by us to a tooling protocol
used by the rest of the industry, that is strictly an improvement over the
status quo, even if our implementation deviates from the others' to some
degree: developers whose tooling doesn't run into the points of
incompatibility can now include Firefox in their scripting and tests, and
the maintainers of tooling that use the CDP can work around
incompatibilities.

I think it's a mistake to analogize this too closely to content-exposed
APIs. Those are under extreme backwards compatibility pressure, of a sort
that I think doesn't hold here. Unlike a web user, who simply sees a broken
page and can't do anything about it, our audience is more technical, and
can do things like upgrade tools when things don't work.


On Thu, Aug 31, 2017 at 1:09 PM, James Graham 
wrote:

> On 31/08/17 19:42, Jim Blandy wrote:
>
>> Some possibly missing context: Mozilla Devtools wants to see this
>> implemented for our own use. After much discussion last summer in London,
>> the Firefox Devtools team decided to adopt the Chrome Debugging Protocol
>> for the console and the JavaScript debugger. (The cases for converting the
>> other tools like the Inspector are less compelling.)
>>
>> Speaking as the designer of Firefox's protocol, the CDP is a de-facto
>> standard. The Firefox protocol really has not seen much uptake outside
>> Mozilla, whereas the Chrome Debugging Protocol is implemented with varying
>> degrees of fidelity by several different browsers. "Proprietary" is not the
>> right term here, but in the sense of "used nowhere else", one could argue
>> that it is Mozilla that is using the proprietary protocol, not Chrome. In a
>> real sense, it is more consistent with Mozilla's mission for us to join the
>> rest of the community, implement the CDP for the tools where it makes
>> sense, and participate in its standardization, than to continue to push a
>> protocol nobody else uses.
>>
>
> I entirely agree that the current Firefox protocol is also proprietary.
> However I also assumed that it's considered an internal implementation
> detail rather than something we would expect people to interoperate with.
> If that wasn't the case then I apologise: I should have complained earlier
> :)
>
> Going forward, if we implement a "de-facto" standard that is not actually
> standardised, we are assuming a large risk, in addition to the problems
> around our stated values. An obvious concern is that Google are free to
> change the protocol as they like, including in ways that are intentionally
> or accidentally incompatible with other implementations. We also know from
> past experience of implementing "de-facto" standards that implementation
> differences end up hardcoded into third party consumers (i.e. web pages in
> the case of DOM APIs), making it impossible to get interoperability without
> causing intolerable short-term breakage. This has prevented standardisation
> and compatibility of "de-facto" standards like innerText and
> contentEditable, which remain nominally equivalent but actually very
> different in all browsers.
>
> If people are starting to standardise not just the protocol but also the
> semantics of CDP, that's great. But people tend to vastly underestimate how
> long standardisation will take, and overestimate the resources that they
> will find to work on it. So it would be good to see concrete progress
> before we are actually shipping.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implementing a Chrome DevTools Protocol server in Firefox

[Jack Moffitt]

> I entirely agree that the current Firefox protocol is also proprietary.
> However I also assumed that it's considered an internal implementation
> detail rather than something we would expect people to interoperate with. If
> that wasn't the case then I apologise: I should have complained earlier :)

We would like a console and debugger for Servo, and those seemed
pretty common. We did an initial implementation of the Firefox
protocol, but hat protocol changed out from under us, and some of the
work we did broke and wasn't not easily fixable.

At the very least there is a desire to interoperate between Servo and
Firefox and the current protocol isn't very helpful for this. The
Chrome one has a huge advantage of being documented, even if not all
the semantics are. I was also under the impression that the design of
the Chrome protocol is better than the Firefox one because you can
ingest the JSON messages and only handle the things you want. It seems
like that would make it more robust to future changes.

Is there another alternative besides CDP you'd like to propose? I
think there's a strong case that doing something besides the current
Firefox protocol is a good idea, and the CDP seems to have some nice
qualities. Is there an alternative that is also suitable, or is the
preference that we simultaneously get involved in standardizing CDP
(or at least ensuring that all parties are amenable to doing that
work)?

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

Re: Implementing a Chrome DevTools Protocol server in Firefox

[Jim Blandy]

Certain bits of the original post are getting more emphasis than I had
anticipated. Let me try to clarify why we in Devtools want this change or
something like it.

The primary goals here are not related to automation and testing. They are:

   - to allow Devtools to migrate the console and the JS debugger to the
   CDP;
   - to start a tools server that can be shared between Gecko and Servo;
   - to replace Gecko's devtools server, implemented in JS, with one
   implemented in Rust, to reduce memory consumption and introduce less noise
   into performance and memory measurements



and to help us share code with Servo. Our user interfaces already work with
the CDP.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implementing a Chrome DevTools Protocol server in Firefox

[Harald Kirschner]

On Thursday, August 31, 2017 at 1:10:30 PM UTC-7, James Graham wrote:
> If people are starting to standardise not just the protocol but also the 
> semantics of CDP, that's great. But people tend to vastly underestimate 
> how long standardisation will take, and overestimate the resources that 
> they will find to work on it. So it would be good to see concrete 
> progress before we are actually shipping.

As mentioned in my last email, CDP already provides a stable core. We did 
review existing tools for API dependencies to understand what the minimum 
viable set should include to be useful for developers. We are still reaching 
out to developers and browser-testing services to capture their feedback, but 
preliminary results are captured in [1]. The list so far suggests that there is 
a shortlist of APIs solving most needs.

[1]: 
https://docs.google.com/document/d/19bimjSpwbiNOPFiEWzBsJ9PtB6cvEaBQCY1Y8UValRk/edit#
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Implementing a Chrome DevTools Protocol server in Firefox

[Jim Blandy]

Sorry for the premature send. The complete message should read:

The primary goals here are not related to automation and testing.

- We want to migrate the Devtools console and the JS debugger to the CDP,
to replace an unpopular protocol with a more widely-used one.

- Servo wants its devtools server to use an industry-standard protocol, not
Firefox's custom thing.

- We'd like to have a devtools server we can share between Gecko and Servo.

- We'd like to move devtools server code out of JS and into a language that
gives us better control over memory use and performance, because the
current server, implemented in JS, introduces a lot of noise into
measurements, affecting the quality of the performance data we're able to
collect.

- We'd like to share front ends (i.e. clients) between Firefox and Servo.
devtools.html already implements both the Firefox protocol and the CDP.

Using a protocol that's more familiar to web developers doing automation
and testing is also good, and we're hoping that will have ancillary
benefits. For example, it turns out that there is lots of interest in our
new JS debugger UI, which has hundreds of contributors now. I don't know
why people want a JS debugger UI, but they do. I believe that Firefox's use
of a bespoke protocol prevents many similar opportunities for collaboration.


On Thu, Aug 31, 2017 at 1:36 PM, Jim Blandy  wrote:

> Certain bits of the original post are getting more emphasis than I had
> anticipated. Let me try to clarify why we in Devtools want this change or
> something like it.
>
> The primary goals here are not related to automation and testing. They are:
>
>- to allow Devtools to migrate the console and the JS debugger to the
>CDP;
>- to start a tools server that can be shared between Gecko and Servo;
>- to replace Gecko's devtools server, implemented in JS, with one
>implemented in Rust, to reduce memory consumption and introduce less noise
>into performance and memory measurements
>
>
>
> and to help us share code with Servo. Our user interfaces already work
> with the CDP.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: New minimum Rust version policy for Firefox

[Mike Hommey]

On Thu, Aug 31, 2017 at 10:27:55AM -0500, Jack Moffitt wrote:
> Specifically for webrender (and anything else under the servo org on
> GitHub), you can just file a bug and assign to edunham and we'll fix
> that up.
> 
> jack.

Note that for webrender specifically, it used to build against stable,
but back then Firefox required 1.15 and a webrender change broke that.
To avoid the problem again, I added 1.15.1 to .travis.yml, but there
were concerns about the number of travis jobs that incurred, so I
removed stable at the same time
(https://github.com/servo/webrender/pull/1334). Later that minimum
version was bumped to 1.17 when Firefox bumped its requirement, but
hasn't been bumped since.

Now that Firefox nightly kinda sorta follows stable, I guess using
stable instead of a hardcoded version again makes sense.

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

Re: Implementing a Chrome DevTools Protocol server in Firefox

[James Graham]

On 31/08/17 21:22, Jack Moffitt wrote:
Is there another alternative besides CDP you'd like to propose? 



I don't have an alternate proposal, and I feel like I must have been 
unclear at some point. I'm not saying "this is bad, period". I'm 
certainly not saying "this is bad because it isn't WebDriver". Given 
that people seem to be in agreement that technically the CDP is good, 
I'm saying "this is bad if it remains a vendor-controlled, partially 
documented, pseudo-standard". The fact that there is apparently interest 
in creating a standard is reassuring, but there doesn't seem to be any 
recent activity on remotedebug.org, so it's hard to tell what the real 
status is, or whether people have understood the amount of work that 
entails. I am slightly worried that there have been several replies 
suggesting that poor interoperability above the message layer won't be a 
big problem because the users will be technical and therefore happy to 
absorb the cost of backwards-incompatible changes between releases. 
Experience from WebDriver is that this isn't true.

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

Proposal: Unified Bootstrap Stages for Gecko

[zbraniecki]

Gecko has a pretty substantial number of metrics used for measuring startup 
performance.

We have probes in Telemetry [0], StartupTimeline [1], various uses of 
MozAfterPaint, both in talos tests [2] and in production code [3][4].
We also have first paint in compositor [5], before-first-paint [6], 
timeToNonBlankPaint [7] which should not be confused with firstNonBlankPaint 
[8] and probably a number of other probes that register different timestamps 
and are used all around to mean different things. Some measure layout, others 
composition. Many of them are misused by capturing the timestamp in the 
callback to event listener fired asynchronously post-event.
We end up seeing huge swings in some "first-paint" [9] that are not 
reproducible in another "first-paint" [10], and we know that things like 
WebRender may not affect some of our "first-paint" because it measures only 
part of paint that WebRender doesn't affect[11].

It doesn't help that some of them are chrome-only while others are available in 
content.

I believe that, while we can recognize the complexity of the systems in play 
and how this complexity explains why different probes ended up being 
constituted, this situation is counter productive to our ability to understand 
the performance implication of our changes in product.

I'd like to suggest establishing a single set of timestamps with unique names 
to represent various stages of the product launch.
Those timestamps would be described based on the user-perceived results and as 
such serve us as best-effort approximations of the impact of any change on the 
user-perceived experience.

In particular, my proposal is based on WICG Paint Timing proposal [12] and 
establishes the 5 major timestamps to be executed at the latest event that 
contributes to the user-perceived outcome.
For example, when selecting when to mark "xPaint" event, we will use the 
consumer notion of the term "paint" and mark it after *all* operations required 
for the paint to happen are done - layout, composition, rendering and paint.

My proposal is also based on the work on negotiated performance milestones 
established for Firefox OS project [13].

The proposed milestones are:

1) firstPaint

This milestone happens when the first paint that is influenced by the data for 
the measured object is completed by the engine (and likely submitted to the 
graphic driver).

In the context of an HTML document, the first paint that is affected by the 
document's background or title is completed.

2) firstContentfulPaint

The first contentful paint of browser.xul happens when the first paint that 
includes layout of DOM data from browser.xul is completed.

3) visuallyCompletedPaint

This milestones is achieved after the first paint with the above-the-fold part 
of the DOM ready is submitted. This event may require the document to inform 
the engine that all the items in the visual field are ready, and the next paint 
captures the timestamp.

4) chromeInteractive

This milestone is achieved when the app reports the UI to be ready to be 
interacted with. The definition of what constitutes of the UI being ready is up 
to the app, and may just include the URL bar being ready to receive URL input, 
or may wait for all core parts of the product to have event handlers attached 
(urlbar, tabbar, main menu etc.)
This milestone may be reached before (3), but not after (5).

5) fullyLoaded

This milestone also may require data from the document and it should mark the 
timestamp when all startup operations are completed.
This should include delayed startup operations that may have waited for 
previous stages to be achieved, but should not wait for non-startup delayed 
operations like periodic updates of data from AMO etc.

The last milestone is a good moment to reliably measure memory consumption 
(possibly after performing GC), take a screenshot for any tests that compare UI 
between starts and so on.

Generally speaking, (5) is when we naively can say "the app is fully launched".


==

This system would require us to provide a way for each document to inform the 
engine when some of the later stages are reached. Then the engine would take 
the next full paint and capture the timestamp.
Such timestamp list would be available for chrome and behind a flag for 
content, to be used by tests.

The value of such milestone approach lies not only in unification of reading, 
but also easier hooking of code into the bootstrap process. Having such a 
consistent multi-stage bootstrap allows developers to decide at which stage 
their code has to be executed to delay only what has to be affected by it and 
in result developing a culture of adding code that doesn't affect early stages 
of the bootstrap unnecessarily.

Lastly of course, the value comes in our ability to say that all telemetry 
probes, talos tests, tp6 tests etc. and automation can now rely on a single set 
of timestamps which would increase developers ability to understan

Quantum Flow Engineering Newsletter #22

[Ehsan Akhgari]

Hi everyone,

With around three weeks left in the development cycle for Firefox 57,
everyone seems to be busy getting the last fixes in to shape up this
long-awaited release.  On the Quantum Flow project, we have kept up with
the triage of the incoming bug reports that are tagged as [qf], and as
we're getting closer to the beta uplift date, the realistic opportunity for
fixing bugs is getting narrower, and as such the bar for prioritizing
incoming bug reports as [qf:p1] keeps getting higher.  This matches with
the overall shift in focus in the past few weeks towards getting all the
ongoing work that is targeting Firefox 57 under control to make sure we
manage to do as much of what we have planned to do for this release as
possible.

This past week we made more progress on optimizing the performance of
Firefox for the Speedometer V2
 benchmark.
Besides many of the usual optimizations, which you will read about in the
acknowledgement section of the newsletter, one noteworthy item was David
Major's investigation 
for adding this benchmark to the set of pages that we load to train the PGO
profile we use on Windows builds.  This allowed the MSVC code generator to
generate better optimized code using the profile information and bought us
a few benchmark score points.  Of course, earlier similar attempts
 hadn't really gained
us better performance, and it's unclear whether this change will stick or
get backed out due to PGO specific crashes or whatnot, but in the mean time
we're not stopping landing other
 improvements
 to Firefox for this
benchmark either!  At the time of this writing, the Firefox Health
Dashboard puts our benchmark score on Nightly at 4.07% of Chrome's.

Another news worthy of mention related to Speedometer is that recently
Speedometer tests with Stylo  were
enabled  on AWFY.  As
can be seen on the reference hardware
 score
page
,
Stylo builds are now a bit faster than normal Gecko when running
Speedometer.  This has been achieved by the hard work of many people on the
Stylo team and I'd like to take a moment to thank them, and especially call
out Bobby Holley who helped make sure that we have a great performance
story here.

In other performance related news, this past week the first implementation
of our cooperative preemptive scheduling of web page JavaScript
, more commonly known
as Quantum DOM, landed.  The design document

describes some of the background information which may be helpful if you
need to understand the details of how the new world looks like.  For now,
this feature is disabled by default while the ongoing work to iron out the
remaining issues continues.

The Quantum DOM project has been a massive overhaul of our codebase.  A
huge part of it has been the "labeling"
 project that Bevis Tseng
has been tirelessly leading for many months now.  The basic idea behind
this part of the project is to give each runnable a name and indicate which
tab or document the runnable is associated with (I'm simplifying a bit,
please see the wiki page 
for more details.)  Bill McCloskey had a great suggestion about some
performance lessons that we have learned through this project for the
performance story section of this newsletter, which was to highlight how
this project ended up uncovering some unexpected performance issues in
Firefox!

Bevis has some telemetry analysis

which measures the number of runnables of a certain type (to view the
interesting part, please scroll down to the "full runnable list" section).
This analysis has been used to prioritize which runnables need to be worked
on next for labeling purposes.  But as this list shows the relative
frequencies of runnables, we've ended up finding several surprises in where
some runnables are showing up on this list, which have uncovered
performance issues which would otherwise be very difficult to detect and
diagnose.  Here are a few examples (thanks to Bill for enumerating them!):

   - We used to send the DidComposite notification to every tab, regardless
   of whether it was in the foreground or background.  We tried to fix this
   once , but the fix
   actually only fixed a related issue involving m

Changing remote type of xpcshell Content processes from "" to "web"

[Andrew Sutherland]

Right now if you have an e10s xpcshell test, the remote type of the 
resulting child (content) process will be NO_DEFAULT_TYPE="". This is 
not a real type, this is not a type you should ever see in Firefox.  In 
https://bugzilla.mozilla.org/show_bug.cgi?id=1395827 I propose changing 
the type to DEFAULT_REMOTE_TYPE="web".  It's not a sure thing, but I 
figure if I make it sound likely to happen and you have an opinion on 
this, you're more likely to speak up. Please chime in on the bug.  Thanks!


Andrew

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