Intent to prototype: Default font metrics overriding

[Jonathan Kew]

Summary: For historical/legacy reasons, fonts may contain multiple, 
conflicting versions of key metrics such as line ascent and descent, and 
user agents/platforms may rely on different fields in the font. This 
results in inconsistencies in line spacing, baseline alignment, etc.


To enable authors to achieve more consistent layout, the CSS WG has 
added descriptors to the @font-face rule that override whatever value 
the browser would use from the font resource, and provide an explicit 
author-provided value instead.


This can be used to harmonize line spacing behavior across browsers and 
platforms, or across different fonts where the designers may have made 
incompatible choices regarding the line metrics.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1681691

Standard: https://www.w3.org/TR/css-fonts-4/#font-metrics-override-desc

Platform coverage: All

Preference: layout.css.font-metrics-overrides.enabled

DevTools bug: None needed. (More generally, it would be awesome to have 
a @font-face rule inspector in DevTools -- distinct from the existing 
font *properties* inspector; such an inspector would expose this along 
with the other @font-face descriptors. But that's not specific to these 
new descriptors.)


Other browsers: Already shipping in Chrome.

web-platform-tests: There are a few tests in /css/css-fonts/, which will 
pass in Firefox once this is implemented.

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

Intent to prototype: glyph-scale-factor descriptor for @font-face rules

[Jonathan Kew]

Summary: For a given "font size" as expressed e.g. in CSS px or points, 
different fonts can vary significantly in how visually large they look. 
The nominal "font size" does not necessarily relate to any specific 
dimension of the glyphs; it sizes the coordinate space within which the 
glyph shapes are drawn, but different designs may fill that space in 
very different ways.


The proposed glyph-scale-factor descriptor (name to be bikeshedded) will 
allow authors to adjust the scaling of individual fonts loaded using 
@font-face, to better harmonize the visual sizes of different designs, 
or to more closely match a fallback face to a resource that may be 
swapped in later, thereby minimizing visual layout shift when the final 
font becomes available.


Unlike modifying the font-size property, this will scale the glyphs (and 
metrics) of the font but will *not* affect things like the CSS 'em' 
unit. It affects how glyphs scale within the font's em square, not the 
size of the em square itself.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1698495

Standard: This is currently under discussion for CSS Fonts 5; details 
still to be worked out. See https://github.com/w3c/csswg-drafts/issues/6075.


Platform coverage: All

Preference: layout.css.glyph-scale-factor.enabled

DevTools bug: None needed. (More generally, it would be awesome to have 
a @font-face rule inspector in DevTools -- distinct from the existing 
font *properties* inspector; such an inspector would expose this along 
with the other @font-face descriptors. But that's not specific to this 
new descriptor.)


Other browsers:
Blink: Considering (already experimented with possible implementation, 
see https://github.com/w3c/csswg-drafts/issues/5533#issuecomment-714166725).

Webkit: Present in CSS WG discussions but no clear signals yet AFAIK.

web-platform-tests: To be added to web-platform/tests/css/css-fonts (as 
.tentative initially, until spec is finalized).


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

PSA: potential new source of intermittent test failures - and how to work around it

[Jonathan Kew]

Do you write Gecko/Firefox patches or testcases, or monitor the Mozilla 
trees?


If so, you may run into new intermittent test failures due to a recent 
(intentional) behavior change.


On 2020-12-31, a patch landed in 
https://bugzilla.mozilla.org/show_bug.cgi?id=1676966 that changed how 
font fallback is handled. Previously, if the fonts specified in a page's 
CSS or through the browser prefs did not support a character present in 
the text, Gecko would potentially search all installed fonts to try and 
find one that could render the character. The first time this happens, 
it can be quite expensive, as it involves loading data from every 
installed font file, of which there may be thousands. Result: unpleasant 
jank.


To avoid this performance issue, we no longer block layout on the 
exhaustive search of all the fonts; instead, we start a background task 
to load the required character mappings from all the fonts, but proceed 
with layout using whatever fallbacks we may find, or just missing-glyph 
boxes. Once the font data is all loaded, we trigger a reflow everywhere 
so that content will be refreshed using the proper fonts.


Why does this matter for tests? It may result in two main types of 
failure in tests that are otherwise fine:


(1) If the test includes content -- such as text in a lesser-used 
Unicode script or unusual symbols -- that depends on font fallback, it 
may render with a different fallback font or not render at all during 
the initial pageload/reflow, if all the necessary font data has not yet 
been loaded. The rendering will be automatically corrected once the 
async font loading completes, but if the reftest harness has already 
taken a snapshot by that time, it may be too late, and the test fails.


(2) If async font data loading was triggered by the testcase, or by one 
shortly preceding it, an "unexpected" extra reflow event will happen 
when the loading completes. This can interfere with tests that are 
specifically concerned with event handling and expect a 
precisely-defined pattern of behavior, or are watching things like frame 
dimensions for changes.


Because the font fallback behavior is asynchronous (and the actual work 
happens in the parent process, while your testcase is usually running 
independently in a content process), the timing of all this cannot be 
accurately predicted, and failures may be intermittent.


(Note also that this async behavior only happens once per browser 
session, the first time content triggers a global font search. This 
means that which testcases are affected may depend on the chunking of 
test suites, and could change over time.)


If you have tests that are impacted by this, you can disable the async 
behavior -- reverting to the previous behavior where global font 
fallback, if needed, will block layout -- for them by setting the pref 
'gfx.font_rendering.fallback.async' to false via a test manifest 
annotation or similar metadata.


We could simply run all tests with the pref set to false, to avoid these 
issues, but I'd prefer not to do that as we then wouldn't be testing the 
configuration we ship to users. So let's try to handle this by 
selectively disabling the new behavior only in cases where we see it 
causing actual problems. Thanks!


JK

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

Re: A new testing policy for code landing in mozilla-central

[Jonathan Kew]

On 15/09/2020 16:03, Brian Grinstead wrote:

> We’re rolling out a change to the review process to put more focus on 
automated testing. [...]


As others have said, it's great that we're setting a clearer policy here 
- thanks!


One thing did strike me as a little surprising, and could perhaps be 
clarified:


> * testing-exception-other: Commits where none of the defined 
exceptions above apply but it should still be landed. This should be 
scrutinized by the reviewer before using it - consider whether an 
exception is actually required or if a test could be reasonably added 
before using it. This requires a comment from the reviewer explaining 
why it’s appropriate to land without tests.


The point that caught my eye here was that it explicitly requires the 
explanatory comment to be *from the reviewer*. I would have thought that 
in many cases it would make sense for the *patch author* to provide such 
an explanatory comment (which the reviewer would of course be expected 
to scrutinize before granting r+). Is that scenario going to be 
considered unacceptable?


Thanks,

JK

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

Intent to implement and ship: updated values for text-decoration properties

[Jonathan Kew]

There have been some recent changes to the CSS spec for the 
text-decoration-thickness, text-underline-offset, and 
text-underline-position: support for percentage values (based on the 
font-size) is added to the -thickness and -offset properties, as an 
alternative to using absolute lengths; and the from-font value is moved 
from text-underline-offset to -position.


Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1607534
https://bugzilla.mozilla.org/show_bug.cgi?id=1607308

Standard:
https://drafts.csswg.org/css-text-decor-4/#text-decoration-width-property
https://drafts.csswg.org/css-text-decor-4/#text-underline-position-property
https://drafts.csswg.org/css-text-decor-4/#underline-offset

Testing: web-platform/tests/css/css-text-decor/

Cross-browser support:
Safari partially supports these properties (it does not yet support 
percentages or the from-font value), while Chrome supports -position 
(without from-font) but not -offset or -thickness. Apple people have 
been involved in the recent spec changes, so I think we can expect to 
see Safari, at least, update its implementation to align with the new 
spec fairly soon.


Platform coverage: All

Restricted to secure contexts:
No; this is an adjustment to existing CSS properties that are available 
everywhere.


Target Release: 74

Preferences behind which this will be implemented:
None. (But note that the CSS properties involved are each gated on 
individual prefs from their original implementations:

layout.css.text-decoration-thickness.enabled
layout.css.text-underline-offset.enabled
layout.css.text-underline-position.enabled
These are enabled by default already.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement and partially ship: extended TextMetrics attributes for canvas text measurement

[Jonathan Kew]

The TextMetrics interface represents the dimensions of a piece of text 
in the canvas, as created by the CanvasRenderingContext2D.measureText() 
method.


Currently, Gecko only supports the .width attribute, but authors would 
also like to determine the actual dimensions that the rendered text 
would have in both x- and y-directions, as well as overall font metrics 
to assist with line spacing, etc.


Safari supports the full set of TextMetrics attributes as currently 
documented in the HTML spec. Chrome has recently shipped support for the 
actualBoundingBox attributes; it has support for additional font-metrics 
attributes behind the "experimental web features" flag.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1102584

Standard: https://html.spec.whatwg.org/multipage/canvas.html#textmetrics

Note that there are a number of open issues regarding the spec (see 
https://github.com/w3ctag/design-reviews/issues/302#issuecomment-427996200). 
For this reason, I propose to implement these attributes behind several 
prefs, and initially enable only the actualBoundingBox* attributes by 
default (matching what Chrome has shipped); the others will be 
preffed-off, but can be selectively enabled by authors who want to 
experiment with them.


Testing: Some (limited) tests are in 
web-platform/tests/2dcontext/drawing-text-to-the-canvas/2d.text.measure.*


Platform coverage: All

Restricted to secure contexts: No. The existing TextMetrics interface is 
not restricted, and other browsers support the extended attributes in 
all contexts.


Target Release: 74

Preferences behind which this will be implemented:
  dom.textMetrics.actualBoundingBox.enabled  (default: true)
  dom.textMetrics.baselines.enabled  (default: false)
  dom.textMetrics.emHeight.enabled   (default: false)
  dom.textMetrics.fontBoundingBox.enabled(default: false)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to ship: text-underline-position

[Jonathan Kew]

I'm shortly intending to turn on support for the CSS property 
text-underline-position on all platforms.


This feature was developed behind the preference
"layout.css.text-underline-position.enabled".

Other UAs shipping this feature:
* Internet Explorer v6 (an earlier non-standard version of the property)
* MS Edge v12 (an earlier non-standard version of the property)
* Blink/Chrome ('under' value since v33, 'left' and 'right' since v71)
* Opera ('under' value since v20, 'left' and 'right' since v58)

Bug to enable by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1606997

This property has been enabled by default in Nightly 73 since a month 
ago, as of bug 770780. I hope to uplift bug 1606997's patch to beta73 so 
that this will ship in Firefox 73.


This feature was previously discussed in the intent-to-prototype
thread:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/zKsl5XCB8LM
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to prototype: CSS property `text-underline-position`

[Jonathan Kew]

On 06/12/2019 09:35, James Graham wrote:

On 03/12/2019 17:50, Jonathan Kew wrote:

web-platform-tests: 
https://wpt.fyi/results/css/css-text-decor/parsing?label=master=text-underline-position 



That looks like it's just testing the property computation. Do we also 
have tests for the layout effect, or is that difficult to do in this case?


There are a couple of WPT tests for the rendering (see 
https://wpt.fyi/results/css/css-text-decor?label=master=experimental=text-decoration-underline-position), 
although reliably testing the rendering is difficult (the test with 
lang=ja is currently somewhat broken, as noted in 
https://github.com/web-platform-tests/wpt/issues/20604).


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

Intent to prototype: CSS property `text-underline-position`

[Jonathan Kew]

[re-sending, with a web-platform-tests link included - sorry!]

Summary: This property offers authors added control of the positioning 
of underlines, primarily for vertical text (where conventions differ as 
to whether an "underline" should appear to the left or right of the 
text), and also for horizontal text where a lower underline may be 
desirable (e.g. to avoid clashing with frequent subscript characters in 
math or scientific content).


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=770780

Standard: 
https://drafts.csswg.org/css-text-decor-3/#text-underline-position-property


Platform coverage: all

Preference: layout.css.text-underline-position.enabled

DevTools bug: n/a

Other browsers: Available in Chrome (& related browsers) since v.33, 
according to https://caniuse.com/#search=text-underline-position; also 
supported in IE/Edge.


web-platform-tests: 
https://wpt.fyi/results/css/css-text-decor/parsing?label=master=text-underline-position


Secure contexts: Not restricted - this is a simple CSS property, not 
restricted to secure contexts in existing browsers.


Is this feature enabled by default in sandboxed iframes? Yes.
If allowed, does it preserve the invariants in terms of what sandboxed 
iframes can do? Yes.


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

Intent to prototype: CSS property `text-underline-position`

[Jonathan Kew]

Summary: This property offers authors added control of the positioning 
of underlines, primarily for vertical text (where conventions differ as 
to whether an "underline" should appear to the left or right of the 
text), and also for horizontal text where a lower underline may be 
desirable (e.g. to avoid clashing with frequent subscript characters in 
math or scientific content).


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=770780

Standard: 
https://drafts.csswg.org/css-text-decor-3/#text-underline-position-property


Platform coverage: all

Preference: layout.css.text-underline-position.enabled

DevTools bug: n/a

Other browsers: Available in Chrome (& related browsers) since v.33, 
according to https://caniuse.com/#search=text-underline-position; also 
supported in IE/Edge.


web-platform-tests:

Secure contexts: Not restricted - this is a simple CSS property, not 
restricted to secure contexts in existing browsers.


Is this feature enabled by default in sandboxed iframes? Yes.
If allowed, does it preserve the invariants in terms of what sandboxed 
iframes can do? Yes.


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

Re: Intent to ship: Web Speech API

[Jonathan Kew]

On 07/10/2019 09:53, Henri Sivonen wrote:

On Mon, Oct 7, 2019 at 5:00 AM Marcos Caceres  wrote:



  - speech is processed in our cloud servers, not on device.


What should one read to understand the issues that lead to this change?


+1. This seems like a change of direction which has *huge* implications 
for issues like availability (the feature doesn't work if my device is 
offline?), privacy (my device is sending microphone input to the 
cloud?), and cost (how much of my expensive metered data does this 
gobble up?) that need to be openly considered and discussed.


The original "Intent to prototype" seemed to be about an entirely 
device-local feature, which means it had fundamentally different 
characteristics.


Thanks,

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

Re: What to do about scroll anchoring?

[Jonathan Kew]

On 27/09/2019 23:19, Botond Ballo wrote:

Emilio, thanks for all your work on this!

On Fri, Sep 27, 2019 at 8:23 AM Emilio Cobos Álvarez  wrote:

Does anyone have strong opinions against removing scroll anchoring from
Gecko, based on the above?


My 2c: it would be unfortunate to give up on scroll anchoring as a
feature altogether.


Yes.


However, if we need to disable it for now, until its spec is in better
shape, I can understand that;


I'd be concerned that if we disable it, we'll in effect no longer be 
providing useful implementation feedback to help shape the spec, and 
neither site nor spec authors will be guided towards anything better or 
more clearly defined than "however Chrome behaves".



especially as the code would
(presumably) still be there and users for whom it works well and
really want it can turn it back on by flipping the pref.


Although our chances of noticing regressions in this code will be 
greatly diminished (as well as the likelihood of noticing site authoring 
problems and spec shortcomings).


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

Re: Watch out for build issues on non-Unicode systems

[Jonathan Kew]

On 22/08/2019 13:42, Nihanth Subramanya wrote:

Note that the config.status changes in bug 844509 seem to break `$./mach
clobber` - I had to manually rm -rf my objdir.



Ah, that'll be what just happened to me, too. (Not just ./mach clobber, 
I was getting the same failure with ./mach build as well.)


Unfortunately I was a bit slow to realize that manually rm'ing the 
objdir might help, so in the meantime I'd wasted time re-running ./mach 
bootstrap, checking if my python was current, etc. :\


JK


On Thu, Aug 22, 2019 at 2:35 AM Mike Hommey  wrote:


Hi,

In bug 1575135 and bug 844509, we've changed how configure handles
strings from files and subprocesses, to normalize everything to Unicode.

On systems where the system locale is based on UTF-8 (e.g. most Linux
or macOS), this shouldn't make a difference.

On systems where the system locale is not based on UTF-8, this might
cause problems, so please watch out, especially on non-Latin Windows.

I don't believe things would have regressed (things should be handled
more or less similarly to before). I can think of a few things that
could fail, but for that matter, those I have in mind would have failed
before too.

However, it is possible that a few corner cases that are not covered by
automation lead to configure complaining about some key or values not
being unicode strings. If that happens, please file bugs with your
mozconfig and as much detail as possible.

Cheers,

Mike
___
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

Intent to prototype and ship: CSS `quotes: auto`

[Jonathan Kew]

Summary:
Adding a new `auto` value as the initial value of CSS `quotes` property, 
with the behavior that language-sensitive quotation marks (derived from 
CLDR) are used for quote-open/close generated content.


Bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1421938

Standard:
https://drafts.csswg.org/css-content-3/#quotes (not yet updated to 
reflect recent WG resolution)

https://html.spec.whatwg.org/multipage/rendering.html#quotes

Platform coverage:
All

Preference:
None, enabled globally.

DevTools bug:
None, the new value is automatically exposed in devtools

Other browsers:
Both webkit and blink have long shipped similar language-sensitive 
quote-mark behavior as a "magic" initial value of the `quotes` property 
(not serializable/round-trippable).
The CSS WG resolved to add `auto` as the name of this "magic" value in 
https://github.com/w3c/csswg-drafts/issues/4074.


web-platform-tests:
Collection of WPT reftests included in the bug. Many are based on 
pre-existing W3C i18n tests (not run in CI).


Secure contexts:
No; additional value for existing CSS property, needed in all contexts 
for interoperability with other browsers that already have this behavior 
by default.


Is this feature enabled by default in sandboxed iframes?
Yes.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Change to preferences via StaticPrefs, tremoval of gfxPrefs

[Jonathan Kew]

Great to see this consolidation happening; it's going to be a great 
improvement on the current situation.


Just to check, would it be correct to assume this won't be landing on 
central until after the current Fx68 soft-freeze period? It seems like 
the sort of wide-ranging change that probably shouldn't be hitting the 
tree just now.


Thanks for cleaning things up for us!

JK

On 15/05/2019 14:02, Jean-Yves Avenard wrote:

Dear all.

/TLDR; Wherever you used to use gfxPrefs, soon you will have to use 
StaticPrefs./


In a couple of days, once /Bug 1550422 
//lands I will be 
retiring gfxPrefs. All features originally found in gfxPrefs are now 
available in StaticPrefs with some extra bonuses./




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

Intent to implement: CSS line-break property

[Jonathan Kew]

Summary: The `line-break` property allows authors more control over 
where soft line breaks are allowed, particularly for East Asian content.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1011369
 https://bugzilla.mozilla.org/show_bug.cgi?id=1531715

Link to standard: https://drafts.csswg.org/css-text-3/#line-break-property

Platform coverage: Everywhere

Estimated or target release: 69

Preference behind which this will be implemented: None

Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: none

Do other browser engines implement this? Yes, both Blink (mostly 
complete, except the recently-added `anywhere` value) and Webkit (less 
complete, according to wpt.fyi results) have been shipping this for some 
time.


web-platform-tests:
https://github.com/web-platform-tests/wpt/tree/master/css/css-text/line-break

Is this feature restricted to secure contexts? No, it's a CSS property 
that has existed in other browsers (for all contexts) for a long time.

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

Re: Lack of browser mochitests in non-e10s configuration and support for turning off e10s on desktop going forward

[Jonathan Kew]

On 01/05/2019 17:29, Randell Jesup wrote:

Jean-Yves writes:

If anyone is chomping at the bit to remove 1proc support from their module,
please speak up.


I am one of those developers that find non-e10s essential to debug core 
features.


I've depended on using non-e10s for ages as well.  Most of my debugging
can in theory be done in e10s, but whenever I have to have multiple GDBs
running, and deal with breaking in one causing breaks in the other (or
timeouts, etc), it's really painful, and especially for any work that
crosses the Content/master boundary.


Just chiming in to agree strongly here. Most bugs I investigate are in 
code that doesn't care whether the browser is running in e10s or 
non-e10s mode, and so I routinely use --disable-e10s to make my 
debugging sessions simpler. Losing that option would hurt.


I realize the time may come when it's impractical to keep non-e10s 
working, but let's not kill it until there's a compelling reason to make 
the sacrifice.


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

Re: Intent to remove "-e10s" from treeherder group symbols and task labels

[Jonathan Kew]

On 09/04/2019 20:44, Andrew Halberstadt wrote:

Yeah, I did consider "non-e10s" for awhile and maybe it is the better
choice. But here are my counter arguments:

1) One of the goals of this change is to de-clutter the treeherder UI.
Using an 8 character symbol suffix runs counter to that goal (even if it is
still less cluttered overall).
2) People who use "e10s" in their |mach try fuzzy| queries out of muscle
memory (or in saved presets) will accidentally select the exact opposite of
what they want.
3) For new contributors "e10s" is a code word anyway. It's just now they
need to learn "fc" instead of "e10s".

None of those are terribly compelling, but it's still enough to make me
prefer "-fc".


I think (1) and (2) here are good points; I'm less convinced by (3). 
Yes, e10s is a code word, but it's one that is pretty long-established 
and pervasive in the project and surrounding documentation (it even 
shows up in the names of about:config settings). It appeared in 
treeherder UI *because* it was a well-established term within the project.


The proposed -fc suffix, on the other hand, seems gratuitously cryptic. 
If it had suddenly appeared in treeherder, I'd have been totally 
clueless as to its meaning; and even after seeing the announcement here, 
it feels like an artificial label that's trying a bit too hard to come 
up with a "clever" code where none is needed. It's not like we're 
starting with a standard multi-process configuration, and launching a 
grand "Fuel Cell" project that aims to merge the processes together.


How about suffixing these jobs with -sp for "Single Process"? That would 
be a lot more transparent, IMO.


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

Re: Proposal to adjust testing to run on PGO builds only and not test on OPT builds

[Jonathan Kew]

On 03/01/2019 16:17, jmaher wrote:

I would like to propose that we do not run tests on linux64-opt, windows7-opt, 
and windows10-opt.

Why am I proposing this:
1) All test regressions that were found on trunk are mostly on debug, and in 
fewer cases on PGO.  There are no unique regressions found in the last 6 months 
(all the data I looked at) that are exclusive to OPT builds.
2) On mozilla-beta, mozilla-release, and ESR, we only build/test PGO builds, we 
do not run tests on plan OPT builds
3) This will reduce the jobs (about 16%) we run which in turn reduces, cpu 
time, money spent, turnaround time, intermittents, complexity of the taskgraph.
4) PGO builds are very similar to OPT builds, but we add flags to generate 
profile data and small adjustments to build scripts behind MOZ_PGO flag 
in-tree, then we launch the browser, collect data, and repack our binaries for 
faster performance.
5) We ship PGO builds, not OPT builds

What are the risks associated with this?
1) try server build times will increase as we will be testing on PGO instead of 
OPT
2) we could miss a regression that only shows up on OPT, but if we only ship 
PGO and once we leave central we do not build OPT, this is a very low risk.


It's not just tryserver build times. Presumably this will also tend to 
increase the time between a patch landing on inbound or autoland and any 
resulting test failures showing up.


This seems like a negative in that it means more patches are likely to 
have landed on top of the regressing one in the meantime, potentially 
complicating backouts, and the original developer may be less likely to 
still be around for a quick investigation/fix.


How long does it typically take for full PGO test results to be 
available for a push? How does that compare to full Opt test results? 
ISTM that if the increase is quite marginal, this may be OK, but if the 
latency becomes substantially greater, there will be a continual cost in 
increased developer and/or sheriff pain.


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

Re: The upcoming C/C++ coding style change

[Jonathan Kew]

On 13/12/2018 14:52, Randell Jesup wrote:

But still all is not lost here.  When you do decide to do the manual
merging when you needed those patches, you would need to:

  * Update your working tree to the parent of the commit that did the
reformat.
  * Apply your patch to that tree and reformat the tree.
  * Diff the reformat commit and your current working directory.  That
would give the reformatted diff.


tl;dr: I need to figure out how I'm going to dig out of the rebasing hole
I'm now in, and could use advice/help, and I think the above sequence
doesn't work for queues of dependent patches.


If I'm understanding your situation correctly, I believe you can use 
rebase to update a whole queue of dependent patches, provided you have 
the format-source extension enabled.


Starting with all patches popped:

$ hg pull -u # get latest tree and make a note of the current tip
$ hg log # changeset that you'll want to rebase your queue onto

$ hg up PRE_TREEWIDE_CLANG_FORMAT # go to the pre-format changeset

$ hg qpush 

$ hg qfin -a# turn your applied patches into local commits

$ hg rebase -d DEST # where DEST is current m-c tip (or wherever you
# want to be working)

$ hg qimport -r tip # pull top local commit into mq
$ hg qpop   # and pop to unapply it

Repeat last two steps for each commit that you want to pull back into 
mq. Now you should have a queue that is based on the updated tree.


The rebase step may require some manual conflict resolution, but should 
be able to manage a lot of it automatically for you.


You lose the original patch names in this process, as "hg qimport -r 
tip" names them automatically (or you could use -n  to assign your 
preferred names when re-importing them).


You can repeatedly go back to PRE_TREEWIDE_CLANG_FORMAT and run this 
sequence for as many separate sets of dependent patches as you care about.


HTH,

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

Re: Dropping support for compiling with MSVC in the near future

[Jonathan Kew]

On 06/12/2018 15:00, Ted Mielczarek wrote:

Hello,

In light of the fact that we've switched to clang-cl for our Windows builds[1], 
we are planning to drop support for compiling Firefox with MSVC in the near 
future[2]. Our estimate is that this will happen sometime in Q1. Supporting 
more than one compiler is a maintenance burden and we've already seen 
developers spend considerable time getting their patches that work with 
clang-cl to build with MSVC. We are currently blocked by the fact that our 
aarch64-windows builds are still using MSVC and we are waiting on upstream 
clang-cl work to switch those builds to clang-cl. Once that takes place we no 
longer have a compelling reason to continue supporting MSVC.


While I sympathize with the concern that "supporting more than one 
compiler is a maintenance burden", this still leaves me feeling a little 
uneasy. Ensuring that our code builds successfully with multiple 
compilers is a useful way to keep us from becoming dependent on quirks 
of a particular tool, and different compilers may provide different 
(valid, useful) diagnostics that we should not simply ignore.


Our C/C++ code should (IMO) be standard and portable enough to build 
with any modern, mainstream C++ compiler; writing code for a clang 
monoculture feels wrong, a bit like building websites for a Blink 
monoculture...


JK



To preempt the question--when this happens we intend to make MSVC error in configure, and 
not just move MSVC to Tier 3 "patches welcome" status. Our reasoning is that 
Tier 3 configurations still create work: developers spend time building in those 
configurations, and lack of CI coverage means that when they inevitably break they waste 
time trying to fix things. Bugs get filed, and other developers waste time trying to help 
or reviewing patches to fix things. Explicitly unsupporting MSVC is the best way for us 
to convey the fact that developers should not be using it and we will not accept patches 
to fix issues that only affect MSVC.

If you have specific reasons for continuing to use MSVC please let us know. If 
there are deficiencies in clang-cl compared to MSVC we should get them filed 
and fixed.

Thanks,
-Ted

1. https://bugzilla.mozilla.org/show_bug.cgi?id=1443590
2. https://bugzilla.mozilla.org/show_bug.cgi?id=1512504
___
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: Proposed W3C Charter: Web Fonts Working Group

[Jonathan Kew]

On 16/11/2018 12:39, Xidorn Quan wrote:

On Fri, Nov 16, 2018, at 11:12 AM, L. David Baron wrote:

The W3C is proposing a revised charter for:

   Web Fonts Working Group
   https://www.w3.org/Fonts/WG/webfonts-2018-ac.html
   https://lists.w3.org/Archives/Public/public-new-work/2018Oct/0015.html

This is proposing a new work item for the group, Progressive Font
Enrichment, to allow progressive download of subsets of the font's
glyph repetoire.


I think we should support it.

While web fonts have been widely used on English websites, it is rarely found 
on Chinese websites as far as I can see, and I believe lack of native support 
of some progressive loading for fonts with large character set is the main 
reason impeding such adoption.



Agreed, we should support this. Once it reaches the point where there's 
a firm specification, I expect it's something we'll want to integrate 
into Firefox as part of our webfont support.


(I'm anticipating that most of the actual development of a spec, and 
probably of a reference implementation, will be tackled by some of the 
other WG members who have long had a strong interest in this; but we'll 
want to monitor the development and eventually adopt the result.)


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

Re: Intent to ship: scrollbar-color and scrollbar-width properties

[Jonathan Kew]

On 26/09/2018 01:59, Xidorn Quan wrote:

As of Firefox 64, I intend to turn scrollbar-color and scrollbar-width properties on by default on 
all platforms. They have been developed behind pref "layout.css.scrollbar-colors.enabled" 
and "layout.css.scrollbar-width.enabled" respectively.


Awesome, thanks for this work!

One tiny nit, which may not be worth bothering about at this point: it 
seems slightly unfortunate that the pref is 
"layout.css.scrollbar-colors.enabled" (plural) when the property name is 
"scrollbar-color" (singular).


I realize this originated back when there were two scrollbar-*-color 
properties, so using plural for the pref made sense, but now it just 
feels a bit confusing.


Maybe consider dropping the final "s" from the pref name so it better 
matches the feature it controls?


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

Re: PSA: Major preference service architecture changes inbound

[Jonathan Kew]

On 20/07/2018 03:25, Kris Maglione wrote:

On Thu, Jul 19, 2018 at 07:17:13PM -0700, Jeff Gilbert wrote:

Using a classic read/write exclusive lock, we would only every contend
on read+write or write+write, which are /rare/.


That might be true if we gave up on the idea of switching to Robin Hood 
hashing. But if we don't, then every lookup is a potential write, which 
means every lookup required a write lock.


I'm a bit puzzled by this statement, actually my understanding of 
Robin Hood hashing (based on looking at a few articles; I don't claim 
anything like in-depth study) is that it may move existing entries 
during *insertion*, and potentially during *deletion* (if using a 
backward-shift deletion approach, rather than tombstones), but *lookup* 
operations wouldn't modify anything.


So we should be able to use Robin Hood hashing with an RWLock that 
allows reading from multiple threads without contention; only writing 
(which for prefs is pretty rare, I believe) would block other threads.


Or is there a more advanced version of the Robin Hood design, where 
*lookup* also rearranges entries?


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

Re: PSA: Major preference service architecture changes inbound

[Jonathan Kew]

On 20/07/2018 03:17, Jeff Gilbert wrote:

Using a classic read/write exclusive lock, we would only every contend
on read+write or write+write, which are /rare/.


Indeed, that's what I envisage we'd want. The -vast- majority of prefs 
access only involves reading values. We should be able to do that from 
any thread without a second thought about either safety or contention.




It's really, really nice when we can have dead-simple threadsafe APIs,
instead of requiring people to jump through hoops or roll their own
dispatch code. (fragile) IIRC most new APIs added to the web are
supposed to be available in Workers, so the need for reading prefs
off-main-thread is only set to grow.

I don't see how this can mutate into a foot-gun in ways that aren't
already the case today without off-main-thread access.

Anyway, I appreciate the work that's been done and is ongoing here. As
you burn down the pref accesses in start-up, please consider
unblocking this feature request. (Personally I'd just eat the 400us in
exchange for this simplifying architectural win)


+1 to that. Our need for OMT access to prefs is only likely to grow, 
IMO, and we should just fix it once, so that any code (regardless of 
which thread(s) it may eventually run on) can trivially read prefs.


Even if that means we can't adopt Robin Hood hashing, I think the 
trade-off would be well worthwhile.


JK



On Thu, Jul 19, 2018 at 2:19 PM, Kris Maglione  wrote:

On Tue, Jul 17, 2018 at 03:49:41PM -0700, Jeff Gilbert wrote:


We should totally be able to afford the very low cost of a
rarely-contended lock. What's going on that causes uncached pref reads
to show up so hot in profiles? Do we have a list of problematic pref
keys?



So, at the moment, we read about 10,000 preferences at startup in debug
builds. That number is probably slightly lower in non-debug builds, bug we
don't collect stats there. We're working on reducing that number (which is
why we collect statistics in the first place), but for now, it's still quite
high.


As for the cost of locks... On my machine, in a tight loop, the cost of a
entering and exiting MutexAutoLock is about 37ns. This is pretty close to
ideal circumstances, on a single core of a very fast CPU, with very fast
RAM, everything cached, and no contention. If we could extrapolate that to
normal usage, it would be about a third of a ms of additional overhead for
startup. I've fought hard enough for 1ms startup time improvements, but
*shrug*, if it were that simple, it might be acceptable.

But I have no reason to think the lock would be rarely contended. We read
preferences *a lot*, and if we allowed access from background threads, I
have no doubt that we would start reading them a lot from background threads
in addition to reading them a lot from the main thread.

And that would mean, in addition to lock contention, cache contention and
potentially even NUMA issues. Those last two apply to atomic var caches too,
but at least they generally apply only to the specific var caches being
accessed off-thread, rather than pref look-ups in general.


Maybe we could get away with it at first, as long as off-thread usage
remains low. But long term, I think it would be a performance foot-gun. And,
paradoxically, the less foot-gunny it is, the less useful it probably is,
too. If we're only using it off-thread in a few places, and don't have to
worry about contention, why are we bothering with locking and off-thread
access in the first place?



On Tue, Jul 17, 2018 at 8:57 AM, Kris Maglione 
wrote:


On Tue, Jul 17, 2018 at 02:06:48PM +0100, Jonathan Kew wrote:



On 13/07/2018 21:37, Kris Maglione wrote:



tl;dr: A major change to the architecture preference service has just
landed, so please be on the lookout for regressions.

We've been working for the last few weeks on rearchitecting the
preference service to work better in our current and future
multi-process
configurations, and those changes have just landed in bug 1471025.




Looks like a great step forward!

While we're thinking about the prefs service, is there any possibility
we
could enable off-main-thread access to preferences?




I think the chances of that are pretty close to 0, but I'll defer to
Nick.

We definitely can't afford the locking overhead—preference look-ups
already
show up in profiles without it. And even the current limited exception
that
we grant Stylo while it has the main thread blocked causes problems (bug
1474789), since it makes it impossible to update statistics for those
reads,
or switch to Robin Hood hashing (which would make our hash tables much
smaller and more efficient, but requires read operations to be able to
move
entries).


I am aware that in simple cases, this can be achieved via the
StaticPrefsList; by defining a VARCACHE_PREF there, I can read its value
from other threads. But this doesn't help in my use case, where I need
another thread to be able to query an extensible set of pref names that
are
not fully known

Re: PSA: Major preference service architecture changes inbound

[Jonathan Kew]

On 13/07/2018 21:37, Kris Maglione wrote:
tl;dr: A major change to the architecture preference service has just 
landed, so please be on the lookout for regressions.


We've been working for the last few weeks on rearchitecting the 
preference service to work better in our current and future 
multi-process configurations, and those changes have just landed in bug 
1471025.


Looks like a great step forward!

While we're thinking about the prefs service, is there any possibility 
we could enable off-main-thread access to preferences?


I am aware that in simple cases, this can be achieved via the 
StaticPrefsList; by defining a VARCACHE_PREF there, I can read its value 
from other threads. But this doesn't help in my use case, where I need 
another thread to be able to query an extensible set of pref names that 
are not fully known at compile time.


Currently, it looks like to do this, I'll have to iterate over the 
relevant prefs branch(es) ahead of time (on the main thread) and copy 
all the entries to some other place that is then available to my worker 
threads. For my use case, at least, the other threads only need read 
access; modifying prefs could still be limited to the main thread.


Possible? Or would the overhead of locking be too crippling?

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

Re: Intent to ship: OpenType Variation Font support

[Jonathan Kew]

On 13/05/2018 14:01, rosesharon...@gmail.com wrote:

On Monday, March 19, 2018 at 3:32:42 PM UTC-7, Jonathan Kew wrote:

As of this week, for the mozilla-61 cycle, I plan to turn support for
OpenType Font Variations on by default.

It has been developed behind the layout.css.font-variations.enabled and
gfx.downloadable_fonts.keep_variation_tables preferences.

Other UAs shipping this or intending to ship it include:
Safari (on macOS 10.13 or later)
Chrome (and presumably other Blink-based UAs)
MSEdge (on Windows 10 Fall Creators Update or later)

Bug to turn on by default:
https://bugzilla.mozilla.org/show_bug.cgi?id=1447163

This feature was previously discussed in this "intent to implement"
thread:
https://groups.google.com/d/topic/mozilla.dev.platform/_FacI6Aw2BQ/discussion




I'm not sure if this was intended as a question, or what?

Anyhow, to update here: we decided to hold back from shipping on 61, to 
give more time to be feature-complete and well-tested. So Variable Fonts 
is currently on track to ship in Firefox 62.


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

Re: New Policy: Marking Bugzilla bugs for features riding behind a pref

[Jonathan Kew]

On 03/05/2018 00:57, Emma Humphries wrote:

To summarize, when you are releasing a feature that "rides behind a 
flag", on the bug for the feature:


* set the behind-pref flag to +
* set the qa-verify flag to ?
* note the bug in the Firefox Feature Trello board

We expect qa-verify to be set to + before enabling prefs on features.


I don't see a flag "qa-verify" in bugzilla; was this possibly a typo for 
"qe-verify"?


Thanks,

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

redundant(?) code churn and code style issues in bug 525063

[Jonathan Kew]

The huge patch that recently hit mozilla-central in bug 525063 makes me 
a bit sad. Did we really need to do this? On this scale?


It's presumably auto-generated by a static-analysis tool or something 
like that, but ISTM it has been overly aggressive, adding a lot more 
code churn than necessary (as well as committing some pretty extreme 
style violations such as over-long lines).


For example, it has added explicit initializers to constructors in cases 
where the members were already default-initialized at the point of 
declaration.


Couldn't we have been a little less heavy-handed here?

(I would have just commented in the bug, but don't have access to it)

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

Re: Intent to ship: OpenType Variation Font support

[Jonathan Kew]

On 21/03/2018 08:03, dr...@chromium.org wrote:


font-{weight,stretch,style} are parsed and hooked up to the variable fonts 
rasterization backend since we initially shipped OpenType Variations in M62. I 
implemented this in Blink, so if you are observing any issues, mind sharing 
them? I'd be happy to take a look.


Hi Dominik,

Thanks for the note - that's interesting. Maybe I'm missing something?

Simple testcase (requires Avenir Next Variable installed):




body { font-family: Avenir Next Variable; font-size: 24px; }



for (i = 400; i <= 700; i += 50) {
  e = document.createElement("div");
  e.textContent = "font-weight " + i;
  e.style.fontWeight = i;
  document.body.appendChild(e);
  e = document.createElement("div");
  e.textContent = "variation wght " + i;
  e.style.fontVariationSettings = "'wght' " + i;
  document.body.appendChild(e);
}


When I view this with Chrome, I see the expected range of weights for 
the elements that use font-variation-settings. But those using 
font-weight are all rendered with the default weight of Avenir, just 
with a slight (and constant) synthetic-bold effect applied at 
font-weight:550 and higher.


This led me to believe something isn't completely hooked up on 
further experimentation, though, I find that it does work as expected if 
the font is loaded from a @font-face resource with the appropriate 
descriptors. So this seems to be only a limitation for installed fonts?


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

Re: Intent to ship: OpenType Variation Font support

[Jonathan Kew]

On 20/03/2018 20:50, gwhi...@gmail.com wrote:



Will 61 bring support for font-optical-sizing as well?


Yes; it's behind the same pref as font-variation-settings, so the two 
properties will be enabled together.

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

Re: Intent to ship: OpenType Variation Font support

[Jonathan Kew]

On 19/03/2018 22:42, L. David Baron wrote:


Is there something with a little more detail about how our (a)
feature set and (b) platform support compares with what other
engines are shipping? 


That sounds like it could be a worthwhile blog post somewhere

In brief: everyone supports font-variation-settings, the most basic tool 
authors can use to control these fonts.


The CSS spec also calls for higher-level linkage to (enhanced forms of) 
the font-{weight,stretch,style} properties. Edge implements this; Blink 
currently accepts [at least some of] the extended CSS values (e.g. 
non-integer font-weight values) but doesn't have them hooked up to 
variation font rendering; we don't yet implement this.


Regarding platform support: Edge, Safari and Firefox only support 
variation fonts on up-to-date versions of Win10 and macOS, while Chrome 
(AIUI) also supports them on older versions (by shipping an embedded 
copy of FreeType to use in place of the system font rasterizer when it 
doesn't have variation support).


On Linux, official Mozilla builds have variation support; distro builds 
that use --with-system-freetype will also work provided the system 
freetype is fairly recent, but old distros may still have a freetype 
that lacks variation support.


I haven't tested recent Chrome on Android but I presume they have the 
same support there as on desktop (as does Firefox).


So to sum up

> That is, are there substantive cases where
> some systems will have variation font support on other browsers but
> not Firefox,

On older releases of macOS and Windows, Chrome will have it but Firefox 
won't (neither will Safari/IE/Edge, however).


> or substantive features that other implementations will
> be shipping but we won't?

Support for the enhanced font-{weight,stretch,style} properties is 
currently only shipping in Edge, AFAICT; Blink has parsing but not full 
rendering support.

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

Re: Intent to ship: OpenType Variation Font support

[Jonathan Kew]

On 20/03/2018 09:54, James Graham wrote:

On 19/03/2018 22:32, Jonathan Kew wrote:
As of this week, for the mozilla-61 cycle, I plan to turn support for 
OpenType Font Variations on by default.


It has been developed behind the layout.css.font-variations.enabled 
and gfx.downloadable_fonts.keep_variation_tables preferences.


Other UAs shipping this or intending to ship it include:
   Safari (on macOS 10.13 or later)
   Chrome (and presumably other Blink-based UAs)
   MSEdge (on Windows 10 Fall Creators Update or later)

Bug to turn on by default: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1447163


This feature was previously discussed in this "intent to implement" 
thread: 
https://groups.google.com/d/topic/mozilla.dev.platform/_FacI6Aw2BQ/discussion 



Are there now (cross-browser) tests for this feature?


There are a handful of tests now in 
web-platform/tests/css/css-fonts/variations, and there a bunch more 
currently in preparation (e.g. see 
https://bugzilla.mozilla.org/show_bug.cgi?id=1436588).


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

Intent to ship: OpenType Variation Font support

[Jonathan Kew]

As of this week, for the mozilla-61 cycle, I plan to turn support for 
OpenType Font Variations on by default.


It has been developed behind the layout.css.font-variations.enabled and 
gfx.downloadable_fonts.keep_variation_tables preferences.


Other UAs shipping this or intending to ship it include:
  Safari (on macOS 10.13 or later)
  Chrome (and presumably other Blink-based UAs)
  MSEdge (on Windows 10 Fall Creators Update or later)

Bug to turn on by default: 
https://bugzilla.mozilla.org/show_bug.cgi?id=1447163


This feature was previously discussed in this "intent to implement" 
thread: 
https://groups.google.com/d/topic/mozilla.dev.platform/_FacI6Aw2BQ/discussion

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

Intent to ship: CSS paint-order for HTML text

[Jonathan Kew]

As of Firefox 60, I intend to turn CSS paint-order for HTML text on by 
default. It has been developed behind the layout.css.paint-order.enabled 
preference.


I am not aware of any other UAs yet shipping this feature, but since our 
intent to implement, the CSS WG has agreed to include this in the "CSS 
Fill and Stroke Module Level 3" spec:

  https://drafts.fxtf.org/fill-stroke/#strokes
  https://github.com/w3c/fxtf-drafts/issues/107
  https://lists.w3.org/Archives/Public/www-style/2018Jan/0004.html

Bug to turn on by default:
  https://bugzilla.mozilla.org/show_bug.cgi?id=1435684

This feature was previously discussed in this "intent to implement" thread:

https://groups.google.com/forum/#!topic/mozilla.dev.platform/mogT087VmJM.

The feature was implemented in
  https://bugzilla.mozilla.org/show_bug.cgi?id=1426146
including a web-platform-test to confirm it is working as expected.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Intent to implement: support CSS paint-order for HTML text

[Jonathan Kew]

Summary: For text that is stroked as well as filled (using 
-webkit-text-stroke), this allows the author to control whether the 
stroke is painted before or after the fill. The current behavior is to 
always paint the stroke on top, which is often visually poor, and leads 
authors to use cumbersome workarounds involving multiple copies of the 
text in order to render a stroke behind the fill.


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1426146

Link to standard: Currently an open issue in the CSS Fill & Stroke spec: 
https://www.w3.org/TR/fill-stroke-3/#issue-57580890


Platform coverage: All

Estimated or target release: Firefox 59 (behind a default-off pref, 
pending CSS WG consideration)


Preference behind which this will be implemented: 
layout.css.paint-order.enabled


Is this feature enabled by default in sandboxed iframes? Yes

DevTools bug: No special DevTools requirements

Do other browser engines implement this? AFAIK, this property is 
currently implemented in other engines only for SVG content (like in 
Firefox), not for HTML text


Tests - Is this feature fully tested by web-platform-tests? No, as it is 
not yet spec'd (see above). I propose to land a basic mozilla reftest 
along with the patches in bug 1426146 (behind a pref); if/when the CSS 
WG agrees to accept this issue in the spec, we can migrate the reftest 
to WPT


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

Re: Dropping remains of support for non-UTF-8 file paths on Gtk platforms (was: Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code)

[Jonathan Kew]

On 05/12/2017 15:16, Henri Sivonen wrote:

On Tue, Dec 5, 2017 at 4:37 PM, ISHIKAWA,chiaki  wrote:

There are other non-ASCII character issues such as
https://bugzilla.mozilla.org/show_bug.cgi?id=1258613


Very weird bug! (Summary for others: decomposed voiced sound mark is
rendered on the wrong base character.)


Not all that weird, really; it's almost certainly due to using a font 
that doesn't support the combining mark. Commented in the bug.


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

Re: Hiding 'new' statements - Good or Evil?

[Jonathan Kew]

On 23/11/2017 12:05, Jeff Gilbert wrote:

I agree that MakeNotNull doesn't sound like it allocates. Reads to me
as Make[Into]NotNull. Context will *usually* make this clear, but why
not NewNotNull? (Honestly I don't like MakeUnique to begin with)


As far as naming is concerned, ISTM that "Create..." would be clearer 
than "Make..." for methods like this, as it's not so easy to 
misinterpret as "make [an existing thing] into [a certain state]".


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

Re: Visual Studio 2017 coming soon

[Jonathan Kew]

On 26/10/2017 15:14, Milan Sreckovic wrote:
Are we locked into using the same compiler for the ESR updates?  In 
other words, do we need to keep VS2015 for ESR52 builds until they are 
not needed anymore?




Yes, IMO.

Whether or not we're "locked" in any technical sense, I think we should 
probably lock ourselves there by policy, unless a specific bug in the 
older compiler is directly affecting ESR builds in a serious way, and 
can only be solved by updating.


Short of something like that (which seems pretty unlikely!), the 
stability risk involved in switching compilers doesn't sound like it 
belongs anywhere near the ESR world.


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

Re: Changes to tab min-width

[Jonathan Kew]

On 06/10/2017 17:05, Boris Zbarsky wrote:

On 10/3/17 5:18 PM, Boris Zbarsky wrote:
So just to make sure I understand the change (and this is a 
theoretical point, because I haven't had a chance to try the change 
yet)... 


OK, now I have had a chance to try it.

When set to the new 50px default, I see 1 letter of title or less (less, 
because the entire second half of the letter is faded out badly).  This 
makes tabs more or less unusable for me.  :(


Agree totally with this. I had seen the beginning of this discussion 
before I updated to a Nightly with the change, so I knew it was coming 
(and what the rationale was), but I was quite shocked at how unusable I 
found the browser with narrow tabs.


No doubt I'd get used to it somehow if there were no way it could be 
changed, but I don't think I'd ever be happy with it. I've reset mine to 
100, though I can see that if I didn't have lots of bugzilla tabs open 
(where I want to see the whole bug number), I might be OK with about 80.


Aside: IMO, a more interesting UI experiment than shrinking the tab 
width would be a built-in option to put a tab-strip on the side of the 
window, instead of across the top. Yes, I know about Tree-Style Tabs and 
similar add-ons, but I tend to run something as close as possible to a 
"vanilla" browser configuration, so that I'm getting a similar 
experience to the majority of our users. If we had "Tabs at the side" 
(or something) in the browser preferences (or in Customize?), I suspect 
a significant number of users might discover and like it, whereas if it 
requires finding an add-on, most people never will.


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

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

[Jonathan Kew]

On 04/10/2017 09:17, Jan Keromnes wrote:

You can also run them on your own code with:


./mach static-analysis check path/to/file.cpp


Sounds awesome! I tried this locally to see what it would say about a 
random(ish) file in the tree, but it ended with the message:


 0:42.99 Could not find artifacts for a toolchain build named 
`macosx64-clang-tidy`


which sounds like something's missing. It would be nice if it could 
automatically obtain the required tools, or at least offer a hint as to 
what I should do to set up a suitable environment.


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

Re: Status of CSS break-* properties

[Jonathan Kew]

On 13/09/2017 12:31, thomas.ja...@gmail.com wrote:

Hi there!

Apparently, most major browsers are currently supporting "break-column", e.g., or its 
"-webkit-column-"-prefixed variant (based on manual testing of 
https://www.quirksmode.org/css/columns/breaks.html in latest Chrome, Safari, Edge and IE 11). 
However, I couldn't find any information on its status in Firefox.


See https://developer.mozilla.org/en-US/docs/Web/CSS/break-after and 
related properties. (Answer: not currently supported.)


> Does anyone know whether there is an intent to implement?

There's a bug on file: 
https://bugzilla.mozilla.org/show_bug.cgi?id=775628. But I'm not aware 
of any timeline for fixing this.


(I think some use-cases can be handled using (or abusing) page-break-* 
properties, which may also affect column breaking, but that's a hacky 
workaround and I don't know if it is guaranteed to continue working once 
the CSS Fragmentation properties are actually implemented.)


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

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

[Jonathan Kew]

On 20/08/2017 23:35, Nicholas Nethercote wrote:

Hi,

For a long time we have had types nsAutoString and nsAutoCString which are
strings with 64 chars of inline storage. They are good for holding short
strings, most often on the stack, because they avoid the need to heap
allocate
a char buffer.

I recently landed patches (bug 1386103) that introduce nsAutoStringN and
nsAutoCStringN. These are like the existing types but their length is a
template parameter. So if you want an nsString with 128 chars of inline
storage, you'd use nsAutoStringN<128>. If you want an nsCString with enough
inline storage to store an nsID you'd use nsAutoCStringN.


Nice!

Wouldn't it be more "modern Gecko-ish", though, to drop the "ns" prefix, 
and perhaps put Auto[C]String into the mozilla namespace?



nsAutoString and nsAutoCString have been redefined as typedefs for
nsAutoStringN<64> and nsAutoCStringN<64>, respectively.

I have updated the MDN docs appropriately:
https://developer.mozilla.org/en-US/docs/Mozilla/Tech/XPCOM/
Guide/Internal_strings

Nick

p.s. The "Auto" in these names is confusing. "Auto" in Mozilla code usually
refers to an RAII wrapper type such as AutoPtr or AutoLock. nsInlineString
and
nsInlineCString would be better names for these types... but that's a
change
for another day.


There's also AutoTArray, though, which uses "Auto" in the same sense as 
nsAutoString...


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

Re: Changing .idl files

[Jonathan Kew]

On 07/08/2017 18:05, Kris Maglione wrote:
At the moment, legacy add-ons are allowed on nightly, but are officially 
unsupported. We're planning to disable them by default on nightlies, but 
it will still be possible to enable them by flipping a pref.


Will that pref still be available in 57 once it reaches Release (and 
then for how much longer?), or will it be going away somewhere between 
now and then?


(I'd been under the impression that legacy add-ons would be dead as of 
FF57, but if they can be re-enabled by flipping a pref, then that's not 
as clear-cut as I thought.)


Thanks,

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

Intent to ship: CSS font-display descriptor

[Jonathan Kew]

For Firefox 57, I intend to turn the CSS 'font-display' descriptor for 
@font-face rules on by default. This feature was developed behind the 
layout.css.font-display.enabled preference.


Blink has already shipped this feature as of Chrome 60:
  https://developers.google.com/web/updates/2017/07/nic60#fontdisplay

This feature was developed in:
  https://bugzilla.mozilla.org/show_bug.cgi?id=1157064
and landed (preffed off) for Firefox 46.

Bug to turn on by default:
  https://bugzilla.mozilla.org/show_bug.cgi?id=1317445

Link to [draft] standard:
  https://drafts.csswg.org/css-fonts-4/#font-display-desc

Testing:
  https://github.com/w3c/web-platform-tests/tree/master/css-font-display


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

Re: Mozilla Charset Detectors

[Jonathan Kew]

On 22/05/2017 10:13, Gabriel Sandor wrote:

Greetings,

I recently came across the Mozilla Charset Detectors tool, at
https://www-archive.mozilla.org/projects/intl/chardet.html. I'm working on
a C# project where I could use a port of this library (e.g.
https://github.com/errepi/ude) for advanced charset detection.

I'm not sure however if this tool is deprecated or not, and still
recommended by Mozilla for use in modern applications. The tool page is
archived and most of the links are dead, while the code seems to be at
least 7-8 years old. Could you please tell me what's the status of this
tool and whether I should use it in my project or look for something else?


I'd suggest looking at ICU, for a modern, actively-maintained library 
that can probably help you:


 http://userguide.icu-project.org/conversion/detection

Or there's also https://github.com/google/compact_enc_det (as mentioned 
in the ICU doc).


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

Re: Intent to remove: Ability to specify the Raanana macOS system font by its Hebrew name in CSS

[Jonathan Kew]

On 18/01/2017 07:04, Henri Sivonen wrote:

I'm in the process of rewriting our encoding converter infrastructure
in Rust. For a new implementation, it makes sense to support only the
Web-exposed encodings, that is, the encodings specified in the
Encoding Standard.

Currently, Firefox supports decoding non-Encoding Standard encodings
in one place: in TrueType system font names. TrueType fonts can
declare multiple names and the encoding of the names is specified on a
per-name basis.

Based on telemetry, Gecko sees these very rarely except for MacHebrew
on Mac, which is due to the set of system-bundled fonts containing a
font, Raanana, that declares one of its names in MacHebrew, and
Firefox enumerates all system fonts. This is not telemetry of the font
getting used but the decoder getting instantiated.

It also happens that Raanana doesn't declare its Hebrew name in
another way (Unicode or windows-1255), so removing support for
non-Encoding Standard font names has the effect of removing the
ability to specify Raanana by its Hebrew name in CSS. (I'm not
actually sure if Raanana is the only macOS-bundled font like this.)



Note that the current CSS Fonts 3 spec explicitly says that UAs are 
required to recognize localized font names:


"Some font formats allow fonts to carry multiple localizations of the 
family name. User agents must recognize and correctly match all of these 
names independent of the underlying platform localization, system API 
used or document encoding..."[1]


(The Hebrew name of Raanana is even included in the examples shown there!)

As you've noted, Chrome does not actually support this, so there is not 
full interoperability in this area; but if we decide to remove this 
support (and don't implement any of the possible workarounds) then I 
think we need to bring it up in the CSS WG and see if there is agreement 
on explicitly changing it in the spec. (I'm not sure how readily Apple 
and Microsoft will buy into that, as I believe there is historically 
some usage of localized font names on both macOS and Windows, though 
clearly Chrome hasn't considered it essential.)


Anyway, just wanted to point out that this is a spec issue, not 
something we should decide in isolation.


JK

[1] https://drafts.csswg.org/css-fonts-3/#font-family-prop

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

Re: Intent to ship: NetworkInformation

[Jonathan Kew]

On 15/12/2016 17:20, Ben Kelly wrote:

On Thu, Dec 15, 2016 at 12:06 PM, Boris Zbarsky  wrote:


On 12/15/16 11:23 AM, Ben Kelly wrote:


if (navigator.connect.downlinkMax > 100) {
  // perform low-priority background downloads
}



Why is the downlinkMax the right thing to be checking here, though? Again,
outside of the "cellphone on a cell network" case, the last-hop bandwidth
tells you pretty much nothing because it's incredibly unlikely that the
last hop is the bottleneck.



Its more information than nothing.


But if it is seriously inaccurate or misleading information (e.g. it 
suggests a fast connection, when the "fast" last-hop is just my laptop 
being tethered to a cellphone that has a slow, expensive connection), 
then it may be worse than nothing.



 And saying its a limit on the maximum
is accurate.  And its a value that can become more accurate over time with
better OS and network integration.


Not necessarily, if it is explicitly spec'd to refer to the speed of the 
last hop. ("The spec is pretty clearly written to specify maximum 
possible downlink given the first hop interface.")



Code using the API gets that for free
without changing anything.  If it special cases on "cellular" or "wifi",
then it has to update its list if a new networking type is introduced in
the future.


If better network integration means that in future, we can reliably 
report the overall bandwidth of the connection to a given server (for 
example), or the cost per byte transferred (perhaps more interesting, in 
many cases), that would presumably be exposed via a new API, not by 
redefining what this API does. But that means code doesn't "get that for 
free", it will need to be updated.




I agree that for the "cellphone on a cell network" case the last-hop

bandwidth can be useful.



Bluetooth networking is also a thing.

I think being able to distinguish this stuff provides some value even if
its not perfect for all cases.  And I don't see how it causes any harm.


It causes harm if it (mis)leads a site/web-app into doing things -- such 
as large downloads over a metered connection, because the last hop 
happens to look fast -- that are not appropriate for the true nature of 
the user's connection.


Arguably, it might be better to not expose such potentially misleading 
information at all; then such a site or app would not be tempted to rely 
on it, and would have to find an alternative approach (perhaps simply 
asking the user "do you want to download X megabytes of stuff?").


JK

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

Re: Intent to implement: OpenType Variation Fonts

[Jonathan Kew]

On 06/12/2016 19:04, Xidorn Quan wrote:

On Tue, Dec 6, 2016, at 01:28 AM, Jonathan Kew wrote:

DevTools bug: It's not yet clear to me whether specific DevTools work
will be needed, beyond the support we'll automatically get for a new CSS
property.


I think DevTools may want to display a panel which lists all available
variation axis supported by the font, and allow developers to adjust
them.


Yes, perhaps something like that would be useful. Though we don't do 
anything along those lines for OpenType font features at present. If 
DevTools is to start exposing details of "font capabilities", both 
features and variations should be treated similarly.


I think that makes it a broader topic, not directly linked to 
variations, which would be just one among various details that could be 
exposed via a DevTools "font inspector".


JK

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

Intent to implement: OpenType Variation Fonts

[Jonathan Kew]

We're proposing to implement support for OpenType Variation Fonts in Gecko.

From the Microsoft announcement[1] of Font Variations technology:

"...make use of a variety of font weights and styles to make your 
message stand out clearly. The problem has been that all those weights 
and styles—bold, semibold, regular, display, caption—are separate font 
files, which increases application size and slows down web page load 
times, especially on mobile phones. OpenType Font Variations provide all 
the weights and styles of a full font family in a single, compact file 
to improve applications size and web site responsiveness."


Other companies and designers have also been posting about the 
technology, which is arousing a good deal of interest in the font and 
web design communities.[2,3,4]


Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1302685

Link to standard: https://drafts.csswg.org/css-fonts-4/, particularly 
https://drafts.csswg.org/css-fonts-4/#low-level-font-variation-settings-control-the-font-variation-settings-property.


Platform coverage: All platforms, although implementation may proceed at 
different speeds depending on native font back-ends involved.


Estimated or target release: Not yet determined.

Preference behind which this will be implemented: 
layout.css.font-variations.enabled


DevTools bug: It's not yet clear to me whether specific DevTools work 
will be needed, beyond the support we'll automatically get for a new CSS 
property.


Do other browser engines implement this?
Blink: Google has discussed the intention to support variation fonts in 
Chrome (see [2]); I'm not sure if a formal "Intent to implement" mail is 
on file.
Edge: The Microsoft announcement[1] indicates a clear intention to 
support this technology.
WebKit: Experimental support is in WebKit nightly builds on OS X (see 
https://webkit.org/blog/7051/variable-fonts-on-the-web/).


Tests: Not yet written.

(Because of the already-existing support for font variations in the 
macOS font system, this will probably be the first platform backend to 
be implemented in Gecko. There's a try build linked from 
https://bugzilla.mozilla.org/show_bug.cgi?id=1321031#c5 for anyone who 
cares to play around with it already.)


JK


[1] 
https://www.microsoft.com/en-us/Typography/FontVariationsAnnouncement.aspx
[2] 
https://opensource.googleblog.com/2016/09/introducing-opentype-font-variations.html
[3] 
https://medium.com/@tiro/https-medium-com-tiro-introducing-opentype-variable-fonts-12ba6cd2369
[4] 
http://blog.typekit.com/2016/09/14/variable-fonts-a-new-kind-of-font-for-flexible-design/


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

Intent to deprecate and then unship: nsIScriptableDateFormat

[Jonathan Kew]

We're proposing to remove the XPCOM service nsIScriptableDateFormat, 
used for locale-appropriate formatting of date/time values.[1]


Front-end code that needs this functionality should move to the standard 
JS i18n APIs.[2,3]  I've got a bunch of patches just about ready to land 
in [4] that make this switch for most of our existing call-sites in 
mozilla-central.


Once we have switched all m-c users of nsIScriptableDateFormat over to 
Intl.DateTimeFormat and related standard APIs, we'd like to remove the 
nsIScriptableDateFormat interface itself (and ultimately the 
platform-specific implementations of nsIDateTimeFormat that back it). 
We don't want to maintain that code any longer, given that we now have a 
standards-based version of essentially equivalent functionality.


We may not be able to completely eliminate the old code until the 
ECMA402 Intl API is enabled on Android.[5]  But this message is intended 
as a heads-up that its doom is approaching


This will, of course, also affect code outside of mozilla-central -- 
e.g. comm-central, add-ons -- that uses nsIScriptableDateFormat.  Such 
code should also migrate to the standard JS APIs for date/time formatting.


I've filed [6] about deprecating the interface; once we have publicly 
done that, I expect the next step will be complete removal.


JK

[1] 
https://dxr.mozilla.org/mozilla-central/source/intl/locale/nsIScriptableDateFormat.idl

[2] https://tc39.github.io/ecma402/#datetimeformat-objects
[3] 
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/DateTimeFormat

[4] https://bugzilla.mozilla.org/show_bug.cgi?id=1301655
[5] https://bugzilla.mozilla.org/show_bug.cgi?id=1215252
[6] https://bugzilla.mozilla.org/show_bug.cgi?id=1313625

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

Re: Removing the Battery Status API?

[Jonathan Kew]

On 26/10/2016 08:30, Chris Peterson wrote:

What is the use case for the Battery Status API [0],
navigator.getBattery()? Can we remove the Battery API or perhaps
restrict it to non-web content like browser extensions or privileged web
apps? Chrome and Firefox support the Battery API, but neither Edge nor
WebKit have signaled an intent to implement it [3].

In theory, web developers would use the Battery API to save document
data before the battery dies, to ease off heavy computation when the
battery is low, or to implement the Firefox OS settings app. The real
world use cases, however, seem to be fingerprinting users [1] and
inflating Uber prices for desperate users with low batteries [2].


Maybe it was just me, but I initially (mis)interpreted this as a claim 
that Uber does this. The article at [2], however, doesn't say that. It 
does suggest this -could- be done, but not that it -has- been; and the 
Uber representative is quoted as saying that "[w]e absolutely don’t use 
that...".


I imagine the negative publicity if a company like Uber were caught 
actually doing this -- which seems like it wouldn't be too hard for an 
investigative reporter to confirm -- could well outweigh any benefit 
they might hope to reap.


JK

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

Re: Why I don't like DXR

[Jonathan Kew]

On 26/9/16 14:14, Honza Bambas wrote:

Today I tried to search for an identifier on DXR.  Something that was so
easy with MXR...

I wanted to find usage of a member called "io_pending".  Typing that
string to the DXR search field gives me a number of results that are
definitely not what I'm looking for, like lines containing
ERROR_IO_PENDING.  Using var:io_pending or ref:io_pending returns zero
results, despite the identifier is definitely used in the code base.
So, I tried to look only for assignments to this identifier (a member
variable, actually), so I typed "io_pending = " to the search field.
And what a surprise! I got the same result as for pure "io_pending", so
very far from what I was looking for and expecting to get.


Questions:

- how can I look for a string as always _case sensitive_ and _whole word
only_ ?  MXR was capable of searching for 'identifiers', why doesn't DXR
provide something simple as that as well?


This is only a partial answer, but if you prefix your search with "@" 
then it'll be case-sensitive, so simply


@io_pending

will get you closer to what you were looking for.

JK



- how can I simply limit search to be performed only in a certain
directory and it's sub-dirs?



Thanks.

-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

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Jonathan Kew]

On 1/6/16 00:51, Nicholas Nethercote wrote:

On Wed, Jun 1, 2016 at 2:37 AM, Jonathan Kew <jfkth...@gmail.com> wrote:


I took a quick look at a random one of these OOMs[1], and what strikes me
about it is that according to the crash report:

 Total Virtual Memory2147352576

 Available Virtual Memory122331136

 System Memory Use Percentage52

 Available Page File 4932567040

 Available Physical Memory   1790652416

 OOM Allocation Size 24

it seems like the system is still some way from running out of memory.
Available Virtual Memory is "only" 122MB, which admittedly isn't very much
in present-day terms, but stillwhy can't we successfully allocate a
24-byte block? Can those 122MB really be _so_ fragmented?!


I looked at a bunch of these yesterday. It's pretty common for OOM to
occur when there is around 200--250 MiB of available virtual memory;
122 MB is probably lower than normal.


Does this suggest that we're not sufficiently proactive about firing 
memory-pressure notifications, so that we'll free up memory from various 
caches, etc? It looks like we regard 128MB of available VM as "low" (see 
[1]) on Windows 32-bit, but apparently we're liable to suffer small-OOM 
crashes well before we reach that point. That doesn't seem like a 
healthy balance.


JK


[1] 
https://dxr.mozilla.org/mozilla-central/source/xpcom/base/AvailableMemoryTracker.cpp#497-498


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

Re: Common crashes due to MOZ_CRASH and MOZ_RELEASE_ASSERT

[Jonathan Kew]

On May 31, 2016, at 2:22 , Nicholas Nethercote
 wrote:



#2 is unannotated MOZ_CRASH() calls, i.e. there is no string
argument given. These are mostly OOMs, though there are a few
others in there. These ones should be annotated so they show up
separately.


I took a quick look at a random one of these OOMs[1], and what strikes 
me about it is that according to the crash report:


Total Virtual Memory2147352576

Available Virtual Memory122331136

System Memory Use Percentage52

Available Page File 4932567040

Available Physical Memory   1790652416

OOM Allocation Size 24

it seems like the system is still some way from running out of memory. 
Available Virtual Memory is "only" 122MB, which admittedly isn't very 
much in present-day terms, but stillwhy can't we successfully 
allocate a 24-byte block? Can those 122MB really be _so_ fragmented?!


JK

[1] 
https://crash-stats.mozilla.com/report/index/e59d2f18-2131-4f24-9f43-7038b2160524

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

Re: ICU proposing to drop support for WinXP (and OS X 10.6)

[Jonathan Kew]

On 28/4/16 18:11, Jeff Muizelaar wrote:

Do we use any of the OS specific parts of ICU?


I don't know.

But even if we don't, I suspect that once they drop support for XP / 
10.6, it won't be long before the project as a whole becomes 
increasingly difficult to build for those targets, as it'll start 
assuming support for compiler and/or runtime library features that 
aren't readily available there.


JK




-Jeff

On Thu, Apr 28, 2016 at 1:00 PM, Jonathan Kew <jfkth...@gmail.com
<mailto:jfkth...@gmail.com>> wrote:

We make considerable (and growing) use of ICU for various aspects of
i18n support in Gecko.†

The ICU project is proposing to drop support for Windows XP and OS X
10.6 in version 58; I guess this will be released sometime shortly
after Unicode 9.0, which is due to appear in June.

Markus (in the message forwarded below) mentions October 2016; I
assume that's when they expect to end support for ICU 57.

So we need to decide how we're going to respond to this. Some
options for consideration:

(a) Adopt ICU 58 when released, and drop Gecko support for WinXP and
OSX 10.6.

(b) Keep Gecko on ICU 57 and Unicode 8.0 until  when? AFAIK, we
have not made any firm decisions regarding EOL for Firefox on these
platforms.

(c) Keep Gecko on ICU 57 code, but update its data files to support
Unicode 9.0. This would take some effort on our side, though
_probably_ not very much.

(d) Push back against the ICU proposal to drop these platforms, and
see if we can convince them to delay it. (No guarantees, though at
least they're asking. If we had a specific end date to propose, I'd
guess that might help our case.)

In the case of either (b) or (c), we'd also need to take
responsibility for handling any critical security issues that are
discovered that affect the no-longer-maintained version we'd be
shipping (e.g. by backporting fixes from the latest upstream version).


Thoughts?

JK


† Except on Android, where we maintain separate code to support some
features; others are simply missing.


 Forwarded Message 
Subject:Re: [icu-design] [icu-support] Drop Windows XP and
OSX 10.6
support
Date:   Thu, 28 Apr 2016 08:55:55 -0700
From:   Markus Scherer <markus@gmail.com
<mailto:markus@gmail.com>>
To: icu-design <icu-des...@lists.sourceforge.net
<mailto:icu-des...@lists.sourceforge.net>>
CC: ICU support mailing list <icu-supp...@lists.sourceforge.net
<mailto:icu-supp...@lists.sourceforge.net>>,
Jonathan Kew <jonat...@jfkew.plus.com <mailto:jonat...@jfkew.plus.com>>



On Wed, Apr 27, 2016 at 4:30 PM, Steven Loomis <s...@icu-project.org
<mailto:s...@icu-project.org>
<mailto:s...@icu-project.org <mailto:s...@icu-project.org>>> wrote:

 Jonathan and other users,
   Please comment on whether dropping Windows XP for ICU 58 will
 cause significant problems.
   We discussed this for 57 (as per below) but no code changes
were made.


For ICU 57, we were just thinking of removing some Windows XP-specific
   synchronization code. We decided to just keep that for 57.

For ICU 58, we are looking at switching more code over to Windows
Vista/7/8 APIs because Windows XP and Windows Server 2003 only support
i18n APIs with LCID parameters and cannot support some languages at all.
Newer Windows versions added APIs that take language tag strings. This
is important for an i18n library on a major platform...

For how long do you plan to support Windows XP past October 2016? Could
you stay on ICU 57/CLDR 29/Unicode 8 until you stop supporting
Windows XP?

Also, Windows Vista seems to have very low market share and seems to be
getting dropped by vendors around the same time they drop XP.
Is it ok to skip Vista and set Windows 7 as the new base for ICU 58?

Best regards,
markus


___
dev-platform mailing list
dev-platform@lists.mozilla.org <mailto: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

ICU proposing to drop support for WinXP (and OS X 10.6)

[Jonathan Kew]

We make considerable (and growing) use of ICU for various aspects of 
i18n support in Gecko.†


The ICU project is proposing to drop support for Windows XP and OS X 
10.6 in version 58; I guess this will be released sometime shortly after 
Unicode 9.0, which is due to appear in June.


Markus (in the message forwarded below) mentions October 2016; I assume 
that's when they expect to end support for ICU 57.


So we need to decide how we're going to respond to this. Some options 
for consideration:


(a) Adopt ICU 58 when released, and drop Gecko support for WinXP and OSX 
10.6.


(b) Keep Gecko on ICU 57 and Unicode 8.0 until  when? AFAIK, we have 
not made any firm decisions regarding EOL for Firefox on these platforms.


(c) Keep Gecko on ICU 57 code, but update its data files to support 
Unicode 9.0. This would take some effort on our side, though _probably_ 
not very much.


(d) Push back against the ICU proposal to drop these platforms, and see 
if we can convince them to delay it. (No guarantees, though at least 
they're asking. If we had a specific end date to propose, I'd guess that 
might help our case.)


In the case of either (b) or (c), we'd also need to take responsibility 
for handling any critical security issues that are discovered that 
affect the no-longer-maintained version we'd be shipping (e.g. by 
backporting fixes from the latest upstream version).



Thoughts?

JK


† Except on Android, where we maintain separate code to support some 
features; others are simply missing.



 Forwarded Message 
Subject:Re: [icu-design] [icu-support] Drop Windows XP and OSX 10.6
support
Date:   Thu, 28 Apr 2016 08:55:55 -0700
From:   Markus Scherer <markus@gmail.com>
To: icu-design <icu-des...@lists.sourceforge.net>
CC: ICU support mailing list <icu-supp...@lists.sourceforge.net>,
Jonathan Kew <jonat...@jfkew.plus.com>



On Wed, Apr 27, 2016 at 4:30 PM, Steven Loomis <s...@icu-project.org
<mailto:s...@icu-project.org>> wrote:

Jonathan and other users,
  Please comment on whether dropping Windows XP for ICU 58 will
cause significant problems.
  We discussed this for 57 (as per below) but no code changes were 
made.



For ICU 57, we were just thinking of removing some Windows XP-specific
  synchronization code. We decided to just keep that for 57.

For ICU 58, we are looking at switching more code over to Windows
Vista/7/8 APIs because Windows XP and Windows Server 2003 only support
i18n APIs with LCID parameters and cannot support some languages at all.
Newer Windows versions added APIs that take language tag strings. This
is important for an i18n library on a major platform...

For how long do you plan to support Windows XP past October 2016? Could
you stay on ICU 57/CLDR 29/Unicode 8 until you stop supporting Windows XP?

Also, Windows Vista seems to have very low market share and seems to be
getting dropped by vendors around the same time they drop XP.
Is it ok to skip Vista and set Windows 7 as the new base for ICU 58?

Best regards,
markus


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

Re: Moving XP to ESR?

[Jonathan Kew]

On 20/4/16 20:14, Ben Hearsum wrote:

This would require a new update channel to support, because it would be
a unique line of code that isn't "release" or "esr".

It couldn't be implemented as a relbranch either, because we'd need CI
for it. You're basically proposing a long lived esr-like branch that we
only ship to XP users.

I suspect that backporting to this would get very difficult very
quickly. We'd be better off moving XP to ESR IMO.



I think you're right about that.

What we should keep in mind, though, is that if we decide to move XP 
users to ESR now, we are in effect making the decision to end support 
for them altogether in a year (when the ESR we've moved them to reaches 
EOL). At that point, the next ESR will be based on a mozilla-central 
that has long since abandoned XP, and there's no chance that we'll 
somehow magically backport it; nor, I think, will there be any appetite 
for extending the life of ESR45 beyond its normal term.


So the question we need to ask ourselves, before making a decision to 
move XP users to ESR, is whether we're prepared to commit ourselves 
_now_ to an EOL date roughly a year away, regardless of how XP usage 
develops over the coming year.


My hunch is that XP usage will decline pretty slowly, and I'm not very 
comfortable with making decisions now that imply we'll be abandoning 
those users in a year.


JK

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

Re: Dan Stillman's concerns about Extension Signing

[Jonathan Kew]

On 30/11/15 15:45, Gavin Sharp wrote:

and it's definitely the wrong thing to do.


Fundamentally the add-on signing system was designed with an important
trade-off in mind: security (ensuring no malicious add-ons are
installed/executed) vs. maintaining a healthy add-on ecosystem (ensuring
that building and distributing add-ons is as easy as it can be).

If your proposed alternative plan is "get rid of automatic signing", then
we know that it's going to significantly hamper Mozilla's ability to
maintain a healthy add-on ecosystem, and harm what were considered some
important add-on use cases. I don't think it strikes the right balance.

If your proposed alternative plan is something else, maybe it would help to
clarify it.



Perhaps if there were a mechanism whereby "trusted" add-on developers 
could have their add-ons -- or even just updates for 
previously-reviewed-and-signed add-ons -- automatically signed without 
having to jump through the validator/review hoops each time?


How would a developer acquire "trusted" status? By demonstrating a track 
record of producing add-ons that pass AMO review -- which may be a 
combination of automatic validation and/or human review.


And of course any add-on developer who is found to have abused their 
"trusted" status to sign and deploy malicious code would have that 
status revoked, in addition to the malicious add-on being blocked.


ISTM this would maintain most of the intended benefits of the signing 
system, while substantially smoothing the path for developers such as 
Dan who need to deliver frequent updates to their users.


Feasible?

JK

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

Re: Intent to ship: vertical text support (CSS writing-mode and related properties)

[Jonathan Kew]

On 1/7/15 11:21, Robert O'Callahan wrote:

So tables and flexbox will be fixed in 41 too?


Both of them are largely working in 41 at this point; I believe 
they're usable for most common use-cases. For tables, the main 
limitation is that caption is not yet placed correctly; that should 
follow in 42 (or possibly 41 if we decide it's upliftable). dholbert 
knows the status of flexbox better than I do.


JK



Congratulations on nearing the end of such a long and difficult project!

Rob
--
oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo
owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo
osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo
owohooo
osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o
o‘oRoaocoao,o’o oioso
oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo
owohooo
osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro
ooofo
otohoeo ofoioroeo ooofo ohoeololo.


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

Re: Intent to ship: vertical text support (CSS writing-mode and related properties)

[Jonathan Kew]

On 1/7/15 13:06, Sebastian Zartner wrote:

CSS Logical Properties Level 1 doesn't even in WD status yet. Therefore
I assume everything in there can still change fundamentally.
So are you sure logical properties should be shipped already? Could the
writing mode features perhaps be shipped independently from the logical
properties?


The writing-mode features are much less useful/usable without the 
support of logical properties. E.g. the default HTML and UA stylesheets 
require the use of logical properties to get reasonable rendering 
behavior in vertical writing modes for many elements. Author stylesheets 
and libraries that want to be usable with both horizontal and vertical 
modes will similarly need to use the logical properties.


(Note that Blink, for example, has been shipping prefixed logical 
properties along with its prefixed writing-mode implementation for some 
time. I don't think shipping one without the other is really workable; 
and given that prefixing is now out of fashion, and that the WG seems to 
be happy with the properties in the current ED, I think it's appropriate 
for us to move forward. I'd expect the browsers that are currently 
shipping prefixed versions based on older naming ideas will migrate to 
the currently-specified names when they unprefix their implementations.)


JK



This is not valuing the status of the implementation, just a note about
the status of the logical properties spec.

Sebastian



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

Intent to ship: vertical text support (CSS writing-mode and related properties)

[Jonathan Kew]

Following up on the message quoted below (Intent to ship on pre-release 
channels), we are now planning to ship support for CSS writing-mode, 
text-orientation, and related logical-direction properties (things like 
block-size and inline-size, margin-block-start, etc) enabled by default 
on all channels.


The RELEASE_BUILD condition that has been keeping these features 
disabled for release builds was removed in bug 1138384, which landed for 
Gecko 41. So unless we have reason to revert this during the Aurora/Beta 
period, we expect these features to ship in Firefox 41.


Relevant specifications:
  http://dev.w3.org/csswg/css-writing-modes-3/
  http://dev.w3.org/csswg/css-logical-props/

JK


On 2/3/15 12:59, Jonathan Kew wrote:

See [1] for additional background on this feature.

We are aiming to enable support for CSS writing-mode and related
features (i.e. vertical text support) in Gecko 39.[2]

This will be enabled behind an #ifndef RELEASE_BUILD condition, so that
for the time being, these features will be available by default in
developer builds, but not in the release version.

Once more key parts of CSS layout have been adapted to support vertical
mode, we'll remove the condition and enable writing-mode by default on
release as well as dev channels.[3]

cc'ing firefox-dev and dev-gaia lists, particularly to make people aware
that while we encourage experimentation with the new properties (please
test and file bugs!), you should not attempt to use them in front-end
code that will ship to release channels where writing-mode remains
disabled-by-default for now.

JK


[1]
https://www.mail-archive.com/dev-platform@lists.mozilla.org/msg12343.html
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1099032
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1138384


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

Intent to ship *on pre-release channels* : vertical text support (CSS writing-mode and related properties)

[Jonathan Kew]

See [1] for additional background on this feature.

We are aiming to enable support for CSS writing-mode and related 
features (i.e. vertical text support) in Gecko 39.[2]


This will be enabled behind an #ifndef RELEASE_BUILD condition, so that 
for the time being, these features will be available by default in 
developer builds, but not in the release version.


Once more key parts of CSS layout have been adapted to support vertical 
mode, we'll remove the condition and enable writing-mode by default on 
release as well as dev channels.[3]


cc'ing firefox-dev and dev-gaia lists, particularly to make people aware 
that while we encourage experimentation with the new properties (please 
test and file bugs!), you should not attempt to use them in front-end 
code that will ship to release channels where writing-mode remains 
disabled-by-default for now.


JK


[1] 
https://www.mail-archive.com/dev-platform@lists.mozilla.org/msg12343.html

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1099032
[3] https://bugzilla.mozilla.org/show_bug.cgi?id=1138384
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Fwd: [blink-dev] Intent to Ship: Plugin Power Saver Poster Images

[Jonathan Kew]

On 7/2/15 10:24, Kyle Huey wrote:

Why don't we just click to play everything?



Yes, we should do that. At least as an option, exposed in Preferences: 
something like


 [ ] Never auto-play video or audio
or
 [ ] Always show a Click to Play control for media

I'd suggest it belongs in Preferences / Content, right along with Block 
pop-up windows. Auto-playing videos (or audio) can be every bit as 
irritating as popups.


To quote from a long-time Firefox user's recent blog posting[1]:

# Give me a 'Play' button, and let me decide when (or whether) to click
# it. If you can configure Firefox - or allow me to configure it - so
# that it will never on any site, ever, no not even then or there, play
# a video without waiting for me to click on a button clearly labelled
# with a right-pointing arrow head of some sort... that would be a
# victory.

JK


[1] 
http://itreallyisupsidedown.blogspot.co.uk/2014/12/an-open-letter-to-mozilla.html



- Kyle
On Feb 7, 2015 5:38 PM, Jet Villegas jville...@mozilla.com wrote:


We should pick this up too.

--Jet

-- Forwarded message --
From: Jet Villegas W3C w...@junglecode.net
Date: Sat, Feb 7, 2015 at 1:36 AM
Subject: Fwd: [blink-dev] Intent to Ship: Plugin Power Saver Poster Images
To: j...@mozilla.com



-- Forwarded message --
From: tommy...@chromium.org
Date: Fri, Feb 6, 2015 at 4:35 PM
Subject: [blink-dev] Intent to Ship: Plugin Power Saver Poster Images
To: blink-...@chromium.org
Cc: Antoine Labour pi...@google.com, Rachel Blum gr...@google.com


Sending this because piman@ thought it was a good idea.


*Contact Emails:*
gr...@chromium.org, tommy...@chromium.org

*Spec:*
A specific portion of this design doc:


https://docs.google.com/document/d/1GQ-B3gWyWYX1cXf_B8mTK2ELSVwHqT-5bAERZqPliCo/edit#heading=h.bea8i8zdwtn7

*Summary:*
Plugin Power Saver pauses plugins deemed to be peripheral (small,
cross-origin). This feature is to allow web authors to specify a poster
image to be used in the paused state.

Usage:
   object data=http://b.tommycli.com/flash.swf;
type=application/x-shockwave-flash width=400 height=100
 param name=poster value=snapshot1.png /
   /object

*Motivation:*
Without a poster image, Chrome tries to automatically extract an
interesting keyframe during a short preroll.

- Plugin start can be deferred if there's a pre-provided poster image.
Better performance for users.
- If Chrome tries to extract a keyframe by analyzing frames, it could
choose mediocre frame to use.
- Keyframe extraction process itself takes up CPU time.

*Link to Intent to Implement:*
I implemented this before I was aware of this process. I sorry. It's behind
a content setting though, so no users will experience it unless they
explicitly opt in.

*Demo link:*
Use Chrome Canary. See http://a.tommycli.com/small_only_poster.html

See here for a video:
https://drive.google.com/open?id=0B-Use9bxumRNZE5Ub2VGYTk0c1E

*Compatibility Risk:*
I think it's minimal. The param tag is already supported. The 'poster'
parameter continues to be passed to the plugin, it's just re-used for a
different purpose. We could call it webkit-poster or something if you guys
are worried, but I'd prefer not to. If we take the feature away, the
browser will just ignore that parameter, and it shouldn't break anything.

*Ongoing technical constraints:*
None that I'm aware of.

*Will this feature be on all platforms?*
Windows, Mac, Linux, ChromeOS. Only the platforms with plugins.

*OWP Tracking bug*
None. Happy to make one if you guys want.

Link to entry on the feature dashboard http://www.chromestatus.com/
Also none, but happy to create also if you guys want.

To unsubscribe from this group and stop receiving emails from it, send an
email to blink-dev+unsubscr...@chromium.org.
___
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

Intent to implement and ship: vertical text support (CSS writing-mode and related properties)

[Jonathan Kew]

We are working on support for

  v
  e
  r
  t
  i
  c
  a
  l

text in Gecko. This will allow web content (and eventually complete web 
apps, if desired) to use vertical writing, as traditionally used in East 
Asia.


In addition to the CSS writing-mode property, this will involve support 
for text-orientation (which determines whether glyphs within vertical 
text remain upright as if in horizontal text, or are rotated 90° to 
render sideways), and for logical versions of many properties that 
refer to physical directions (such as margin-left, padding-top, 
border-bottom, min-width, max-height, etc. etc.), so that stylesheets -- 
in particular, the UA's built-in stylesheets -- can be written in a form 
that works for both horizontal and vertical content.


The top-level meta bug covering this work is 
https://bugzilla.mozilla.org/show_bug.cgi?id=145503.


The major standards relevant to this work are:
http://dev.w3.org/csswg/css-writing-modes/
http://dev.w3.org/csswg/css-logical-props/

This will be part of the standard Gecko engine, available to HTML 
content across all products and platforms. (At this time, we are not 
planning to support vertical writing modes for XUL.)


Our intention is to implement and release support for vertical text and 
layout in stages: initially, vertical mode will be supported for simple 
blocks and inline elements, including styling and editing text as 
expected. Some of the simpler form controls such as checkboxes, radio 
buttons, input fields and textareas should also be usable in the first 
release. However, more complex controls and layout constructs will not 
be vertical-enabled until later releases. Thus, the initial release 
should be adequate to support pages that want to display straightforward 
blocks of text using vertical writing (e.g. a news site, blog, or ebook 
reader).


There is already some vertical writing mode support in webkit, blink and 
IE, and tests are being developed (e.g. see 
http://www.gtalbot.org/BrowserBugsSection/CSS3WritingModes/). Current 
implementations are prefixed, and appear to be somewhat incomplete 
and/or based on earlier drafts of the specs, but there seems to be a 
good prospect of browsers converging as the specifications become more 
stable.


A good deal of the layout work to support writing modes has landed over 
the past year. It is controlled by the boolean pref 
layout.css.vertical-text.enabled, which is currently false by default.


We intend to enable this feature by toggling the vertical-text pref to 
true in https://bugzilla.mozilla.org/show_bug.cgi?id=1099032 once the 
code is sufficiently stable. This may be in Gecko 38, if the remaining 
dependencies can be resolved.


JK

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

Re: PSA: Non-unified builds no longer occurring on central/inbound and friends

[Jonathan Kew]

On 15/1/15 15:56, ISHIKAWA,chiaki wrote:


Debugging using gdb will be very difficult when the unified build
creates a source file on the fly (but it is removed, correct?).

No sane compiler/debugger combination can help me do
the source level debugging if the source code that the compiler compiled
is gone by the time debugger tries to find it...

Maybe I am missing something...



This shouldn't be a problem. The unified source file simply #includes 
the real sources, and so the debugger will know the paths to those.


JK


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

Re: Unified compilation is going to ride the train

[Jonathan Kew]

On 28/11/14 08:46, L. David Baron wrote:

On Friday 2014-11-28 10:12 +0900, Mike Hommey wrote:

The downside from doing so, though, is that non-unified build *will*
be broken, and code purity (right includes in the right sources,
mostly) won't be ensured. Do you think this is important enough to keep
non-unified builds around?


Another disadvantage here is that it will make adding or removing
source files harder, because you'll have to clean up the accumulated
nonunified bustage that shows up when files are shifted around
between unified files.  (This might be somewhat harder to fix a year
or two later than it is when causing it.)



IMO, it seems worth maintaining a non-unified build, to minimize this 
obscure fragility that will otherwise tend to accumulate over time. We 
could reduce the infrastructure load by doing the non-unified build on a 
more occasional basis; perhaps once a day would be enough?


We already have builds that (normally) happen once a day: nightlies. How 
about switching to a pattern where in addition to the nightly build, we 
also kick off a non-unified build for each platform on the same 
changeset? If that fails, we file a bug, and the normal expectation 
should be that such bugs can and will be fixed within a day (more or 
less), so the non-unified builds aren't left perma-broken.


JK

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

Re: Unified compilation is going to ride the train

[Jonathan Kew]

On 28/11/14 14:36, Ehsan Akhgari wrote:


The question is: what do we gain from doing that, technical purity
aside?  Note that as Mike mentioned, even with doing both unified and
non-unified builds, you may still get build failures when
adding/removing .cpp files, so keeping support for non-unified builds
will not fix that issue.


What is identified by non-unified build is a problem of responsibility.
Finding missing symbols is the responsibility of the person who is
adding references without including headers.  This is not at the charge
of the person who is adding/removing files from a moz.build.


That is not the only failure mode though.  You may for example get into
a situation where Unified_foo0.cpp includes windows.h and that header
#defines CreateEvent to something else, and you remove a file from the
unified compilation causing a file from Unified_foo1.cpp to fall into
Unified_foo0.cpp and break because of the CreateEvent macro that is now
in effect in that translation unit.

Also, as I have mentioned upthread, we have never been in a situation
where each source file includes all of the headers that it requires, and
unified builds only barely make that problem worse.


I know I made these mistake multiple times, and having B2G builds
reporting such issues was helpful at cleaning my patches at the earliest
time.


The point is, no amount of non-unified/unified build config combinations
can detect scenarios such as the above.


While it's true that there are failure scenarios that regular 
non-unified builds can not detect, I think the basic problem where a 
source file fails to #include (directly or indirectly) the headers that 
it needs, is common enough to be worth catching early. I've seen it 
happen any number of times, in both my patches and others'. I don't 
think we should allow that pattern to remain - and spread - in the tree, 
as it will become an increasing source of fragility and pain.


JK

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

Re: Intent to implement: WOFF2 webfont format

[Jonathan Kew]

On 8/10/14 15:44, Patrick McManus wrote:



On Wed, Oct 8, 2014 at 6:10 AM, Gervase Markham g...@mozilla.org
mailto:g...@mozilla.org wrote:

On 07/10/14 14:53, Patrick McManus wrote:
 content format negotiation is what accept is meant to do. Protocol level
 negotiation also allows designated intermediaries to potentially transcode
 between formats.

Do you know of any software which transcodes font formats on the fly as
they move across the network?


I'm not aware of font negotiation - but negotiation is most useful when
introducing new types (such as woff2). The google compression proxy
already does exactly that for images and people are successfully using
the AWS cloudfront proxy in environments where the same thing is done.
Accept is used to opt-in to webp on those services and that allows them
to avoid doing UA sniffing. They don't normally give firefox webp, but
if you make an add-on that changes the accept header to include webp
they will serve firefox that format. That's what we want to encourage
instead of UA sniffing.



But the model for webfonts is explicitly *not* to have a single URL that 
may be delivered in any of several formats, but rather to offer several 
distinct resources with different URLs, and let the browser decide which 
of them to request.


So the negotiation is handled within the browser, on the basis of the 
information provided in the CSS stylesheet, *prior* to sending any 
request for an actual font resource.


Given that this is the established model, defined in the spec for 
@font-face and implemented all over the place, I don't see much value in 
adding things to the Accept header for the actual font resource request.


Even where a service (like Google fonts, AIUI) is currently sniffing UA 
versions and varying its behavior, it wouldn't help to advertise WOFF2 
support via the Accept header for the font request, because that won't 
result in them serving the appropriate WOFF2-supporting CSS to Firefox. 
We need to get them to serve the right CSS; and once they do that 
(either universally, or based on UA sniffing) the existing @font-face 
mechanism will let us choose the best of the available resource formats 
for our use.




 imo you should add woff2 to the accept header.


as with webp, this is particularly useful to opt-in to a new format. I
agree that as a list of legacy formats and q-values is all rather
useless, but as a signal that you want something new that might not be
widely implemented its a pretty good thing. In this case its certainly
better than the txt/html based header being used.

Do you know of any software which pays attention to this header?

above.

http request header byte counts aren't something to be super concerned
with within reason (uris, cookies, and congestion control pretty much
determine your performance fate on the request side). And it sounds like
wrt fonts the accept header could be made more relevant and actually
smaller as well.


FWIW, when DNT was being created HTTP request header byte count seemed 
to be a pretty strong concern, which (AIUI) was why we ended up with 
DNT: 1 rather than something clearer like DoNotTrack: true.


JK

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

Re: Intent to implement: WOFF2 webfont format

[Jonathan Kew]

On 8/10/14 16:48, Patrick McManus wrote:



On Wed, Oct 8, 2014 at 11:44 AM, Anne van Kesteren ann...@annevk.nl
mailto:ann...@annevk.nl wrote:

On Wed, Oct 8, 2014 at 5:34 PM, Patrick McManus
mcma...@ducksong.com mailto:mcma...@ducksong.com wrote:
 intermediaries, as I mentioned before, are a big reason. It provides an
 opt-in opportunity for transcoding where appropriate (and I'm not claiming
 I'm up to speed on the ins and outs of font coding).

If the format is negotiated client-side before a URL is fetched,
that's not going to help, is it?


scenario - origin only enumerates ttf in the css, client requests ttf
(accept: woff2, */*), intermediary transcodes to woff2 assuming such a
transcoding is a meaningful operation.


Possible in theory, I guess; unlikely in practice. The compression 
algorithm used in WOFF2 is extremely asymmetrical, offering fast 
decoding but at the cost of slow encoding. The intent is that a large 
library like Google Fonts can pre-compress their fonts offline, and then 
benefit from serving smaller files; it's not expected to be suitable for 
on-the-fly compression.


JK

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

Re: Intent to implement: WOFF2 webfont format

[Jonathan Kew]

On 3/10/14 01:11, Jonas Sicking wrote:

On Thu, Oct 2, 2014 at 9:42 AM, Jonathan Kew jfkth...@gmail.com wrote:

Or do people need to hardcode
UA versions to know what UAs support it?



I believe that's what Google Fonts currently does, though IMO a better
approach is to serve CSS that offers both WOFF2 and older (more
widely-supported) formats, using the @font-face src descriptor's format
hint to let the browser choose the optimal resource depending on what it
supports:

   @font-face {
 font-family: MyFont;
 src: url(myfont.woff2) format(woff2),
  url(myfont.woff) format(woff),
  url(myfont.eot) format(embedded-opentype),
  url(myfont.ttf) format(truetype);
   }


Could we at least add woff2 to the Accept header when fetching fonts?



Sounds like a good suggestion in principle.

Wondering what we currently send in that header, I looked at some font 
requests in the DevTools Network panel... it seems we fetch fonts using


  Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

which doesn't look even remotely sensible. If we're going to adjust 
this, we should probably not simply add woff2 to this but do a more 
thorough cleanup job.


For comparison, Chrome appears to use simply

  Accept:*/*

and Safari, at least according to its inspector, doesn't send an Accept 
header at all when fetching fonts. (Or images, for that matter.)


I just filed bug 1077312. However, I don't think this needs to actually 
block the implementation of WOFF2 support.


JK

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

Intent to implement: WOFF2 webfont format

[Jonathan Kew]

The W3C WebFonts Working Group[1] has been working on designing and 
specifying a new compressed font format for the web, aiming to give 
significantly smaller file sizes than the existing WOFF format (to 
reduce bandwidth requirements), while remaining cheap to decode (for 
low-power devices).


The format is primarily based on earlier TrueType compression work 
(MicroType Express) by Monotype, and a new entropy coder (Brotli) 
developed by Google's data compression team in Zurich.


For more information about the WOFF2 format, see the FPWD spec[2] and 
current Editors' Draft.[3]


WOFF2 is currently supported by Chrome and Opera,[4] and the Google 
webfonts service is serving WOFF2-compressed fonts to browser versions 
that are known to support it.[5]


I'm proposing to add WOFF2 support to Gecko, based on the reference 
implementation code from the Google font and compression teams, found 
at [6].


Support for WOFF2 will be controlled by a new boolean pref 
gfx.downloadable_fonts.woff2.enabled. Initially this defaults to false 
for release builds, and true for nightlies; when we're ready to ship the 
feature on-by-default, we can simply flip the pref to true for all channels.


This work is happening in bugs [7] and [8], which I hope to land real 
soon now (in time for Gecko 35, if all goes well).


- JK


[1] http://www.w3.org/Fonts/WG/
[2] http://www.w3.org/TR/WOFF2/
[3] http://dev.w3.org/webfonts/WOFF2/spec/
[4] http://caniuse.com/#feat=woff2
[5] https://code.google.com/p/font-compression-reference/wiki/testing_woff2
[6] https://code.google.com/p/font-compression-reference/
[7] https://bugzilla.mozilla.org/show_bug.cgi?id=1066160
[8] https://bugzilla.mozilla.org/show_bug.cgi?id=1064737
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: WOFF2 webfont format

[Jonathan Kew]

On 2/10/14 16:20, Ralph Giles wrote:

On 2014-10-02 4:03 AM, Jonathan Kew wrote:


The format is primarily based on earlier TrueType compression work
(MicroType Express) by Monotype, and a new entropy coder (Brotli)
developed by Google's data compression team in Zurich.


What kind of filesize reductions do you see over ttf and woff1?



Results will vary considerably depending on the specific fonts involved, 
but a compressed size that is around 25-30% smaller than WOFF 1.0 would 
be typical for TrueType fonts.


See Appendix B of http://www.w3.org/TR/WOFF20ER/.

JK

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

Re: Icon fonts in FxOS

[Jonathan Kew]

On 17/6/14 13:17, Wilson Page wrote:
If we are using ligatures in our apps, this isn't a problem. If 
someone wants to remove PUA glyphs, great! But this has no reason to 
block.


Right, if we're embedding the font in our apps rather than installing it 
in the OS, then the PUA codepoints it includes aren't likely to be 
exposed to the world in general. Still, it'd be cleaner to eliminate 
them - especially if we expect this may be adopted by other authors as well.


Where is the script that generates this font maintained?

JK




*From: *Anne van Kesteren ann...@annevk.nl
*To: *Wilson Page wilsonp...@mozilla.com
*Cc: *Jonathan Kew j...@mozilla.com, Patryk Adamczyk 
padamc...@mozilla.com, John Daggett jdagg...@mozilla.com, 
b2g-internal b2g-inter...@mozilla.org, L. David Baron 
dba...@mozilla.com, Jaime Chen jac...@mozilla.com, Jonathan 
Watt jw...@mozilla.com, Jet Villegas j...@mozilla.com, Cameron 
McCormack hey...@gmail.com, Vivien vnico...@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 12:26:19 PM
*Subject: *Re: Icon fonts in FxOS

On Tue, Jun 17, 2014 at 1:19 PM, Wilson Page wilsonp...@mozilla.com 
wrote:

 Maybe I'm late to the party, but I don't know what the PUA issue is?

Code points carry semantics. If you assign meaning to unassigned code
points through fonts, you have created a portability problem. That is,
the font is required to make sense out of the code points. This was a
problem with Emoji until it was standardized by Unicode. It would be
good to avoid doing that again.


--
http://annevankesteren.nl/



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

Re: Icon fonts in FxOS

[Jonathan Kew]

On 17/6/14 11:52, 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.


I'm not exactly sure if glyphs are still assigned to code points 
within the generated font, is that an issue?
I looked at the embedded font in your CSS file, and it has the icons 
encoded at PUA character codes U+E001..E01D. If we could avoid exposing 
PUA codes at all, that would be helpful, as it eliminates any risk that 
authors actually use (non-portable) PUA codes to render the icons.


AFAIK, it should be possible to do this. In fontforge, the glyphs are 
referenced by name; they shouldn't need codepoints assigned.




IMO we should just treat icon assets in the same way we do images 
assets. Baking them into the platform seems like it could cause 
unnecessary complications further down the line, for negligible perf 
gains. 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.


If this works acceptably, can we close bug 951593 (and 1008458) as 
WontFix? That'd be awesome, IMO, as none of the proposed strategies 
there are really satisfactory. Where are we at w.r.t. the launch 
regression that was filed as bug 1002904? Has the data-URL version of 
the embedded font been tried there?


One other optimization you might want to consider - especially as the 
icon collection grows - is to have your build scripts generate a custom 
font subset for each app that's using them, instead of having all the 
apps (separately) load the complete set of icons even if they only need 
a few. So the original collection of graphics would be a shared 
building block resource, but the actual CSS that embeds the font would 
be individually generated for each app depending on its needs. 
(Presumably it'd be simple to scan the app's files and determine exactly 
which icons it needs.)


JK



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 Watt 
jw...@mozilla.com, L. David Baron dba...@mozilla.com, Jaime 
Chen jac...@mozilla.com, Vivien vnico...@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 11:31:18 AM
*Subject: *Re: Icon fonts in FxOS

On 17/6/14 11:10, Wilson Page wrote:

The gaia-icons font currently uses ligatures to place icons, see
here
https://github.com/gaia-components/gaia-icons/blob/master/style.css#L32.
The ligature character sequence is derived from the original
filename of the SVG source file in `images/`.

Is this what you were referring to?


OK, so if you're using ligatures to access the icon glyphs, can you 
modify the script that generates this font so that it does NOT assign 
PUA codepoints to the glyphs at all? It should be possible to leave 
them unencoded (i.e. with no entry in the font's cmap), so that the 
only way they can be accessed is via the ligature sequence.


I see you're embedding the generated font directly in a CSS file as a 
data-URL. How's the performance of this approach? It won't be quite as 
efficient as installing the font in the base OS, because each app that 
uses it will be instantiating its own separate copy, so there must be 
a memory and perf cost. But maybe it's good enough?


JK


*From: *Jet Villegas j...@mozilla.com
*To: *Wilson Page wilsonp...@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 Watt
jw...@mozilla.com, L. David Baron dba...@mozilla.com, Jaime
Chen jac...@mozilla.com, Vivien vnico...@mozilla.com,
sicking sick...@mozilla.com, Robert O'Callahan
rocalla...@mozilla.com, Jonathan Kew j...@mozilla.com,
mozilla.dev.platform group dev-platform@lists.mozilla.org
*Sent: *Tuesday, June 17, 2014 12:54:57 AM
*Subject: *Re: Icon fonts in FxOS

Wilson:

How difficult would it be to have your grunt script add a dlig
table to your font?
https://www.microsoft.com/typography/otspec/features_ae.htm#dlig
https://bugzilla.mozilla.org/show_bug.cgi?id=1008458#c22

--Jet

- Original Message -
From: Wilson Page wilsonp...@mozilla.com

We

Re: Icon fonts in FxOS

[Jonathan Kew]

On 16/6/14 22:09, James Burke wrote:

On 6/16/14, 12:34 PM, Jet Villegas wrote:

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.


The Gaia email app has gone privileged instead of certified just
recently. I expect that most partners will want to deliver the email app
with the same look and feel as the other apps that may be certified. If
that means the use of the icon font, we might have some trouble.

In general, I prefer solutions that do not require certified status, as
I hope more apps for gaia can move to privileged and even be delivered
through the Marketplace and for Android devices that can use Marketplace
apps.

I can appreciate there are other factors involved, just mentioning a
general desire to move more to apps out of the certified embrace. For
email, I will likely look for any alternatives that allow us to stay
privileged instead of reverting to certified.


OK, that's useful info, thanks! And it significantly changes the 
picture, as it means that implementing a platform-level solution 
targeting certified apps may be less useful than expected.


JK

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

Re: Intent to ship: Hyperlink Auditing (a ping)

[Jonathan Kew]

On 16/5/14 10:29, Tim Taubert wrote:

*Link to Standard*
http://www.whatwg.org/specs/web-apps/current-work/#hyperlink-auditing


A couple of quotes from there:

User agents should allow the user to adjust this behavior, for example 
in conjunction with a setting that disables the sending of HTTP Referer 
(sic) headers. Based on the user's preferences, UAs may either ignore 
the ping attribute altogether, or selectively ignore URLs in the list 
(e.g. ignoring any third-party URLs).


When the ping attribute is present, user agents should clearly indicate 
to the user that following the hyperlink will also cause secondary 
requests to be sent in the background, possibly including listing the 
actual target URLs.


What's our story here? It's not obvious to me from a (brief) look at the 
bugs whether we have addressed these issues. Without them, I find the 
idea of a ping quite disturbing...


JK


*Summary*
Anchor tags can have a ping attribute that sends asynchronous pings
after or while navigating to the target page for auditing purposes.

*Motivation*
Since bug 786347 landed our Hyperlink Auditing implementation follows
the spec but is disabled by default. If a website wants to audit
navigation to outgoing links (think Google, DuckDuckGo, Facebook, etc.)
it nowadays has to either link to an internal page to record and then
redirect to the target page or use sync XHRs. a ping allows to
asynchronously (and with low prio) send one or multiple pings after or
while we start loading the target page.

*Bug to enable by default*
https://bugzilla.mozilla.org/show_bug.cgi?id=951104

*Notes*
The navigator.sendBeacon() API is a superset of a ping. a ping
allows for lightweight navigation pings without having to use JavaScript.

The number of pings per link is currently limited to 1
(browser.send_pings.max_per_link). Chrome does not limit the number of
pings, we should look into raising or disabling the limit.


- Tim




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

Re: Intent to ship: Hyperlink Auditing (a ping)

[Jonathan Kew]

On 16/5/14 13:02, L. David Baron wrote:

On Friday 2014-05-16 12:49 +0100, Jonathan Kew wrote:

When I click a Google search result (for example), I can see --
thanks to the status overlay that shows the URLs being requested --
that it's redirecting me via a Google URL that is presumably being
used to track me.


You actually don't, since Google doesn't add the tracking stuff to
the link until you click it.  But it adds it early enough in click
handling so that it affects what happens when you click the link.

To see this:
  1. search for something on Google
  2. hover over the link in a result; you see a normal link
  3. right-click to get the link's context menu
  4. hover over the link again

In step (2) you see the link on its own; in step (4) you see the
version with the tracking redirect added.


Yes; but even if I simply click the link at step (2), I see (via the 
status overlay) that it actually sends me via a Google tracking URL 
instead of directly to the destination. I remember noticing (and 
disapproving) when this behavior was first introduced to their search 
results.


At that point, of course, it's too late to decide I didn't want Google 
to know that I clicked that link -- but in the process, I've learned 
something: that Google search results are not simply links for my 
browser to follow, but booby-traps that will report back to Google 
before taking me to the target page. And if I don't like that, I might 
decide to look for a different search engine, or to be more careful what 
I do with results in future.


Replacing the redirects with a ping will completely hide this from me; 
in that case, I might never have noticed that clicking those links was 
anything more than a simple go to this page.


Maybe that's OK, but I do think this changes things in a significant 
way, and we should give some priority to addressing the concerns. Maybe 
the send-ping preference should be exposed at a similar level to Do Not 
Track?


For comparison, I really like the fact that when an email comes with 
return receipt request, Thunderbird will ask me something like the 
sender asked to be notified when you open this message... and let me 
choose whether or not to respond. While I guess a ping will probably 
become so widespread that I wouldn't want to be prompted every time 
(Google asked to be notified when you click this link...), some kind 
of user notification and UI to opt in/out of tracking does seem needed here.


JK

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

Re: Intent to ship: Hyperlink Auditing (a ping)

[Jonathan Kew]

On 16/5/14 14:37, Kyle Huey wrote:

On Fri, May 16, 2014 at 6:30 AM, Curtis Koenig curt...@mozilla.com wrote:


On 16 May, 2014, at 09:11 AM, Tim Taubert ttaub...@mozilla.com wrote:


I think it really might make sense to remove the
preferences altogether



Given our stance on privacy[1] and commitment to Real Choices, Sensible 
Settings and User Control; I don’t believe removing the users ability to 
control this preference would be a positive move. David’s point is more correct 
in that we need to be careful as to how the preference is exposed. We could 
also do something very innovative in this case like what is done with do not 
track. We could default to allowing all requests (which would honor the spec) 
but allow the users to change the pref to 2 other states. One being only allow 
pings from the sites I specify and the final one being don’t allow any at all. 
With accompanying text that explains the tradeoffs/benefits/pain of each 
setting. This would help us both keep inline with the goal of Hyperlink 
Auditing and balance our stance on privacy.

[1] https://wiki.mozilla.org/Privacy/Principles
--
Curtis

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


The point being made is that the preference is not a real choice.  If
you disable this feature you can still be tracked in the exact same
way by methods that exist today and are not covered by the preference.



Yes; but the methods being used by at (least some major) sites are 
visible to the user, which makes them less insidious than an 
invisible-by-design tracking feature.


If we implement a ping, and make it on-by-default (but with a user 
preference to turn it off), we can reasonably expect sites to use this 
as their tracking method in place of redirects, etc. And if they hten 
detect (can they?) that the user has turned off pings and fall back to 
other methods to track the user - who by disabling it has expressed a 
desire not to be tracked - this puts them in much the same category as 
those who decide to stop honoring Do Not Track.


We can't force sites to honor DNT, and we can't prevent them working 
around user-disabled a ping. But in both cases we can and should (IMO) 
provide a simple means for the user to express a wish about tracking. 
Respectable sites will interoperate nicely with it; those that decide to 
circumvent it should be publicly shamed.


JK

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

Re: Controlling font size as per system DPI in Windows

[Jonathan Kew]

On 1/4/14 13:05, bhargava.animes...@gmail.com wrote:

Hi,

We have a property in greprefs.js layout.css.dpi by which we can
control pixel size , but this doesn't work in Windows. There is
another property layout.css.devPixelsPerPx which control font size
in Windows but this needs to be modified each time as per system DPI.
I need to show font size as per system DPI. How can this be achieved?
I am using gecko SDK 14.0.1.


Set layout.css.devPixelsPerPx to -1.0. However, I expect this will be 
quite buggy in 14.0.1; you need a newer version of Gecko (at least Gecko 
22 or thereabouts, IIRC) for better Windows DPI-setting support.


See https://bugzilla.mozilla.org/show_bug.cgi?id=820679 and its 
dependencies.


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

Re: Including Adobe CMaps

[Jonathan Kew]

On 28/2/14 11:44, Gervase Markham wrote:

On 26/02/14 20:21, Jonathan Kew wrote:

Lets turn this question around. If we had an on-demand way to load
stuff like this, what else would we want to load on demand?


A few examples:

Spell-checking dictionaries
Hyphenation tables
Fonts for additional scripts


If this came with an update system (i.e. a way for Firefox to know the
data is out of date) then the Public Suffix List would benefit. It's a
small amount of data, but non-ideal if it goes stale.

But maybe that's scope creep.


Presumably we always want the complete PSL available. So it really 
should be part of the base product, not a [try-to-]load-on-demand resource.


Isn't it sufficient to update that with each new Firefox release?

If there is data such as this that is always included, but would benefit 
from being updated separately from the regular release schedule (without 
actually pushing out a dot release or chemspill), I think that's a 
rather different use-case, even if a common underlying mechanism could 
perhaps end up serving both.


JK

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

Re: Including Adobe CMaps

[Jonathan Kew]

On 26/2/14 19:57, Andreas Gal wrote:


Lets turn this question around. If we had an on-demand way to load stuff like 
this, what else would we want to load on demand?


A few examples:

Spell-checking dictionaries
Hyphenation tables
Fonts for additional scripts

JK




Andreas

On Feb 26, 2014, at 8:53 PM, Bobby Holley bobbyhol...@gmail.com wrote:


That's still a ton for something that most of our users will not (or will
rarely) use. I think we absolutely need to get an on-demand story for this
kind of stuff. It isn't the first time it has come up.

bholley


On Wed, Feb 26, 2014 at 11:38 AM, Brendan Dahl bd...@mozilla.com wrote:


Yury Delendik worked on reformatting the files a bit and was able to get
them down to 1.1MB binary which gzips to 990KB. This seems like a
reasonable size to me and involves a lot less work than setting up a
process for distributing these files via CDN.

Brendan

On Feb 24, 2014, at 10:14 PM, Rik Cabanier caban...@gmail.com wrote:





On Mon, Feb 24, 2014 at 5:01 PM, Andreas Gal andreas@gmail.com

wrote:


My assumption is that certain users only need certain CMaps because they

tend to read only documents in certain languages. This seems like something
we can really optimize and avoid ahead-of-time download cost for.


So, you'd only install the Korean CMaps if the language is Korean?
The problem with that is that if a user might install a English version

of Firefox but still open Korean PDFs (which will then display as junk)



The fact that we don't do this yet doesn't seem like a good criteria.

There is a lot of good things we aren't doing yet. You can be the first to
change that on this particular topic, if it technically makes sense.


Load-on-demand (with an option to download all of them) seems like a

nice solution. A large majority of users will never need CMaps or only a
very small subset.


On Feb 25, 2014, at 1:27 AM, Brendan Dahl bd...@mozilla.com wrote:


It's certainly possible to load dynamically. Do we currently do this

for any other Firefox resources?


 From what I've seen, many PDF's use CMaps even if they don't

necessarily have CJK characters, so it may just be better to include them.
FWIW both Popper and Mupdf embed the CMaps.


Brendan

On Feb 24, 2014, at 3:01 PM, Andreas Gal andreas@gmail.com

wrote:



Is this something we could load dynamically and offline cache?

Andreas

Sent from Mobile.


On Feb 24, 2014, at 23:41, Brendan Dahl bd...@mozilla.com wrote:

PDF.js plans to soon start including and using Adobe CMap files for

converting character codes to character id's(CIDs) and mapping character
codes to unicode values. This will fix a number of bugs in PDF.js and will
improve our support for Chinese, Korean, and Japanese(CJK) documents.


I wanted to inform dev-platform because there are quite a few files

and they are large. The files are loaded lazily as needed so they shouldn't
affect the size of Firefox when running, but they will affect the
installation size. There are 168 files with an average size of ~40KB, and
all of the files together are roughly:

6.9M
2.2M when gzipped

http://sourceforge.net/adobe/cmap/wiki/Home/




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

Re: Platform-specific nsICollation implementations

[Jonathan Kew]

On 25/11/13 11:16, Henri Sivonen wrote:

Now that we have ICU in the tree, do we still need platform-specific
nsICollation implementations? In particular, the Windows and Unix back
ends look legacy enough that it seems that making nsICollation
ICU-backed would be a win.



In particular, this would allow us to ensure consistent behavior across 
platforms, which I doubt the current implementations can provide. (And 
it'd be a good opportunity to document more carefully what the flags in 
nsICollation.idl really mean, or fix them if they're broken... 
kCollationCaseInsensitiveAscii, I'm looking at you!)


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

Re: What platform features can we kill?

[Jonathan Kew]

On 9/10/13 17:18, Boris Zbarsky wrote:

On 10/9/13 12:01 PM, Gervase Markham wrote:

In the spirit of learning from this, what's next on the chopping block?



* XSLT (Chrome have already announced they will remove it:


Have they? I admit I haven't made it through every post in their 
discussion threads, but AFAICS, some people from Chrome have expressed 
an interest in removing it, but this suggestion generated considerable 
debate (including some definite opposition to the idea).




We'd need to do the same extension thing they're proposing or something;
this is used in the wild for sites that people care about.


It's used in the wild on the web, and I've also known it to be used 
locally as a convenient tool to present views of data files that happen 
to be maintained in XML format.


Moving it to an extension (so that it isn't available unless the user is 
aware of it and explicitly installs support) would seem like a negative 
step, though if usage is rare/specialized enough, perhaps it would be 
OK. But I think we should be very hesitant to entirely remove XSLT 
support from the platform.


JK

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

Re: Introducing Brotli - an alternative to LZMA

[Jonathan Kew]

On 11/9/13 14:12, Jeff Muizelaar wrote:


Brotli increases the window size and thus memory requirement to 4MB
which is quite a bit. It's also larger than the cache size on mobile
devices which is currently around 1MB so it would be interesting to
see decompression speeds on small cache devices.


That's an interesting point, which we should certainly raise with the 
developers.



Brotli seems to have similar design to OodleLZHLW
(http://www.radgametools.com/oodlecompressors.htm) it would of course
be interesting to know how it competes.


It would, although that looks like a commercial product and thus not 
something we could adopt as part of the open Web platform, even if it 
appears to have particularly desirable performance.


Thanks,

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

Introducing Brotli - an alternative to LZMA

[Jonathan Kew]

[tl;dr]

Considering the use of LZMA [or bzip2?] somewhere in the web platform, 
for improved compression compared to gzip algorithms? Take a look at a 
new project, Brotli, an alternative with several potential benefits:


  - formal specification will be available
  - commitment to security review
  - simpler implementation (small delta from existing Flate decoder)
  - substantially faster decompression

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -

This message is intended to make people aware of a new (upcoming) data 
compression algorithm known as Brotli that (IMO) we may want to adopt 
within Gecko.


The background to this is the investigation currently being done in the 
W3C WebFonts Working Group into a possible WOFF2 format, as a 
next-generation successor to WOFF with improved compression. Initially, 
it was proposed that WOFF2 would rely on LZMA for entropy coding, as 
this is known to give substantially better compression than the Flate 
(gzip) algorithm used in the current WOFF spec.


However, several concerns regarding LZMA (lack of formal specification 
combined with complexity of the code, making careful security review and 
maintenance difficult; relatively slow decompression) led the 
compression team at Google to begin exploring an alternative. The basic 
idea is to take the existing Flate algorithm and make some fairly minor 
adjustments that can result in significantly improved compression 
ratios, while avoiding the aspects of LZMA that lead to slower 
decompression.


While this work was originally motivated by webfont requirements, the 
new compression format may be a good fit for other applications as well. 
In particular, I'm thinking of bug 366559, which suggests supporting 
LZMA as an HTTP transfer encoding and bug 173044 (similar, about bzip).


There's a short presentation available[1] that gives a brief overview of 
Brotli (presented within the context of the WOFF2 work). We expect that 
reference code and a draft specification will be available for review 
within the next few weeks. Further details should appear on the W3C Web 
Fonts WG mailing list[2] (though the actual standardization work for the 
new format will probably end up elsewhere, e.g. in IETF).


As this project matures, it'd be great if some Mozilla people with 
interest/expertise in compression and in security review could take a 
look and help to refine the spec and code, and determine whether this is 
the right technology for us to adopt.


JK

[1] 
https://docs.google.com/presentation/d/1aigINmRR7fw_ml8rz0rJ3NTv08Qb3n6lZ_qvmxo8CzQ/present

[2] http://lists.w3.org/Archives/Public/public-webfonts-wg/
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Including algorithm just to get std::min and std::max

[Jonathan Kew]

On 9/9/13 00:29, Nicholas Cameron wrote:


I don't think these kind of time improvements make it worth
duplicating std library code into mfbt, we may as well just pull in
the headers and forget about it.


+1 to that.

We've been trying to get *away* from requiring special Mozilla-isms in 
our codebase, and use standard C++ instead. Let's not reintroduce stuff 
like that just for the sake of a few seconds on a 20-minute clobber 
build, or milliseconds in a dep build.


Reducing unnecessary #include usage is a good thing, of course; but 
replacing standard library #includes with custom Mozilla ones for the 
sake of (extremely) marginal build-time wins is not.


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

Re: Feedback wanted on font checker

[Jonathan Kew]

On 9/8/13 15:36, Axel Hecht wrote: So I created three test cases based 
on the data I see, Greek and

 Bulgarian monospace and Hindi sans-serif. They're linked off of
 http://pike.github.io/fonts/. It's prerendered images on the left
 column, and regular text on the right.

 Hindi is blank squares as I expect, but for Bulgarian and Greek, I see
 Bulgarian and Greek letters on my 1.1 unagi.

 It'd be great to get some help as to what I actually see there. Oh fonts.

Font fallback means that if there's ANY font on your Unagi that includes 
Cyrillic (or Greek) characters, you'll see them rather than blank boxes, 
even if that font isn't what's listed in the font.name prefs (And it may 
not even be monospaced... it's probably falling back to Open Sans or 
Charis SIL or something.)


JK

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

Re: Feedback wanted on font checker

[Jonathan Kew]

On 8/8/13 15:17, Axel Hecht wrote:

Hi,

I'm looking for a review of some rather hacky tool I just created to see
if the fonts on b2g actually support a particular language.

https://github.com/Pike/font-tool

Basic outline of what the tool does:

Parses langGroups.properties to see which locale has which group, with
default to x-unicode.

Preprocesses all.js with -DANDROID -DMOZ_WIDGET_GONK, and parses
pref(font.name)

Uses fc-scan to find all the fonts in moztt and
platform/frameworks/base, pick those with style Regular.

Uses fc-validate to figure out if those fonts actually support the given
locale.

Example, Bulgarian seems to be missing 60 glyphs for monospace:

python buildfonts.py /src/central/mozilla-central/ bg
monospace
moztt/SourceCodePro-1.017/SourceCodePro-Regular.ttf:0 Missing 60
glyph(s) to satisfy the coverage for bg language


That sounds plausible, as SourceCodePro does not yet have Cyrillic 
support. (Do we have Droid Sans Mono on the device? If so, we should 
probably be falling back to that.)



sans-serif
base/data/fonts/Roboto-Regular.ttf:0 Satisfy the coverage for bg language
serif
moztt/CharisSILCompact-4.114/CharisSILCompact-R.ttf:0 Satisfy the
coverage for bg language

Couter example seems to be Chinese, the unagi shows something, while my
tool reports 13k missing glyphs for zh-TW.


Not surprising, really. Two issues here: first, we rely on font fallback 
to find a font that supports a given character, if the default specified 
by prefs doesn't have it. In the case of Chinese, I think we tend to 
list a Latin font so that it will be used (rather than the often-ugly 
Latin glyphs in a Chinese font) for Latin characters, which are commonly 
found mixed in to Chinese pages, and then rely on fallback to find the 
actual Chinese font when needed.


So you'd need to check the fallback font (probably Droid Sans Fallback, 
unless there's something else we're shipping on b2g), not necessarily 
the font listed in prefs.


And second, validating the character coverage of a Chinese font is a 
bit tricky - you'll need to specify more carefully what the exact 
requirements are. For Chinese, there are tens of thousands of glyphs 
that are part of the writing system, but most everyday text will only 
use a relatively small subset - still several thousand, but nowhere near 
everything.


The file fontconfig/tree/fc-lang/zh_tw.orth notes that it is Made by 
trimming the Big5 - unicode mapping down to just Chinese glyphs, which 
results in a list of around 13,000 characters. In contrast, according to 
[1] (though estimates will vary, no doubt), An educated Chinese person 
will know about 8,000 characters, but you will only need about 2-3,000 
to be able to read a newspaper. So for most practical purposes, that 
collection should be (more than) sufficient.


If we're using Droid Sans Fallback, I believe it supports somewhere well 
over 20,000 Chinese characters, so that probably includes all those in 
fontconfig's list - but that still doesn't mean it has *every* possible 
Chinese character.


JK


[1] 
http://www.bbc.co.uk/languages/chinese/real_chinese/mini_guides/characters/characters_howmany.shtml


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

Re: Some data on mozilla-inbound

[Jonathan Kew]

On 23/4/13 09:58, Neil wrote:

Kartikaya Gupta wrote:


The vast majority of changesets that are backed out from inbound are
detectable on a try push


Hopefully a push never burns all platforms because the developer tried
it locally first, but stranger things have happened! But what I'm most
interested in is whether patches are more likely to be backed out for
build or test failures. Perhaps if we could optimise our use of Try then
that would reduce the load on inbound. For example:

* At first, the push is built on one fast and readily available
  platform (linux64 is often mentioned)
* If this builds, then all platforms build
* Only once all platforms have built are tests run

This would avoid running tests for pushes that are known not to build on
all platforms.



OTOH, it would significantly extend the time a developer has to wait 
before tryserver test results begin to appear. Which I think people 
would find discouraging.


JK

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

Re: End of life for tinderbox.mozilla.org

[Jonathan Kew]

On 3/4/13 15:32, Ed Morley wrote:
 On 03 April 2013 15:21:33, Neil wrote:
 Since tinderboxpushlog no longer uses tinderbox, maybe it should get
 renamed ;-)

 Agreed - TBPL's successor is going to be called something other than
 TBPL2 (name chosen so far is treeherder).

I presume it'll be at https://ent.mozilla.org/, then.

JK

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

Re: Synchronous loading of data: URLs

[Jonathan Kew]

On 11/12/12 10:51, Neil wrote:

Neil wrote:


Jonathan Kew wrote:


You shouldn't normally see a flash of fallback text unless the font
is particularly slow to load; the text should be invisible until the
font is available. We aim to hide the text until the font is ready,
unless it takes more than a few seconds to load. (The timeout is
configurable - see gfx.downloadable_fonts.fallback_delay - so if
you've set it lower than the default of 3000ms, you'll see visible
fallback more frequently.)


This is a debug build on a machine with an IDE disk, so it's possible
it might be taking more than three seconds to load the font. I'll try
tweaking the delay to see whether it helps.


Increasing the preference to 1 made no difference.



Could you give an example of a page where you see this happening? I 
wonder if it's doing something like inserting the stylesheet dynamically 
after the page has initially loaded.


JK

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

Re: Synchronous loading of data: URLs

[Jonathan Kew]

On 11/12/12 12:18, Henri Sivonen wrote:

On Wed, Dec 5, 2012 at 5:37 AM, John Daggett
moz.li...@windingwisteria.com wrote:

Fonts are loaded when used so font loading won't start until the
contents using a particular font are laid out.


That seems like a problem for JS-driven display. A big problem in the
canvas case and at least an annoyance when a JS program drives the
input to CSS layout.


This optimization simply eliminates the extra reflow required by spinning the 
event
loop.


That makes sense. However, it’s still not nice for data: to be magic
for the JS-driven case. For JS-driven cases, I think the platform
really needs an async API that lets a JS program say “start loading
this font now” and then some callback for getting notified
asynchronously (regardless of URL scheme) when the font has been
loaded so that it is ready for use with canvas or ready for use with
CSS without a flash of unfontified content.



This sounds like what Font Load events and the FontLoader interface[1] 
are trying to address. I think that spec is still some way from being 
stable and ready to implement, though.


JK

[1] http://dev.w3.org/csswg/css3-fonts/#font-load-events

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

Re: Freetype autohinter (was Re: Proposed W3C Charter: Web Fonts Working Group)

[Jonathan Kew]

On 17/10/12 14:17, Zack Weinberg wrote:

On 2012-10-17 4:07 AM, Henri Sivonen wrote:

On Tue, Oct 16, 2012 at 9:16 PM, Zack Weinberg za...@panix.com wrote:

Until quite recently the FreeType autohinter did a very bad job on a
surprising number of popular webfonts - rendering letters in the same
word
with inconsistent perceptual x-height, for instance.


What kind of fonts? Bicameral or other? Display fonts or more normal
fonts?


I've mostly noticed it in bicameral Latin serif fonts.  It's more
obvious at display sizes but can show up at body-copy sizes as well. See
http://savannah.nongnu.org/file/quattrocento-irregular-x-height.png?file_id=25578
for an example; according to Werner Lemberg, the autohinter could not
handle fonts whose serif height exceeds an internal threshold.
Unfortunately, that seems to include the bulk of the serif fonts on
Google Web Fonts!

http://savannah.nongnu.org/bugs/?36091 is the whole bug report.  It _is_
fixed as of FreeType 2.4.11 -- but it looks like our bundled version is
older than that (2.4.9 according to modules/freetype2/README.moz-patches)


I believe that's correct - the most recent update we took was in bug 733512.

AFAICS, the latest stable release is currently 2.4.10; do you know when 
2.4.11 is expected?


JK

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

Re: Proposed W3C Charter: Web Fonts Working Group

[Jonathan Kew]

On 16/10/12 14:42, Henri Sivonen wrote:

On Thu, Oct 11, 2012 at 7:54 PM, L. David Baron dba...@dbaron.org wrote:

W3C is proposing a revised charter for the Web Fonts Working Group.
For more details, see:
http://lists.w3.org/Archives/Public/public-new-work/2012Sep/0016.html
http://www.w3.org/2012/06/WebFonts/draft-charter-ac.html

Mozilla has the opportunity to send comments or objections through
Monday, October 22.  Please reply to this thread if you think
there's something we should say.


Even though there seem to be strong reasons for incompatible changes
to WOFF, it scares me that they are presented as an enhancement to
WOFF as opposed to being presented as a new incompatible format. To
me, it seems essential that the new format not be treated as a mere
enhancement to WOFF for the purpose of the format() specifier in CSS.
That is, the new format should not use format(woff) in CSS but
something else even if only format(woff2). Maybe this is so obvious
that it isn't written in the charter because it is too obvious or
maybe this is a matter that's considered to be out of scope for the
charter, but, still, discussing an incompatible format as a mere
enhancement without affirming a plan to call it something different
for the purposes of the different format specifier scares me.


It's clear to me (and I think other WG members would readily agree) that 
any new, incompatible format, even if referred to as WOFF 2.0, would 
need to be clearly distinguished from the existing WOFF 1.0 - both for 
purposes of the CSS format-specifier hint and by the signature field in 
the file header - to allow existing UAs that support (only) WOFF 1.0 to 
easily skip/reject WOFF 2.0 files.


I don't think you need to be concerned that the Web Fonts WG is likely 
to define a new, incompatible WOFF 2.0 format without addressing this 
aspect.


JK

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

Re: W3C Proposed Recommendation: WOFF File Format 1.0

[Jonathan Kew]

On 15/10/12 15:28, alexander.alis...@gmail.com wrote:

 Any properly licensed TrueType/OpenType/Open Font Format file can be packaged in 
WOFF format for Web use.

anybody else see problems here.  W3C its main goal is to open standards 
right ?


No, I don't see a problem there.

WOFF *is* an open standard.

The fact that it's an open standard has nothing to do with the licensing 
of any content (fonts) delivered in this format, whether extremely free 
and open or highly restrictive - just as the HTTP protocol, for example, 
may be used to deliver either free or proprietary content.


That sentence, IMO, is merely a reminder that packaging a font file in 
WOFF format does not in itself magically alter or remove any copyright 
restrictions or licensing terms that may be applicable; and conversely, 
that a font delivered as a WOFF file is still subject to whatever terms 
the font owner chooses (just like any other content, regardless of how 
it is packaged).

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

Re: Gecko switched to use standard integer types

[Jonathan Kew]

On 22/8/12 17:35, Ehsan Akhgari wrote:

I just landed the patches in bug 579517 which switch all of the code in
mozilla-central and comm-central [1] to use the standard integer types
as opposed to NSPR integer types.  Here's what this means to you:

* If you're a developer, this will most likely bitrot your patches.  You
can use this script [2] in order to unbitrot your patches if you use
mercurial queues.



[2] https://bugzilla.mozilla.org/attachment.cgi?id=650572


Beware that this script is slightly obsolete, inasmuch as it converts 
PRIntn/PRUintn to int32_t/uint32_t (should be int/unsigned).


JK

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