Intent to unship: SMIL accessKey support

[Brian Birtles]

Background: SMIL includes a feature for triggering animations based on
keypresses:

e.g.


  


Proposal: In bug 1423098 I intend to remove this feature.

Rationale:

* Apart from Gecko, only Presto supports it.
* accessKey has been the source of security issues in the past such as
bug 704482.
* We're trying to reduce the amount of SMIL-specific code in Gecko,
since it is not used a lot, it increases our attack surface area, and
it slows down other work on the style system like the Stylo project.

Status in other browsers:

Blink: No support. There is a "// FIXME: accesskey() support" in the code.[1]
WebKit: No support. The FIXME appears to be pre-fork.[2]
IE/Edge: No SVG SMIL support at all.
Presto: Supports accessKey but you need to press Shift + Esc first.

I'm not planning on adding a developer console warning at this point
unless someone suggests that would be useful.

Best regards,

Brian

[1] 
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/svg/animation/SVGSMILElement.cpp?q=syncbase+file:%5Esrc/+package:%5Echromium$=CSs=465
[2] 
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/svg/animation/SVGSMILElement.cpp#L425
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code

[Gregory Szorc]

On Mon, Dec 4, 2017 at 7:22 PM, Robert O'Callahan 
wrote:

> On Tue, Dec 5, 2017 at 2:00 PM, Gregory Szorc  wrote:
>
>> Many programming languages paper over these subtle differences leading to
>> badness. For example, the preferred path APIs for Python and Rust assume
>> paths are Unicode (they have their own logic to perform encoding/decoding
>> behind the scenes and depending on settings, run-time failures or data
>> loss
>> can occur).
>
>
> I don't think that's true for Rust. Rust's `Path` and `PathBuf` are the
> preferred data types and wrap an underlying `OsStr`/`OsString`, which
> claims to be able to represent any path for the target platform. On Linux
> an `OsString` is just an array of bytes with no specified encoding, and on
> Windows it appears to be an array of WTF-8 bytes, so that claim seems valid.
>

Yes. I was confusing Rust's handling of paths with environment variables
and command line arguments. std::env::vars() and std::env::args() panic if
an element isn't "Unicode." (The docs for those types don't say how Rust
chooses which encoding it treats the underlying bytes as and now I'm
legitimately curious.) That's why there are vars_os() and args_os() to get
the raw data. I got mixed up and thought there was a Path and OsPath
distinction as well.


>
> Of course PathBuf isn't exactly what you want for an application like
> Mercurial, since there I guess you want a type that represents any path
> from any platform, including platforms other than the target platform...
>

Indeed. Mercurial treats all paths as bytes (for better or worse). There
are known problems with path handling on Windows. For the curious, read
https://www.mercurial-scm.org/wiki/WindowsUTF8Plan and
https://www.mercurial-scm.org/wiki/EncodingStrategy. And, uh, I should have
linked to EncodingStrategy before because that contains a lot of useful
info. Although it is a bit light on links to back up the research. That
page was mostly authored by mpm, so I generally trust the accuracy of the
content.


> --
> lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
> toD
> selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
> rdsme,aoreseoouoto
> o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
> lurpr
> .a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt
> sstvr  esn
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code

[Robert O'Callahan]

On Tue, Dec 5, 2017 at 2:00 PM, Gregory Szorc  wrote:

> Many programming languages paper over these subtle differences leading to
> badness. For example, the preferred path APIs for Python and Rust assume
> paths are Unicode (they have their own logic to perform encoding/decoding
> behind the scenes and depending on settings, run-time failures or data loss
> can occur).


I don't think that's true for Rust. Rust's `Path` and `PathBuf` are the
preferred data types and wrap an underlying `OsStr`/`OsString`, which
claims to be able to represent any path for the target platform. On Linux
an `OsString` is just an array of bytes with no specified encoding, and on
Windows it appears to be an array of WTF-8 bytes, so that claim seems valid.

Of course PathBuf isn't exactly what you want for an application like
Mercurial, since there I guess you want a type that represents any path
from any platform, including platforms other than the target platform...

Rob
-- 
lbir ye,ea yer.tnietoehr  rdn rdsme,anea lurpr  edna e hnysnenh hhe uresyf
toD
selthor  stor  edna  siewaoeodm  or v sstvr  esBa  kbvted,t
rdsme,aoreseoouoto
o l euetiuruewFa  kbn e hnystoivateweh uresyf tulsa rehr  rdm  or rnea
lurpr
.a war hsrer holsa rodvted,t  nenh hneireseoouot.tniesiewaoeivatewt sstvr
esn
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code

[Gregory Szorc]

On Mon, Dec 4, 2017 at 5:00 PM, Gregory Szorc  wrote:

> On Wed, Nov 29, 2017 at 5:09 PM, Karl Tomlinson  wrote:
>
>> I've always found this confusing, and so I'll write down the
>> understanding I've reached, in the hope that either it will help
>> others, or others can help me by correcting if these are
>> misunderstandings.
>>
>> On Unix systems:
>>
>>   `nativePath`
>>
>>  contains the bytes corresponding to the native filename used
>>  by native system calls.
>>
>>   `path`
>>
>>  is a UTF-16 encoding of an attempt to provide a human
>>  readable version of the native filename.  This involves
>>  interpreting native bytes according to the character encoding
>>  specified by the current locale of the application as
>>  indicated by nl_langinfo(CODESET).
>>
>>  For different locales, the same file can have a different
>>  `path`.
>>
>>  The native bytes may not be valid UTF-8, and so if the
>>  character encoding is UTF-8, then there may not be a valid
>>  `path` that can be encoded to produce the same `nativePath`.
>>
>>   It is best to use `nativePath` for working with filenames,
>>   including conversion to URI, but use `path` when displaying
>>   names in the UI.
>>
>> On WINNT systems:
>>
>>   `path`
>>
>>  contains wide characters corresponding to the native filename
>>  used by native wide character system APIs.  For at least most
>>  configurations, I assume wide characters are UTF-16, in which
>>  case this is also human readable.
>>
>>   `nativePath`
>>
>>  is an attempt to represent the native filename in the native
>>  multibyte character encoding specified by the current locale
>>  of the application.
>>
>>  For different locales, I assume the same file can have a
>>  different `nativePath`.
>>
>>  I assume there is not necessarily a valid multibyte character
>>  encoding, and so there may not be a valid `nativePath` that
>>  can be decoded to produce the same `path`.
>>
>>   It is best to use `path` for working with filenames.
>>   Conversion to URI involves assuming `path` is UTF-16 and
>>   converting to UTF-8.
>>
>> The parameters mean very different things on different systems,
>> and so it is not generally possible to write XP code with either
>> of these, but Gecko attempts to do so anyway.
>>
>> The numbers of applications not using UTF-8 and filenames not
>> valid UTF-8 are much smaller on Unix systems than the numbers of
>> applications not using UTF-8 and non-ASCII filenames on WINNT
>> systems, and so choosing to work with `path` provides more
>> compatibility than working with `nativePath`.
>>
>
> My understanding from contributing to Mercurial (version control tools are
> essentially virtual filesystems that need to store paths and realize them
> on multiple operating systems and filesystems) is as follows.
>
> On Linux/POSIX, a path is any sequence of bytes not containing a NULL
> byte. As such, a path can be modeled by char*. Any tool that needs to
> preserve paths from and to I/O functions should be using NULL terminated
> bytes internally. For display, etc, you can attempt to decode those bytes
> using an encoding. But there's no guarantee the byte sequences from the
> filesystem/OS will be e.g. proper UTF-8. And if you normalize all paths to
> e.g. Unicode internally, this can lead to round tripping errors.
>
> On Windows, there are multiple APIs for I/O. Under the hood, NTFS is
> purportedly using UTF-16 to store filenames. Although I can't recall if it
> is actual UTF-16 or just byte pairs. This means you should be using the
> *W() functions for all I/O. e.g. CreateFileW(). (Note: if you use
> CreateFileW(), you can also use the "\\?\" prefix on the filename to avoid
> MAX_PATH (260 character) limitations. If you want to preserve filenames on
> Windows, you should be using these functions. If you use the *A() functions
> (e.g. CreateFileA()) or use the POSIX libc compatibility layer (e.g.
> open()), it is very difficult to preserve exact byte sequences. Further
> clouding matters is that values from environment variables, command line
> arguments, etc may be in unexpected/different encodings. I can't recall
> specifics here. But there are definitely cases where the bytes being
> exposed may not match exactly what is stored in NTFS.
>
> In addition to that, there are various normalizations that the operating
> system or filesystem may apply to filenames. For example, Windows has
> various reserved filenames that the Windows API will disallow (but NTFS can
> store if you use the NTFS APIs directly) and MacOS or its filesystem will
> silently munge certain Unicode code points (this is a fun one because of
> security implications).
>
> In all cases, if a filename originates from something other than the
> filesystem, it is probably a good idea to normalize it to Unicode
> internally and then spit out UTF-8 (or whatever the most-native API
> 

Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code

[Gregory Szorc]

On Wed, Nov 29, 2017 at 5:09 PM, Karl Tomlinson  wrote:

> I've always found this confusing, and so I'll write down the
> understanding I've reached, in the hope that either it will help
> others, or others can help me by correcting if these are
> misunderstandings.
>
> On Unix systems:
>
>   `nativePath`
>
>  contains the bytes corresponding to the native filename used
>  by native system calls.
>
>   `path`
>
>  is a UTF-16 encoding of an attempt to provide a human
>  readable version of the native filename.  This involves
>  interpreting native bytes according to the character encoding
>  specified by the current locale of the application as
>  indicated by nl_langinfo(CODESET).
>
>  For different locales, the same file can have a different
>  `path`.
>
>  The native bytes may not be valid UTF-8, and so if the
>  character encoding is UTF-8, then there may not be a valid
>  `path` that can be encoded to produce the same `nativePath`.
>
>   It is best to use `nativePath` for working with filenames,
>   including conversion to URI, but use `path` when displaying
>   names in the UI.
>
> On WINNT systems:
>
>   `path`
>
>  contains wide characters corresponding to the native filename
>  used by native wide character system APIs.  For at least most
>  configurations, I assume wide characters are UTF-16, in which
>  case this is also human readable.
>
>   `nativePath`
>
>  is an attempt to represent the native filename in the native
>  multibyte character encoding specified by the current locale
>  of the application.
>
>  For different locales, I assume the same file can have a
>  different `nativePath`.
>
>  I assume there is not necessarily a valid multibyte character
>  encoding, and so there may not be a valid `nativePath` that
>  can be decoded to produce the same `path`.
>
>   It is best to use `path` for working with filenames.
>   Conversion to URI involves assuming `path` is UTF-16 and
>   converting to UTF-8.
>
> The parameters mean very different things on different systems,
> and so it is not generally possible to write XP code with either
> of these, but Gecko attempts to do so anyway.
>
> The numbers of applications not using UTF-8 and filenames not
> valid UTF-8 are much smaller on Unix systems than the numbers of
> applications not using UTF-8 and non-ASCII filenames on WINNT
> systems, and so choosing to work with `path` provides more
> compatibility than working with `nativePath`.
>

My understanding from contributing to Mercurial (version control tools are
essentially virtual filesystems that need to store paths and realize them
on multiple operating systems and filesystems) is as follows.

On Linux/POSIX, a path is any sequence of bytes not containing a NULL byte.
As such, a path can be modeled by char*. Any tool that needs to preserve
paths from and to I/O functions should be using NULL terminated bytes
internally. For display, etc, you can attempt to decode those bytes using
an encoding. But there's no guarantee the byte sequences from the
filesystem/OS will be e.g. proper UTF-8. And if you normalize all paths to
e.g. Unicode internally, this can lead to round tripping errors.

On Windows, there are multiple APIs for I/O. Under the hood, NTFS is
purportedly using UTF-16 to store filenames. Although I can't recall if it
is actual UTF-16 or just byte pairs. This means you should be using the
*W() functions for all I/O. e.g. CreateFileW(). (Note: if you use
CreateFileW(), you can also use the "\\?\" prefix on the filename to avoid
MAX_PATH (260 character) limitations. If you want to preserve filenames on
Windows, you should be using these functions. If you use the *A() functions
(e.g. CreateFileA()) or use the POSIX libc compatibility layer (e.g.
open()), it is very difficult to preserve exact byte sequences. Further
clouding matters is that values from environment variables, command line
arguments, etc may be in unexpected/different encodings. I can't recall
specifics here. But there are definitely cases where the bytes being
exposed may not match exactly what is stored in NTFS.

In addition to that, there are various normalizations that the operating
system or filesystem may apply to filenames. For example, Windows has
various reserved filenames that the Windows API will disallow (but NTFS can
store if you use the NTFS APIs directly) and MacOS or its filesystem will
silently munge certain Unicode code points (this is a fun one because of
security implications).

In all cases, if a filename originates from something other than the
filesystem, it is probably a good idea to normalize it to Unicode
internally and then spit out UTF-8 (or whatever the most-native API
expects).

Many programming languages paper over these subtle differences leading to
badness. For example, the preferred path APIs for Python and Rust assume
paths are Unicode (they have their own logic to perform 

Re: Phabricator/Lando update, November 2017

[Gregory Szorc]

On Wed, Nov 29, 2017 at 11:40 AM, Mark Côté  wrote:

> On Wednesday, 29 November 2017 12:43:58 UTC-5, Steve Fink  wrote:
> > On 11/29/2017 08:35 AM, Mark Côté wrote:
> > > I posted an update on Phabricator and Lando to my blog a couple weeks
> ago, but I figured I should share it here too:
> https://mrcote.info/blog/2017/11/17/phabricator-and-lando-november-update/
> > >
> > > There are two important points:
> > >
> > > 1. Our Phabricator instance has been up and running for a few months
> now.  Our team has been using it regularly, as has the NSS team and some
> Firefox devs.  We were hesitant to advertise this too widely in order not
> to create any confusion around the Quantum release, but now that that has
> settled down I am told it should be fine for anyone to start using it.  The
> instance is at https://phabricator.services.mozilla.com/ and there are
> docs at https://moz-conduit.readthedocs.io/en/latest/phabricator-user.html.
> We will have some hands-on training in Austin as well.
> >
> > Where should we file bugs, and what sorts of bugs would be useful right
> now?
> >
> > I see in bugzilla Conduit :: Phabricator (Upstream) and Conduit ::
> > Phabricator Extensions. I don't know what Conduit is. I checked Conduit
> > :: General, but it just says "General Conduit bugs." What terminology do
> > we need to know in order to be able to file bugs and find the right
> > documentation?
> >
> > So for example, "recent commits" on the mozilla-central repo appears to
> > be backwards. It only shows stuff from 2007, and the related pages
> > (History, Graph) are the same. The Graph page, in particular, seems to
> > only allow advancing a page at a time, so there's no way you'd ever get
> > to the tip. But this is totally noncritical functionality right now, so
> > perhaps it would just add friction to file a bunch of obvious bugs?
>
> "Conduit" is the name of the whole system consisting of all our services
> related to code review and landing (and a few other things).  The "Getting
> in Touch" section of our docs has a breakdown of components:
> http://moz-conduit.readthedocs.io/en/latest/phabricator-user.html#getting-
> in-touch
>
> Huh yeah I didn't notice that about the history & graphs.  That is weird.
> To be honest, Diffusion is not the best source-code viewer for a repo the
> size of mozilla-central.  I would still default to using hg.mozilla.org,
> despite it not having as fancy an interface.  But feel free to file those
> bugs as I am curious why the behaviour is the way it is.  Those would
> belong in Conduit :: Phabricator (Upstream), as we do not intend to heavily
> customize our instance and hence would like to work with upstream on these
> kinds of issues.
>

My understanding is that another user of Phabricator with a Very Large
Repository does not use the Phabricator repository viewer because of
scaling and usability issues. My info may be a bit out of date though. But
I'm inclined to say we should steer people away from the Phabricator UI
(for better or worse).

Also, Mercurial has steadily been getting a slew of updates to the HTML
interface. There's a ton coming in the not-yet-released 4.5 release. But
we're still running 4.2 on hg.mozilla.org. You can run `hg serve` to run a
local server, which will get you the modern goodies (and it will be fast
since it avoids network round trips).
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: INTENT TO DEPRECATE (taskcluster l10n routing)

[Jet Villegas]

On Sun, Dec 3, 2017 at 05:15 Axel Hecht  wrote:

> Am 01.12.17 um 16:45 schrieb Justin Wood:
> > Hey Everyone,
> >
> > tl;dr if you don't download nightly l10n repacks via taskcluster index
> > routes, this does not affect you.
> >
> > Up until recently you could only find nightly l10n repacks with the
> > following routes:
> >
> > *
> >
> .gecko.v2.{project}.revision.{head_rev}.{build_product}-l10n.{build_name}-{build_type}.{locale}
> > *
> >
> .gecko.v2.{project}.pushdate.{year}.{month}.{day}.{pushdate}.{build_product}-l10n.{build_name}-{build_type}.{locale}
> > *
> >
> {index}.gecko.v2.{project}.latest.{build_product}-l10n.{build_name}-{build_type}.{locale}
> >
> > Recently I have updated the routing to match that of regular Nightlies,
> > specifically one such route is:
> >
> >
> gecko.v2.mozilla-central.nightly.revision.a21f4e2ce5186e2dc9ee411b07e9348866b4ef30.firefox-l10n.linux64-opt
>
> That's followed by locale code, right? I found
>
>
> gecko.v2.mozilla-central.nightly.revision.de1f7a92e8726bdd365d4bbc5e65eaa369fbc20a.firefox-l10n.macosx64-opt.de
>
> > This deprecation is in preparation of actually building l10n repacks on
> > (nearly) every code checkin, rather than just on nightlies.
>
> Does that mean that you're deprecating all but that route, or are there
> more?
>
> > Let me know if there are any questions or concerns.
>
> No concerns, just curiousity. We're not running any tests on localized
> builds at this point, right?
>

I hope we can change that (testing on localized builds) with this proposed
change. We’ve gotten reports that localized builds (and related usage;
e.g., input method editors) cause A11y API activation, which triggers other
bugs for us.



> Axel
> ___
> 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: Intent to implement (again): Shadow DOM

[Philip Jägenstedt]

On Mon, Nov 27, 2017 at 2:50 PM Emilio Cobos Álvarez 
wrote:

> On 11/27/2017 02:01 PM, James Graham wrote:
> > On 27/11/17 12:20, smaug wrote:
> >> This is basically an after the fact notification that
> >> we're in progress of implementing Shadow DOM again, this time v1[1].
> >> While doing this, the v0 implementation, which was never exposed to
> >> the web, will be removed.
> >> v1 is luckily way simpler, so this all should simplify various bits in
> >> DOM.
> >>
> >> FF60 might be quite realistic target to ship this, but there will be
> >> intent-to-ship
> >> before that.
> >>
> >> Many parts of the spec (DOM) is stable, but there are still couple of
> >> tricky issues in HTML, like
> >> session history handling with shadow DOM. However Chrome and Safari
> >> are shipping v1 already.
> >>
> >> Devtools will be able to see into the Shadow DOM.
> >>
> >> Currently the work is under the old pref "dom.webcomponents.enabled"
> >> but perhaps we should change that, so that people who were testing v0
> >> don't get
> >> v1 APIs.
> >
> > Do we have cross-browser (i.e. web-platform) tests for this feature, and
> > have we assessed whether they are sufficiently complete to give us
> > confidence of interop?
>
> There are some web platform tests, but I'm moderately sure that the
> rendering bits of them are not quite enough, since they're quite basic.
>
> I also know that Chromium and WebKit have tons of crashtests and tests
> for dynamic changes of the page that we'd definitely benefit from.
>
> I know there's an effort in Chromium to upstream LayoutTests to WPT. The
> Shadow DOM v1 LayoutTests would be extremely helpful to have upstream IMO.
>

What kind of timeline are we talking about here? Are any of the tests more
valuable than others, such that you'd import them into Gecko directly from
Chromium if they aren't upstreamed to wpt?

+Hayato Ito  FYI.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: PSA: increased chance of new leaks due to delayed shutdown issue

[Ben Kelly]

Actually this was backed out from m-c for a single failing android test
this morning.  So please be aware we are at risk of introducing leaks again.

On Sat, Dec 2, 2017 at 9:27 PM, Ben Kelly  wrote:

> Both fixes have stuck and are in the latest nightly.  Sorry for the
> headaches here.
>
> On Dec 1, 2017 1:15 PM, "Ben Kelly"  wrote:
>
>> FYI, we have a fix identified for the late shutdown leak as well.  I will
>> push them to inbound once the trees re-open.
>>
>> On Thu, Nov 30, 2017 at 11:18 PM, Ben Kelly  wrote:
>>
>>> Hi all,
>>>
>>> I just wanted to send a note about a bug in nightly which is leading to
>>> delayed shutdowns.  Currently nightly is taking 5 to 10 seconds to shutdown.
>>>
>>> Bisection has shown this was introduced by my landing in:
>>>
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1419536
>>>
>>> I have a fix here:
>>>
>>> https://bugzilla.mozilla.org/show_bug.cgi?id=1420594
>>>
>>> But I discovered upon pushing the fix that at least one new leak has
>>> crept in while shutdowns have been delayed.  I'm currently bisecting on try
>>> to figure out what happened.  I am, however, worried about more leaks
>>> appearing while I figure this out.
>>>
>>> If you are touching anything that might live until shutdown, please
>>> include the patches from bug 1420594 to avoid the delayed shutdown issue.
>>>
>>> I'll send another mail once the fix lands and sticks.
>>>
>>> Thanks for your help.  Sorry for the trouble.
>>>
>>> Ben
>>>
>>
>>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

IMEs can instantiate accessibility (was Re: INTENT TO DEPRECATE (taskcluster l10n routing))

[David Bolter]

On Mon, Dec 4, 2017 at 8:58 AM, Axel Hecht  wrote:

> Am 04.12.17 um 05:42 schrieb Jet Villegas:
>
>>
>> On Sun, Dec 3, 2017 at 05:15 Axel Hecht  l...@mozilla.com>> wrote:
>>
>> Am 01.12.17 um 16:45 schrieb Justin Wood:
>> > Hey Everyone,
>>
>>
[snip]

I hope we can change that (testing on localized builds) with this proposed
>> change. We’ve gotten reports that localized builds (and related usage;
>> e.g., input method editors) cause A11y API activation, which triggers other
>> bugs for us.
>>
>
> My gut reaction is "that shouldn't happen", though, well, no idea what
> IMEs do. Do we have bugs tracking these? I'd love to be on CC on those.
>

It can happen. IMEs often have prediction features and they need to examine
the context under which the input is happening. One example we recently
learned of is a Japanese IME feature ATOK's "insight" which analyzes
focused web content for input prediction and switching dictionaries.

The main side effect is performance.

We need to do two things here:
1. Add more caching to our Windows e10s a11y solution.
2. Do something smart about the different kinds of clients that instantiate
a11y. This will likely be two things: blocking 'a11y' clients who that are
just being ridiculous, and better, copying what Chrome does and instantiate
only 'portions' of our a11y support... think of this as having a
'lightweight' mode, although it may be that we have multiple levers.

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

Re: INTENT TO DEPRECATE (taskcluster l10n routing)

[Axel Hecht]

Am 04.12.17 um 05:42 schrieb Jet Villegas:


On Sun, Dec 3, 2017 at 05:15 Axel Hecht > wrote:


Am 01.12.17 um 16:45 schrieb Justin Wood:
> Hey Everyone,
>
> tl;dr if you don't download nightly l10n repacks via taskcluster
index
> routes, this does not affect you.
>
> Up until recently you could only find nightly l10n repacks with the
> following routes:
>
> *
>

.gecko.v2.{project}.revision.{head_rev}.{build_product}-l10n.{build_name}-{build_type}.{locale}
> *
>

.gecko.v2.{project}.pushdate.{year}.{month}.{day}.{pushdate}.{build_product}-l10n.{build_name}-{build_type}.{locale}
> *
>

{index}.gecko.v2.{project}.latest.{build_product}-l10n.{build_name}-{build_type}.{locale}
>
> Recently I have updated the routing to match that of regular
Nightlies,
> specifically one such route is:
>
>

gecko.v2.mozilla-central.nightly.revision.a21f4e2ce5186e2dc9ee411b07e9348866b4ef30.firefox-l10n.linux64-opt

That's followed by locale code, right? I found


gecko.v2.mozilla-central.nightly.revision.de1f7a92e8726bdd365d4bbc5e65eaa369fbc20a.firefox-l10n.macosx64-opt.de



> This deprecation is in preparation of actually building l10n
repacks on
> (nearly) every code checkin, rather than just on nightlies.

Does that mean that you're deprecating all but that route, or are
there
more?

> Let me know if there are any questions or concerns.

No concerns, just curiousity. We're not running any tests on localized
builds at this point, right?


I hope we can change that (testing on localized builds) with this 
proposed change. We’ve gotten reports that localized builds (and 
related usage; e.g., input method editors) cause A11y API activation, 
which triggers other bugs for us.


My gut reaction is "that shouldn't happen", though, well, no idea what 
IMEs do. Do we have bugs tracking these? I'd love to be on CC on those.


As for running tests, we have 100 localizations and 5 platforms, we'll 
need to be pretty conservative on which tests we run so that we don't 
blow up our budget by a factor of 500. Also, many of our tests actually 
hard-code en-US artifacts, like "ensure that the button on this dialog 
says "Save", and thus will fail when run on localized builds. I don't 
have a list, though.


Axel

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

[Masatoshi Kimura]

On 2017/12/04 20:19, Henri Sivonen wrote:
> I suggest that instead of delaying with a round of telemetry, we make
> all non-Windows platforms in nsNativeCharsetUtils.cpp use what's
> currently the OSX/Android code path.

+1

Some other data points:
* If by any chance a profile path contains non-ASCII characters on
non-UTF-8 UNIX systems, Firefox 57.0.1 must have broken the profile just
like 57.0 broke it on Windows. But we didn't hear any such complaints.

* Our GMP service assumes that the native encoding is always UTF-8
except Windows. Some media playbacks must have been broken on UNIX
systems unless the locale is UTF-8.

I agree that telemetry is waste of time in this case.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

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)

[Henri Sivonen]

On Fri, Dec 1, 2017 at 3:15 AM, Makoto Kato  wrote:
> I think that we don't have any data when user doesn't use non-UTF-8
> (and C) locale such as ja_JP.eucJP.  We should get data via telemetry.

What should the telemetry measure? (Measuring whether we compute paths
to be UTF-8 in the code that still supports non-UTF-8 configurations
would probably be the wrong thing to measure, because the "C" locale
doesn't compute to UTF-8 and no one has cared enough to fix that.)

What kind of telemetry data would we need to see in order to proceed
with https://bugzilla.mozilla.org/show_bug.cgi?id=960957 (removing the
remains of support for non-UTF-8 file paths)?

And if we didn't proceed with that course of action, what would the
alternative course of action be? The current state doesn't really
support non-UTF-8 file paths.
https://bugzilla.mozilla.org/show_bug.cgi?id=1342659 has been open for
9 months, and the user was upgrading from Firefox 17 to 50 in order to
notice the problem, so the bug has been there for more than 9 months
before the complaint.
https://bugzilla.mozilla.org/show_bug.cgi?id=848268 has been open for
5 years. It looks like no one cares enough about non-UTF-8
configurations to make Gecko do what arguably would be the right way
to support non-UTF-8 file paths: using the glib file path conversion
functions, which don't do non-UTF-8 things unless the
G_BROKEN_FILENAMES environment variable has been set. The name of the
environment variable is very telling.

Considering that we mainly get Gtk telemetry from Ubuntu which has had
UTF-8 paths since its introduction and our support for non-UTF-8 file
paths has been broken for years without much complaint (AFAIK 3 users
reporting non-UTF-8: two EUC-JP and one ISO-8859-something in the past
5 years), can we really expect telemetry to tell us anything useful?
Non-UTF-8 paths are an even more deeply legacy configuration than
non-PulseAudio audio, and telemetry told us was OK to go
PulseAudio-only.

Four years ago, smontagu said that in the last 5 years (i.e. since
nine years ago now), the code he had contributed assumed UTF-8 on
*nix: https://www.mail-archive.com/dev-platform@lists.mozilla.org/msg06083.html

I suggest that instead of delaying with a round of telemetry, we make
all non-Windows platforms in nsNativeCharsetUtils.cpp use what's
currently the OSX/Android code path.

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