Re: HTML-based chrome and

[Vivien Nicolas]

On Mon, Feb 29, 2016 at 2:21 PM, Benjamin Francis 
wrote:

> On 26 February 2016 at 21:26, Ehsan Akhgari 
> wrote:
>
> > Without intending to start a shadow discussion on top of what's already
> > happening on the internal list (sadly), to answer your technical
> > question, the "platform"/Firefox point is a false dichotomy.  As an
> > example, you can create a new application target similar to browser,
> > b2g/dev or mobile/android, select that using --enable-application, and
> > start to hack away.  That should make it possible to create a
> > non-Firefox project on top of Gecko.  You can use an HTML file for
> > browser.startup.homepage, and you can use  if you
> > need to load Web content.  So it's definitely possible to achieve what
> > you want as things stand today.
> >
>
> OK, so to follow this logic in the case of B2G, your recommended solution
> would be to transform /b2g/chrome/content/shell.html [1] into a replacement
> for Gaia's system app and land that code directly in mozilla-central?
>
> That could potentially work for the B2G use case and would remove an entire
> layer from the architecture which sounds great. But it would mean putting
> that code in mozilla-central rather than a completely separate project on
> GitHub.
>
>

If you look at Planula source code you will see that it basically runs on
top of Firefox Nightly, replacing browser.xul by a custom HTML file, using
 to load web content. Planula is also a separate github
project.

At the end it's not perfect, nor the most ideal situation, but at least you
can start to prototype a new browser, or anything else, without having to
rebuild m-c every time. (hint: you can basically use F5 to refresh the
whole UI).

That said, if you want to build a full featured web browser, with only HTML
technologies, you may have to deal with some internal details of Gecko. You
can bypass some of it with the right set of hand-crafted addons (look at
config/profile/extensions/zyzzyva). Some others details will force part of
you architecture to be exactly how Gecko expects the front-end to be
formatted (e.g having an iframe with the type content-primary in your
startup page, or exposing a gBrowser global in some cases...) but you can
really go very far if you want to build a browser and follow what Alexandre
and myself have done with Planula.

You may also needs a few set of patches to apply to Gecko to allow your
front-end to load the devtools, or use about: pages. But most of those are
pretty small and scoped patches that should not be too hard to uplift
upstream.

Again Planula is mostly designed to explore part of Firefox that can be
replaced without the help of XUL/XPCOM and see how much can be really
achieved with such technologies that trying to simulate a full-featured
Electron clone (which would be cool but seems a lot of work with a lot of
resources dedicated to it from various teams, and seems unrealistic with
the current focus from MoCo).

While Planula goal is to try to land some parts of it into browser/ and
toolkit/, you can already start to prototype something right away without
the need to hit m-c.

Vivien.


> Ben
>
> 1.
>
> https://dxr.mozilla.org/mozilla-central/source/b2g/chrome/content/shell.html
> ___
> 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: HTML-based chrome and

[Vivien Nicolas]

Just to make things clearer.

Planula is not doing exactly what you proposed. It does not tries at all to
emulate Electron, nor provide the same set of APIs. It does not try to be
an HTML app-runtime neither.

Planula is an HTML browser experiment, running on top of *Firefox Nightly*
(with a very small subset of patches that I need to upload to the repo...).
It does not implies a new permission model, nor new APIs. Though it rely on
mozbrowser iframes.

Planula aims to be a very small shell around iframe mozbrowser. No features
are really built-in, except tabs and an urlbar. The plan is to implement
*all* features as WebExtensions. In this context a feature means: a
download manager, a bookmark button + a bookmark manager, Firefox Hello,
etc..

Basically I would like Planula to be a kind of dedicated sandbox to migrate
Firefox bits out of XUL/XPCOM in an incremental manner. For example, this
kind of sandbox can let us implement a particular feature (e.g the bookmark
button) with pure web technologies, and then try to backport it to Firefox
itself as a self-contained WebExtension.

This is why Planula re-use as much as possible from Firefox, such as about:
pages, devtools, etc...

If Planula is ever maintained or used for what it is designed for, one of
the last thing to do would be to convert  to . This will require a bit of plumbing (parts of it beeing
already done in bug 1238160 as jryan mentioned).

Vivien.

On Wed, Feb 24, 2016 at 9:19 PM, Benjamin Francis 
wrote:

> Hi,
>
> I've been thinking about working towards deprecating "Open Web Apps" (aka
> mozApps
> <
> https://developer.mozilla.org/en-US/docs/Mozilla/Firefox_OS/API/Navigator/mozApps
> >)
> in Gecko.
>
> For the most part I think mozApps should eventually be replaced by
> standards-based web apps using Web Manifest, Service Workers etc. I'd love
> to see a standalone display mode for Firefox which supports these web apps
> on desktop and mobile to replace the now defunct web runtime, but that's
> not what this email is about.
>
> For the most privileged pieces of UI like the browser chrome of the
> browser.html project and the Firefox OS system app I think we may need
> another solution. I'd like us to be able to split Gaia
>  into chrome (the system pieces) and
> standard web content (everything else). (I'd also like to see a lot of the
> current mozApps-only DOM APIs become web services).
>
>- In the past we had XULRunner but this has recently been removed and it
>seems the continued use of XUL is being discouraged in favour of HTML.
>- There was an attempt at rebooting the Chromeless project
> but it looks like that was
>still based on XULRunner.
>- The browser.html 
> project
>currently uses Graphene
><
> https://github.com/browserhtml/browserhtml/wiki/Building-Graphene-%28Gecko-flavor%29
> >,
>a build of Gecko/Servo which runs locally hosted web content as browser
>chrome, but that's based on certified mozApps and the mozBrowser API.
>
> After chatting with members of the browser.html team I'd like to propose a
> solution inspired by Electron  (which they
> already proposed 
> before ). This would involve a
> new type of HTML-based chrome including a new  element.
>
> Kan-Ru previously did a comparison
>  of Mozilla's
> mozBrowser API, Google's  and Microsoft's  and I started
> to spec something out  with a view
> to potentially standardising this, but the web lacks the security model
> needed to expose this API and there's currently not much interest in a
> standard. So my proposal is a chrome-only  element for Gecko which
> would replace the mozApps-only mozBrowser API
> ,
> along the lines of Electron's  element
> , to allow you to
> safely embed web content in an application with HTML-based chrome.
>
> We could also potentially emulate other parts of Electron's APIs too, see
> their quick start tutorial
>  to get an
> idea
> of how their embedding works.
>
> Initially this would be used by the browser.html and Firefox OS projects,
> but I think it could be a possible route away from XUL for Firefox in the
> future too.
>
> I've chatted with a few people working on browser.html and Firefox OS about
> this, but I'd like to get broader feedback. Vivien told me he's already
> prototyping a similar solution  to
> the same problem so I'd like to kick off some discussion here about which
> direction we should take.

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

[Vivien Nicolas]

Thanks for the information.

On Sat, Nov 28, 2015 at 7:02 AM, Boris Zbarsky <bzbar...@mit.edu> wrote:

> On 11/27/15 5:33 AM, Vivien Nicolas wrote:
>
>> But don't we need at least a Flush_Style to make sure the CSS that tries
>> to
>> use background-image will start triggering images decoding and block the
>> onload event ?
>>
>
> Yes, we do.  That's handled in nsDocLoader::DocLoaderIsEmpty.
>
> -Borsi
>
> ___
> 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: ESLint is now available in the entire tree

[Vivien Nicolas]

On Sun, Nov 29, 2015 at 2:30 PM, David Bruant  wrote:

> Hi,
>
> Just a drive-by comment to inform folks that there is an effort to
> transition Mozilla JavaScript codebase to standard JavaScript.
> Main bugs is: https://bugzilla.mozilla.org/show_bug.cgi?id=867617
>
> And https://bugzilla.mozilla.org/show_bug.cgi?id=1103158 is about
> removing non-standard features from SpiderMonkey.
> Of course this can rarely be done right away and most often requires
> dependent bugs to move code to standard ECMAScript (with a period with
> warnings about the usage of the non-standard feature).
>

What about .jsm modules ? Or is that not really considered ?

I have been told that ES6 modules may help to solve some of the problems
covered by .jsm but I don't see how you can create a ES6 module that is can
be accessed from multiple js context from the same origin. Mostly
interested as it would be nice to be able to write a module once and share
it between multiple tabs instead of having to reload the same JS script for
all similar tabs, like all the bugzilla tabs many of us have open for
example.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

[Vivien Nicolas]

It may be a stupid question as my understanding of this part of the code is
flaky.

But don't we need at least a Flush_Style to make sure the CSS that tries to
use background-image will start triggering images decoding and block the
onload event ?

I just want to make sure it won't create flickering effects when app author
tries to reveal their page content after the onload event.


On Fri, Nov 27, 2015 at 8:29 AM, Xidorn Quan  wrote:

> On Fri, Nov 27, 2015 at 6:15 PM, Axel Hecht  wrote:
> > On 11/27/15 4:09 AM, Robert O'Callahan wrote:
> >>
> >> On Fri, Nov 27, 2015 at 3:59 PM, Boris Zbarsky 
> wrote:
> >>
> >>> On 11/26/15 9:24 PM, Robert O'Callahan wrote:
> >>>
>  We've always done it, but I can't think of any good reasons.
> 
> >>>
> >>> I've tried to fix this in the past and ran into two problems.
> >>>
> >>> The first problem was that some tests failed as a result.  This is
> >>> somewhat minor, really.
> >>>
> >>> The second problem, pointed out by the first, is that some tests
> stopped
> >>> testing what they mean to be testing, because all of our reftests and
> >>> crashtests assume layout gets flushed onload, so they can test dynamic
> >>> behavior by doing stuff after that.
> >>>
> >>> See https://bugzilla.mozilla.org/show_bug.cgi?id=581685 for details.
> I
> >>> haven't had a chance to get back and really figure this out, though we
> >>> should.
> >>
> >>
> >>
> >> Mmmm. This could be a significant win!
> >>
> >> Rob
> >>
> >
> > I wonder, how much of the web could rely on this, given our tests do?
>
> I don't think the web would be affected by this change, because if the
> page do something in onload which requires a layout, the layout would
> always happen no matter whether we do this in advance.
>
> Our tests relying on this is probably because certain bugs are only
> detectable when we apply content/style change after a layout flush.
>
> - Xidorn
> ___
> 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: Allowing web apps to delay layout/rendering on startup

[Vivien Nicolas]

Is there any concerns about the solution I'm proposing or should I move
forward ?

On Fri, Oct 16, 2015 at 12:29 PM, Vivien Nicolas <vnico...@mozilla.com>
wrote:

>
>
> On Thu, Oct 8, 2015 at 6:10 PM, Mounir Lamouri <mou...@lamouri.fr> wrote:
>
>> Note that Chrome 46 has a way to work around the white screen while a
>> page load using a new property in the Manifest. If a website added to
>> the homescreen on Chrome Android has a background_color information, it
>> will be used while the page loads. After Chrome gets the first paint
>> following a non-empty layout, it will remove that plain colour and
>> switch to whatever the page has ready. It allows websites to be
>> constructed as websites and not rely on that splashscreen feature that
>> might or might not be present (given the UA and the current context) and
>> also keep the principle of quick first paint.
>>
>> Would using a similar system (ie. background_color from the Manifest)
>> help you here?
>>
>
> For what it worth, I have started to play with background_color in bug
> 1215077.
>
> It looks cool, and I really like it. But because of the FirefoxOS UX which
> displays an icon on top of the defined background color, it is not enough
> by itself for most apps.
>
> For example with the calendar app, we will end up with:
>  - Orange background with Calendar icon in the middle
>  - Orange background from the app without an icon (the app can likely add
> that but it starts to become very UA specific)
>  - App content.
>
> But generally it is nice and I would like to support that on FirefoxOS.
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Allowing web apps to delay layout/rendering on startup

[Vivien Nicolas]

On Thu, Oct 8, 2015 at 6:10 PM, Mounir Lamouri  wrote:

> Note that Chrome 46 has a way to work around the white screen while a
> page load using a new property in the Manifest. If a website added to
> the homescreen on Chrome Android has a background_color information, it
> will be used while the page loads. After Chrome gets the first paint
> following a non-empty layout, it will remove that plain colour and
> switch to whatever the page has ready. It allows websites to be
> constructed as websites and not rely on that splashscreen feature that
> might or might not be present (given the UA and the current context) and
> also keep the principle of quick first paint.
>
> Would using a similar system (ie. background_color from the Manifest)
> help you here?
>

For what it worth, I have started to play with background_color in bug
1215077.

It looks cool, and I really like it. But because of the FirefoxOS UX which
displays an icon on top of the defined background color, it is not enough
by itself for most apps.

For example with the calendar app, we will end up with:
 - Orange background with Calendar icon in the middle
 - Orange background from the app without an icon (the app can likely add
that but it starts to become very UA specific)
 - App content.

But generally it is nice and I would like to support that on FirefoxOS.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Allowing web apps to delay layout/rendering on startup

[Vivien Nicolas]

There should be an answer in the middle. Showing something as soon as
possible is best iif it not a half baked part of the UI.
So for example showing the navigation chrome first is good, if it is not
rebuilding right after. Then showing the app content.

But I'm not convinced any of us is the best to answer this UX question and
this is likely the subject of a separate thread.

On Sat, Oct 10, 2015 at 1:27 PM, Mounir Lamouri  wrote:

> On Sat, 10 Oct 2015, at 02:02, zbranie...@mozilla.com wrote:
> > On Friday, October 9, 2015 at 10:51:54 AM UTC-7, Mounir Lamouri wrote:
> > > As far as speed feeling goes, they would win to show something as soon
> > > as possible and handle any post-first paint loading themselves.
> >
> > That is unfortunately not consistent with my experience. People tend to
> > perceive visible progressive as much slower than delayed first-paint in
> > most scenarios.
> >
> > On top of that, it is perceived as a really_bad_ux.
>
> I don't think I agree but I don't mean to discuss Firefox OS product
> decisions.
>
> -- Mounir
> ___
> 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: Allowing web apps to delay layout/rendering on startup

[Vivien Nicolas]

On Thu, Oct 8, 2015 at 6:10 PM, Mounir Lamouri  wrote:

> Note that Chrome 46 has a way to work around the white screen while a
> page load using a new property in the Manifest. If a website added to
> the homescreen on Chrome Android has a background_color information, it
> will be used while the page loads. After Chrome gets the first paint
> following a non-empty layout, it will remove that plain colour and
> switch to whatever the page has ready. It allows websites to be
> constructed as websites and not rely on that splashscreen feature that
> might or might not be present (given the UA and the current context) and
> also keep the principle of quick first paint.
>

> Would using a similar system (ie. background_color from the Manifest)
> help you here?
>


I will be happy to use the background_color field in the manifest. It will
likely help web app pinned to the homescreen.
I also think it will be a great idea to use it to replace the static black
color that is displayed before applications are launched and try to unify
the experience between installed apps and pinned apps.

However while I think background_color is useful, the white flash we are
trying to address here is between the splash screen and the app content
beeing loaded. I think, but I may be wrong, that we don't want to have a 3
steps startup with:
 1. Black splashscreen with icon
 2. plain background_color instead of a white flash
 3. App content beeing displayed when ready.

I guess 1. and 2. can be merged.

Now the issue, if my understanding is correct, Gecko does not have the
notion of firstpaint after a non-empty layout. Which means even if 1. and
2. are merged we can end up in a situation where you have:
 1./2. background_color with/without icon
 3. white flash
 4. App content beeing displayed when ready.

So basically what I want to add in bug 1211853 (first attachement) is (a
very simple) mechanism to not paint until there is something to paint. And
from here provide a mechanism for web app to control when first paint
happens without enforcing them to be built a specific way.

As James mentioned, background_color may also be tricky to used for
applications with dynamic first page. For instance if you want to have a
setup page with a different background color than the rest of your
application. That said I still believe it can be useful for the vast
majority of apps.

An other constraints for application with multi-steps startup is to display
something as quick as possible to the user and continue their execution
after first paint. As of today there is no way (at least in Gecko, dunno
for Chrome) to know when the UA has painted something on the screen. I
would like to introduce a (moz)firstpaint event so app authors can optimize
their app to quicly show something on the screen, then wait for the UA to
paint, and then continue their execution.

Vivien.


>
> -- Mounir
>
> On Wed, 7 Oct 2015, at 14:17, vnico...@mozilla.com wrote:
> > I also forgot to say that the proposed solution does not help for cases
> > like bug 1199674 afaict.
> > ___
> > 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

Re: Icon fonts in FxOS

[Vivien Nicolas]

On 06/17/2014 09:18 PM, James Burke wrote:

On 6/17/14, 10:08 AM, Vivien Nicolas wrote:
That's true. Actually there are many other hacks that depends on the 
fact that application are certified. So even if I would like to have 
more apps as privileged apps just for the principle, it's not that 
simple. And we may need to reconsider the |privileged| status of the 
email app based on some of the use case on some low end devices for now.


So one of the only reason the email app has been made |privileged| is 
for some CSP compliance things, and because it does not needs APIs 
that are certified-only. But we may need to keep it certified for 
perf reasons if needed. It will depends on the impact of icon font there.


I appreciate there are always tradeoffs, but I also want to caution 
against just proceeding because there is an escape value via 
certified. We have a train model, and if it takes another train to 
avoid certified-only, all apps benefit. It is already disconcerting 
that just switching the type value in the manifest from certified to 
privileged, we see a 20ms slowdown[1].


TBH I'm not surpised. We (re)discovered last september/october that the 
CSP in JS was consuming a lot of startup time. Not because the JS code 
was slow, but because of 1 xpconnect call per file, and apps loads a lot 
of files.


So for certified app, we landed a fast path. It would be good to 
investigate if this is purely related to the CSP or not, by simply 
disabling it (security.csp.enable = false), and if yes, investigate if 
reducing the number of files by aggregating them helps.




The greater concern is these certified escapes build up, and then 
taking the time to undo them later eats into the next certified escape 
that is wanted, so the gap will continue to grow. A good way to start 
fighting the issue is to stop adding to the pile.




It's true that this is a big concern. The greater concern is that the 
web platform is not competitive / successful. So in order to mitigate 
some of the issues, that are always solvable but takes time, we adding 
to the pile. We know that at some point we have to pay the cost, and we 
always try to not take this path - sadly sometimes there is no other 
choice for a given release, and then we need to add to the pile.



On icon fonts, it would be good to make sure there implemented with 
accessibility in mind. This document[1] talks about that, and mentions 
a Firefox bug[2] about aria-hidden that may need some attention if 
icon fonts are used in buttons.


[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1024005
[2] http://filamentgroup.com/lab/bulletproof_icon_fonts.html
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=948540

James



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

Re: Icon fonts in FxOS

[Vivien Nicolas]

On 06/16/2014 09:34 PM, Jet Villegas wrote:

Hi All:

We need a path forward on the deployment of Icon fonts in FxOS. The Gaia team 
understandably wants to squeeze every bit of performance on their apps in v1.4:
https://bugzilla.mozilla.org/show_bug.cgi?id=951593

We are concerned about leaking these fonts into Open Web content, so we want to 
restrict it to certified Gaia apps:
https://bugzilla.mozilla.org/show_bug.cgi?id=1008458

The approach we take to restrict icon fonts to certified Gaia apps is under 
some debate, and we've got 4 possibilities:

1. Let people use the icon fonts anywhere. (ie. like MS WingDings can be used 
for this purpose)
2. The patch in bug 1008458 introduces private fonts that use the Unicode 
Private Use Area (PUA) for icon glyphs.
3. Use PUA characters as per bug 1008458 but disable use of PUA characters in 
local fonts on all platforms except for FirefoxOS certified apps.
4. Use the OpenType discretionary ligatures (dlig) feature to hide the glyphs 
( see https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22 )

I'm afraid of the amount of code in the patch for bug 1008458 for the 1.4 
release, so I'm inclined to let the Gaia team use the icon font as-is (option 
1) with the promise that they won't use it in uncertified non-system apps.

I also propose that we make any required code changes in v2.0 so that 
non-certified apps can't get unrestricted use of the font. All the options 
proposed (#2,3, or 4,) have drawbacks, the common one being that they may be 
overly restrictive.

I'd like some feedback here, first on my proposal that we go with Option 1 for 
1.4. Second, I'd like us to solve the font leakage problem for 2.0 with one of 
the 3 other proposals, if still needed--I'd like to see how far we get to 
improve SVG performance (bug 31) to make all this a moot point. I really am 
not a fan of icon fonts (see 
https://twitter.com/73inches/status/468368206282113024/photo/1 )


Ideally we would like to use SVG instead of Icon Fonts in Gaia for many 
use cases. But I believe the SVG performance won't be as good an Icon 
Font baked into the platform in the 2.1 timeframe.


3 seems agressive. PUA has always worked on the web AFAIK and it's 
unclear to me why we want to changed this.
4 seems like an obfuscation mechanism, which is smart, but won't prevent 
what 2 and 3 try to prevent, which is leaking our glyphs on the web.


I'm not saying I like 2 - it always sad when we have to do a 
certified-only hack - but it seems the cleaner approach as it draw a 
clear line between regular and this private font without regressing 
things that already works, or trying to hide the feature even if it works.


Then once SVG would be good enough, yes I believe we will use it.

Vivien.



Thanks,

--Jet


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

Re: Icon fonts in FxOS

[Vivien Nicolas]

On 06/17/2014 06:01 PM, Wilson Page wrote:
Just to clarify: I am in favor of icon-fonts, but less baking them 
into the system. Do we have perf figures comparing normal @font-face 
loading (external or inlined) compared to the baked in solution?


Yeah, looked at comment 37 of bug 948856. Between not baking it, and 
baking it, there is a 500ms diff :/





*From: *Vivien Nicolas vnico...@mozilla.com
*To: *Wilson Page wilsonp...@mozilla.com, Jonathan Kew 
j...@mozilla.com
*Cc: *Jet Villegas j...@mozilla.com, Patryk Adamczyk 
padamc...@mozilla.com, John Daggett jdagg...@mozilla.com, 
b2g-internal b2g-inter...@mozilla.org, Cameron McCormack 
hey...@gmail.com, Jonathan Watt jw...@mozilla.com, L. David 
Baron dba...@mozilla.com, Jaime Chen jac...@mozilla.com, 
sicking sick...@mozilla.com, Robert O'Callahan 
rocalla...@mozilla.com, mozilla.dev.platform group 
dev-platform@lists.mozilla.org

*Sent: *Tuesday, June 17, 2014 4:48:19 PM
*Subject: *Re: Icon fonts in FxOS

Just want to make sure that there is no misunderstanding here: based 
on the data from 
https://bugzilla.mozilla.org/show_bug.cgi?id=948856#c37, some 
experience with loading icon fonts versus images versus svg that has 
been described on dev-gaia, *preloading the font is needed*.


On 06/17/2014 12:52 PM, Wilson Page wrote:

I'm inlining to minimise cross-origin issues and to reduce
requests. The entire asset is 12k so I'm really not concerned
with performance here, especially considering the number of PNG
assets this replaces. We've been using a similar approach in
Camera for quite some time and all has been well. I think there
are better areas we can focus performance efforts.


Performance is not always related to the size of the asset. For 
example last time I found that we consume 2.4mb of memory all the time 
in the System app because we were loading 4 times an image asset of 
3k. Every time this asset was rendered it was consuming 600k of 
memory. This asset was a gradient and it was expensive to render it.


When you consider the size of the asset in this case, you should also 
consider at which time it is read, if is it going to trigger some 
invalidations because the image will arrive after the app is rendered, 
how long will it take for the font subsystem to render those glyphs, 
can we save some memory by using some system features, instead of 
having a local copy in all apps, etc...


I'm not exactly sure if glyphs are still assigned to code points
within the generated font, is that an issue?

IMO we should just treat icon assets in the same way we do images
assets.


Image assets may be slow. We run into this issue multiple times in the 
Settings app. Replacing our current image assets icons with an icon 
font baked into the platform shave ~300ms of load time.


Baking them into the platform seems like it could cause
unnecessary complications further down the line, for negligible
perf gains.


Obviously 300ms is not negligible :)

Also in terms of memory there is an impact too, and since we're 
targeting very low end devices, I expect this to be useful too.
The current mechanism used by Gecko to discard images help us to 
reduce the memory overhead here for background apps, but it has the 
side effect that the image needs to be re-decoded when the app goes to 
foreground and it takes time (you see images flashes when the images 
are re-decoded / repainted).


So icon font would make some apps to load faster, consume less memory, 
and avoid some glitches when the app goes from background to 
foreground. Definitively not negligible.


At the end of the day we're a collection of web-apps, the more we
exploit our platform power, the further we distance ourselves from
the real web platform.


What you say here is true. And we would all like to use only simple 
web features, and that's definitively the goal.
But while we are heading up to this goal, we sometimes needs to do 
some trade-offs, and using icon fonts is one of them. It does not mean 
there is more distance from the real web platform, as I believe that 
while Gaia use icon fonts, a lot of efforts will be done on the svg 
side in order to replace the icon font with SVG when it will be time 
to do so.


So you should see that as: it makes us more competitive in this 
extremely competitive area, and offers us a bit more time to fix the 
real issue, which is that SVG does not fit yet, and beside that, to 
fix the web platform to make it becomes reals on mobile.


Vivien.

W.


*From: *Jonathan Kew j...@mozilla.com
*To: *Wilson Page wilsonp...@mozilla.com, Jet Villegas
j...@mozilla.com
*Cc: *Patryk Adamczyk padamc...@mozilla.com, John Daggett
jdagg...@mozilla.com, b2g-internal b2g-inter...@mozilla.org,
Cameron McCormack hey...@gmail.com, Jonathan

Re: Icon fonts in FxOS

[Vivien Nicolas]

On 06/17/2014 06:51 PM, Jonathan Kew wrote:

On 17/6/14 17:02, Vivien Nicolas wrote:


On 06/17/2014 06:01 PM, Wilson Page wrote:
Just to clarify: I am in favor of icon-fonts, but less baking them 
into the system. Do we have perf figures comparing normal @font-face 
loading (external or inlined) compared to the baked in solution?


Yeah, looked at comment 37 of bug 948856. Between not baking it, and 
baking it, there is a 500ms diff :/


If I'm reading bug 948856 correctly, the difference may have been 
somewhat less (150ms? comment 17) when the font was inlined in the CSS 
using a data URI, rather than loaded from a separate file.


The 150ms is going from gif - icon font if I read correctly too. And 
moving it into moztt was 10 ms better.


It seems somewhat different than what is state in comment 37, which says:

3- Replacing gif with icon font with the font in shared/style (median: 1595)
4- Replacing gif with icon font with the font in system/fonts (median: 1010)


It worth double checking the time here.



If we can't afford that, then we still need some other solution here.

But jburke said that we're generally downgrading apps from certified 
to privileged as much as possible. If the system-installed icon font 
were available only to certified apps, would this adequately address 
the issue? Any Gaia apps that go from certified to privileged would 
need to adopt a separate (lower-perf) approach at that point.




That's true. Actually there are many other hacks that depends on the 
fact that application are certified. So even if I would like to have 
more apps as privileged apps just for the principle, it's not that 
simple. And we may need to reconsider the |privileged| status of the 
email app based on some of the use case on some low end devices for now.


So one of the only reason the email app has been made |privileged| is 
for some CSP compliance things, and because it does not needs APIs that 
are certified-only. But we may need to keep it certified for perf 
reasons if needed. It will depends on the impact of icon font there.


This could be solved by roc's suggestion of providing the font through 
@font-face with a public mozilla URL, which the platform then 
recognizes and special-cases to use a locally preinstalled copy 
instead, but I'm not really comfortable with making all this dependent 
on a public URL (which we're then obligated to maintain forever, so as 
not to break other people's apps that may start to depend on it). I'd 
prefer a solution that is purely an internal optimization in the FxOS 
device, and not exposed to the Web at all.


For certified apps, we could do that; but if it needs to be available 
to non-certified Gaia apps as well, it's less clear how we can handle 
this. We could extend use of the private font to privileged as well 
as certified apps, but does that make it too public to be healthy? 
It still wouldn't be leaking to the general Web, but we might find 
that a lot of 3rd-party apps start to depend on it, and thus risk 
breaking any time we want to revise it for Gaia (or switch Gaia to 
some completely different solution such as SVG images).




For the moment, I think we should just consider |certified| app.


JK






*From: *Vivien Nicolas vnico...@mozilla.com
*To: *Wilson Page wilsonp...@mozilla.com, Jonathan Kew 
j...@mozilla.com
*Cc: *Jet Villegas j...@mozilla.com, Patryk Adamczyk 
padamc...@mozilla.com, John Daggett jdagg...@mozilla.com, 
b2g-internal b2g-inter...@mozilla.org, Cameron McCormack 
hey...@gmail.com, Jonathan Watt jw...@mozilla.com, L. David 
Baron dba...@mozilla.com, Jaime Chen jac...@mozilla.com, 
sicking sick...@mozilla.com, Robert O'Callahan 
rocalla...@mozilla.com, mozilla.dev.platform group 
dev-platform@lists.mozilla.org

*Sent: *Tuesday, June 17, 2014 4:48:19 PM
*Subject: *Re: Icon fonts in FxOS

Just want to make sure that there is no misunderstanding here: based 
on the data from 
https://bugzilla.mozilla.org/show_bug.cgi?id=948856#c37, some 
experience with loading icon fonts versus images versus svg that has 
been described on dev-gaia, *preloading the font is needed*.


On 06/17/2014 12:52 PM, Wilson Page wrote:

I'm inlining to minimise cross-origin issues and to reduce
requests. The entire asset is 12k so I'm really not concerned
with performance here, especially considering the number of PNG
assets this replaces. We've been using a similar approach in
Camera for quite some time and all has been well. I think there
are better areas we can focus performance efforts.


Performance is not always related to the size of the asset. For 
example last time I found that we consume 2.4mb of memory all the 
time in the System app because we were loading 4 times an image 
asset of 3k. Every time this asset was rendered it was consuming 
600k of memory. This asset was a gradient and it was expensive to 
render it.


When you consider