Re: Is Big5 form submission fast enough?

[Tim Guan-tin Chien]

According to Alexa top 100 Taiwan sites and quick spot checks, I can only
see the following two sites encoded in Big5:

http://www.ruten.com.tw/
https://www.momoshop.com.tw/

Both are shopping sites (eBay-like and Amazon-like) so you get the idea how
forms are used there.

Mike reminded me to check the Tax filing website: http://www.tax.nat.gov.tw/
.Yes, it's unfortunately also in Big5.


On Mon, May 15, 2017 at 3:33 PM, Henri Sivonen  wrote:

> On Fri, May 12, 2017 at 4:28 AM, Kan-Ru Chen  wrote:
> > On Thu, May 11, 2017, at 01:43 PM, Henri Sivonen wrote:
> >> In Firefox 43, I rewrote our Big5 support and, among other things, I
> >> optimized the *encoder* for footprint rather than speed on the theory
> >> that users won't notice anyway since the encoder run is followed by a
> >> dominating wait for the network when submitting a form.
> >>
> >> Since then, I've learned that the relative slowness of the Big5
> >> encoder is greater than I had anticipated. Still, I haven't seen
> >> anyone complaining, but I don't know if anyone who finds it too slow
> >> knows how to attribute the complaint.
> >>
> >> I'd like to hear from someone who uses a Web site/app that involves
> >> submitting a textarea of Traditional Chinese text in Big5 if the form
> >> submission performance seems normal (doesn't feel particularly slow)
> >> on low-performance hardware, like an Android phone. (In the phone
> >> case, I mean the amount of text you'd feel OK to input on a phone at
> >> one time.)
> >>
> >> If UTF-8 is so widely deployed that no one in the Taipei office needs
> >> to submit forms in Big5 anymore, that would be good to know, too.
> >
> > I don't feel that I see a lot of Big5 websites out there. It's hard for
> > me to even find one to test.
>
> Thank you. I guess it doesn't really matter whether Big5 form
> submission feels slow or not if it's something that people very rarely
> experience.
>
> >> Context:
> >> I need to decide if I should make Big5 encode faster or if I should
> >> trade off speed for smaller footprint for the legacy Simplified
> >> Chinese and Japanese *encoders*, too.
> >
> > I think Shift_JIS are still widely used. But this is just my experience
> > and guessing. If we really want to know the real word usage we should
> > collect data. Is there some telemetry probe for this already?
>
> If Big5 form submission is so rarely used that its performance doesn't
> matter, we can't then extrapolate the lack of complaints to inform the
> implementation Japanese or Simplified Chinese legacy encodings.
> Keeping the implementation approach asymmetry between Big5 on one hand
> and legacy Japanese and legacy Simplified Chinese encodings on the
> other hand seems like a valid approach in the case of a large
> disparity in usage today.
>
> There aren't telemetry probes for "this" regardless of what "this" you
> meant. To my knowledge, there's no telemetry probe for counting form
> submission encodings and there is no telemetry probe measuring form
> submission round trip time by encoding.
>
> Telemetry analysis in this area would have to be scoped by locale
> (e.g. analysis of relative frequency of Big5 and UTF-8 form
> submissions scoped to the zh-TW locale) to be meaningful, and, from
> experience, such analyses are annoying to carry out, because they need
> manual privileged access to telemetry data. Locale-scoped views aren't
> available on the telemetry dashboards, because some locales have so
> few users that scoping by locale would narrow the population so much
> that the data could be potentially too identifiable. It would be nice
> if locale-scoped views were available for locales whose
> telemetry-enabled instances are more numerous than some threshold.
> (Each of zh-TW, zh-CN and ja-JP surely has enough users, at least on
> the release channel, for aggregate data views not to be too
> identifiable.)
>
> Additionally, I don't really know what would be a good way to place a
> probe in our code to measure form submission round trip time (what the
> user perceives) rather than the encode step only. (It's already
> obvious that the encode step itself would show a disparity by a
> massive factor between UTF-8 and Big5.)
>
> (I don't think we need telemetry to believe that Shift_JIS and gbk
> form submissions still happen routinely.)
>
> --
> Henri Sivonen
> hsivo...@hsivonen.fi
> https://hsivonen.fi/
> ___
> 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: Removing Jemalloc 4

[Eric Rahm]

Having been involved with jemalloc 3/4/5 work as well, I agree with Mike's
conclusions.

-e

On Mon, May 15, 2017 at 6:19 PM, Nicholas Nethercote  wrote:

> Just to add some context: glandium is deeply familiar with jemalloc4's
> internals, having submitted numerous patches and fixes to it. And he has
> spent *significant* time and effort on multiple occasions, on multiple
> versions of jemalloc4, trying to avoid the performance regressions, without
> success. If he can't get it into a state suitable for our use, I have
> trouble imagining who else could.
>
> In other words, this is not a hasty or premature decision, but one made
> reluctantly based on experience.
>
> Nick
>
> On Tue, May 16, 2017 at 10:14 AM, Mike Hommey  wrote:
>
> > Hi,
> >
> > We've tried to get off mozjemalloc for, apparently, close to 5 years
> > (date of the filing of bug 762449). We've had memory usage regressions
> > (like bug 1219914), and we've had perf regressions as per talos numbers
> > (things like bug 1138999), and those have never gone away (with
> > variations with each update of jemalloc >= 3).
> >
> > My best bet at this point is that it's "just" a consequence of the
> > difference in memory layout due to the differences in how the allocators
> > work. That doesn't make it more okay.
> >
> > Many updates to recent versions of jemalloc have been painful (usually
> > breaking everything except linux), and the current tip of the jemalloc
> > dev branch is not making things any better (see bug 1357301).
> >
> > Furthermore, bug 1361258 has started to modify mozjemalloc with new
> > features for stylo, further deepening the API surface between both
> > allocators. While what was added in bug 1361258 is possible to implement
> > for jemalloc 4, the burden of continuing to maintain both allocators is
> > not really appealing considering the perspective of ever switching.
> >
> > As much as it pains me, it's time to admit that switching to jemalloc >=
> > 3 is not going to happen, and pull the plug once and for all. This
> > decision has taken way too long to be made, and I apologize for that.
> >
> > This will happen with the landing of bug 1363992 in a few hours.
> >
> > As for the things we were hoping jemalloc >= 3 would allow us to do
> > (essentially, heap partitioning), we'll be working on getting that on
> > mozjemalloc shortly (bug 1361258 and followups will actually get us
> > close on the necessary infrastructure), as well as cleaning up its code
> > (I have a local patch queue that removes 15% of jemalloc.c), and
> > probably converting it to C++ (at least for some RAII benefits, and
> > converting some of the gory macros to templates)
> >
> > Mike.
> > ___
> > dev-platform mailing list
> > dev-platform@lists.mozilla.org
> > https://lists.mozilla.org/listinfo/dev-platform
> >
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Removing Jemalloc 4

[Nicholas Nethercote]

Just to add some context: glandium is deeply familiar with jemalloc4's
internals, having submitted numerous patches and fixes to it. And he has
spent *significant* time and effort on multiple occasions, on multiple
versions of jemalloc4, trying to avoid the performance regressions, without
success. If he can't get it into a state suitable for our use, I have
trouble imagining who else could.

In other words, this is not a hasty or premature decision, but one made
reluctantly based on experience.

Nick

On Tue, May 16, 2017 at 10:14 AM, Mike Hommey  wrote:

> Hi,
>
> We've tried to get off mozjemalloc for, apparently, close to 5 years
> (date of the filing of bug 762449). We've had memory usage regressions
> (like bug 1219914), and we've had perf regressions as per talos numbers
> (things like bug 1138999), and those have never gone away (with
> variations with each update of jemalloc >= 3).
>
> My best bet at this point is that it's "just" a consequence of the
> difference in memory layout due to the differences in how the allocators
> work. That doesn't make it more okay.
>
> Many updates to recent versions of jemalloc have been painful (usually
> breaking everything except linux), and the current tip of the jemalloc
> dev branch is not making things any better (see bug 1357301).
>
> Furthermore, bug 1361258 has started to modify mozjemalloc with new
> features for stylo, further deepening the API surface between both
> allocators. While what was added in bug 1361258 is possible to implement
> for jemalloc 4, the burden of continuing to maintain both allocators is
> not really appealing considering the perspective of ever switching.
>
> As much as it pains me, it's time to admit that switching to jemalloc >=
> 3 is not going to happen, and pull the plug once and for all. This
> decision has taken way too long to be made, and I apologize for that.
>
> This will happen with the landing of bug 1363992 in a few hours.
>
> As for the things we were hoping jemalloc >= 3 would allow us to do
> (essentially, heap partitioning), we'll be working on getting that on
> mozjemalloc shortly (bug 1361258 and followups will actually get us
> close on the necessary infrastructure), as well as cleaning up its code
> (I have a local patch queue that removes 15% of jemalloc.c), and
> probably converting it to C++ (at least for some RAII benefits, and
> converting some of the gory macros to templates)
>
> Mike.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Have you run 'mach bootstrap' lately?

[Gregory Szorc]

I thought there was a bug on file, but maybe not. I've long thought the
following changes should be made:

* `mach mercurial-setup` should be rolled into `mach bootstrap`
* `mach doctor` should be rolled into `mach bootstrap`
* `mach bootstrap` should remember answers from last time and not prompt on
subsequent runs unless a flag is specified
* `mach bootstrap` should be renamed/aliased to `mach refresh` (or similar)
to reflect that it is no longer limited to initial system setup

And of course there are missing features, such as Git configuration and
offering to create a Git clone.

bootstrap, doctor, and mercurial-setup are all under-loved features. They
tend to not get prioritized very highly. Typically, new features or bug
fixes are implemented when someone feels like scratching an itch. I wish I
could justify spending more time on these things because turnkey optimal
development environments are important. But it's a lot of ongoing work and
there always seems to be something else competing for my time :(

On Mon, May 15, 2017 at 4:59 PM, Ralph Giles  wrote:

> The stand-alone bootstrap.py script actually has a --no-interactive
> option (which answers 'yes' to everything) but the mach wrapper
> doesn't support this.
>
> `mach mercurial-setup` takes an --update-only option. Maybe we
> implementing something like that for `mach boostrap` would help. Or
> calling it something more descriptive like `mach update-deps`. Like
> mercurial-setup, it could still use the bootstrap python module to
> install things. While the two use cases are different, it makes sense
> to share code between an initial development environment setup script
> and one that updates that environment.
>
>  -r
>
> On Mon, May 15, 2017 at 3:39 PM, Ethan Glasser-Camp
>  wrote:
> > Actually, I think my real question is "What is the intended way for
> > developers to keep their development environment up-to-date?" I don't
> think
> > that way should require a developer to answer questions, because the
> > answers presumably haven't changed since the last time they answered
> them.
> > If the intended way is `mach bootstrap`, then I think `mach bootstrap`
> > should have an option to skip the questions[*]. If `mach bootstrap` is
> only
> > intended to run once when setting up a new development environment, then
> > maybe there should be a `mach tune-up` command or something like that.
> >
> > I'm happy to file bugs for whichever is the case, but I'm not sure which
> > one it is.
> >
> > Ethan
> >
> > [*] When using `./mach bootstrap --settings ./mozconfig`, I get: `The
> > bootstrap command does not accept the arguments: --settings ./mozconfig`.
> > When using `./mach --settings ./mozconfig bootstrap`, I get the
> questions.
> >
> >
> > On Fri, May 12, 2017 at 1:04 PM, Geoffrey Brown 
> wrote:
> >
> >> I'm not sure. I always just answer the prompts and am happy with that.
> >>
> >> There is a --settings option, which sounds like it might be helpful,
> but I
> >> don't have any experience with that.
> >>
> >>  - Geoff
> >>
> >> On Fri, May 12, 2017 at 9:00 AM, Ethan Glasser-Camp <
> >> eglasserc...@mozilla.com> wrote:
> >>
> >>> Is there a way to run it without having to reanswer the configuration
> >>> questions?
> >>>
> >>> Ethan
> >>>
> >>>
> >>
> > ___
> > 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

Removing Jemalloc 4

[Mike Hommey]

Hi,

We've tried to get off mozjemalloc for, apparently, close to 5 years
(date of the filing of bug 762449). We've had memory usage regressions
(like bug 1219914), and we've had perf regressions as per talos numbers
(things like bug 1138999), and those have never gone away (with
variations with each update of jemalloc >= 3).

My best bet at this point is that it's "just" a consequence of the
difference in memory layout due to the differences in how the allocators
work. That doesn't make it more okay.

Many updates to recent versions of jemalloc have been painful (usually
breaking everything except linux), and the current tip of the jemalloc
dev branch is not making things any better (see bug 1357301).

Furthermore, bug 1361258 has started to modify mozjemalloc with new
features for stylo, further deepening the API surface between both
allocators. While what was added in bug 1361258 is possible to implement
for jemalloc 4, the burden of continuing to maintain both allocators is
not really appealing considering the perspective of ever switching.

As much as it pains me, it's time to admit that switching to jemalloc >=
3 is not going to happen, and pull the plug once and for all. This
decision has taken way too long to be made, and I apologize for that.

This will happen with the landing of bug 1363992 in a few hours.

As for the things we were hoping jemalloc >= 3 would allow us to do
(essentially, heap partitioning), we'll be working on getting that on
mozjemalloc shortly (bug 1361258 and followups will actually get us
close on the necessary infrastructure), as well as cleaning up its code
(I have a local patch queue that removes 15% of jemalloc.c), and
probably converting it to C++ (at least for some RAII benefits, and
converting some of the gory macros to templates)

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

Re: Have you run 'mach bootstrap' lately?

[Ralph Giles]

The stand-alone bootstrap.py script actually has a --no-interactive
option (which answers 'yes' to everything) but the mach wrapper
doesn't support this.

`mach mercurial-setup` takes an --update-only option. Maybe we
implementing something like that for `mach boostrap` would help. Or
calling it something more descriptive like `mach update-deps`. Like
mercurial-setup, it could still use the bootstrap python module to
install things. While the two use cases are different, it makes sense
to share code between an initial development environment setup script
and one that updates that environment.

 -r

On Mon, May 15, 2017 at 3:39 PM, Ethan Glasser-Camp
 wrote:
> Actually, I think my real question is "What is the intended way for
> developers to keep their development environment up-to-date?" I don't think
> that way should require a developer to answer questions, because the
> answers presumably haven't changed since the last time they answered them.
> If the intended way is `mach bootstrap`, then I think `mach bootstrap`
> should have an option to skip the questions[*]. If `mach bootstrap` is only
> intended to run once when setting up a new development environment, then
> maybe there should be a `mach tune-up` command or something like that.
>
> I'm happy to file bugs for whichever is the case, but I'm not sure which
> one it is.
>
> Ethan
>
> [*] When using `./mach bootstrap --settings ./mozconfig`, I get: `The
> bootstrap command does not accept the arguments: --settings ./mozconfig`.
> When using `./mach --settings ./mozconfig bootstrap`, I get the questions.
>
>
> On Fri, May 12, 2017 at 1:04 PM, Geoffrey Brown  wrote:
>
>> I'm not sure. I always just answer the prompts and am happy with that.
>>
>> There is a --settings option, which sounds like it might be helpful, but I
>> don't have any experience with that.
>>
>>  - Geoff
>>
>> On Fri, May 12, 2017 at 9:00 AM, Ethan Glasser-Camp <
>> eglasserc...@mozilla.com> wrote:
>>
>>> Is there a way to run it without having to reanswer the configuration
>>> questions?
>>>
>>> Ethan
>>>
>>>
>>
> ___
> 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: Have you run 'mach bootstrap' lately?

[Ethan Glasser-Camp]

Actually, I think my real question is "What is the intended way for
developers to keep their development environment up-to-date?" I don't think
that way should require a developer to answer questions, because the
answers presumably haven't changed since the last time they answered them.
If the intended way is `mach bootstrap`, then I think `mach bootstrap`
should have an option to skip the questions[*]. If `mach bootstrap` is only
intended to run once when setting up a new development environment, then
maybe there should be a `mach tune-up` command or something like that.

I'm happy to file bugs for whichever is the case, but I'm not sure which
one it is.

Ethan

[*] When using `./mach bootstrap --settings ./mozconfig`, I get: `The
bootstrap command does not accept the arguments: --settings ./mozconfig`.
When using `./mach --settings ./mozconfig bootstrap`, I get the questions.


On Fri, May 12, 2017 at 1:04 PM, Geoffrey Brown  wrote:

> I'm not sure. I always just answer the prompts and am happy with that.
>
> There is a --settings option, which sounds like it might be helpful, but I
> don't have any experience with that.
>
>  - Geoff
>
> On Fri, May 12, 2017 at 9:00 AM, Ethan Glasser-Camp <
> eglasserc...@mozilla.com> wrote:
>
>> Is there a way to run it without having to reanswer the configuration
>> questions?
>>
>> Ethan
>>
>>
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Switching to async/await from Task.jsm/yield

[Sam Foster]

I think this deserves a round of applause. Its a large undertaking with
measurable perf wins in areas with strong SEP(1) fields

1. https://en.wikipedia.org/wiki/Somebody_else%27s_problem

/Sam



On Wed, May 10, 2017 at 7:09 PM, Florian Quèze  wrote:

> On Mon, Mar 27, 2017 at 9:42 PM, Dave Townsend 
> wrote:
>
> > lets go ahead with this and avoid using Task.jsm in the future.
>
> Patches to remove Task.jsm usage from browser/ and toolkit/ are now
> available in https://bugzilla.mozilla.org/show_bug.cgi?id=1353542
> along with the scripts that generated them.
>
> I currently expect to land them on Friday morning. Given the size of
> the patches (2040 files changed, more than 35k lines changed), this
> landing will likely happen with a tree closure, to avoid merging
> conflicts between inbound and autoland.
>
> If you have WIP front-end patches that are almost ready to land, I
> would suggest landing them soon to avoid bitrot.
>
> Florian
>
> --
> Florian Quèze
> ___
> firefox-dev mailing list
> firefox-...@mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Have you run 'mach bootstrap' lately?

[Ryan VanderMeulen]

On 5/12/17 6:16 PM, Gregory Szorc wrote:


Isn't that something that mach bootstrap should be doing?



Yes. A patch is in Ryan's review queue to do this.


Said patch is now merged to mozilla-central! :-)

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

Re: IDNA processing

[Gervase Markham]

On 12/05/17 08:46, Anne van Kesteren wrote:
> For about five years I've been trying to figure out the IDNA algorithm
> that a) browsers follow and b) browsers want to follow, but I've not
> had much luck thus far getting folks to reply. E.g.,
> https://lists.w3.org/Archives/Public/www-archive/2017Feb/0006.html
> went largely unaddressed.

Well, you generally know my opinion :-) IDNA 2008 non-transitional.

> One big difference between http://www.unicode.org/reports/tr46/ and
> browsers is how ASCII is handled. Per UTS #46 ASCII is handled the
> same as non-ASCII. However, in browsers ASCII takes a "fast path" and
> skips the ToASCII algorithm. YouTube now depends on that (it has CDN
> domains with hyphens in the third and fourth position, as reported at,
> e.g., https://github.com/nodejs/node/issues/12965).

ISTM that the 3rd/4th placed hyphens were banned so the domain name
system had an extension mechanism, and that was used for IDNA (xn--). If
we allow domains of that form, we no longer have that extension
mechanism. The question is, how big a loss is that?

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

Re: No information about the related folder in the bookmark manager screen

[Marco Bonardo]

There's an old bug about this
https://bugzilla.mozilla.org/show_bug.cgi?id=469421 but no ETA (I also
suspect a Library redesign may happen after Photon)

On Sun, May 14, 2017 at 10:34 AM,  wrote:

> Hi,
>
> When searching for a bookmark we don't have any information about the
> folder.
> It could be very useful to have this information on this screen:
> http://imgur.com/Xm9urfPl.png
>
> It's also an important information when trying to remove duplicated
> bookmarks.
>
> Thank you.
>
> Firefox 53.0.2 64 bits
> ___
> 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: Is Big5 form submission fast enough?

[Henri Sivonen]

On Fri, May 12, 2017 at 4:28 AM, Kan-Ru Chen  wrote:
> On Thu, May 11, 2017, at 01:43 PM, Henri Sivonen wrote:
>> In Firefox 43, I rewrote our Big5 support and, among other things, I
>> optimized the *encoder* for footprint rather than speed on the theory
>> that users won't notice anyway since the encoder run is followed by a
>> dominating wait for the network when submitting a form.
>>
>> Since then, I've learned that the relative slowness of the Big5
>> encoder is greater than I had anticipated. Still, I haven't seen
>> anyone complaining, but I don't know if anyone who finds it too slow
>> knows how to attribute the complaint.
>>
>> I'd like to hear from someone who uses a Web site/app that involves
>> submitting a textarea of Traditional Chinese text in Big5 if the form
>> submission performance seems normal (doesn't feel particularly slow)
>> on low-performance hardware, like an Android phone. (In the phone
>> case, I mean the amount of text you'd feel OK to input on a phone at
>> one time.)
>>
>> If UTF-8 is so widely deployed that no one in the Taipei office needs
>> to submit forms in Big5 anymore, that would be good to know, too.
>
> I don't feel that I see a lot of Big5 websites out there. It's hard for
> me to even find one to test.

Thank you. I guess it doesn't really matter whether Big5 form
submission feels slow or not if it's something that people very rarely
experience.

>> Context:
>> I need to decide if I should make Big5 encode faster or if I should
>> trade off speed for smaller footprint for the legacy Simplified
>> Chinese and Japanese *encoders*, too.
>
> I think Shift_JIS are still widely used. But this is just my experience
> and guessing. If we really want to know the real word usage we should
> collect data. Is there some telemetry probe for this already?

If Big5 form submission is so rarely used that its performance doesn't
matter, we can't then extrapolate the lack of complaints to inform the
implementation Japanese or Simplified Chinese legacy encodings.
Keeping the implementation approach asymmetry between Big5 on one hand
and legacy Japanese and legacy Simplified Chinese encodings on the
other hand seems like a valid approach in the case of a large
disparity in usage today.

There aren't telemetry probes for "this" regardless of what "this" you
meant. To my knowledge, there's no telemetry probe for counting form
submission encodings and there is no telemetry probe measuring form
submission round trip time by encoding.

Telemetry analysis in this area would have to be scoped by locale
(e.g. analysis of relative frequency of Big5 and UTF-8 form
submissions scoped to the zh-TW locale) to be meaningful, and, from
experience, such analyses are annoying to carry out, because they need
manual privileged access to telemetry data. Locale-scoped views aren't
available on the telemetry dashboards, because some locales have so
few users that scoping by locale would narrow the population so much
that the data could be potentially too identifiable. It would be nice
if locale-scoped views were available for locales whose
telemetry-enabled instances are more numerous than some threshold.
(Each of zh-TW, zh-CN and ja-JP surely has enough users, at least on
the release channel, for aggregate data views not to be too
identifiable.)

Additionally, I don't really know what would be a good way to place a
probe in our code to measure form submission round trip time (what the
user perceives) rather than the encode step only. (It's already
obvious that the encode step itself would show a disparity by a
massive factor between UTF-8 and Big5.)

(I don't think we need telemetry to believe that Shift_JIS and gbk
form submissions still happen routinely.)

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

[Firefox Desktop] Issues found: May 8th to May 12th

[Andrei Vaida]

Hi everyone,

Here's the list of new issues found and filed by the Desktop Release QA 
Team last week, May 8 - May 12 (week 19).


Additional details on the team's priorities last week as well as the 
plans for the current week are available at:

https://public.etherpad-mozilla.org/p/DesktopManualQAWeeklyStatus

RELEASE CHANNEL
none

BETA CHANNEL
IDSummaryProductComponentIs a regressionAssigned to1363315 
"Save page to 
pocket" doesn't work for pdfs in presentation modeFirefoxPDF 
ViewerTBDNOBODY1363671 
No favicon on 
about:addonsCoreDOM: SecurityTBDNOBODY1364436 
Close button does 
not stick at the bottom of the menu page in three.js 
demoCoreGeneralREDNOBODY1364440 
Scroll inside 
three.js demo causes elements to bounce up and downCorePanning and 
ZoomingTBDNOBODY1364443 
Scrolling inside 
elements from three.js is ignored and instead it scrolls the whole 
pageCorePanning and ZoomingTBDNOBODY#2829 
Page 
Whiteouts after opening Firefox Screenshots while holding the Escape 
buttonScreenshots--NOBODY#2838 
"UI is not 
defined" error is constantly thrown when dragging through the 
websiteScreenshots--NOBODY#2842 
“Invalid 
tab ID” error is constantly thrown if switching back to the tab from 
which the screenshot was performedScreenshots--Ian Bicking


NIGHTLY CHANNEL
IDSummaryProductComponentIs a regressionAssigned to1363378 
[e10s] Tab 
processes are not killed after crashing FirefoxCoreDOM: Content 
ProcessesTBDNOBODY1364041 
Not enough space 
between some strings and dropdown 
fieldsFirefoxPreferencesYESNOBODY1364061 
Inconsistent 
distances between name sections and their 
contentFirefoxPreferencesNONOBODY


ESR CHANNEL
none

Regards,
Andrei (:avaida)
Desktop Release QA
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform