Re: Intent to unship: -moz-placeholder pseudo-element and pseudo-class

[顧思捷]

ok, I see your point. I also saw some usage of moz-placeholder in add-on
repository as well, and Boris pointed out it might too early to remove it,
so I should pending this task.

Mike, do we get any complaint about not supporting webkit placeholder
alias?

On Thu, May 25, 2017 at 4:10 AM, Mike Taylor  wrote:

> On 5/24/17 1:50 PM, Boris Zbarsky wrote:
> > On 5/24/17 1:06 PM, Mike Taylor wrote:
> >> [1]
> >>  766b035e43/app/assets/stylesheets/theme.css#L136-L141>
> >
> > Sadly, that code is already buggy in Firefox: it uses
> > ":moz-placeholder", which doesn't parse.  The thing that parses is
> > ":-moz-placeholder".
>
> Yeah, good point Boris -- I overlooked that.
>
> But it's not hard to find more results on GitHub that aren't parse
> errors:
>  type=Code&utf8=%E2%9C%93>
>
>
> For example,
> https://github.com/yields/rework-pseudos/blob/
> c4d2a48fe82a3a387f2f78744b25e765acbd06f3/test/fixtures/
> pseudos.out.css#L38-L60
>
> Looking at some of these results, it makes me wonder if adding a webkit
> prefix alias would improve things more than removing a moz prefix.
>
> --
> Mike Taylor
> Web Compat, Mozilla
> ___
> 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: Improving visibility of compiler warnings

[Ehsan Akhgari]

On 05/19/2017 02:44 PM, Gregory Szorc wrote:

`mach build` attempts to parse compiler warnings to a persisted "database."
You can view a list of compiler warnings post build by running `mach
warnings-list`. The intent behind this feature was to make it easier to
find and fix compiler warnings. After all, something out of sight is out of
mind.

There have been a few recent changes to increase the visibility of compiler
warnings with the expectation being that raising visibility will increase
the chances of someone addressing them. After all, a compiler warning is
either a) valid and should be fixed or b) invalid and should be ignored.
Either way, a compiler warning shouldn't exist.


Since mystor and billm's objection seems to have gone unaddressed in 
this thread, let me try once again.  There is a (c) scenario that you 
are ignoring here:


c) the warning is valid and should be fixed but it's not more important 
than other things than the developer may want to do at the moment.  I 
would like to posit that this is often the case.  Let's look at what I 
get these days at the end of a normal debug build on Linux.  This output 
is long and I am intentionally pasting the full thing here in order to 
make a point on how much useless information we are presenting at the 
end of each build:


18:39.34 warning: db/sqlite3/src/sqlite3.c:131236:39 
[-Wunreachable-code] code will never be executed
18:39.34 warning: db/sqlite3/src/sqlite3.c:131292:39 
[-Wunreachable-code] code will never be executed
18:39.34 warning: db/sqlite3/src/sqlite3.c:137670:9 [-Wunreachable-code] 
code will never be executed
18:39.34 warning: 
gfx/angle/src/compiler/translator/ASTMetadataHLSL.cpp:93:15 
[-Wimplicit-fallthrough] unannotated fall-through between switch labels
18:39.34 warning: 
gfx/angle/src/compiler/translator/ParseContext.cpp:1123:9 
[-Wimplicit-fallthrough] unannotated fall-through between switch labels
18:39.34 warning: 
gfx/angle/src/compiler/translator/ParseContext.cpp:3640:9 
[-Wimplicit-fallthrough] unannotated fall-through between switch labels
18:39.34 warning: 
gfx/angle/src/compiler/translator/ParseContext.cpp:3808:9 
[-Wimplicit-fallthrough] unannotated fall-through between switch labels
18:39.34 warning: gfx/cairo/libpixman/src/pixman-bits-image.c:268:32 
[-Wshift-negative-value] shifting a negative signed value is undefined
18:39.34 warning: gfx/cairo/libpixman/src/pixman-linear-gradient.c:395:6 
[-Wunreachable-code] code will never be executed
18:39.34 warning: gfx/cairo/libpixman/src/pixman-x86.c:80:5 
[-Wexpansion-to-defined] macro expansion producing 'defined' has 
undefined behavior
18:39.34 warning: gfx/cairo/libpixman/src/pixman-x86.c:119:5 
[-Wexpansion-to-defined] macro expansion producing 'defined' has 
undefined behavior
18:39.34 warning: intl/hyphenation/hyphen/hyphen.c:332:27 
[-Wsign-compare] comparison of integers of different signs: 'int' and 
'unsigned long'
18:39.34 warning: intl/icu/source/common/locdspnm.cpp:286:14 
[-Wunused-private-field] private field 'capitalizationBrkIter' is not used
18:39.34 warning: intl/icu/source/common/udataswp.c:438:29 
[-Wsign-compare] comparison of integers of different signs: 'int32_t' 
(aka 'int') and 'unsigned long'
18:39.34 warning: intl/icu/source/common/ulist.c:161:24 [-Wsign-compare] 
comparison of integers of different signs: 'int32_t' (aka 'int') and 
'unsigned long'
18:39.34 warning: intl/icu/source/common/uloc_tag.c:1374:31 
[-Wsign-compare] comparison of integers of different signs: 'int32_t' 
(aka 'int') and 'unsigned long'
18:39.34 warning: intl/icu/source/common/uloc_tag.c:1409:36 
[-Wsign-compare] comparison of integers of different signs: 'int32_t' 
(aka 'int') and 'unsigned long'
18:39.34 warning: intl/icu/source/common/ures_cnv.c:46:18 
[-Wsign-compare] comparison of integers of different signs: 'int32_t' 
(aka 'int') and 'unsigned long'
18:39.34 warning: intl/icu/source/common/ures_cnv.c:64:22 
[-Wsign-compare] comparison of integers of different signs: 'int32_t' 
(aka 'int') and 'unsigned long'
18:39.34 warning: intl/icu/source/common/ushape.cpp:1247:12 [-Wcomma] 
possible misuse of comma operator here
18:39.34 warning: intl/icu/source/common/ustring.cpp:860:57 [-Wcomma] 
possible misuse of comma operator here
18:39.34 warning: intl/icu/source/common/ustring.cpp:870:57 [-Wcomma] 
possible misuse of comma operator here
18:39.34 warning: intl/icu/source/common/ustrtrns.cpp:488:47 [-Wcomma] 
possible misuse of comma operator here
18:39.34 warning: intl/icu/source/common/ustrtrns.cpp:535:47 [-Wcomma] 
possible misuse of comma operator here
18:39.34 warning: intl/icu/source/common/ustrtrns.cpp:609:51 [-Wcomma] 
possible misuse of comma operator here
18:39.34 warning: intl/icu/source/common/ustrtrns.cpp:655:47 [-Wcomma] 
possible misuse of comma operator here
18:39.34 warning: intl/icu/source/common/ustrtrns.cpp:704:47 [-Wcomma] 
possible misuse of comma operator here
18:39.34 warning: intl/icu/source/common/utrace.c:149:16 
[-Wsign-compare] compa

Re: Improving visibility of compiler warnings

[Boris Zbarsky]

On 5/25/17 8:31 AM, Ehsan Akhgari wrote:

This currently only
serves to make it more difficult to find compiler errors when they
occur.


Fwiw (and not to distract from your main point), 
https://bugzilla.mozilla.org/show_bug.cgi?id=1367405 just got fixed so 
we should no longer get the warning spew when there are compiler errors.


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

Re: Improving visibility of compiler warnings

[Eric Rescorla]

I'd like to second Ehsan's point, but also expand upon it into a more
general observation.

As it becomes progressively more difficult to build Firefox without mach,
it becomes
increasingly important that mach respect people's workflows. For those of
us who
were comfortable with make and the behavior of having relatively unfiltered
access
to what the build system is doing, it would be great if mach could have
some set of
flags to preserve that view (cf. the flags to remove the timestamps so that
emacs
compiler mode works).

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

more setTimeout() changes incoming

[Ben Kelly]

Hi all,

I want to give everyone a heads-up that I'm hoping to push some
setTimeout() changes to inbound in the next day or two:

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

The main result people should be aware of is that setTimeout() will be more
accurate and precise after this lands [1]:

1. We will no longer be able to fire setTimeout() handlers early.
2. Assuming an idle main thread setTimeout() handlers will be less delayed.
3. setTimeout(f, 0) may be a simple runnable dispatch now and can fire a
bit faster than before.

As you can imagine, changing setTimeout() timings has interesting effects
on our test results.  I've been working hard to find and fix intermittents,
but there will undoubtedly be some changes to our orange after landing this.

If you have an intermittent you think appeared after this lands, please
look for any possible timing races in the test.  Also, feel free to NI me
to help investigate.

Again, I've worked hard to squash the intermittents I've seen in try, so I
don't believe there will be any super frequent failures from this bug.  (Or
I wouldn't be landing, etc...)

Please let me know if there are any questions or concerns.  Thanks!

Ben

[1] For example, using this tool:

https://people-mozilla.org/~bkelly/timeout-precision/?mode=delta&delay=10&count=100

My current FF55 on windows 10 gives the following stats for "differences
from specified firing time" in milliseconds:

min:-0.120 mean:1.922 median:1.830 max:5.180 stdev:1.753

So sometimes it fires as much as 120us early and has a median firing time
1.8ms late.  With bug 1363829 we get:

min:0.010 mean:0.403 median:0.025 max:4.155 stdev:1.098

So we don't fire early any more and our median firing time is only 25us
late.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving visibility of compiler warnings

[Chris Peterson]

On 2017-05-25 5:31 AM, Ehsan Akhgari wrote:

On 05/19/2017 02:44 PM, Gregory Szorc wrote:

`mach build` attempts to parse compiler warnings to a persisted
"database."
You can view a list of compiler warnings post build by running `mach
warnings-list`. The intent behind this feature was to make it easier to
find and fix compiler warnings. After all, something out of sight is
out of
mind.


Given that we treat warnings as errors on CI and most directories that 
opt out of warnings-as-errors are third-party code 
(ALLOW_COMPILER_WARNINGS in moz.build [1]), I don't think we need to 
make the warning list any more visible. A warning regression in nearly 
all first-party code is already treated as an error.



[1] 
https://searchfox.org/mozilla-central/search?q=ALLOW_COMPILER_WARNINGS&case=true&path=moz.build

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

Re: Race Cache With Network experiment on Nightly

[mgrimes]

Hey folks. I run the Shield team. Pref flipping experiments ARE available on 
Nightly and will be available in all channels (including Release) at some point 
in Firefox 54. 

Since the process is still relatively new, I've been hacking on some how to 
docs: 
https://docs.google.com/document/d/16bpDZGCPKrOIgkkIo5mWKHPTlYXOatyg_-CUi-3-e54/edit#heading=h.mzzhkdagng85

Feel free to give those a spin. Feedback on the docs/process is welcome.

On Wednesday, May 24, 2017 at 6:14:55 PM UTC-7, Patrick McManus wrote:
> a howto for a pref experiment would be awesome..
> 
> On Wed, May 24, 2017 at 9:03 PM, Eric Rescorla  wrote:
> 
> > What's the state of pref experiments? I thought they were not yet ready.
> >
> > -Ekr
> >
> >
> > On Thu, May 25, 2017 at 7:15 AM, Benjamin Smedberg 
> > wrote:
> >
> > > Is there a particular reason this is landing directly to nightly rather
> > > than using a pref experiment? A pref experiment is going to provide much
> > > more reliable comparative data. In general we're pushing everyone to use
> > > controlled experiments for nightly instead of landing experimental work
> > > directly.
> > >
> > > --BDS
> > >
> > > On Wed, May 24, 2017 at 11:36 AM, Valentin Gosu  > >
> > > wrote:
> > >
> > > > As part of the Quantum Network initiative we are working on a project
> > > > called "Race Cache With Network" (rcwn) [1].
> > > >
> > > > This project changes the way the network cache works. When we detect
> > that
> > > > disk IO may be slow, we send a network request in parallel, and we use
> > > the
> > > > first response that comes back. For users with slow spinning disks and
> > a
> > > > low latency network, the result would be faster loads.
> > > >
> > > > This feature is currently preffed off - network.http.rcwn.enabled
> > > > In bug 1366224, which is about to land on m-c, we plan to enable it on
> > > > nightly for one or two days, to get some useful telemetry for our
> > future
> > > > work.
> > > >
> > > > For any crashes or unexpected behaviour, please file bugs blocking
> > > 1307504.
> > > >
> > > > Thanks!
> > > >
> > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=rcwn
> > > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1366224
> > > > ___
> > > > 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
> >
> >

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

Re: Improving visibility of compiler warnings

[Kris Maglione]

On Thu, May 25, 2017 at 08:31:24AM -0400, Ehsan Akhgari wrote:
What was the motivation behind this change?  Was there a complaint 
from a significant number of developers about it being difficult 
fixing compiler warnings grepping for things like "warning:" or using 
./mach warnings-list? Was the feedback from developers who have the 
use case of writing code and fix compiler errors in such code taken 
into account?


For what it's worth, I've often wished for something like this 
when watching huge numbers of warnings flow by in NSS and media 
code, if only to motivate people to fix them. But the fact that 
we compile with -Werror and generally only get warnings in 
third-party code (ignoring NSS and NSPR) means that they're 
effectively pretty useless, and we'd be better off just 
disabling warnings in that code.


What I really want at the end of a compile is a list of warnings 
and errors that matter, rather than a lot of useless warning 
spew that makes it harder to find the ones that do among the 
ones that don't.

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

Re: Mozilla Charset Detectors

[gabi . t . sandor]

On Tuesday, May 23, 2017 at 7:47:12 PM UTC+3, Joshua Cranmer 🐧 wrote:
> On 5/23/17 2:58 AM, Gabriel Sandor wrote:
> > Hello Henri,
> >
> > I was afraid this might be the case, so the library really is deprecated.
> >
> > The project i'm working on implies multi-lingual environment, users, and
> > files, so yes, having a good encoding detector is important. Thanks for the
> > alternate recommendations, i see that they are C/C++ libraries but in
> > theory they can be wrapped into a managed C++.NET assembly and consumed by
> > a C# project. I haven't seen yet any existing C# ports that also handle
> > charset detection.
> 
> You only need charset detection if you can't get reliable charsets 
> passed around. Most word processing formats embed the charset they use 
> in the document (or just use UTF-8 unconditionally), so you only need 
> charset detection if you're getting lots of multilingual plain text (or 
> plain text-ish formats like markdown or HTML), and even then, only if 
> you expect the charset information to be unreliable. It's also worth 
> pointing out that letting users override the charset information on a 
> per-file basis goes a very long way to avoiding the need for charset 
> detection.
> 
> -- 
> Joshua Cranmer
> Thunderbird and DXR developer
> Source code archæologist

There are cases when i'm dealing with files that don't explicitly mention the 
charset. Think of XML files without the "encoding" attribute in the declaration 
or HTML files without the meta charset tag. Or plain text files in arbitrary 
languages. Many of these are not UTF-8. So there are indeed situations when 
heuristic encoding detection is needed.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to unship: -moz-placeholder pseudo-element and pseudo-class

[Mike Taylor]

On 5/25/17 5:48 AM, Ku(顧思捷)CJ wrote:
> Mike, do we get any complaint about not supporting webkit placeholder
> alias?  

Nah, not that I'm aware of. I was just looking through GitHub search
results and finding some stuff that only includes webkit-input-placeholder:



Pretty much everywhere else that has a -moz-placeholder includes a
-webkit-input-placeholder (or unprefixed, or both). But I'm guessing
add-on code would be the exception.

-- 
Mike Taylor
Web Compat, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Race Cache With Network experiment on Nightly

[Jason Duell]

I'm worried we're going from too little process here to too much (at least
for this bug).  Opening a meta-bug + 4 sub-bugs and doing a legal review,
etc., is a lot of overhead to test some network plumbing that is not going
to be especially noticeable to users.

Also, we expect that this code will mostly benefit users with slow hardware
(disk drives especially).  We'll need to cast a very wide net to get
nightly users that match that profile.  The Shield docs say that
"participation for Shield Studies is currently around 1-2% of randomly
selected participants" (does that map to 1-2% of nightly users?), so I'm
not sure we'd get enough coverage if we used Shield.

Jason

On Thu, May 25, 2017 at 11:30 AM,  wrote:

> Hey folks. I run the Shield team. Pref flipping experiments ARE available
> on Nightly and will be available in all channels (including Release) at
> some point in Firefox 54.
>
> Since the process is still relatively new, I've been hacking on some how
> to docs: https://docs.google.com/document/d/16bpDZGCPKrOIgkkIo5mWKHPTlYXOa
> tyg_-CUi-3-e54/edit#heading=h.mzzhkdagng85
>
> Feel free to give those a spin. Feedback on the docs/process is welcome.
>
> On Wednesday, May 24, 2017 at 6:14:55 PM UTC-7, Patrick McManus wrote:
> > a howto for a pref experiment would be awesome..
> >
> > On Wed, May 24, 2017 at 9:03 PM, Eric Rescorla  wrote:
> >
> > > What's the state of pref experiments? I thought they were not yet
> ready.
> > >
> > > -Ekr
> > >
> > >
> > > On Thu, May 25, 2017 at 7:15 AM, Benjamin Smedberg <
> benja...@smedbergs.us>
> > > wrote:
> > >
> > > > Is there a particular reason this is landing directly to nightly
> rather
> > > > than using a pref experiment? A pref experiment is going to provide
> much
> > > > more reliable comparative data. In general we're pushing everyone to
> use
> > > > controlled experiments for nightly instead of landing experimental
> work
> > > > directly.
> > > >
> > > > --BDS
> > > >
> > > > On Wed, May 24, 2017 at 11:36 AM, Valentin Gosu <
> valentin.g...@gmail.com
> > > >
> > > > wrote:
> > > >
> > > > > As part of the Quantum Network initiative we are working on a
> project
> > > > > called "Race Cache With Network" (rcwn) [1].
> > > > >
> > > > > This project changes the way the network cache works. When we
> detect
> > > that
> > > > > disk IO may be slow, we send a network request in parallel, and we
> use
> > > > the
> > > > > first response that comes back. For users with slow spinning disks
> and
> > > a
> > > > > low latency network, the result would be faster loads.
> > > > >
> > > > > This feature is currently preffed off - network.http.rcwn.enabled
> > > > > In bug 1366224, which is about to land on m-c, we plan to enable
> it on
> > > > > nightly for one or two days, to get some useful telemetry for our
> > > future
> > > > > work.
> > > > >
> > > > > For any crashes or unexpected behaviour, please file bugs blocking
> > > > 1307504.
> > > > >
> > > > > Thanks!
> > > > >
> > > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=rcwn
> > > > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1366224
> > > > > ___
> > > > > 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
> > >
> > >
>
> ___
> 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: Race Cache With Network experiment on Nightly

[Matthew Grimes]

I think you were looking at the docs for opt-in Shield studies (experiments
deployed as add-ons), not for pref flipping experiments. Due to the nature
of some of the opt-in studies we run they require a different approval
process. Pref flipping is available for all users, it is not opt-in. The
process currently requires one bug and an email to release drivers.
Feedback on the doc/process is always welcome!

On Thu, May 25, 2017 at 1:40 PM, Jason Duell  wrote:

> I'm worried we're going from too little process here to too much (at least
> for this bug).  Opening a meta-bug + 4 sub-bugs and doing a legal review,
> etc., is a lot of overhead to test some network plumbing that is not going
> to be especially noticeable to users.
>
> Also, we expect that this code will mostly benefit users with slow
> hardware (disk drives especially).  We'll need to cast a very wide net to
> get nightly users that match that profile.  The Shield docs say that
> "participation for Shield Studies is currently around 1-2% of randomly
> selected participants" (does that map to 1-2% of nightly users?), so I'm
> not sure we'd get enough coverage if we used Shield.
>
> Jason
>
> On Thu, May 25, 2017 at 11:30 AM,  wrote:
>
>> Hey folks. I run the Shield team. Pref flipping experiments ARE available
>> on Nightly and will be available in all channels (including Release) at
>> some point in Firefox 54.
>>
>> Since the process is still relatively new, I've been hacking on some how
>> to docs: https://docs.google.com/document/d/16bpDZGCPKrOIgkkIo5mWKHPT
>> lYXOatyg_-CUi-3-e54/edit#heading=h.mzzhkdagng85
>>
>> Feel free to give those a spin. Feedback on the docs/process is welcome.
>>
>> On Wednesday, May 24, 2017 at 6:14:55 PM UTC-7, Patrick McManus wrote:
>> > a howto for a pref experiment would be awesome..
>> >
>> > On Wed, May 24, 2017 at 9:03 PM, Eric Rescorla  wrote:
>> >
>> > > What's the state of pref experiments? I thought they were not yet
>> ready.
>> > >
>> > > -Ekr
>> > >
>> > >
>> > > On Thu, May 25, 2017 at 7:15 AM, Benjamin Smedberg <
>> benja...@smedbergs.us>
>> > > wrote:
>> > >
>> > > > Is there a particular reason this is landing directly to nightly
>> rather
>> > > > than using a pref experiment? A pref experiment is going to provide
>> much
>> > > > more reliable comparative data. In general we're pushing everyone
>> to use
>> > > > controlled experiments for nightly instead of landing experimental
>> work
>> > > > directly.
>> > > >
>> > > > --BDS
>> > > >
>> > > > On Wed, May 24, 2017 at 11:36 AM, Valentin Gosu <
>> valentin.g...@gmail.com
>> > > >
>> > > > wrote:
>> > > >
>> > > > > As part of the Quantum Network initiative we are working on a
>> project
>> > > > > called "Race Cache With Network" (rcwn) [1].
>> > > > >
>> > > > > This project changes the way the network cache works. When we
>> detect
>> > > that
>> > > > > disk IO may be slow, we send a network request in parallel, and
>> we use
>> > > > the
>> > > > > first response that comes back. For users with slow spinning
>> disks and
>> > > a
>> > > > > low latency network, the result would be faster loads.
>> > > > >
>> > > > > This feature is currently preffed off - network.http.rcwn.enabled
>> > > > > In bug 1366224, which is about to land on m-c, we plan to enable
>> it on
>> > > > > nightly for one or two days, to get some useful telemetry for our
>> > > future
>> > > > > work.
>> > > > >
>> > > > > For any crashes or unexpected behaviour, please file bugs blocking
>> > > > 1307504.
>> > > > >
>> > > > > Thanks!
>> > > > >
>> > > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=rcwn
>> > > > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1366224
>> > > > > ___
>> > > > > 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
>> > >
>> > >
>>
>> ___
>> 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: Scope of XML parser rewrite?

[Eric Rahm]

Thanks Henri, I think we can find a middle ground so as to avoid a ton of
scope creep but leave the door open to a better iterative solution. See
notes inline.

-e

On Wed, May 24, 2017 at 11:18 PM, Henri Sivonen 
wrote:

> On Wed, May 24, 2017 at 10:11 AM, Henri Sivonen 
> wrote:
> >> Our current interface is UTF-16, so that's my target for now. I think
> >> whatever cache-friendliness would be lost converting from UTF-16 ->
> UTF-8 ->
> >> UTF-16.
> >
> > I hope this can be reconsidered, because the assumption that it would
> > have to be UTF-16 -> UTF-8 -> UTF-16 isn't accurate.
>
> I see that this part didn't get an on-list reply but got an blog reply:
> http://www.erahm.org/2017/05/24/a-rust-based-xml-parser-for-firefox/
>

Yes sorry, I should have followed up here as well!


> I continue to think it's a bad idea to write another parser that uses
> UTF-16 internally. Even though I can see your desire to keep the
> project tightly scoped, I think it's fair to ask you to expand the
> scope a bit by 1) adding a way to pass Latin-1 data to text nodes
> directly (and use this when the the parser sees a text node is all
> ASCII) and 2) replacing nsScanner with a bit of new buffering code
> that takes bytes from the network and converts them to UTF-8 using
> encoding_rs.
>
> We've both had the displeasure of modifying nsScanner as part of a
> security fix. nsScanner isn't valuable code that we should try to
> keep. It's no longer scanning for anything. It's just an
> over-complicated way of maintaining a buffer of UTF-16 data. While
> nsScanner and the associated classes are a lot of code, they do
> something simple that should be done in quite a bit less code, so as
> scope creep, replacing nsScanner should be a drop in a bucket
> effort-wise compared to replacing expat.
>
> I think it's super-sad if we get another UTF-16-using parser because
> replacing nsScanner was scoped out of the project.
>

Limiting to modifying nsScanner might be an option, but probably not
changing all callers that use the nsAString interface. I guess we can just
UTF-16 => UTF-8 those and file a bunch of follow ups?

One thing we've ignored are all the consumers expect output to be UTF-16,
so there's a fair amount of work on that side as well.

Maybe a reasonable approach is to use a UTF-8 interface for the replacement
Rust library and work on a staged rollout:

   1. Start just converting UTF-16 => UTF-8 for input at the nsExpatDriver
   level, UTF-8 => UTF-16 for output
   2. Modify/replace nsScanner with something that works with UTF-8 (and
   encoding_rs?), convert UTF-16 => UTF-8 for the nsAString methods
   3. Follow up replacing nsAString methods with UTF-8 versions
   4.  Look into whether modifying the consumers of the tokenized data to
   handle UTF-8 is reasonable, follow up as necessary

WDYT?


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

e10s-multi going to Release

[Blake Kaplan]

Hey all,

We've been running a series of e10s-multi experiments on the Beta
branch for a while now while watching memory use numbers, crash rates,
and other release criteria. After some positive returns from the first
round of testing we started talking about maybe releasing e10s-multi
in Firefox 54 while being cautiously pessimistic that something would
come up.

Well, nothing's come up. We are currently looking at releasing
e10s-multi, with 4 content processes for users without addons when
Firefox 54 releases and, assuming no major issues come up, expanding
the target audience.

To sum up: starting in Firefox 54, 80% of eligible users (users
eligible for e10s and that don't have addons) will be receiving multi
in the form of 4 content processes. We will be looking to expand that
to more users assuming good results.

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

Re: Improving visibility of compiler warnings

[gsquelart]

On Friday, May 26, 2017 at 6:03:02 AM UTC+12, Chris Peterson wrote:
> On 2017-05-25 5:31 AM, Ehsan Akhgari wrote:
> > On 05/19/2017 02:44 PM, Gregory Szorc wrote:
> >> `mach build` attempts to parse compiler warnings to a persisted
> >> "database."
> >> You can view a list of compiler warnings post build by running `mach
> >> warnings-list`. The intent behind this feature was to make it easier to
> >> find and fix compiler warnings. After all, something out of sight is
> >> out of
> >> mind.
> 
> Given that we treat warnings as errors on CI and most directories that 
> opt out of warnings-as-errors are third-party code 
> (ALLOW_COMPILER_WARNINGS in moz.build [1]), I don't think we need to 
> make the warning list any more visible. A warning regression in nearly 
> all first-party code is already treated as an error.
> 
> 
> [1] 
> https://searchfox.org/mozilla-central/search?q=ALLOW_COMPILER_WARNINGS&case=true&path=moz.build

Tangentially: "we treat warnings as errors on CI" -- It'd be great if local 
builds could have that behavior by default, so we (or just I?) don't get caught 
by surprise when warnings-as-errors appear after landing.

Or at least: Can I opt-in locally? (I tried 'ac_add_options 
--enable-warnings-ar-errors' in mozconfig, but that was not recognized.)
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving visibility of compiler warnings

[Andrew McCreight]

On Thu, May 25, 2017 at 4:03 PM,  wrote:

> On Friday, May 26, 2017 at 6:03:02 AM UTC+12, Chris Peterson wrote:
> > On 2017-05-25 5:31 AM, Ehsan Akhgari wrote:
> > > On 05/19/2017 02:44 PM, Gregory Szorc wrote:
> > >> `mach build` attempts to parse compiler warnings to a persisted
> > >> "database."
> > >> You can view a list of compiler warnings post build by running `mach
> > >> warnings-list`. The intent behind this feature was to make it easier
> to
> > >> find and fix compiler warnings. After all, something out of sight is
> > >> out of
> > >> mind.
> >
> > Given that we treat warnings as errors on CI and most directories that
> > opt out of warnings-as-errors are third-party code
> > (ALLOW_COMPILER_WARNINGS in moz.build [1]), I don't think we need to
> > make the warning list any more visible. A warning regression in nearly
> > all first-party code is already treated as an error.
> >
> >
> > [1]
> > https://searchfox.org/mozilla-central/search?q=ALLOW_
> COMPILER_WARNINGS&case=true&path=moz.build
>
> Tangentially: "we treat warnings as errors on CI" -- It'd be great if
> local builds could have that behavior by default, so we (or just I?) don't
> get caught by surprise when warnings-as-errors appear after landing.
>
> Or at least: Can I opt-in locally? (I tried 'ac_add_options
> --enable-warnings-ar-errors' in mozconfig, but that was not recognized.)
>

This has worked for me before:
ac_add_options --enable-warnings-as-errors


___
> 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: Improving visibility of compiler warnings

[Eric Rahm]

I think we disable it for local builds because we don't control what
versions of tools folks use. So clang vFOO might spit out errors we don't
see in clang vBAR and it would be a huge pain if those failed locally even
though they'd be fine in automation.

-e

On Thu, May 25, 2017 at 4:07 PM, Andrew McCreight 
wrote:

> On Thu, May 25, 2017 at 4:03 PM,  wrote:
>
> > On Friday, May 26, 2017 at 6:03:02 AM UTC+12, Chris Peterson wrote:
> > > On 2017-05-25 5:31 AM, Ehsan Akhgari wrote:
> > > > On 05/19/2017 02:44 PM, Gregory Szorc wrote:
> > > >> `mach build` attempts to parse compiler warnings to a persisted
> > > >> "database."
> > > >> You can view a list of compiler warnings post build by running `mach
> > > >> warnings-list`. The intent behind this feature was to make it easier
> > to
> > > >> find and fix compiler warnings. After all, something out of sight is
> > > >> out of
> > > >> mind.
> > >
> > > Given that we treat warnings as errors on CI and most directories that
> > > opt out of warnings-as-errors are third-party code
> > > (ALLOW_COMPILER_WARNINGS in moz.build [1]), I don't think we need to
> > > make the warning list any more visible. A warning regression in nearly
> > > all first-party code is already treated as an error.
> > >
> > >
> > > [1]
> > > https://searchfox.org/mozilla-central/search?q=ALLOW_
> > COMPILER_WARNINGS&case=true&path=moz.build
> >
> > Tangentially: "we treat warnings as errors on CI" -- It'd be great if
> > local builds could have that behavior by default, so we (or just I?)
> don't
> > get caught by surprise when warnings-as-errors appear after landing.
> >
> > Or at least: Can I opt-in locally? (I tried 'ac_add_options
> > --enable-warnings-ar-errors' in mozconfig, but that was not recognized.)
> >
>
> This has worked for me before:
> ac_add_options --enable-warnings-as-errors
>
>
> ___
> > 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

Re: Improving visibility of compiler warnings

[gsquelart]

On Friday, May 26, 2017 at 11:08:09 AM UTC+12, Andrew McCreight wrote:
> On Thu, May 25, 2017 at 4:03 PM,  wrote:
> 
> > On Friday, May 26, 2017 at 6:03:02 AM UTC+12, Chris Peterson wrote:
> > > On 2017-05-25 5:31 AM, Ehsan Akhgari wrote:
> > > > On 05/19/2017 02:44 PM, Gregory Szorc wrote:
> > > >> `mach build` attempts to parse compiler warnings to a persisted
> > > >> "database."
> > > >> You can view a list of compiler warnings post build by running `mach
> > > >> warnings-list`. The intent behind this feature was to make it easier
> > to
> > > >> find and fix compiler warnings. After all, something out of sight is
> > > >> out of
> > > >> mind.
> > >
> > > Given that we treat warnings as errors on CI and most directories that
> > > opt out of warnings-as-errors are third-party code
> > > (ALLOW_COMPILER_WARNINGS in moz.build [1]), I don't think we need to
> > > make the warning list any more visible. A warning regression in nearly
> > > all first-party code is already treated as an error.
> > >
> > >
> > > [1]
> > > https://searchfox.org/mozilla-central/search?q=ALLOW_
> > COMPILER_WARNINGS&case=true&path=moz.build
> >
> > Tangentially: "we treat warnings as errors on CI" -- It'd be great if
> > local builds could have that behavior by default, so we (or just I?) don't
> > get caught by surprise when warnings-as-errors appear after landing.
> >
> > Or at least: Can I opt-in locally? (I tried 'ac_add_options
> > --enable-warnings-ar-errors' in mozconfig, but that was not recognized.)
> >
> 
> This has worked for me before:
> ac_add_options --enable-warnings-as-errors

Haha, I've just noticed that I had typed '--enable-warnings-ar-errors' (Notice 
the 'ar' instead of 'as' -- must have been pirate day!)

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

Re: Improving visibility of compiler warnings

[Gregory Szorc]

On Thu, May 25, 2017 at 4:11 PM, Eric Rahm  wrote:

> I think we disable it for local builds because we don't control what
> versions of tools folks use. So clang vFOO might spit out errors we don't
> see in clang vBAR and it would be a huge pain if those failed locally even
> though they'd be fine in automation.
>

Exactly.

When we offer a build mode that uses the exact toolchain that automation is
using and can guarantee that the local environment reasonably approximates
CI, we can enable --enable-warnings-as-errors by default in that
configuration. We'll likely need a flag on `mach build` to disable that
warnings as errors per invocation, as sometimes developers just want to get
code to compile, even if there are warnings. But the default should be to
match CI so there are fewer surprises and errors are caught quicker. Of
course, the more we write Rust the more warnings as errors becomes the
explicit behavior because Rust just flat out refuses to compile problems
that C++ compilers treat as warnings.


>
> On Thu, May 25, 2017 at 4:07 PM, Andrew McCreight 
> wrote:
>
> > On Thu, May 25, 2017 at 4:03 PM,  wrote:
> >
> > > On Friday, May 26, 2017 at 6:03:02 AM UTC+12, Chris Peterson wrote:
> > > > On 2017-05-25 5:31 AM, Ehsan Akhgari wrote:
> > > > > On 05/19/2017 02:44 PM, Gregory Szorc wrote:
> > > > >> `mach build` attempts to parse compiler warnings to a persisted
> > > > >> "database."
> > > > >> You can view a list of compiler warnings post build by running
> `mach
> > > > >> warnings-list`. The intent behind this feature was to make it
> easier
> > > to
> > > > >> find and fix compiler warnings. After all, something out of sight
> is
> > > > >> out of
> > > > >> mind.
> > > >
> > > > Given that we treat warnings as errors on CI and most directories
> that
> > > > opt out of warnings-as-errors are third-party code
> > > > (ALLOW_COMPILER_WARNINGS in moz.build [1]), I don't think we need to
> > > > make the warning list any more visible. A warning regression in
> nearly
> > > > all first-party code is already treated as an error.
> > > >
> > > >
> > > > [1]
> > > > https://searchfox.org/mozilla-central/search?q=ALLOW_
> > > COMPILER_WARNINGS&case=true&path=moz.build
> > >
> > > Tangentially: "we treat warnings as errors on CI" -- It'd be great if
> > > local builds could have that behavior by default, so we (or just I?)
> > don't
> > > get caught by surprise when warnings-as-errors appear after landing.
> > >
> > > Or at least: Can I opt-in locally? (I tried 'ac_add_options
> > > --enable-warnings-ar-errors' in mozconfig, but that was not
> recognized.)
> > >
> >
> > This has worked for me before:
> > ac_add_options --enable-warnings-as-errors
> >
> >
> > ___
> > > 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
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Improving visibility of compiler warnings

[Ehsan Akhgari]

On 05/25/2017 02:14 PM, Gregory Szorc wrote:
On Thu, May 25, 2017 at 5:31 AM, Ehsan Akhgari 
mailto:ehsan.akhg...@gmail.com>> wrote:


What was the motivation behind this change?  Was there a complaint
from a significant number of developers about it being difficult
fixing compiler warnings grepping for things like "warning:" or
using ./mach warnings-list? Was the feedback from developers who
have the use case of writing code and fix compiler errors in such
code taken into account?


The motification was that relevant compiler warnings are flying under 
the radar and are detected too late in the development process - such 
as when pushing to Try. We want to catch problems as early in the 
development cycle as possible to reduce the end-to-end times for patch 
development. There have been complaints from developers over the years 
about this. What specifically motivated me to make this change 
recently was finding a pattern of feature requests during bug triage 
that all seemed to point to improving visibility of compiler warnings 
as a potential solution.


I fully acknowledge that the spew of warnings at the end of the build 
is annoying. This was expected to cause temporary pain. The hope was 
that this would spur people into fixing the warnings.


FWIW, IMO this is not OK.  I don't think there is any consensus that 
fixing compiler warnings is suddenly of such a great importance that we 
need to interrupt everyone's different workflows without them having 
opted into doing the work to fix the warnings.  And it may very well 
turn out that a project with a different format that isn't structured 
around the tools forcing people into fixing things may be more suitable 
to efforts like this, as years of work on 
https://bugzilla.mozilla.org/show_bug.cgi?id=buildwarning shows.


There has been some movement there. ICU warnings were suppressed, for 
example. And, there has been talk in this thread (and presumably 
elsewhere) about fixing other large offenders. So on that front, I'd 
say this change was successful.


I hope in the future you would consider discussing disruptive changes 
like this first instead of announcing them post-facto. Maybe at least we 
would have been able to think of a better initial implementation 
including not emitting the list for third-party library warnings or 
failed builds.  Or maybe we should have allowed people to opt in first.  
As the bug above shows, there are people who are interested to help in 
this area.


But the pace of progress hasn't been terrific and the status quo is 
annoying. This thread is also sapping up people's time. I've prepared 
a patch to tweak the behavior that I think strikes a compromise. I'll 
file a bug to track the review shortly.
Thank you.  I think most of the immediate productivity drain issues are 
fixed for now.


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

Re: Race Cache With Network experiment on Nightly

[Jason Duell]

>I think you were looking at the docs for opt-in Shield studies

Ah, right you are :)

OK, I've filed a bug for the pref study:

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

Thanks!

Jason

On Thu, May 25, 2017 at 2:27 PM, Matthew Grimes  wrote:

> I think you were looking at the docs for opt-in Shield studies
> (experiments deployed as add-ons), not for pref flipping experiments. Due
> to the nature of some of the opt-in studies we run they require a different
> approval process. Pref flipping is available for all users, it is not
> opt-in. The process currently requires one bug and an email to release
> drivers. Feedback on the doc/process is always welcome!
>
> On Thu, May 25, 2017 at 1:40 PM, Jason Duell  wrote:
>
>> I'm worried we're going from too little process here to too much (at
>> least for this bug).  Opening a meta-bug + 4 sub-bugs and doing a legal
>> review, etc., is a lot of overhead to test some network plumbing that is
>> not going to be especially noticeable to users.
>>
>> Also, we expect that this code will mostly benefit users with slow
>> hardware (disk drives especially).  We'll need to cast a very wide net to
>> get nightly users that match that profile.  The Shield docs say that
>> "participation for Shield Studies is currently around 1-2% of randomly
>> selected participants" (does that map to 1-2% of nightly users?), so I'm
>> not sure we'd get enough coverage if we used Shield.
>>
>> Jason
>>
>> On Thu, May 25, 2017 at 11:30 AM,  wrote:
>>
>>> Hey folks. I run the Shield team. Pref flipping experiments ARE
>>> available on Nightly and will be available in all channels (including
>>> Release) at some point in Firefox 54.
>>>
>>> Since the process is still relatively new, I've been hacking on some how
>>> to docs: https://docs.google.com/document/d/16bpDZGCPKrOIgkkIo5mWKHPT
>>> lYXOatyg_-CUi-3-e54/edit#heading=h.mzzhkdagng85
>>>
>>> Feel free to give those a spin. Feedback on the docs/process is welcome.
>>>
>>> On Wednesday, May 24, 2017 at 6:14:55 PM UTC-7, Patrick McManus wrote:
>>> > a howto for a pref experiment would be awesome..
>>> >
>>> > On Wed, May 24, 2017 at 9:03 PM, Eric Rescorla  wrote:
>>> >
>>> > > What's the state of pref experiments? I thought they were not yet
>>> ready.
>>> > >
>>> > > -Ekr
>>> > >
>>> > >
>>> > > On Thu, May 25, 2017 at 7:15 AM, Benjamin Smedberg <
>>> benja...@smedbergs.us>
>>> > > wrote:
>>> > >
>>> > > > Is there a particular reason this is landing directly to nightly
>>> rather
>>> > > > than using a pref experiment? A pref experiment is going to
>>> provide much
>>> > > > more reliable comparative data. In general we're pushing everyone
>>> to use
>>> > > > controlled experiments for nightly instead of landing experimental
>>> work
>>> > > > directly.
>>> > > >
>>> > > > --BDS
>>> > > >
>>> > > > On Wed, May 24, 2017 at 11:36 AM, Valentin Gosu <
>>> valentin.g...@gmail.com
>>> > > >
>>> > > > wrote:
>>> > > >
>>> > > > > As part of the Quantum Network initiative we are working on a
>>> project
>>> > > > > called "Race Cache With Network" (rcwn) [1].
>>> > > > >
>>> > > > > This project changes the way the network cache works. When we
>>> detect
>>> > > that
>>> > > > > disk IO may be slow, we send a network request in parallel, and
>>> we use
>>> > > > the
>>> > > > > first response that comes back. For users with slow spinning
>>> disks and
>>> > > a
>>> > > > > low latency network, the result would be faster loads.
>>> > > > >
>>> > > > > This feature is currently preffed off - network.http.rcwn.enabled
>>> > > > > In bug 1366224, which is about to land on m-c, we plan to enable
>>> it on
>>> > > > > nightly for one or two days, to get some useful telemetry for our
>>> > > future
>>> > > > > work.
>>> > > > >
>>> > > > > For any crashes or unexpected behaviour, please file bugs
>>> blocking
>>> > > > 1307504.
>>> > > > >
>>> > > > > Thanks!
>>> > > > >
>>> > > > > [1] https://bugzilla.mozilla.org/show_bug.cgi?id=rcwn
>>> > > > > [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1366224
>>> > > > > ___
>>> > > > > 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
>>> > >
>>> > >
>>>
>>> ___
>>> 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: Improving visibility of compiler warnings

[Joshua Cranmer 🐧]

On 5/25/17 6:11 PM, Eric Rahm wrote:

I think we disable it for local builds because we don't control what
versions of tools folks use. So clang vFOO might spit out errors we don't
see in clang vBAR and it would be a huge pain if those failed locally even
though they'd be fine in automation.


It should be possible to check the compiler and version and enable it by 
default if it's the same version as the ones on our check-in infrastructure.


--
Joshua Cranmer
Thunderbird and DXR developer
Source code archæologist

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

Re: Scope of XML parser rewrite?

[Henri Sivonen]

On Fri, May 26, 2017 at 1:18 AM, Eric Rahm  wrote:
> Limiting to modifying nsScanner might be an option, but probably not
> changing all callers that use the nsAString interface. I guess we can just
> UTF-16 => UTF-8 those and file a bunch of follow ups?

Yeah. The main follow-up would be
https://bugzilla.mozilla.org/show_bug.cgi?id=1355106 , which would
allow the avoidance of UTF-16 expansion in the
innerHTML/createContextualFragment/DOMParser cases for strings that
the JS engine doesn't store as 16-bit units in the first place.

(Performance-wise, I see the network entry point as the main thing for
the XML parser and innerHTML/createContextualFragment/DOMParser as
secondary.)

> One thing we've ignored are all the consumers expect output to be UTF-16, so
> there's a fair amount of work on that side as well.

I guess we have a viewpoint difference in terms of what the
"consumers" are. I think of the DOM as a consumer, and the DOM takes
Atoms (which can be looked up from UTF-8). While the callbacks in
nsExpatDriver aren't bad code like nsScanner is, I don't think of the
exact callback callback code as worth preserving in its precise
current state.

> Maybe a reasonable approach is to use a UTF-8 interface for the replacement
> Rust library and work on a staged rollout:
>
> Start just converting UTF-16 => UTF-8 for input at the nsExpatDriver level,
> UTF-8 => UTF-16 for output
> Modify/replace nsScanner with something that works with UTF-8 (and
> encoding_rs?), convert UTF-16 => UTF-8 for the nsAString methods
> Follow up replacing nsAString methods with UTF-8 versions
>  Look into whether modifying the consumers of the tokenized data to handle
> UTF-8 is reasonable, follow up as necessary
>
> WDYT?

Seems good to me with the note that doing the direct UTF-8 to nsIAtom
lookup would probably be a pretty immediate thing rather a true
follow-up.

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