Re: Coding style question: Meaningless argument names in declarations

[Kan-Ru Chen]

On Thu, Sep 7, 2017, at 11:16 PM, Emilio Cobos Álvarez wrote:
> This is very context dependent, I'd never omit a name in a function that
> takes (Element& aParent, Element& aChild), but it seems reasonable to
> omit it in the case where there's no better name, like (InsertionKind
> aInsertionKind) or (Element& aElement).

IMO even the seemly redundant name |aElement| conveys information like
"this method can take any Element" and that is very different when I see
|aParent| or |aChild|.

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

Re: sccache as ccache

[Kan-Ru Chen]

On Wed, Jul 26, 2017, at 09:05 PM, Ted Mielczarek wrote:
> Yesterday I published sccache 0.2 to crates.io, so you can now `cargo
> install sccache` and get the latest version (it'll install to
> ~/.cargo/bin). If you build Firefox on Linux or OS X you can (and
> should) use sccache in place of ccache for local development. It's as
> simple as adding this to your mozconfig (assuming sccache is in your
> $PATH):
> 
>   ac_add_options --with-ccache=sccache
> 
> The major benefit you gain over ccache is that sccache can cache Rust
> compilation as well, and the amount of Rust code we're adding to Firefox
> is growing quickly. (We're on track to enable building Stylo by default
> soon, which will add quite a bit of Rust.)
> 
> On my several-year-old Linux machine (Intel(R) Core(TM) i7-3770 CPU @
> 3.40GHz, 32GB, SSD), if I build; clobber; build with sccache enabled the
> second (fully-cached) build completes in just over 4 minutes:
> 
>   4:11.92 Overall system resources - Wall time: 252s; CPU: 69%; Read
>   bytes: 491520; Write bytes: 6626512896; Read time: 60; Write time:
>   1674852
> 
> sccache still isn't completely straightforward to use on Windows[1] but
> I aim to fix that this quarter so that using it there will be just as
> simple as on other platforms.

Windows support sounds very exciting! Will it support cache sharing?

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

Re: how exactly are the P*.h files generated ?

[Kan-Ru Chen]

Hi!

On Sun, Jul 23, 2017, at 03:42 PM, Enrico Weigelt, metux IT consult
wrote:
> Hi folks,
> 
> I've got some trouble w/ regenarating
> ./obj-thunderbird/ipc/ipdl/_ipdlheaders/mozilla/dom/PContentParent.h
> 
> 
> I had to change ./mozilla/dom/ipc/ContentParent.h to ifdef-out some
> methods (trying to build tbird w/o media stuff), but PContentParent.h
> still contains these functions (and no #ifdef around them).

They are IPDL generated headers.

The P*{Parent,Child}.h files are generated from their corresponding
P*.ipdl files. So for PContentParent.h you would need to lookup
PContent.ipdl which is at dom/ipc/PContent.ipdl

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

Re: Avoiding jank in async functions/promises?

[Kan-Ru Chen]

On Thu, May 18, 2017, at 10:10 AM, L. David Baron wrote:
> On Thursday 2017-05-18 11:22 +1000, Mark Hammond wrote:
> > I'm wondering if there are any ideas about how to solve this optimally?
> > Naively, it seems that the (broadest sense of the term) "platform" might be
> > able to help here using it's knowledge of the event-loop state - eg, a
> > function that indicates "are we about to starve the event loop and become
> > janky?", or possibly even the whole hog (ie, "please yield to the event loop
> > if you think now is a good time, otherwise just hand back a pre-resolved
> > promise").
> 
> One other option would be to use time rather than iterations as a
> measure of when to return.
> 
> A platform API that's somewhat like this is requestIdleCallback,
> whose spec is at https://w3c.github.io/requestidlecallback/ -- in
> particular, the timeRemaining() method on the IdleDeadline object
> passed to the callback.  See also:
> https://developer.mozilla.org/en-US/docs/Web/API/Window/requestIdleCallback
> https://developer.mozilla.org/en-US/docs/Web/API/Background_Tasks_API
> 
> I'm not sure whether it works for privileged (chrome) JS, but it
> seems like it ought to...

The non-DOM version of rIC is being tracked by
https://bugzilla.mozilla.org/show_bug.cgi?id=1353206 and
https://bugzilla.mozilla.org/show_bug.cgi?id=1358476

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

Re: Is Big5 form submission fast enough?

[Kan-Ru Chen]

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.

> 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?

Kanru

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

IPDL now supports async returns with MozPromise

[Kan-Ru Chen]

Hello!

With bug 1313200 landed, async IPC messages can now return data via
MozPromises.

The IPDL syntax:

protocol PFoo {
child:
async Bar() returns (bool param);
};

will generate IPC code that allow the send method like this:

SendBar()->Then(AbstractThread::GetCurrent(), __func__,
[](bool param) {
  // do something
},
[](PromiseRejectReason aReason) {
  // handle send failure
});

For a message named Foo it will receive a promise resolver with type
FooPromise. For example the receiving side of previous message
PFoo::Bar the handler looks like this:

mozilla::ipc::IPCResult
FooChild::RecvBarMessage(RefPtr&& aPromise)
{
bool result;
// do some computation
aPromise->Resolve(result);
}

If there are multiple return values, they will be wrapped in a
mozilla::Tuple.

The usual MozPromise rule applies. You can store the promise and
resolve it later. You can direct the ThenFunction to be run on other
threads. If the channel is closed before all promises are resolved,
the pending promises will be rejected with
PromiseRejectReason::ChannelClosed. Promises resolved after channel
close are ignored.

It is discouraged for the receiving handler to reject the promise. It
should be reserved for the IPC system to signal errors. If you must
reject the promise, only PromiseRejectReason::HandlerRejected is valid
value.

Please give it a try. In theory this should work for all IPC actors. If
you encountered issues or have ideas to
improve this, please file a bug in Core :: IPC.

Thanks,
Kanru

P.S. Note that async constructor or destructor does not support return
promises because the semantic is still not clear.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Tier 3 win64 ASan builds on try

[Kan-Ru Chen]

Hooray! Thanks for making tests working on Windows!

Kanru 

On Thu, Apr 6, 2017, at 10:14 PM, Jeff Muizelaar wrote:
> Glorious. Thanks to everyone who made this happen.
> 
> -Jeff
> 
> On Thu, Apr 6, 2017 at 10:11 PM, Ting-Yu Chou  wrote:
> > Just a heads up that now we have win64 ASan builds on try. The try format:
> >
> >   try: -b o -p win64-asan -u none -t none
> >
> > Bug 1347793 is tracking the failed tests on taskcluster, though by now the
> > tests
> > for normal windows builds are not all green yet and I haven't seen any real
> > ASan
> > issue.
> >
> > I am not sure if js/fuzzing folks are interested, but probably we can try
> > to do
> > fuzzing for jsshell-asan, on windows. (Wonder do we have automated fuzzing
> > tests
> > on any infrastructure.)
> >
> > Note this is still in tier 3, things can regress easily.
> >
> > Ting
> > ___
> > 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

New sync IPC messages will require IPC peers' review

[Kan-Ru Chen]

Hi,

In order to reduce the performance issues caused by sync IPC messages,
we are tracking and removing sync IPCs from the content process or the
UI thread[1]. With bug 1336919 landed[[2] all additions of new sync
messages must be recorded in ipc/ipdl/sync-messages.ini and reviewed by
an IPC peer. Shortly we will also extend the WebIDL hook to block
unreviewed changes from pushing[3]. This is to ensure that we don't add
sync IPC messages that cause performance issues needlessly. We
appreciate your understanding.

Kanru

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

ExposureGuidelines updated (was Re: Intent to implement: CSS text-justify property)

[Kan-Ru Chen]

On Thu, Feb 9, 2017, at 12:28 AM, Boris Zbarsky wrote:
> On 2/8/17 5:08 AM, Jeremy Chen wrote:
> > Link to standard: https://drafts.csswg.org/css-text-3/#text-justify-property
> 
> How stable is this spec?
> 
> Note that even if it's unstable that shouldn't stop us implementing; 
> that mostly affects shipping.  So as long as we're pretty sure that the 
> basic set of functionality is stable, even if the actual names of the 
> values are not, implementing makes sense.

After having seen many intent to implement mails raised this question, I
copied above sentences to the email template suggestions (thanks,
Boris).

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

Re: Expanding regular regression triage to include crashes?

[Kan-Ru Chen]

On Thu, Dec 15, 2016, at 11:17 AM, Ryan VanderMeulen wrote:
> I like the idea in principle, but in practice, two meetings a week is 
> already not enough to get through regression bugs. Are we going to add 
> more meetings to accommodate this? And I'll note that already, 
> attendance of the regular regression triage meetings has declined from 
> where it was a month or two ago.

I think the most important is to identify whether the crash bugs are
regressions so they can be tracked accordingly. We have a third triage
meeting in Asia friendly timezone; I think we can try to go over the
list of crash bugs and put correct flags in the meeting.

Kanru

> Also, I thought one of the roles of the Uptime team was to triage crash 
> bugs. Is that not actually the case?
> 
> -Ryan
> 
> On 12/14/2016 9:42 PM, Jet Villegas wrote:
> > +1 on expanding the search. That should help get earlier diagnosis. We
> > should also add 'regression' to those bugs as part of triage, as
> > appropriate.
> >
> > --Jet
> 
> ___
> 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

PSA: The return type of IPDL Recv* methods changed from bool to mozilla::ipc::IPCResult

[Kan-Ru Chen]

Hello,

In bug 1314254 the return type of IPDL Recv* methods was changed from
bool to mozilla::ipc::IPCResult in order to make crash reports to have
better stack information. There are now three choices to return from a
Recv* method:

1. return IPC_OK(); where previously we return true
2. return IPC_FAIL_NO_REASON(this); where we previously return false
3. return IPC_FAIL(this, "a string explaining the failure");

All the existing methods are mass converted to either 1 or 2. New codes
are encouraged to annotate the failing reason with 3. I'm sorry that
some patches were backed out because they caused m-i to m-c merge
conflict. Hopefully the conflicts should be very easy to fix.

Kanru

[bug]: https://bugzilla.mozilla.org/show_bug.cgi?id=1314254
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to restrict to secure contexts: navigator.geolocation

[Kan-Ru Chen]

On Sat, Oct 22, 2016, at 09:38 PM, Richard Barnes wrote:
> On Fri, Oct 21, 2016 at 5:56 PM, Ehsan Akhgari 
> wrote:
> > Since the proposal in the bug is adding [SecureContext] to
> > Navigator.geolocation, have we also collected telemetry around which
> > properties and methods are accessed?  Since another kind of breakage we
> > may encounter is code like |navigator.geolocation.getCurrentPosition()|
> > throwing an exception and breaking other parts of site scripts...
> >
> 
> I'm not picky about how exactly we turn this off, as long as the
> functionality goes away.  Chrome and Safari both immediately call the
> error handler with the same error as if the user had denied permission.  We
> could do that too, it would just be a little more code.

I would be OK with this change if it is implemented in a way compatible
with Chrome and Safari. Looks like they both call the error handler and
show an error in the console when the request is denied. And it should
be behind a pref so we can monitor it's usage during the release cycle.

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

Re: PSA: mozilla/unused.h renamed to mozilla/Unused.h

[Kan-Ru Chen]

On Sat, Aug 27, 2016, at 11:35 AM, Gregory Szorc wrote:
> On Fri, Aug 26, 2016 at 8:27 PM, Steve Fink <sf...@mozilla.com> wrote:
> 
> > On 08/26/2016 08:16 PM, Gregory Szorc wrote:
> >
> >>
> >> On Aug 26, 2016, at 19:54, Kan-Ru Chen <kc...@mozilla.com> wrote:
> >>>
> >>> Hello,
> >>>
> >>> In Bug 1297276 I landed a patch to rename mozilla/unused.h to
> >>> mozilla/Unused.h to make it more consistent with our other MFBT headers.
> >>> Normally rename a header shouldn't cause too much trouble, however this
> >>> rename is only changing the case so you might experience some problems
> >>> on case insensitive filesystem.
> >>>
> >>> As pointed out by Tim in
> >>> https://bugzilla.mozilla.org/show_bug.cgi?id=1297276#c19 if you use
> >>> |git pull -f| to update local copy of gecko and git refuse to, you can
> >>> rm mfbt/unused.* first to make git happy.
> >>>
> >> Case only renames cause a lot of havoc. Somewhere there is an open bug to
> >> implement a server side hook to reject them.
> >>
> >> What I'm trying to say is thank you for reminding me to implement the
> >> hook. And congratulations on likely being the last person to perform a case
> >> only rename on the repo.
> >>
> >
> > For the record, is there a better way to accomplish this? In this
> > particular case, it seems like we really do want the rename. Would it work
> > better to do two commits, one from mozilla/unused.h ->
> > mozilla/LucyTheDancingFerret.h, then another doing
> > mozilla/LucyTheDancingFerret.h -> mozilla/Unused.h?
> 
> 
> No. Because if you perform an update/checkout across the rename, you may
> encounter problems. This can happen when bisecting, for example.
> 
> Now, this isn't as bad as a case folding collision where you have both
> unused.h and Unused.h: some filesystems just flat out refuse that.
> 
> At least with a rename your VCS has the opportunity to delete the old
> file
> before creating the different cased one. But even then, build systems and
> other tools can be confused because some filesystems are case insensitive
> but case preserving and tools may make inappropriate decisions about
> whether "unused.h" and "Unused.h" are the same file. There's a lot that
> can
> go wrong. So the whole scenario is best avoided.

So given the fact people can make mistakes, what would you suggest if
one really wants to fix the filename? I hope the hook will display such
suggestions instead of just say "don't do this."

Kanru
 
> The bug tracking the server hook is 797962 btw.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

PSA: mozilla/unused.h renamed to mozilla/Unused.h

[Kan-Ru Chen]

Hello,

In Bug 1297276 I landed a patch to rename mozilla/unused.h to
mozilla/Unused.h to make it more consistent with our other MFBT headers.
Normally rename a header shouldn't cause too much trouble, however this
rename is only changing the case so you might experience some problems
on case insensitive filesystem.

As pointed out by Tim in
https://bugzilla.mozilla.org/show_bug.cgi?id=1297276#c19 if you use 
|git pull -f| to update local copy of gecko and git refuse to, you can
rm mfbt/unused.* first to make git happy.

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

Re: Intent to Implement: User Timing API

[Kan-Ru Chen]

Yes! The marks could be used by SPS or Tasktracer!

Kyle Machulis kmachu...@mozilla.com writes:

 Small correction, the preference should be dom.enable_user_timing, not 
 dom.enable_performance 

 - Original Message -

 From: Jonas Sicking jo...@sicking.cc
 To: Kyle Machulis kmachu...@mozilla.com
 Cc: dev-platform dev-platform@lists.mozilla.org, dev-webapi
 dev-web...@lists.mozilla.org
 Sent: Thursday, December 11, 2014 5:15:22 PM
 Subject: Re: Intent to Implement: User Timing API

 Yes!

 On Thu, Dec 11, 2014 at 5:11 PM, Kyle Machulis kmachu...@mozilla.com wrote:
  Summary: We've already got the performance resource timing API implemented
  (https://bugzilla.mozilla.org/show_bug.cgi?id=822480), but never got
  around to implementing the user timing API. This would allow users to set
  unique marks for profiling events in their own code, and most of the
  objects already exist, we just need to expose/store them in the right way.
  There's some performance tools being developed for FxOS that polyfill this
  API, but it'd be nice to just have it done.
 
  Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=782751
 
  Link to Standard: http://www.w3.org/TR/user-timing/
 
  Platform Coverage: all
 
  Estimated or Target Release: Firefox 38
 
  Preference behind which this will be implemented: dom.enable_performance
  ___
  dev-platform mailing list
  dev-platform@lists.mozilla.org
  https://lists.mozilla.org/listinfo/dev-platform
 ___
 dev-webapi mailing list
 dev-web...@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-webapi
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform