On Jun 18, 2014, at 2:03 AM, Vivien Nicolas <vnico...@mozilla.com> wrote:
> > 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. Please profile this. I am sure this can be optimized. We likely don’t need to involve xpconnect here for starters. Thanks, Andreas > >> >> 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 >> > > _______________________________________________ > b2g-internal mailing list > b2g-inter...@mozilla.org > https://mail.mozilla.org/listinfo/b2g-internal _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
