from:"Patrick Brosset"

Re: Intent to implement: CSS conic-gradient

2020-02-17 Thread Patrick Brosset

Thanks Tim, this is very exciting!

Regarding DevTools: you are right, having an editor would be great and the
same is true for other kinds of gradients. Here's a bug for a
linear-gradient editor for reference:
https://bugzilla.mozilla.org/show_bug.cgi?id=1364380

Additionally, could we make sure that the conic-gradient function gets
suggested in the CSS autocomplete of the Inspector panel? I forget how this
normally works, but could you please file a bug for it?

Patrick

On Sun, Feb 16, 2020 at 11:46 AM Tim Nguyen  wrote:

> Summary: CSS conic-gradients allow developers to specify gradients that
> start from a certain angle where color stops are placed around the
> circumference of a circle centered around a specified point.
>
> Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=conic-gradients
>
> Standard: https://drafts.csswg.org/css-images-4/#conic-gradients
>
> Target Release: 75-76
>
> Platform coverage: All, initially WebRender only (though it shouldn't be
> long until it's implemented for other backends)
>
> Preference behind which this will be implemented:
> layout.css.conic-gradient.enabled,
> turned off by default until it's implemented outside of WebRender
>
> DevTools bug: n/a, devtools could potentially add a gradient editor, but
> that's also applicable to linear/radial gradients
>
> Other browsers: shipped since Chrome 69, Safari 12.1, Edge 79 and Opera 64
>
> web-platform-tests:
>
> https://searchfox.org/mozilla-central/search?q=conic-gradient&case=false®exp=false&path=testing%2Fweb-platform
>
> Restricted to secure contexts: No, CSS features are usually not restricted
> to secure contexts
>
> Is this feature enabled by default in sandboxed iframes?  Yes
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Unship: in content

2020-02-14 Thread Patrick Brosset

Thanks Kris.

Related to this: RDM (Responsive Design Mode, in DevTools) is one of the
consumers of . We've been at work removing the
dependency from RDM on this type of iframe, and are nearing the completion
of the main bucket of work. By March this year, we should have a new, fully
functional version of RDM that does not depend on .
The "old" RDM will still be in the tree by this date and we might not have
pref'd the new one on yet, but we'll be very close.

A simple completion chart for this project can be found at
https://arewefissionyet.com/devtools/ (under the RDM section).
In bugzilla, the whiteboard flag fission-rdm-mvp tracks the project:
https://bugzilla.mozilla.org/buglist.cgi?quicksearch=fission-rdm-mvp&list_id=15103084

Patrick

On Mon, Feb 10, 2020 at 9:46 PM Kris Maglione  wrote:

>  in non-chrome documents has been unsupported
> in production environments for some time. Maintaining support
> for it in content processes has become increasingly difficult in
> the light of Fission, to the point that we've decided it is time
> to fully remove support. Since support is disabled by default,
> and there is no user-visible way to enable it, there should be
> no users in the wild. The only in-tree users are tests, which
> will need to be updated by their owners or disabled.
>
> Bug 1614462 will track this work.
>
>
> -Kris
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Optional Chaining Operator

2020-01-22 Thread Patrick Brosset

Thanks Yulia, this is going to be very useful and helpful in reducing code
complexity!

For info, here's a DevTools bug to make sure the console panel still
supports autocompletion even when ?. is used:
https://bugzilla.mozilla.org/show_bug.cgi?id=1594009
I also a question: do you know if eslint is ready for this new syntax? In
other words, can we use it in m-c without causing eslint parsing errors?

On Tue, Jan 21, 2020 at 8:11 PM Yulia Startsev  wrote:

> Hi,
>
> In Firefox 74, we'll ship the optional chaining operator.
>
> *Bug: *https://bugzilla.mozilla.org/show_bug.cgi?id=1566143
> *Standard: *https://tc39.es/proposal-optional-chaining/
> *Platform coverage: *All, no pref
> *DevTools bug: *N/A.
> *Other browsers:* Shipping in Chrome, Shipping in Safari
> *Testing: *
>
> https://github.com/tc39/test262/tree/master/test/language/expressions/optional-chaining
> <
> https://github.com/tc39/test262/tree/master/test/language/expressions/coalesce
> >
>
> *Use cases: *Optional chaining may be useful in cases where a property may
> be conditionally present. This affects property access, dynamic property
> access, and function calls in the following way:
>
> *Property access*
>
> Before
> const street = user.address && user.address.street;
>
> After
> const street = user.address?.street;
>
> *Dynamic Property Access*
> Before
> const street = user.address && user.address["street"];
>
> After
> const street = user.address?.["street"];
>
> *Optional function calls:*
>
> Before
> const result = myObj.method && myObj.method();
>
> After
> const result = myObj?.method();
>
>
> *Secure contexts:* This is a JS language feature and is therefore present
> in all contexts.
> ___
> 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

Announcing the Multiprocess Browser Toolbox

2019-12-20 Thread Patrick Brosset

(cross-posting to dev-platform and dev-developer-tools, please respond to
*firefox-dev*)

The short version:

The new Multiprocess Browser Toolbox (which can inspect and debug both
parent and content processes) is now enabled in nightly! If you see
anything wrong, please file a bug that blocks the dt-fission
 bug.

The longer version:

If you have ever worked on browser code, you likely already know what
the Browser
Toolbox 
is. If you don't, think of it as the developer tools for the browser itself
(it allows you to debug the browser's own JavaScript and inspect/modify the
browser's own UI).

Up until now, the Browser Toolbox allowed you to interact with the things
that lived in the parent Firefox process only.

However, over the past few months, we have been hard at work on improving
the Browser Toolbox. It can do much more: not only can it interact with the
parent process as before, it can now also see into content processes (i.e.
walk the DOM inside  elements, log messages from all
processes to the console, set breakpoints and debug scripts from all
threads, etc.).

We did this because it gave us the right environment to get DevTools ready
for Fission.

Indeed, by making the Browser Toolbox aware of more than just one process
(the parent) we can almost just as easily make the normal DevTools (i.e.
inside a tab) aware of all of the processes that make up a web page (other
origin iframes, workers, etc.)

If you are remote debugging Fenix/Firefox Preview, this also means that
debugging the main process will now give you access to content processes as
well (see this comment
).

This work has been done under the DevTools Fission M1 project (completion
chart ), which is now complete!

*Today, we are pleased to announce that the new Multiprocess Browser
Toolbox has been enabled in Nightly (bug 1588050
).*

A lot of work  was done to make this possible, and
a lot of code changed, so it is possible that you encounter issues. This is
why we are keeping this in nightly for now.

If you see anything wrong, please let us know by filing a bug that blocks
the dt-fission 
bug.

If you have any questions about any of this, the answer may be in this FAQ
,
if not, feel free to let us know.


We hope you like this new Browser Toolbox!

What's next?

Because the new Browser Toolbox can be used to debug content processes, we
will be retiring the Browser Content Toolbox soon (in bug 1603376
).

But more importantly, our next milestone for making DevTools Fission
compatible will start beginning of 2020 (we call it M2, see the completion
chart ). We plan on working on the
following tracks:


   -

   Making the necessary DevTools framework adjustments to support remote
   iframes inside web pages.
   -

   Making all tools support navigation process switches (already underway).
   -

   Re-architecting highlighters (the things that appear over the content
   page when ve.g. selecting a node) so they work cross-frames.
   -

   And implementing new UI allowing users to switch JS execution context
   throughout the tools.


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

Re: Intent to ship: CSS column-span property

2019-10-09 Thread Patrick Brosset

Regarding DevTools support: the new value can be found in the CSS values
auto-complete in the Rules panel, so that's great.
But I just wanted to mention the potential inspector feature that could be
built around multicol layouts. We have leading tools when it comes to grid
support, and I think a similar tool could be done for multicol. Something
that highlights the columns, the gaps between them, and the items
(especially useful when items span multiple columns).
Positioning items in a multicol layout is not nearly as complex as doing
the same in a grid layout, so a tool like this is probably not as
important. But still worth considering at some point.

Kudos for shipping this feature btw! Great work.

On Tue, Oct 8, 2019 at 8:32 PM Ting-Yu Lin 林庭宇  wrote:

> As of today, I intend to turn "column-span" on by default for all platforms
> in Firefox 71. It has been developed behind
> "layout.css.column-span.enabled" preference, and has been enabled on
> Nighly-only in bug 1423383.
>
> *Summary: *
> The CSS column-span property, when its value is set to "all" makes an
> element span across all columns in the multi-column layout.
>
> *Bug to turn on by default: *
> https://bugzilla.mozilla.org/show_bug.cgi?id=1426010
>
> *Meta bug where this feature is developed:*
> https://bugzilla.mozilla.org/show_bug.cgi?id=616436
>
> *Standard:*
> https://www.w3.org/TR/css-multicol-1/#column-span
>
> *Platform coverage:*
> Like many other CSS features, column-span has support on all platforms.
>
> *DevTools bug:*
> None. Column-span doesn't require special support from the DevTools.
>
> *Other browsers: *
> According to caniuse.com, Chrome has shipped unprefixed column-span since
> Chrome 50 in 2016, and Safari has shipped this in Safari 9 since 2015.
> https://caniuse.com/#search=column-span
>
> *web-platform-tests: *
> Those tests with title "multicol-span-all-*" in multi-column test suite.
> https://github.com/web-platform-tests/wpt/tree/master/css/css-multicol
>
> *Secure contexts:* N/A
>
> *Note:*
> To support the development of column-span, the architecture of the multicol
> layout needs to be changed in a nontrivial way. If you see any bug, please
> one file under "Layout: Columns" component. Thanks!
>
>
> Ting-Yu Lin
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: |clip-path: path()|

2019-09-02 Thread Patrick Brosset

On Fri, Aug 30, 2019 at 7:45 PM Boris Chiou  wrote:

> *DevTools*: We don't support DevTools for this function now.
>

For reference: this was already discussed at Mozilla between the layout and
devtools team and agreed that we would not make a tool for this just yet
(we do have a tool for editing circle() ellipse() polygon()).
Doing a tool for this would require pretty much making a full SVG editor.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: individaul transform

2017-12-15 Thread Patrick Brosset

(cc'ing the dev-developer-tools list, please keep responses to dev-platform)

Very happy to see this being implemented.
I would like to point out that this does have some DevTools impact that we
might want to align with the target release for this.

There's a (sort of hidden) feature in DevTools where, if you position your
cursor over a `transform` property name inside the CSS Rules panel of the
inspector, then an overlay appears in the page. This overlay shows you 2
things: where the element selected in the inspector currently is on the
page, and where it would have been if that `transform` property had not
been there. It gives a sense of how CSS transform works.
This MDN page describes that feature:
https://developer.mozilla.org/en-US/docs/Tools/Page_Inspector/How_to/Visualize_transforms

If we also want to support the new properties being introduced here, that
will require some work in DevTools, and I'm not sure how the feature would
even work. I think it would be a good opportunity for us to revise the UX
of the feature and possibly come up with an even better transform tool.

Note that none of this is a blocker, people using `transform` will still
benefit from this feature. The new properties will just act as normal
properties in the Rules panel, and hovering over them will just do nothing.

On Fri, Dec 15, 2017 at 8:51 AM, Ku(顧思捷)CJ  wrote:

> Summary:
>   The translate, rotate, and scale properties allow authors to specify
> simple transforms independently, in a way that maps to typical user
> interface usage, rather than having to remember the order in transform that
> keeps the actions of transform(), rotate() and scale() independent and
> acting in screen coordinates.
>   Both Blink and Edge have implemented this feature.
>
> Bug:
>   https://bugzilla.mozilla.org/show_bug.cgi?id=1207734
>
> Link to standard:
>   https://drafts.csswg.org/css-transforms-2/#individual-transforms
>
> Platform coverage:
> All platforms
>
> Target release:
>   FF60
>
> Preference behind which this will be implemented:
>   "layout.css.individual-transform.enabled"
>
> Do other browser engines implement this?
>   Blink/ Edge
>
> Tests:
>   WPT test
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to Enable: Automated Static Analysis feedback in MozReview

2017-10-09 Thread Patrick Brosset

This sounds awesome Jan.
Are there plans to have something similar for JS code linting (with ESLint)?

On Wed, Oct 4, 2017 at 7:14 PM, Ehsan Akhgari 
wrote:

> On 10/04/2017 03:17 AM, Jan Keromnes wrote:
>
>> TL;DR -- We wrote a static analysis bot for MozReview ("clangbot") and
>> it's
>> about to complain about any patches that would introduce new C/C++ code
>> defects to Firefox.
>>
> This is fantastic to see, thank you for making it happen!
>
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: HTML scoped style sheets (

2017-06-20 Thread Patrick Brosset

DevTools also uses a scoped stylesheet in its tooltip widget [1].
I have filed a bug [2] to remove it.

Cameron, what bug should this one block (iiuc chrome support will be
removed a bit later, so we have some time, do you already have a bug for
that part?)

Thanks!
Patrick

[1]
http://searchfox.org/mozilla-central/source/devtools/client/shared/widgets/tooltip/HTMLTooltip.js#643
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1374555

On Tue, Jun 20, 2017 at 7:20 AM, Cameron McCormack  wrote:

> On Tue, Jun 20, 2017, at 01:08 PM, Jared Wein wrote:
> > We use a scoped stylesheet for styling the popup for  [1]. We
> > chose this route to limit performance impact as well as limit our
> > temporary stylesheet from affecting other parts of the browser UI.
> > Will your removal also remove support in the chrome/parent process?
> For now we'll keep  available in chrome documents.  But in
> the medium term , we will want to style chrome documents with Servo too
> https://bugzilla.mozilla.org/show_bug.cgi?id=1294570, and at that point
> we'll have to remove