Re: Intent to ship: Changing default Japanese fonts to modern fonts

[Masayuki Nakano]

Ah, yes, this change is only on Windows (only on Windows, we still use 
legacy Japanese fonts as default settings).
FYI: We still need to keep using legacy "MS Gothic" font for default 
Japanese monospace font since Windows doesn't have modern monospace font.


On 8/24/2017 7:47 AM, ISHIKAWA,chiaki wrote:

Hi,

I use firefox under Windows most of the time, and so it will be very nice.

But obviously this is only for Windows platform, and
does not affect linux or OSX versions. Correct?



On 2017/08/23 14:19, Masayuki Nakano wrote:

Hi,

We decided that we should change our default Japanese fonts from 
legacy "MS PGothic" (sans-serif) and "MS PMincho" (serif) which have 
bitmap glyph to modern "Meiryo" or "Yu Gothic" (sans-serif) and "Yu 
Mincho" (serif).


This has been enabled on Nightly and early Beta since 55 [1].

Then, I removed the |#ifdef EARLY_BETA_OR_EARLIER| in Nightly 
yesterday [2].  I.e., the new default settings are enabled on release 
build starting from 57.


I'd like to introduce some backgrounds:

"Meiryo" is installed on Vista or later (but not installed on Win10 
unless you add Japanese in system language settings). "Yu Gothic" and 
"Yu Mincho" is installed on Win8.1 or later.


Both Edge and Chrome already started to use "Meiryo" as their default 
Japanese fonts. So, using "Meiryo" improves the compatibility between 
browsers and just looks better and is easier to read than bitmap glyph.


One of the reason why we didn't use "Meiryo" as default fonts is, 
"Meiryo" has normal style glyph as italic style glyph. E.g., 
|abc| looks like |abc|, not |a/b/c|. The other browsers have 
this issue, but I see many users who complain about this issue. For 
solving this issue, we added a hack to ignore italic style family of 
"Meiryo" at loading fonts [3]. So, now, Gecko is the only one engine 
which supports italic style Japanese text with default fonts!


On the other hand, there are still some problems.

"Meiryo" has too big internal leading for supporting accent marks of 
Western languages. This causes increasing normal line height than 
other fonts. Additionally, Gecko's normal line height computation is 
not same as the other browsers. Therefore, this may cause 
compatibility issue with the other browsers. For example, our  
allows to scroll its content. Therefore, if user drags text in  
vertically, the text may be scrolled [4].


If we could use "Yu Gothic" as Japanese default font, it'd be really 
nicer except compatibility with the other browsers because it has 
nicer glyph than "Meiryo" ("Meiryo" was designed for UI, not for 
document. Therefore, it was designed as easier to read even if the 
font size is small) and does not have too big leading like "Meiryo".  
However, there is a big problem. Text renderer of Windows has a bug. 
Text of "Yu Gothic" is rendered as too light [5]. So, the contrast 
between text and background color may not be enough for some users. 
Therefore, currently, we use "Yu Gothic" as a fallback font only when 
"Meiryo" isn't available.


Anyway, I believe that this makes 57 look nicer for Japanese users!

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=548311
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1354004
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1351332
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1378065
[5] https://bug548311.bmoattachments.org/attachment.cgi?id=8848439



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




--
Masayuki Nakano 
Software Engineer, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Triage Summary 2017-08-21

[Emma Humphries]

Correcting some links at the bottom of this report:

*Untriaged Bugs in Current Cycle*

Bugs filed since the start of the Firefox 57 release cycle which do not
have a triage decision.

https://mzl.la/2wzJxLP

Recommendation: review bugs you are responsible for
([*
https://bugzilla.mozilla.org/page.cgi?id=triage\_owners.html*](https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html)
)
and make triage decision, or RESOLVE.

*Untriaged Bugs in Current Cycle (57) Affecting Next Release (56)*

Bugs marked status\_firefox56 = affected and untriaged.

https://mzl.la/2wzjHaH

*Enhancements in Release Cycle*

Bugs filed in the release cycle which are enhancement requests, severity
= enhancement, and untriaged.

https://mzl.la/2wzCBy8

​Recommendation: ​product managers should review and mark as P3, P5, or
RESOLVE as WONTFIX.

*High Priority Bugs without Owners*

Bugs with a priority of P1, which do not have an assignee, have not been
modified in the past two weeks, and do not have pending needinfos.

https://mzl.la/2u1VLem

Recommendation: review priorities and assign bugs, re-prioritize to P2,
P3, P5, or RESOLVE.

*Stalled High Priority Bugs*

There 159 bugs with a priority of P1, which have an assignee, but have
not been modified in the past two weeks.

https://mzl.la/2u2poMJ

Recommendation: review assignments, determine if the priority should be
changed to P2, P3, P5 or RESOLVE.

On Mon, Aug 21, 2017 at 4:01 PM, Emma Humphries  wrote:

> It's the weekly report on the state of triage in Firefox-related
> components. I apologize for missing last week’s report. I was travelling
> and did not have a chance to sit down and focus on this.
>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Propose a Treeherder downtime / Tree closure 8/28/17 4:00am PT

[Cameron Dawson]

I have to run a DB migration on Treeherder that will take around 4 hours to 
complete.  And during that time, job ingestion will be paused.  So Treeherder 
will be in maintenance mode during that window.  You won’t be able to even 
query existing data at that time.

Tomcat—  I think you’ll be the Sheriff at that time, perhaps?  Let’s coordinate 
in #sheriff to update Tree Status in that time period.

For Tree Closures, Per Kwierso:

1. Trees that need to be closed: mozilla-central, mozilla-inbound, autoland
2. Trees that probably should be closed: mozilla-beta, mozilla-release, 
mozilla-esr52

After the closure, we will resume data ingestion and will catch up after a 
short bit.  Sorry for the inconvenience.  If this is going to be a BIG 
inconvenience, please let me know and I can try to find a better time window.

Thanks for your understanding,
-Cam
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: Changing default Japanese fonts to modern fonts

[ISHIKAWA,chiaki]

Hi,

I use firefox under Windows most of the time, and so it will be very nice.

But obviously this is only for Windows platform, and
does not affect linux or OSX versions. Correct?



On 2017/08/23 14:19, Masayuki Nakano wrote:

Hi,

We decided that we should change our default Japanese fonts from legacy 
"MS PGothic" (sans-serif) and "MS PMincho" (serif) which have bitmap 
glyph to modern "Meiryo" or "Yu Gothic" (sans-serif) and "Yu Mincho" 
(serif).


This has been enabled on Nightly and early Beta since 55 [1].

Then, I removed the |#ifdef EARLY_BETA_OR_EARLIER| in Nightly yesterday 
[2].  I.e., the new default settings are enabled on release build 
starting from 57.


I'd like to introduce some backgrounds:

"Meiryo" is installed on Vista or later (but not installed on Win10 
unless you add Japanese in system language settings). "Yu Gothic" and 
"Yu Mincho" is installed on Win8.1 or later.


Both Edge and Chrome already started to use "Meiryo" as their default 
Japanese fonts. So, using "Meiryo" improves the compatibility between 
browsers and just looks better and is easier to read than bitmap glyph.


One of the reason why we didn't use "Meiryo" as default fonts is, 
"Meiryo" has normal style glyph as italic style glyph. E.g., 
|abc| looks like |abc|, not |a/b/c|. The other browsers have this 
issue, but I see many users who complain about this issue. For solving 
this issue, we added a hack to ignore italic style family of "Meiryo" at 
loading fonts [3]. So, now, Gecko is the only one engine which supports 
italic style Japanese text with default fonts!


On the other hand, there are still some problems.

"Meiryo" has too big internal leading for supporting accent marks of 
Western languages. This causes increasing normal line height than other 
fonts. Additionally, Gecko's normal line height computation is not same 
as the other browsers. Therefore, this may cause compatibility issue 
with the other browsers. For example, our  allows to scroll its 
content. Therefore, if user drags text in  vertically, the text 
may be scrolled [4].


If we could use "Yu Gothic" as Japanese default font, it'd be really 
nicer except compatibility with the other browsers because it has nicer 
glyph than "Meiryo" ("Meiryo" was designed for UI, not for document. 
Therefore, it was designed as easier to read even if the font size is 
small) and does not have too big leading like "Meiryo".  However, there 
is a big problem. Text renderer of Windows has a bug. Text of "Yu 
Gothic" is rendered as too light [5]. So, the contrast between text and 
background color may not be enough for some users. Therefore, currently, 
we use "Yu Gothic" as a fallback font only when "Meiryo" isn't available.


Anyway, I believe that this makes 57 look nicer for Japanese users!

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=548311
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1354004
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1351332
[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1378065
[5] https://bug548311.bmoattachments.org/attachment.cgi?id=8848439



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

Re: JavaScript Binary AST Engineering Newsletter #1

[Jim Blandy]

Can code transmitted as an AST be source-mapped, so that developer tools
can work properly?

On Fri, Aug 18, 2017 at 4:39 AM, David Teller  wrote:

> Hey, all cool kids have exciting Engineering Newsletters these days, so
> it's high time the JavaScript Binary AST got one!
>
>
> # General idea
>
> JavaScript Binary AST is a joint project between Mozilla and Facebook to
> rethink how JavaScript source code is stored/transmitted/parsed. We
> expect that this project will help visibly speed up the loading of large
> codebases of JS applications, including web applications, and will have
> a large impact on the JS development community, including both web
> developers, Node developers, add-on developers and ourselves.
>
>
> # Context
>
> The size of JavaScript-based applications – starting with webpages –
> keep increasing, while the parsing speed of JavaScript VMs has basically
> peaked. The result is that the startup of many web/js applications is
> now limited by JavaScript parsing speed. While there are measures that
> JS developers can take to improve the loading speed of their code, many
> applications have reached a situation in which such an effort becomes
> unmanageable.
>
> The JavaScript Binary AST is a novel format for storing JavaScript code.
> The global objective is to decrease the time spent between
> first-byte-received and code-execution-starts. To achieve this, we focus
> on a new file format, which we hope will aid our goal by:
>
> - making parsing easier/faster
> - supporting parallel parsing
> - supporting lazy parsing
> - supporting on-the-fly bytecode generation
> - decreasing file size.
>
> For more context on the JavaScript Binary AST and alternative
> approaches, see the companion high-level blog post [1].
>
>
> # Progress
>
> ## Benchmarking Prototype
>
> The first phase of the project was spent developing an early prototype
> format and parser to validate our hypothesis that:
>
> - we can make parsing much faster
> - we can make lazy parsing much faster
> - we can reduce the size of files.
>
> The prototype built for benchmarking was, by definition, incomplete, but
> sufficient to represent ES5-level source code. All our benchmarking was
> performed on snapshots of Facebook’s chat and of the JS source code our
> own DevTools.
>
> While numbers are bound to change as we progress from a proof-of-concept
> prototype towards a robust and future-proof implementation, the results
> we obtained from the prototype are very encouraging.
>
> - parsing time 0.3 (i.e. parsing time is less than a third of original
> time)
> - lazy parsing time *0.1
> - gzipped file size vs gzipped human-readable source code *0.3
> - gzipped file size vs gzipped minified source code *0.95.
>
> Please keep in mind that future versions may have very different
> results. However, these values confirm that the approach can
> considerably improve performance.
>
> More details in bug 1349917.
>
>
> ## Reference Prototype
>
> The second phase of the project consisted of building a second prototype
> format designed to:
>
> - support future evolutions of JavaScript
> - support annotations designed to allow safe lazy/concurrent parsing
> - serve as a reference implementation for third-party developers
>
> This reference prototype has been implemented (minus compression) and is
> currently being tested. It is entirely independent from SpiderMonkey and
> uses Rust (for all the heavy data structure manipulation) and Node (to
> benefit from existing parsing/pretty-printing tool Babylon). It is
> likely that, as data structures stabilize, the reference prototype will
> migrate to a full JS implementation, so as to make it easier for
> third-party contributors to join in.
>
> More details on the tracker [2].
>
>
> ## Standard tracks
>
> As any proposed addition to the JavaScript language, the JavaScript
> Binary AST needs to go through standards body.
>
> The project has successfully been accepted as an ECMA TC39 Stage 1
> Proposal. Once we have a working Firefox implementation and compelling
> results, we will proceed towards Stage 2.
>
> More details on the tracker [3].
>
>
>
> # Next few steps
>
> There is still lots of work before we can land this on the web.
>
>
> ## SpiderMonkey implementation
>
> We are currently working on a SpiderMonkey implementation of the
> Reference Prototype, initially without lazy or concurrent parsing. We
> need to finish it to be able to properly test that JavaScript decoding
> works.
>
> ## Compression
>
> The benchmarking prototype only implemented naive compression, while the
> reference prototype – which carries more data – doesn’t implement any
> form of compression yet. We need to reintroduce compression to be able
> to measure the impact on file size.
>
>
>
> # How can I help?
>
> If you wish to help with the project, please get in touch with either
> Naveed Ihsanullah (IRC: naveed, mail: nihsanullah) or myself (IRC:
> Yoric, mail: dteller).
>
>
> [1] https://yoric.github.io/post/binary

Re: Retaining Nightly users after disabling of legacy extensions

[Andrew McKay]

If an extension updates to a WebExtension, users will automatically
get that update.

If the author or another author creates an alternative then a user
will have to find that.

The recommendations are being populated and other changes are being
made. For example, on September 1st only WebExtensions will be
featured on AMO (as opposed to extensions that expect to upgrade). The
recommendation tool on AMO is being populated with add-ons any
suggestions welcome as per the thread here:
https://discourse.mozilla-community.org/t/favorite-webextensions/17087.

We are specifically and consciously focusing on release here and
giving the extension developers time to upgrade their extensions.

On 14 August 2017 at 13:16, Honza Bambas  wrote:
> On 8/13/17 6:42 PM, Ed Morley wrote:
>>
>> For the short term, Nightly users therefore have the following options:
>> a) Use latest nightly with legacy extensions disabled, and make do without
>> their extensions.
>
>
> There is also a2): find webext based alternatives "by hand" (what I have
> done and intend to help those addon developers to improve before 57 goes to
> release).  Note that in both cases (only two addons I really need to work -
> the rest is RIP now) are coming from *different* developers than the
> original xpcom-addons authors are.
>
> And here is my question: do we have a story for how to automatically updated
> addons of RELEASE channel users going from 56 to 57?  Given how we are gonna
> market 57, it would be sad that people after updating loose all their
> addons.  It will be just frustrating and ruin the main goal of 57 effort.
>
> Ed already mentioned that the addons manager doesn't automatically suggest
> or even update to webext alternatives.  We really should have something like
> this SOON - the more automatic or fluent the better.
>
> -hb-
>
>
> ___
> 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

PSA: Use nsStringFwd.h for forward declaring strings

[Eric Rahm]

Hi all-

In bug 1391803  I'm
removing all manually forward declared string types and replacing them with
a #include "nsStringFwd.h". Moving forward please use that include file if
you want to forward declare a string class.

In the next few weeks we plan on changing the underlying class names and
statements like 'class nsCString;' will no longer work.

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

Re: Retaining Nightly users after disabling of legacy extensions

[Chris Hutten-Czapski]

For those interested, preliminary data shows a continuing increase in the
Nightly population since 57. The number of users using Nightly 57 on August
17 was the highest number of users on any day on any Nightly version
since... well, our data retention policy cuts out at 6 months, so since at
least February 23. This continues the general growth of Nightly we've been
seeing since July with 56.

For the buildids, I just did a quick count of Nightly57 "main" pings
submitted on Aug 17 and found that over 90% are from after the 11th. Not
sure how normal that is (some people take forever to update their nightly),
but it puts a limit on how many users are purposefully "holding back".

Yes, I'm being purposefully vague on the numbers. I did say "preliminary
data" you'll notice. :)

:chutten

On Mon, Aug 14, 2017 at 9:28 AM, Andrew Swan  wrote:

> On Mon, Aug 14, 2017 at 6:16 AM, Honza Bambas  wrote:
>
> > Ed already mentioned that the addons manager doesn't automatically
> suggest
> > or even update to webext alternatives.  We really should have something
> > like this SOON - the more automatic or fluent the better.
>
>
> There is a "find a replacement" button next to disabled legacy extensions
> in about:addons.  Ed's original comment was that if, eg, Adblock Plus has a
> legacy version and a webextension version, we don't automatically direct
> users with the disabled legacy version to the webextension.  That's mostly
> because we don't actually have a straightforward way to do so, but it's
> also only an issue for users on non-release channels.
>
> -Andrew
> ___
> 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

Triage Summary 2017-08-21

[Emma Humphries]

It's the weekly report on the state of triage in Firefox-related
components. I apologize for missing last week’s report. I was travelling
and did not have a chance to sit down and focus on this.

Hotspots

The components with the most untriaged bugs remain the JavaScript Engine
and Build Config.

I discussed the JavaScript bugs with Naveed. What will happen is that the
JavaScript bugs which have not been marked as a priority for Quantum Flow
(the ‘\[qf:p[1:3]\]’ whiteboard tags) or existing work (the ‘\[js:p[1:3]\]’
whiteboard tags) will be moved to the backlog (P3) for review after the
Firefox 57 release. See https://bugzilla.mozilla.org/show_bug.cgi?id=1392436
.

Rank

Component

2017-08-07

This Week

1

Core: JavaScript Engine

449

471

2

Core: Build Config

429

450

3

Firefox for Android: General

411

406

4

Firefox: General

242

246

5

Core: General

234

235

6

Core: XPCOM

176

178

7

Core: JavaScript: GC

—

168

8

Core: Networking

—

161

All Components

8,373

8,703

Please make sure you’ve made it clear what, if anything will happen with
these bugs.

Not sure how to triage? Read
https://wiki.mozilla.org/Bugmasters/Process/Triage.

Next Release


Version

56

56

56

56

57

57

57


Date

7/10

7/17

7/24

7/31

8/7

8/14

8/14


Untriaged this Cycle

4,525

4,451

4,317

4,479

479

835

1,196


Unassigned Untriaged this Cycle

3,742

3,682

3,517

3,674

356

634

968


Affected this Upcoming Release (56)

111

126

139

125

123

119


Enhancements

102

107

91

103

3

5

11


Orphaned P1s

199

193

183

192

196

191

183


Stalled P1s

195

173

159

179

157

152

155





What should we do with these bugs? Bulk close them? Make them into P3s?
Bugs without decisions add noise to our system, cause despair in those
trying to triage bugs, and leaves the community wondering if we listen to
them.

Methods and Definitions

In this report I talk about bugs in Core, Firefox, Firefox for Android,
Firefox for IOs, and Toolkit which are unresolved, not filed from
treeherder using the intermittent-bug-filer account*, and have no pending
needinfos.

By triaged, I mean a bug has been marked as P1 (work on now), P2 (work on
next), P3 (backlog), or P5 (will not work on but will accept a patch).

A triage decision is not the same as a release decision (status and
tracking flags.)

https://mozilla.github.io/triage-report/#report

Age of Untriaged Bugs

The average age of a bug filed since June 1st of 2016 which has gone
without triage.

https://mozilla.github.io/triage-report/#date-report

Untriaged Bugs in Current Cycle

Bugs filed since the start of the Firefox 55 release cycle (March 6th,
2017) which do not have a triage decision.

https://mzl.la/2u1R7gA

Recommendation: review bugs you are responsible for (
https://bugzilla.mozilla.org/page.cgi?id=triage_owners.html) and make
triage decision, or RESOLVE.

Untriaged Bugs in Current Cycle Affecting Next Release

Bugs marked status_firefox56 = affected and untriaged.

https://mzl.la/2u2GCcG

Enhancements in Release Cycle

Bugs filed in the release cycle which are enhancement requests, severity =
enhancement, and untriaged.

​Recommendation: ​product managers should review and mark as P3, P5, or
RESOLVE as WONTFIX.

High Priority Bugs without Owners

Bugs with a priority of P1, which do not have an assignee, have not been
modified in the past two weeks, and do not have pending needinfos.

https://mzl.la/2u1VLem

Recommendation: review priorities and assign bugs, re-prioritize to P2, P3,
P5, or RESOLVE.

Stalled High Priority Bugs

There 159 bugs with a priority of P1, which have an assignee, but have not
been modified in the past two weeks.

https://mzl.la/2u2poMJ

Recommendation: review assignments, determine if the priority should be
changed to P2, P3, P5 or RESOLVE.

* New intermittents are filed as P5s, and we are still cleaning up bugs
after this change, See  https://bugzilla.mozilla.org/show_bug.cgi?id=1381587
,
https://bugzilla.mozilla.org/show_bug.cgi?id=1381960, and
https://bugzilla.mozilla.org/show_bug.cgi?id=1383923

If you have questions or enhancements you want to see in this report,
please reply to me here, on IRC, or Slack and thank you for reading.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform