Re: Deprecating XUL in new UI

[Tim Guan-tin Chien]

Hi Dave,

I am glad that we are having this conversation. To be honest, two of
features spinning in Taipei are already partly implemented in HTML,
out of the expectations that, dealing with familiar tech means faster
development and less regressions. They are

- Desktop video control UI within 
https://bugzilla.mozilla.org/show_bug.cgi?id=1271765
- The date/time picker to popup from  and  https://bugzilla.mozilla.org/show_bug.cgi?id=888320

Things are obviously not as perfect as we would have imagined. I would
say the outstanding complications learned are the quirks of the XUL
embedder. The video control is implemented in HTML but within a XUL
anno node. The pickers are implemented in an XHTML embedded inside an
xul:panel > xul:iframe. By looking at the
patches/follow-up/regressions there you will see how much code would
still be live inside XBL (e.g. event forwarding), and one unfortunate
layout surprise (bug 173).

We would need to look at that more broadly to achieve the goal stated.
That could even mean re-invest in some XUL layout features if we must.

Within HTML, a longer discussion is needed (and intentional decisions
outside of HTML features) on how components in HTML should work. Gaia
was started in 2011 and became hard to work with quickly due to
various reasons, and compartmentalization being one of the biggest. I
will stop here as an effort of stop beating the dead horse.

DevTools team is using React. We should be ready to make a similar
decision when we need to — single-page-web-app needs a committed way
of compartmentalization to stay sane, i.e. something (platform feature
or not) is needed here to replace XBL.

Yeah, the Web Components. I've been hearing about this ever since my
employment in Mozilla. Yet, around 2015, I was told the current
pref-off implementation will likely be changed as the spec matures so
front-end should not build anything on top of it. I don't know if the
status has changed but I will personally back away from it before I am
given a strong commitment from the platform engineering.

Feel free to reach out. Thanks,


Tim


On Tue, Jan 17, 2017 at 4:43 AM, Dave Townsend  wrote:
> One of the things I've been investigating since moving back to the desktop
> team is how we can remove XUL from the application as much as possible. The
> benefits for doing this are varied, some obvious examples:
>
> * XUL is a proprietary standard and we barely maintain it.
> * Shallower learning curve for new contributors who may already know and use
> HTML.
> * HTML rendering is more optimized in the platform than XUL.
> * Further integration of Servo code may require dropping XUL altogether.
>
> The necessary first step of reducing XUL use is to stop adding any more UI
> that uses XUL and here I'm talking about wholly new UI, additions to
> browser.xul and other existing UI are a separate concern. What do folks
> think about making this a rule for new projects in the near future?
>
> Of course there are some features missing from HTML that make this
> impossible in some cases right now. Some that I've already found:
>
> * HTML has no support for popup panels like XUL does. The devtools team have
> been working around this but they are still dependent on XUL right now.
> * iframe elements don't have the same capabilities that the XUL browser
> element does and we use that in some UI.
> * Top level menus on OSX are currently only able to be defined with XUL
> elements. This only affects UI that uses top-level windows and most of our
> new UI is in-content so may be less of an issue.
>
> What other features do we depend on in XUL that I haven't listed?
>
> ___
> 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: Deprecating XUL in new UI

[Robert O'Callahan]

On Tue, Jan 17, 2017 at 11:41 AM, Sebastian Zartner <
sebastianzart...@gmail.com> wrote:

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


My comments in that bug still apply. Ellipsizing in the centre when the
line contains more than just a single text node is really hard.

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Joshua Cranmer ]

On 1/16/2017 2:43 PM, Dave Townsend wrote:

One of the things I've been investigating since moving back to the desktop
team is how we can remove XUL from the application as much as possible. The
benefits for doing this are varied, some obvious examples:

* XUL is a proprietary standard and we barely maintain it.
* Shallower learning curve for new contributors who may already know and
use HTML.
* HTML rendering is more optimized in the platform than XUL.
* Further integration of Servo code may require dropping XUL altogether.

The necessary first step of reducing XUL use is to stop adding any more UI
that uses XUL and here I'm talking about wholly new UI, additions to
browser.xul and other existing UI are a separate concern. What do folks
think about making this a rule for new projects in the near future?

Of course there are some features missing from HTML that make this
impossible in some cases right now. Some that I've already found:

* HTML has no support for popup panels like XUL does. The devtools team
have been working around this but they are still dependent on XUL right now.
* iframe elements don't have the same capabilities that the XUL browser
element does and we use that in some UI.
* Top level menus on OSX are currently only able to be defined with XUL
elements. This only affects UI that uses top-level windows and most of our
new UI is in-content so may be less of an issue.

What other features do we depend on in XUL that I haven't listed?


XUL trees are probably the most complex feature that HTML doesn't have. 
Some of its features that I consider important include the use of an 
nsITreeView-like generative interface, advanced styling capabilities 
(you can style rows/cells based on content, effectively), lazy loading 
(in particular, data for child elements isn't asked for until their 
parents are expanded). There's also probably performance aspects and 
accessibility factors that don't normally feature in the minds of 
developers.


XUL overlays and XBL widgets are also things that are likely to be 
missed, although Web Components probably largely covers the same feature 
space (I don't know enough to know what is missing).


The final point I would make is that we probably need to pick a standard 
widget toolkit. I believe in the past, we were shipping 4 different 
versions of jQuery because every little frontend silo was importing it 
locally for their own needs. Particularly if we need to reimplement 
major widgets like , it makes much more sense to have one 
shared implementation that can be collaboratively improved. And put it 
in toolkit/, please, not browser/. :-)



--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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

Re: Deprecating XUL in new UI

[Dave Townsend]

Trees! I knew I was forgetting something, thank you. Yeah those are things
we're going to need some sane replacements for.

AS far as XBL goes, while I suspect it works from HTML documents I think we
want to be phasing out use of XBL too for pretty much the same reasons as
XUL. Web components seem like an obvious alternative and I understand that
they are only preffed off right now. If we can have them work in chrome
documents they could be the right replacement.

On Mon, Jan 16, 2017 at 1:28 PM, Matthew N.  wrote:

> Trees are the big thing that come to mind. I've heard about three non-XUL
> re-implementations (IIRC mostly in devtools) which sounds like a
> maintainability issue and potentially redundancy. I would rather keep using
> XUL trees than have even more different tree implementations (though I'd be
> fine with a one or two simpler replacements since many uses of a xul:tree
> don't need a lot of the feature like nesting) which brings me to my next
> point:
>
> What about XBL? Does it just work from XHTML documents? Is our
> implementation of Web Components ready to replace it and riding the trains?
> I think it would be good to implement drop-in replacements (or as close as
> possible) for some simple XBL bindings or native XUL elements to prove that
> Web Components are a replacement. Once the Web Component version is working
> we can transition to it everywhere. Perhaps something like 
> would be a good candidate.
>
> Matthew
>
> On Mon, Jan 16, 2017 at 12:43 PM, Dave Townsend 
> wrote:
>
>> One of the things I've been investigating since moving back to the
>> desktop team is how we can remove XUL from the application as much as
>> possible. The benefits for doing this are varied, some obvious examples:
>>
>> * XUL is a proprietary standard and we barely maintain it.
>> * Shallower learning curve for new contributors who may already know and
>> use HTML.
>> * HTML rendering is more optimized in the platform than XUL.
>> * Further integration of Servo code may require dropping XUL altogether.
>>
>> The necessary first step of reducing XUL use is to stop adding any more
>> UI that uses XUL and here I'm talking about wholly new UI, additions to
>> browser.xul and other existing UI are a separate concern. What do folks
>> think about making this a rule for new projects in the near future?
>>
>> Of course there are some features missing from HTML that make this
>> impossible in some cases right now. Some that I've already found:
>>
>> * HTML has no support for popup panels like XUL does. The devtools team
>> have been working around this but they are still dependent on XUL right now.
>> * iframe elements don't have the same capabilities that the XUL browser
>> element does and we use that in some UI.
>> * Top level menus on OSX are currently only able to be defined with XUL
>> elements. This only affects UI that uses top-level windows and most of our
>> new UI is in-content so may be less of an issue.
>>
>> What other features do we depend on in XUL that I haven't listed?
>>
>> ___
>> 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: Deprecating XUL in new UI

[Dave Townsend]

Thanks for your feedback Jaroslav, it's really helpful. The issue around
mixing XUL and HTML is one in particular where I think we may end up having
to make some platform fixes to at least make the transition away from XUL
possible.

On Mon, Jan 16, 2017 at 1:31 PM, Jaroslav Šnajdr  wrote:

> Hello Dave,
>
> while contributing to some of the devtools.html refactoring projects, I
> noticed the following further issues:
>
> - the XUL label element has attribute crop=start|center|end, which can be
> used to truncate the label text and insert an ellipsis character at the
> place of your choice. HTML doesn't have this - ellipsis can be inserted
> only at the end, and after doing some RTL magic, also at the start (but not
> 100% bug-free). The "center" option is not available at all. Solving this
> in CSS would be a really nice addition to the web platform. There's been
> some spec work done by Sebastian Zartner few years ago.
>
> - there is a difference in how events are dispatched in HTML vs XUL
> iframes. In HTML, the capture/bubble phases are isolated inside the iframe
> window, but in XUL, the target chain crosses the iframe boundaries. This
> causes problems for React and its event system, which relies on the HTML
> behavior. This can be solved by patching React, or adding a special flag to
> the iframe element.
>
> - when there are elements from both XUL and HTML namespaces inside one XUL
> document (happens when doing incremental migration), it can be challenging
> to make flex-like layouts work correctly. The standard flex layout and the
> XUL flex (-moz-box) interact in ways that are hard to understand.
>
> Jarda
>
>
>
> On Mon, Jan 16, 2017 at 9:43 PM, Dave Townsend 
> wrote:
>
>> One of the things I've been investigating since moving back to the
>> desktop team is how we can remove XUL from the application as much as
>> possible. The benefits for doing this are varied, some obvious examples:
>>
>> * XUL is a proprietary standard and we barely maintain it.
>> * Shallower learning curve for new contributors who may already know and
>> use HTML.
>> * HTML rendering is more optimized in the platform than XUL.
>> * Further integration of Servo code may require dropping XUL altogether.
>>
>> The necessary first step of reducing XUL use is to stop adding any more
>> UI that uses XUL and here I'm talking about wholly new UI, additions to
>> browser.xul and other existing UI are a separate concern. What do folks
>> think about making this a rule for new projects in the near future?
>>
>> Of course there are some features missing from HTML that make this
>> impossible in some cases right now. Some that I've already found:
>>
>> * HTML has no support for popup panels like XUL does. The devtools team
>> have been working around this but they are still dependent on XUL right now.
>> * iframe elements don't have the same capabilities that the XUL browser
>> element does and we use that in some UI.
>> * Top level menus on OSX are currently only able to be defined with XUL
>> elements. This only affects UI that uses top-level windows and most of our
>> new UI is in-content so may be less of an issue.
>>
>> What other features do we depend on in XUL that I haven't listed?
>>
>> ___
>> 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: Deprecating XUL in new UI

[Dave Townsend]

On Mon, Jan 16, 2017 at 1:33 PM, Mike Connor  wrote:

> I think the rule is fine, subject to the reality that the scope of totally
> new doc-level UX is fairly limited.  I think you'll want to be a little
> more aggressive up front if you want to shift the overall codebase in
> finite time.
>
> To that end, I'd propose an additional requirement that any major refactor
> or redesign of in-content or separate-window UI (i.e. I've heard rumblings
> of a pending preferences redesign) should move to HTML if possible.  If
> it's not possible, the relevant issues should be filed and tracked as a
> condition of waiving the refactor requirement.  (I think it's a module
> owner call whether to waive, since getting off XUL is likely going to
> matter more in another year or two.)
>

Yeah that makes a lot of sense. Of course as with any rule we make I expect
there to be small cases where we have to waive at least at first.

On your bullet points, I think the main blocker to moving everything to at
> least mostly-HTML outside of browser.xul is going to be the top-level menu
> issue.  That might be a good test case for a new Web Component binding, to
> follow on from MattN's thinking.
>
> -- Mike
>
> On Mon, Jan 16, 2017 at 3:43 PM, Dave Townsend 
> wrote:
>
>> One of the things I've been investigating since moving back to the
>> desktop team is how we can remove XUL from the application as much as
>> possible. The benefits for doing this are varied, some obvious examples:
>>
>> * XUL is a proprietary standard and we barely maintain it.
>> * Shallower learning curve for new contributors who may already know and
>> use HTML.
>> * HTML rendering is more optimized in the platform than XUL.
>> * Further integration of Servo code may require dropping XUL altogether.
>>
>> The necessary first step of reducing XUL use is to stop adding any more
>> UI that uses XUL and here I'm talking about wholly new UI, additions to
>> browser.xul and other existing UI are a separate concern. What do folks
>> think about making this a rule for new projects in the near future?
>>
>> Of course there are some features missing from HTML that make this
>> impossible in some cases right now. Some that I've already found:
>>
>> * HTML has no support for popup panels like XUL does. The devtools team
>> have been working around this but they are still dependent on XUL right now.
>> * iframe elements don't have the same capabilities that the XUL browser
>> element does and we use that in some UI.
>> * Top level menus on OSX are currently only able to be defined with XUL
>> elements. This only affects UI that uses top-level windows and most of our
>> new UI is in-content so may be less of an issue.
>>
>> What other features do we depend on in XUL that I haven't listed?
>>
>> ___
>> 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: Deprecating XUL in new UI

[Mike Connor]

I think the rule is fine, subject to the reality that the scope of totally
new doc-level UX is fairly limited.  I think you'll want to be a little
more aggressive up front if you want to shift the overall codebase in
finite time.

To that end, I'd propose an additional requirement that any major refactor
or redesign of in-content or separate-window UI (i.e. I've heard rumblings
of a pending preferences redesign) should move to HTML if possible.  If
it's not possible, the relevant issues should be filed and tracked as a
condition of waiving the refactor requirement.  (I think it's a module
owner call whether to waive, since getting off XUL is likely going to
matter more in another year or two.)

On your bullet points, I think the main blocker to moving everything to at
least mostly-HTML outside of browser.xul is going to be the top-level menu
issue.  That might be a good test case for a new Web Component binding, to
follow on from MattN's thinking.

-- Mike

On Mon, Jan 16, 2017 at 3:43 PM, Dave Townsend 
wrote:

> One of the things I've been investigating since moving back to the desktop
> team is how we can remove XUL from the application as much as possible. The
> benefits for doing this are varied, some obvious examples:
>
> * XUL is a proprietary standard and we barely maintain it.
> * Shallower learning curve for new contributors who may already know and
> use HTML.
> * HTML rendering is more optimized in the platform than XUL.
> * Further integration of Servo code may require dropping XUL altogether.
>
> The necessary first step of reducing XUL use is to stop adding any more UI
> that uses XUL and here I'm talking about wholly new UI, additions to
> browser.xul and other existing UI are a separate concern. What do folks
> think about making this a rule for new projects in the near future?
>
> Of course there are some features missing from HTML that make this
> impossible in some cases right now. Some that I've already found:
>
> * HTML has no support for popup panels like XUL does. The devtools team
> have been working around this but they are still dependent on XUL right now.
> * iframe elements don't have the same capabilities that the XUL browser
> element does and we use that in some UI.
> * Top level menus on OSX are currently only able to be defined with XUL
> elements. This only affects UI that uses top-level windows and most of our
> new UI is in-content so may be less of an issue.
>
> What other features do we depend on in XUL that I haven't listed?
>
> ___
> 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: Deprecating XUL in new UI

[Jaroslav Šnajdr]

Hello Dave,

while contributing to some of the devtools.html refactoring projects, I
noticed the following further issues:

- the XUL label element has attribute crop=start|center|end, which can be
used to truncate the label text and insert an ellipsis character at the
place of your choice. HTML doesn't have this - ellipsis can be inserted
only at the end, and after doing some RTL magic, also at the start (but not
100% bug-free). The "center" option is not available at all. Solving this
in CSS would be a really nice addition to the web platform. There's been
some spec work done by Sebastian Zartner few years ago.

- there is a difference in how events are dispatched in HTML vs XUL
iframes. In HTML, the capture/bubble phases are isolated inside the iframe
window, but in XUL, the target chain crosses the iframe boundaries. This
causes problems for React and its event system, which relies on the HTML
behavior. This can be solved by patching React, or adding a special flag to
the iframe element.

- when there are elements from both XUL and HTML namespaces inside one XUL
document (happens when doing incremental migration), it can be challenging
to make flex-like layouts work correctly. The standard flex layout and the
XUL flex (-moz-box) interact in ways that are hard to understand.

Jarda



On Mon, Jan 16, 2017 at 9:43 PM, Dave Townsend 
wrote:

> One of the things I've been investigating since moving back to the desktop
> team is how we can remove XUL from the application as much as possible. The
> benefits for doing this are varied, some obvious examples:
>
> * XUL is a proprietary standard and we barely maintain it.
> * Shallower learning curve for new contributors who may already know and
> use HTML.
> * HTML rendering is more optimized in the platform than XUL.
> * Further integration of Servo code may require dropping XUL altogether.
>
> The necessary first step of reducing XUL use is to stop adding any more UI
> that uses XUL and here I'm talking about wholly new UI, additions to
> browser.xul and other existing UI are a separate concern. What do folks
> think about making this a rule for new projects in the near future?
>
> Of course there are some features missing from HTML that make this
> impossible in some cases right now. Some that I've already found:
>
> * HTML has no support for popup panels like XUL does. The devtools team
> have been working around this but they are still dependent on XUL right now.
> * iframe elements don't have the same capabilities that the XUL browser
> element does and we use that in some UI.
> * Top level menus on OSX are currently only able to be defined with XUL
> elements. This only affects UI that uses top-level windows and most of our
> new UI is in-content so may be less of an issue.
>
> What other features do we depend on in XUL that I haven't listed?
>
> ___
> 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: Deprecating XUL in new UI

[Philipp Kewisch]

On 1/16/17 9:43 PM, Dave Townsend wrote:
> One of the things I've been investigating since moving back to the
> desktop team is how we can remove XUL from the application as much as
> possible. The necessary first step of reducing XUL use is to stop
> adding any more UI that uses XUL and here I'm talking about wholly
> new UI, additions to browser.xul and other existing UI are a separate
> concern. What do folks think about making this a rule for new
> projects in the near future?
> 
> Of course there are some features missing from HTML that make this 
> impossible in some cases right now.

I think this would be a great step forward and help towards getting rid
of XUL. Thanks for kicking this off. One of the roadblocks I have had in
XUL applications where I was meaning to port to HTML is the decision on
what framework, if at all, to use.

I know devtools has been making heavy use of react, and I can see other
components following this lead. This is of course a pretty strong
dependency, with the usual caveats of using an external dependency.

Aside from XUL you should also make a recommendation for XBL
replacements, as widgets are fairly commonly used. React allows for
creating widgets, another alternative would be web components. I have
seen some progress there lately but am also aware the spec is still
somewhat in flux. Nevertheless, I think using web components would
better allow sticking to native web technologies (and it is also my
personal preference).

Anyway, if you make HTML a requirement for new features, I think you
also need to provide some direction on the framework to use, or if we
should be sticking to the built-in tech instead.

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

Re: GPU Process Experiment Results

[Anthony Hughes]

Thanks for the feedback Chris.

Graphs measuring crash rates is "crashes per 1000 hours" for Telemetry data
via the crash_aggregates table (links to my re:dash queries are link at the
bottom of the post) and "crashes per install_time cardinality" for Socorro
data. I tried to focus on crash rate instead of crash count this time
around. I'll endeavour to add more context in future graphs.

Cheers!

On 16 January 2017 at 13:22, Chris Hutten-Czapski 
wrote:

> My one-sentence summary of the article - If anything, the test cohort with
> the GPU process saw improved stability, especially for graphics crashes.
>
> Which is awesome!
>
> May need error bars for the figures to see how much of the results you saw
> we might have to attribute to the noise of reported crash figures.
>
> Also, I can't quite tell what the units are. The initial graphs seem to be
> #crashes-reported-to-Socorro, but later ones talk of
> #crashes-per-1000-usage-hours. The axes aren't labelled, so it's difficult
> to be precise.
>
> Have you attempted to measure crash counts and types via Telemetry instead
> of Socorro? If all you need is a count and some metadata, the submission
> rate to Telemetry is much (25x) higher than Socorro. (actually, if all you
> need is a count, crash_aggregates would be a good place to start, as most
> of the counting has been done for you).
>
> All in all, very interesting and I can't wait to see future experiments in
> Aurora and on Beta, when the time is right.
>
> :chutten
>
>
> On Mon, Jan 16, 2017 at 4:11 PM, Anthony Hughes 
> wrote:
>
>> Hello Platform folks,
>>
>> Over the Christmas break I rolled out a Telemetry Experiment on Nightly to
>> measure the stability impact of the GPU Process. This experiment concluded
>> on January 11. Having had time to analyze the data I've published a report
>> on my blog:
>> https://ashughes.com/?p=374
>>
>> It should come up on Planet shortly but I wanted to post here for
>> increased
>> visibility. Feel free to send me questions, comments, and feedback.
>>
>> Cheers
>>
>> --
>> Anthony Hughes
>> Senior Quality Engineer
>> Mozilla Corporation
>> ___
>> dev-platform mailing list
>> dev-platform@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-platform
>>
>
>


-- 
Anthony Hughes
Senior Quality Engineer
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[Matthew N.]

Trees are the big thing that come to mind. I've heard about three non-XUL
re-implementations (IIRC mostly in devtools) which sounds like a
maintainability issue and potentially redundancy. I would rather keep using
XUL trees than have even more different tree implementations (though I'd be
fine with a one or two simpler replacements since many uses of a xul:tree
don't need a lot of the feature like nesting) which brings me to my next
point:

What about XBL? Does it just work from XHTML documents? Is our
implementation of Web Components ready to replace it and riding the trains?
I think it would be good to implement drop-in replacements (or as close as
possible) for some simple XBL bindings or native XUL elements to prove that
Web Components are a replacement. Once the Web Component version is working
we can transition to it everywhere. Perhaps something like 
would be a good candidate.

Matthew

On Mon, Jan 16, 2017 at 12:43 PM, Dave Townsend 
wrote:

> One of the things I've been investigating since moving back to the desktop
> team is how we can remove XUL from the application as much as possible. The
> benefits for doing this are varied, some obvious examples:
>
> * XUL is a proprietary standard and we barely maintain it.
> * Shallower learning curve for new contributors who may already know and
> use HTML.
> * HTML rendering is more optimized in the platform than XUL.
> * Further integration of Servo code may require dropping XUL altogether.
>
> The necessary first step of reducing XUL use is to stop adding any more UI
> that uses XUL and here I'm talking about wholly new UI, additions to
> browser.xul and other existing UI are a separate concern. What do folks
> think about making this a rule for new projects in the near future?
>
> Of course there are some features missing from HTML that make this
> impossible in some cases right now. Some that I've already found:
>
> * HTML has no support for popup panels like XUL does. The devtools team
> have been working around this but they are still dependent on XUL right now.
> * iframe elements don't have the same capabilities that the XUL browser
> element does and we use that in some UI.
> * Top level menus on OSX are currently only able to be defined with XUL
> elements. This only affects UI that uses top-level windows and most of our
> new UI is in-content so may be less of an issue.
>
> What other features do we depend on in XUL that I haven't listed?
>
> ___
> 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: GPU Process Experiment Results

[Chris Hutten-Czapski]

My one-sentence summary of the article - If anything, the test cohort with
the GPU process saw improved stability, especially for graphics crashes.

Which is awesome!

May need error bars for the figures to see how much of the results you saw
we might have to attribute to the noise of reported crash figures.

Also, I can't quite tell what the units are. The initial graphs seem to be
#crashes-reported-to-Socorro, but later ones talk of
#crashes-per-1000-usage-hours. The axes aren't labelled, so it's difficult
to be precise.

Have you attempted to measure crash counts and types via Telemetry instead
of Socorro? If all you need is a count and some metadata, the submission
rate to Telemetry is much (25x) higher than Socorro. (actually, if all you
need is a count, crash_aggregates would be a good place to start, as most
of the counting has been done for you).

All in all, very interesting and I can't wait to see future experiments in
Aurora and on Beta, when the time is right.

:chutten


On Mon, Jan 16, 2017 at 4:11 PM, Anthony Hughes  wrote:

> Hello Platform folks,
>
> Over the Christmas break I rolled out a Telemetry Experiment on Nightly to
> measure the stability impact of the GPU Process. This experiment concluded
> on January 11. Having had time to analyze the data I've published a report
> on my blog:
> https://ashughes.com/?p=374
>
> It should come up on Planet shortly but I wanted to post here for increased
> visibility. Feel free to send me questions, comments, and feedback.
>
> Cheers
>
> --
> Anthony Hughes
> Senior Quality Engineer
> Mozilla Corporation
> ___
> 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

GPU Process Experiment Results

[Anthony Hughes]

Hello Platform folks,

Over the Christmas break I rolled out a Telemetry Experiment on Nightly to
measure the stability impact of the GPU Process. This experiment concluded
on January 11. Having had time to analyze the data I've published a report
on my blog:
https://ashughes.com/?p=374

It should come up on Planet shortly but I wanted to post here for increased
visibility. Feel free to send me questions, comments, and feedback.

Cheers

-- 
Anthony Hughes
Senior Quality Engineer
Mozilla Corporation
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Deprecating XUL in new UI

[smaug]

On 01/16/2017 10:43 PM, Dave Townsend wrote:

One of the things I've been investigating since moving back to the desktop
team is how we can remove XUL from the application as much as possible. The
benefits for doing this are varied, some obvious examples:

* XUL is a proprietary standard and we barely maintain it.
* Shallower learning curve for new contributors who may already know and
use HTML.
* HTML rendering is more optimized in the platform than XUL.


But XUL has prototype cache which makes for parsing faster and opening new 
windows even faster
since one needs to just clone from the prototype, and not load anything.
So, be careful with the performance numbers.



* Further integration of Servo code may require dropping XUL altogether.

The necessary first step of reducing XUL use is to stop adding any more UI
that uses XUL and here I'm talking about wholly new UI, additions to
browser.xul and other existing UI are a separate concern. What do folks
think about making this a rule for new projects in the near future?

Of course there are some features missing from HTML that make this
impossible in some cases right now. Some that I've already found:

* HTML has no support for popup panels like XUL does. The devtools team
have been working around this but they are still dependent on XUL right now.
* iframe elements don't have the same capabilities that the XUL browser
element does and we use that in some UI.
* Top level menus on OSX are currently only able to be defined with XUL
elements. This only affects UI that uses top-level windows and most of our
new UI is in-content so may be less of an issue.

What other features do we depend on in XUL that I haven't listed?


templates? xul:tree? I guess both those can be implemented in JS too, just 
possibly not as efficiently.



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

Deprecating XUL in new UI

[Dave Townsend]

One of the things I've been investigating since moving back to the desktop
team is how we can remove XUL from the application as much as possible. The
benefits for doing this are varied, some obvious examples:

* XUL is a proprietary standard and we barely maintain it.
* Shallower learning curve for new contributors who may already know and
use HTML.
* HTML rendering is more optimized in the platform than XUL.
* Further integration of Servo code may require dropping XUL altogether.

The necessary first step of reducing XUL use is to stop adding any more UI
that uses XUL and here I'm talking about wholly new UI, additions to
browser.xul and other existing UI are a separate concern. What do folks
think about making this a rule for new projects in the near future?

Of course there are some features missing from HTML that make this
impossible in some cases right now. Some that I've already found:

* HTML has no support for popup panels like XUL does. The devtools team
have been working around this but they are still dependent on XUL right now.
* iframe elements don't have the same capabilities that the XUL browser
element does and we use that in some UI.
* Top level menus on OSX are currently only able to be defined with XUL
elements. This only affects UI that uses top-level windows and most of our
new UI is in-content so may be less of an issue.

What other features do we depend on in XUL that I haven't listed?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

[Firefox Desktop] Issues found: January 9th to January 13th

[Cornel Ionce]

Hi everyone,


Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, *January 09 - January 13* (week 2).


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
1330333  	draw_instanced_ubo demo not 
displayed on macOS Sierra with AMD graphics 	Core 	Canvas: WebGL 	NO 
NOBODY
1330334  	Animation for buffer_uniform test 
not working on some mac 	Core 	Canvas: WebGL 	NO 	NOBODY
1330979  	Drag & drop files no longer works 
on onedrive.com 	Core 	Canvas: WebGL 	YES 
 
	Michael Layzell 




*AURORA CHANNEL*
ID  Summary Product Component   Is a regression 
Assigned to
1329922  	[DTMF] Tones are not heard when 
duration is set to lowest (70) 	Core 	WebRTC: Audio/Video 	NO 	David 
Minor 
1330350  	The "mediaDevices.ondevicechange" 
devices counter is faulty 	Core 	WebRTC: Audio/Video 	NO 	NOBODY
1330653  	Headphone plug / unplug events are 
not registered on Mac OS for mediaDevice.ondevicechanges 	Core 	WebRTC: 
Audio/Video 	NO 	NOBODY




*NIGHTLY CHANNEL
*
ID  Summary Product Component   Is a regression 
Assigned to
1330967  	Can't open Statistics view through 
request-list context menu if its open and closed for several times 
Firefox 	Developers Tools: Netmonitor 	YES 
 
	Steve Chung 
1330998  	NPAPI plugins can still be enabled 
in Nightly 53 	Core 	Plugins 	TBD 	NOBODY


*
*
**ESR CHANNEL*
*none*

*Regards,
Cornel Ionce
Team Lead
SOFTVISION

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


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