Intent to Prototype: text-decoration-skip-ink

[Charlie Marlow]

Summary: text-decoration-skip-ink is a CSS feature that makes underlines and 
overlines skip around the text, instead of painting behind it. There is a 
picture of this effect on the standards link.

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

Standard: 
https://drafts.csswg.org/css-text-decor-4/#text-decoration-skip-ink-property 
 

Platform coverage: This will be available on all platforms using Gecko.

Preference: It will be preffed off by default under 
layout.css.text-decoration-skip-ink.enabled

DevTools bug: This is a minor, cosmetic visual feature with no clear 
opportunity for DevTools integration. 

Other browsers: It works in both Chrome and Safari.

Web-platform-tests: Initial reftests will be landed with the first patch, they 
are here: https://phabricator.services.mozilla.com/D40707 
 

Secure contexts: No, it is not restricted to secure contexts in other browsers, 
so for compatibility we don’t restrict it either.


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

[intent to deploy] Changes to show_bug.cgi on BMO

[Emma Humphries]

Hello,

Kohei's finishing up some changes to how information is organized in
show_bug.cgi, and we'd like your feedback before we deploy it.

The enhancement bug for this work is:
https://bugzilla.mozilla.org/show_bug.cgi?id=1344091

You can see this work previewed on https://bugzilla-dev.allizom.org. For
example: https://bugzilla-dev.allizom.org/show_bug.cgi?id=238966.

Please take a look, and either comment on, or file a blocker on
https://bugzilla.mozilla.org/show_bug.cgi?id=1344091.

Thanks.

Emma, for the BMO team
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Planned Taskcluster Migration Upcoming

[Dustin Mitchell]

*tl;dr:* Taskcluster, the platform supporting Firefox CI, will be moving to
a new hosting environment during the tree-closing window at the end of
September.  This is a major change and upgrade to the platform, but may
cause some bumps along the way.

Taskcluster is in the midst of a few migrations [1], and one of those is
moving to a new hosting environment.  This has a few advantages:
 * Firefox CI will be handled by dedicated teams, separate from the TC team:
   * Service operations will be managed by cloudops
   * Administration will be managed by releng
   * Workers will be managed by relops
 * Hosting will be in a more trusted environment (GCP instead of Heroku)
 * The services will have a new, faster UI
 * Worker provisioning will be faster and more reliable, and cover more
cloud environments
 * ..lots of other achievements unlocked by shedding 5+ years of legacy

The downside is that URLs will be changing, likely leaving some dangling
pointers.  We've anticipated some of the most common (such as
https://queue.taskcluster.net/ URLs) and are planning workarounds, but
nonetheless anticipate some dead links for a while following the switch.

This work is tracked in bug 1546801 [2].  If you have questions or
concerns, please get in touch with me or anyone on the team, or file a bug
in Taskcluster :: General and we will triage it appropriately.

Dustin

[1]
https://mana.mozilla.org/wiki/pages/viewpage.action?spaceKey=TAS=Migrations
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1546801
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to ship: accumulating most JS scripts' data as UTF-8, then directly parsing as UTF-8 (without inflating to UTF-16)

[Jeff Walden]

On 8/6/19 8:16 AM, Anne van Kesteren wrote:
> On Sat, Jul 20, 2019 at 2:05 AM Jeff Walden  wrote:
>> (*Only* valid UTF-8: any invalidity, including for WTF-8, is an immediate 
>> error, no replacement-character semantics applied.)
> 
> Wouldn't adding this allow you to largely bypass the text decoder if
> it identifies the content to be UTF-8? Meaning we'd have to scan and
> copy bytes even less?

In principle "yes"; in current reality "no".

First and foremost, as our script-loading/networking code is set up now there's 
an inevitable copy.  When we load an HTTP channel we process its data using a 
|NS_NewIncrementalStreamLoader| that ultimately invokes this signature:

NS_IMETHODIMP
ScriptLoadHandler::OnIncrementalData(nsIIncrementalStreamLoader* aLoader,
 nsISupports* aContext,
 uint32_t aDataLength, const uint8_t* aData,
 uint32_t* aConsumedLength) {

This function is *provided* a prefilled (probably by NSPR, ultimately by 
network driver/card?) buffer, then we use an |intl::Decoder| to 
decode-by-copying that buffer's bytes into the script loader's JS 
allocator-allocated buffer, reallocating and expanding it as necessary.  (The 
buffer must be JS-allocated because it's transferred to the JS engine for 
parsing/compilation/execution.  If you don't transfer a JS-owned buffer, 
SpiderMonkey makes a fresh copy anyway.)  To avoid a copy, you'd need to 
intersperse decoding (and buffer-expanding) code into the networking layer -- 
theoretically doable, practically tricky (especially if we assume the buffer is 
mindlessly filled by networking driver code).

Second -- alternatively -- if the JS engine literally processed raw code units 
of utterly unknown validity and networking code could directly fill in the 
buffer the JS engine would process --the JS engine would require additional 
changes to handle invalid code units.  UTF-16 already demands this because JS 
is natively WTF-16 (and all 16-bit sequences are WTF-16).  But all UTF-8 
processing code assumes validity now.  Extra effort would be required to handle 
invalidity.  We do a lot of keeping raw pointers/indexes into source units and 
then using them later -- think for things like atomizing identifiers -- and all 
those process-this-range-of-data operations would have to be modified.  
*Possible*?  Yes.  Tricky?  For sure.  (Particularly as many of those 
coordinates we end up baking into the final compiled script representation -- 
so invalidity wouldn't be a transient concern but one that would persistent 
indefinitely.)

Third and maybe most important if the practical considerations didn't exist: 
like every sane person, I'm leery of adding yet another place where arbitrary 
ostensibly-UTF-8 bytes are decoded with any sort of 
invalid-is-not-immediate-error semantics.  In a very distant past I fixed an 
Acid3 failure where we mis-implemented UTF-16 replacement-character semantics.  
https://bugzilla.mozilla.org/show_bug.cgi?id=421576  New implementations of 
replacement-character semantics are disproportionately risky.  In fact when I 
fixed that I failed to fix a separate UTF-16 decoding implementation that had 
to be consistent with it, introducing a security bug.  
https://bugzilla.mozilla.org/show_bug.cgi?id=489041#c9  *Some* of that problem 
was because replacement-character stuff was at the time under-defined, and now 
it's well-defined...but still.  Risk.  Once burned, twice shy.

In principle this is all solvable.  But it's all rather complicated and 
fraught.  We can probably get better and safer wins making improvements 
elsewhere.

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

Re: Non-header-only headers shared between SpiderMonkey and the rest of Gecko

[Kris Maglione]

On Tue, Aug 06, 2019 at 10:56:55AM +0300, Henri Sivonen wrote:
Do we have some #ifdef for excluding parts of mfbt/ when mfbt/ is being used 
in a non-SpiderMonkey/Gecko context?


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

Re: Intent to ship: accumulating most JS scripts' data as UTF-8, then directly parsing as UTF-8 (without inflating to UTF-16)

[Anne van Kesteren]

On Sat, Jul 20, 2019 at 2:05 AM Jeff Walden  wrote:
> (*Only* valid UTF-8: any invalidity, including for WTF-8, is an immediate 
> error, no replacement-character semantics applied.)

Wouldn't adding this allow you to largely bypass the text decoder if
it identifies the content to be UTF-8? Meaning we'd have to scan and
copy bytes even less?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Non-header-only headers shared between SpiderMonkey and the rest of Gecko

[Henri Sivonen]

On Tue, Aug 6, 2019 at 10:15 AM Henri Sivonen  wrote:
> In general, it seems problematic to organize headers based on whether
> they have associated .cpp or crate code. I'd expect developers to look
> for stuff under mfbt/ instead of some place else, since developers
> using the header shouldn't have to know if the implementation is
> header-only or not. :-(

Notably, in my case the functions would logically belong in Utf8.h
(which already has Utf8.cpp under mfbt/) and in TextUtils.h. What
should my r+ expectations be if I put the entry points there despite
the code requiring linking with Rust crates that SpiderMonkey (and,
therefore, Gecko) depends on? Do we have some #ifdef for excluding
parts of mfbt/ when mfbt/ is being used in a non-SpiderMonkey/Gecko
context?

-- 
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Non-header-only headers shared between SpiderMonkey and the rest of Gecko

[Henri Sivonen]

On Mon, Aug 5, 2019 at 4:14 PM Gabriele Svelto  wrote:
> On 05/08/19 12:04, Henri Sivonen wrote:
> > I has come to my attention that that putting non-header-only code
> > under mfbt/ is something we're trying to get away from:
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1554062
> >
> > Do we have an appropriate place for headers that declare entry points
> > for non-header-only functionality (in my case, backed by Rust code)
> > and that depend on types declared in headers that live under mfbt/ and
> > that need to be available both to SpiderMonkey and the rest of Gecko?
>
> IIRC we have some stuff like that under mozglue/misc. The TimeStamp
> class for example is used in both Gecko and SpiderMonky, has
> platform-dependent C++ implementations (also linking to external
> libraries) and uses MFBT headers.

Is mozglue only for Gecko and SpiderMonkey and not anything else?
(I.e. not crash reporter or anything else that doesn't link the Rust
crates that SpiderMonkey links?)

In general, it seems problematic to organize headers based on whether
they have associated .cpp or crate code. I'd expect developers to look
for stuff under mfbt/ instead of some place else, since developers
using the header shouldn't have to know if the implementation is
header-only or not. :-(

-- 
Henri Sivonen
hsivo...@mozilla.com
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform