Re: Proposed W3C Charter: Second Screen Working Group

[Shih-Chiang Chien]

Thanks David, the revised comment lgtm.
Making SecondScreen WG focusing on interoperability first would be a better
direction for now.

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

On Sat, Jan 6, 2018 at 6:37 PM, Martin Thomson <m...@mozilla.com> wrote:

> Thanks for doing this David.  The objection here is very neatly put.  I
> hope that we can do something soon to help address the shortcoming
> regarding the protocol.
>
> On 6 Jan. 2018 2:26 pm, "Tantek Çelik" <tan...@cs.stanford.edu> wrote:
>
>> This is an improvement and I think has a better chance of effecting
>> change with the specific proposals.
>>
>> We're still making this an FO right? (I think we should)
>>
>> perhaps:
>>
>> s/We would ask that:/We ask (formal objection) that:
>>
>> Your "open to other paths" closing statement provides an out to
>> resolving the FO without necessarily doing everything we precisely
>> ask, which both helps the dialog, and allows us room to declare the FO
>> upfront.
>>
>> Thanks,
>>
>> Tantek
>>
>> On Fri, Jan 5, 2018 at 12:58 PM, L. David Baron <dba...@dbaron.org>
>> wrote:
>> > So after a little off-list discussion with SC, I have a somewhat
>> > revised proposal for comments that perhaps proposes what might be a
>> > more acceptable remedy (although thanks to timezones I don't
>> > actually know what SC thinks of this proposal).
>> >
>> > -David
>> >
>> > =
>> >
>> > The current situation with the API developed by this Working Group
>> > is that it is a API for a web page to interact with a connection
>> > between the web browser and a separate screen that exists entirely
>> > in a closed ecosystem.  For example, a browser made by Google might
>> > connect to displays that support the proprietary Chromecast
>> > protocol, whereas one made by Apple might connect to displays that
>> > support the proprietary AirPlay protocol.
>> >
>> > We know that parts of an Open Screen Protocol are in an early stage
>> > of development at https://github.com/webscreens/openscreenprotocol
>> > (as linked from the charter), and the goal of this work is to
>> > improve on this situation.  We hope it will allow for interoperable
>> > discovery of, identification of, and communication with presentation
>> > displays.
>> >
>> > However, we're deeply concerned about chartering a second iteration
>> > of the work that continues building the Presentation API on top of a
>> > closed ecosystem, when the work to make the ecosystem more open
>> > appears to have a lower priority.  While we understand that the work
>> > on building an open ecosystem still requires incubation, we believe
>> > it should have the highest priority in this space.
>> >
>> > We would ask that:
>> >
>> >  * the charter be clearer that modifications to the current CR-level
>> >specs that are needed to achieve interoperability are expected
>> >(rather than saying "This Working Group does not anticipate
>> >further changes to this specification."),
>> >
>> >  * the charter be clearer that building an open system that allows
>> >multiple browsers to interact with multiple displays is a
>> >requirement for the specifications advancing to Proposed
>> >Recommendation and to Recommendation, and
>> >
>> >  * work on a second level of the presentation API remain in
>> >incubation (and not yet be added to this charter) until after the
>> >work to build an open protocol moves from incubation into
>> >standardization,
>> >
>> > although we are open to other paths toward fixing this situation.
>> >
>> >
>> > On Friday 2018-01-05 09:36 -0700, Peter Saint-Andre wrote:
>> >> Agreed. Thanks for the careful wording, David! (BTW s/apple/Apple/)
>> >>
>> >> On 1/5/18 9:08 AM, Eric Rescorla wrote:
>> >> > LGTM!
>> >> >
>> >> > On Thu, Jan 4, 2018 at 9:56 PM, L. David Baron <dba...@dbaron.org>
>> wrote:
>> >> > >
>> >> > > So I think Martin, Peter, and I share similar concerns here, and
>> I'm
>> >> > > inclined to turn those concerns into an objection to this charter.
>> >> > >
>> >> > > So how does this sound for proposed comments on the charter
>> >> > > (submitted as a formal object

Re: Proposed W3C Charter: Second Screen Working Group

[Shih-Chiang Chien]

The SecondScreen WG intended to move the protocol development to CG, and
will possibly move to IETF after the incubation phase.
The revised charter is trying to associate the work of CG to the timeline
of Presentation API development.

At the meantime, WG will tackle the testability issue found while creating
test cases and cultivating Level 2 API requirements for advanced use cases.

I'll vote to support this revised charter.

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

On Thu, Jan 4, 2018 at 10:08 AM, L. David Baron <dba...@dbaron.org> wrote:

> The W3C is proposing a revised charter for:
>
>   Second Screen Working Group
>   https://w3c.github.io/secondscreen-charter/
>   https://lists.w3.org/Archives/Public/public-new-work/2017Dec/.html
>
> Mozilla has the opportunity to send comments or objections through
> Friday, January 52.  (Sorry for failing to send this out sooner!)
>
> A diff relative to the current charter is:
> https://services.w3.org/htmldiff?doc1=https%3A%2F%2Fwww.w3.org%2F2014%
> 2Fsecondscreen%2Fcharter-2016.html=https%3A%2F%2Fw3c.
> github.io%2Fsecondscreen-charter%2F
>
> The participants in the working group are:
> https://www.w3.org/2000/09/dbwg/details?group=74168=1=org
>
> Please reply to this thread if you think there's something we should
> say as part of this charter review, or if you think we should
> support or oppose it.
>
> One longstanding concern for me with this work is to what extent it
> defines an API that lets an Google-made browser talk to a Google
> screen, and an Apple-made browser talk to an Apple screen, versus to
> what extent it allows any browser to talk to any screen that
> supports a particular piece of technology.  I think there might
> have been some encouraging news on this front at TPAC in November,
> but I don't remember the details.  But if there was, I'd rather
> expect it to be incorporated into this charter, but I don't really
> see that after a first read.  I'm curious what others know and think
> about this issue.
>
> -David
>
> --
> 턞   L. David Baron http://dbaron.org/   턂
> 턢   Mozilla  https://www.mozilla.org/   턂
>  Before I built a wall I'd ask to know
>  What I was walling in or walling out,
>  And to whom I was like to give offense.
>- Robert Frost, Mending Wall (1914)
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Website memory leaks

[Shih-Chiang Chien]

about:performance can provide the tab/pid mapping, with some performance
indexes.
This might help solve your issue listed in the side note.

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

On Thu, Nov 2, 2017 at 3:34 PM, Randell Jesup <rjesup.n...@jesup.org> wrote:

> [Note: I'm a tab-hoarder - but that doesn't really cause this problem]
>
> tl;dr: we should look at something (roughly) like the existing "page is
> making your browser slow" dialog for website leaks.
>
>
> Over the last several months (and maybe the last year), I've noticed an
> increasing problem in websites: runaway leaks, leading to
> a poorly-performing browser or OOM crashes.  Yes, these have *always*
> occurred (people write bad code, shock!), but the incidence seems to
> have gotten much worse 'recently' (anecdotally).
>
> This may be the result of ads/ad networks (in some cases it provably
> is), in other cases it's the sites themselves (like the 4M copies of
> ":DIV" that facebook was creating over a day if you left a message
> visible, plus GB of related leaks (80K copies of many strings/objects).
> Many of the pages causing these leaks are major sites, like nytimes.com,
> washington post, cnn, arstechnica, Atlantic, New Yorker, etc.
>
> However, regardless of who's making the error or the details, I've been
> noticing that I'm having to "hunt for the bad tab" more and more
> frequently (usually via about:memory, which users wouldn't
> do/understand).  Multi-e10s helps a bit and some tabs won't degrade, but
> also enables my system to get into phyical-memory-pressure faster.  (The
> machine I notice this on is Win10, 12GB ram, quad-core AMD 8xxx (older,
> but 3.5GHz).  I'm running Nightly (32-bit) with one profile (for
> facebook), and beta (64bit) with another profile).
>
> While physical-memory pressure causes problems (including for the system
> as a whole), the leaking can make Content processes unresponsive, to the
> point where about:memory doesn't get data for them (or it's incomplete).
> This makes it hard-to-impossible to fix the problem; I kill Content
> processes by hand in that case - regular users would just force-close the
> browser (and perhaps start Chrome instead of restarting.)  We see an
> insanely high number of OOMs in the field; likely this is a major
> contributing factor.  Chrome will *tend* to have less tabs impacted by
> one leaking, though the leaking tab will still be ugly.
>
> Sometimes the leak manifests simply as a leak (like the washington post
> tab I just killed and got 3.5 of the 5GB in use by a content process
> back).  Others (depending I assume on what is leaked and how it's kept
> alive) cause a core (each) to be chewed doing continual GC/CC (or
> processing events in app JS touching some insanely-long internal
> structure), slowing the process (and system) to a crawl.
>
>
> *Generally* these are caused by leaving a page up for a while - navigate
> and leave, and you never notice it (part of why website developers don't
> fix these, or perhaps don't care (much)).  But even walking away from a
> machine with one or a couple of tabs, and coming back the next day can
> present you with an unusable tab/browser, or a "this tab has crashed"
> screen.
>
>
> Hoping site owners (or worse, ad producers) will fix their leaks is a
> losing game, though we should encourage it and offer tools where
> possible.  However, we need a broader solution (or at least tools) for
> dealing with this for users.
>
>
> I don't have a magic-bullet solution, and I'm sure there isn't one given
> JS and GC as a core of browsers.  I do think we need to talk about it
> (and perhaps not just Mozilla), and find some way to help users here.
>
>
> One half-baked idea is to provide a UI intervention similar to what we
> do on JS that runs too-long, and ask the user if they want to freeze the
> tab (or better yet in this case, reload it).  If we trigger before the
> side-effects get out of hand, freezing may be ok.  We should also
> identify the tab (in the message/popup, and visually in the tab bar - we
> don't do either today).  This solution has issues (though freezing tabs
> now that "slow down your browser" does too, but it's still useful
> overall).
>
> We can also look at tools to characterize site leaks or identify
> patterns that point to a leak before it gets out of hand.  Also tools
> that help website builders identify if their pages are leaking in the
> field (memory-use triggers? within-tab about:memory dumps available to
> the page?)
>
> Perhaps we can also push to limit memory use (CPU use??) in embedded
> ads/restricted-iframes/etc, so sites can stop ads from destroying the
> website performance for users ov

Intent to Unship: stream decoder for BinHex format

[Shih-Chiang Chien]

Currently on non-Mac platform, firefox will decompression the content while
loading resource with MIME type "application/mac-binhex40". This introduces
the confusion like bug 1390708 when Firefox trying to decode BinHex file.
On Mac platform we already disabled stream decoding of BinHex file.

I tested with Google Chrome 61, Internet Explorer 11, and Safari 11. All
these browsers treat BinHex file as binary file and trigger file download
directly.

I intent to remove all the code that handling BinHex decoding, i.e.
nsBinHex.cpp, from mozilla-central if no other project is using it. This
will happen on Firefox 58 if no objection on mailing list and in bug
1390708.

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: refcounting - which types to use ?

[Shih-Chiang Chien]

You should use |forget| to transfer the ownership of the nsIArray from list
to _retval.

/* nsIArray FindRecipients (in AString name); */
NS_IMETHODIMP nsAddrBookService::FindRecipients(const nsAString & addr,
nsIArray * *_retval)
{
nsresult rv = NS_OK;
nsCOMPtr list =
do_CreateInstance(NS_ARRAY_CONTRACTID, );
NS_ENSURE_SUCCESS(rv, rv);

if (NS_FAILED(rv = FillRecipients(addr, list)) {
  return rv;
}

list.forget(_retval);
return NS_OK;
}

On Wed, Aug 16, 2017 at 6:56 PM, Enrico Weigelt, metux IT consult <
enrico.weig...@gr13.net> wrote:

> Hi folks,
>
>
> I'm still a bit confused on which types (nsCOMPtr, ...) to use when
> exactly, in combination w/ IDLs.
>
> Let's consider a case where an nsArray is created and returned
> (as rval, not out-parameter):
>
> IDL:
>
> [scriptable, uuid(ea0d8b3d-a549-4666-82d8-3a82cee2a3f1)]
> interface nsIAddrBookService : nsISupports
> {
> nsIArray FindRecipients(in AString name);
> ...
> }
>
> C++:
>
> /* nsIArray FindRecipients (in AString name); */
> NS_IMETHODIMP nsAddrBookService::FindRecipients(const nsAString & addr,
> nsIArray * *_retval)
> {
> nsresult rv = NS_OK;
> nsCOMPtr list =
> do_CreateInstance(NS_ARRAY_CONTRACTID, );
> NS_ENSURE_SUCCESS(rv, rv);
> *_retval = list;
>
return FillRecipients(addr, list);
> }
>

> I'd assume that do_CreateInstance() returns the object w/ refcnt=1.
> The assignment to nsCOMPtr should increase refcount. Correct ?
> When the function is left, the nsCOMPtr is destroyed, and refcnt
> goes back to 1 (we now have a reference left in the caller's pointer
> field).
>
> Now the caller side: (inspired by various examples ...)
>
> nsCOMPtr list;
> rv = addrBookService->FindRecipients(
> splittedRecipients[j].mEmail,
> getter_AddRefs(list));
>
> I'd guess getter_AddRefs() causes refcnt to be increased again, so
> we're back at 2. That could lead to a leak, when that function returns
> (and doesn't pass the ref anywhere else).
>
> So, should I use dont_AddRef() here ?
>
> Is the situation different when using out parameter instead of rval ?


>
> BTW: what happens when passing nsCOMPtr as a reference (w/o IDL) ?
>
> Assume the following code:
>
> void caller() {
> nsCOMPtr ref;
>
> callee(ref);
> ref->Something();
> }
>
> void callee(nsCOMPtr & outref) {
> nsCOMPtr myref = do_CreateInstance(...);
> ...
> outref = myref;
> }
>
> I'd assume that the last line will fill the caller's ref field w/ the
> pointer and increase the object's refcnt (so it's 2 now), then when
> callee is left, its myref is destroyed and refcnt is back to 1.
>
> Is that correct ?
>
>
> --mtx
>
> ___
> 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: Start logging at runtime (Firefox 52)

[Shih-Chiang Chien]

Which platform you're using? For windows it seems to be solved by
https://bugzilla.mozilla.org/show_bug.cgi?id=1320458, however other
platforms are not fixed yet.


Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

On Tue, May 23, 2017 at 11:59 AM, Chris Pearce <cpea...@mozilla.com> wrote:

> On Sunday, November 27, 2016 at 5:59:27 AM UTC+13, Valentin Gosu wrote:
> > Hi everyone,
> >
> > (I meant to send this mail a few weeks ago but forgot it in my Drafts
> > folder.)
> >
> > With the landing of Bug 1303762 (Firefox 52), we now have a way for users
> > to enable logging without restarting the browser, and without having to
> > know what an environment variable is.
> >
> > We've added a new Logging section to about:networking. When a user
> > encounters a bug, all they have to do is open that page, click on "Start
> > Logging", reproduce the bug, then click on "Stop Logging" and upload the
> > logs. The buttons will be disabled if the MOZ_LOG_FILE or MOZ_LOG env
> > variables have been defined.
> > The log modules are automatically set to the most common networking
> > modules, but you may instruct the bug reporters to change them - just
> tell
> > them the string.
> >
> > This is very useful for bugs that are harder to reproduce once you
> restart
> > the browser.
> >
> > There are a bunch of improvements that we could make to the UI, so please
> > feel free to send me your feedback and patches. Many thanks to Honza
> > Bambas, Eric Rahm, Jared Wein, Patrick McManus and all others that helped
> > with the implementation and review of this bug and its dependencies.
> >
> > https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/
> HTTP_logging?document_saved=true#Using_aboutnetworking
>
> This seems super handy, but I tried it out and it seems to only affect the
> parent process, and not the sub-processes of Firefox?
>
> ___
> 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

Intent to ship: Presentation API on Fennec

[Shih-Chiang Chien]

Hi all,

In Bug 1318214 <https://bugzilla.mozilla.org/show_bug.cgi?id=1318214> I've
default enabled Presentation API on Fennec nightly, which allow web page to
use Google Chromecast/Nexus Player as a extended screen.

We implement 1-UA mode described in spec. Session resumption and many-to-1
session is not available in this mode.

The release plan of this API on Firefox desktop is still under discussion.

Google have release this API on both desktop and Android browser for 2-UAs
mode (see https://www.chromestatus.com/feature/6676265876586496), which
allows web page to communicate with Chromecast receiver apps. They are
implementing 1-UA mode as well, see
https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/HZ_ZHEE9oDo

For interoperability, W3C Second Screen CG have initiate the discussion of
defining open protocol for presentation control and video casting.

If you found any issue please file bugs and set dependency to Bug 1184036
<https://bugzilla.mozilla.org/show_bug.cgi?id=1184036>.

link to spec: https://www.w3.org/TR/presentation-api/

Platform coverage: Firefox for Android

Estimate of target release: Firefox 53

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: File() constructor with a string argument no longer works since Firefox 52a?

[Shih-Chiang Chien]

use File.createFromFileName(path)
see https://dxr.mozilla.org/mozilla-central/source/dom/webidl/File.webidl#48

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

On Wed, Nov 23, 2016 at 3:18 PM, 段垚 <duan...@ustc.edu> wrote:

> Thanks. So the chrome-only constructor was removed. Is there an
> alternative way to create a File object from a path?
>
>
>
> 在 2016/11/23 14:04, Kris Maglione 写道:
>
>> See https://bugzil.la/1303518
>>
>> On Wed, Nov 23, 2016 at 01:48:43PM +0800, 段垚 wrote:
>>
>>> Hi,
>>>
>>> In Firefox 51 chrome code, this code works: `new File(path_to_file)` ,
>>> if  `path_to_file` exists.
>>>
>>> However in Firefox 52a (2016-11-22)，an execption is thrown: "TypeError:
>>> Not enough arguments to File".
>>>
>>> I don't see a deprecation or removing note in the dev-doc[1], what's the
>>> problem?
>>>
>>> Thanks.
>>>
>>>
>>> [1] https://developer.mozilla.org/en-US/docs/Extensions/Using_th
>>> e_DOM_File_API_in_chrome_code
>>>
>> ___
>> 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: Dynamic Logging

[Shih-Chiang Chien]

Cool! Does it also work on content process?

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

On Fri, Jan 8, 2016 at 5:38 PM, Patrick McManus <mcma...@ducksong.com>
wrote:

> On Fri, Jan 8, 2016 at 8:32 PM, Eric Rahm <er...@mozilla.com> wrote:
>
> > Why is this so cool? Well now you don't need to restart your browser to
> > enable logging [1]. You also don't have to set env vars to enable logging
> > [2].
> >
>
>
> epic! thank you.
> ___
> dev-platform mailing list
> dev-platform@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Intent to implement: File system provider API

[Shih-Chiang Chien]

Hi Jonas,

Is there any document or bug for the new addon architecture? We'd like to
know more details and put it into our design.

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

On Mon, Jul 27, 2015 at 6:31 AM, Jonas Sicking jo...@sicking.cc wrote:

 On Sat, Jul 25, 2015 at 7:14 AM, Kershaw Chang kech...@mozilla.com
 wrote:
  Since the addon model on Firefox OS is not implemented now, I still use
 the
  old term apps in previous mail.
  I also think it makes much more sense to make this API to be only
 available
  for addons.

 Great!

  In addition, do we have a way to let an API only be used by addons now?

 We don't currently. But that should be available soon once the new
 addon architecture lands.

 / Jonas
 ___
 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: Updated mozilla-central code coverage

[Shih-Chiang Chien]

Thanks for the explanation. IIRC content process is closed by SIGKILL in
Gecko. Looks like we'll have to tweak the timing.

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

On Wed, May 27, 2015 at 10:10 AM, Joshua Cranmer  pidgeo...@gmail.com
wrote:

 On 5/26/2015 8:54 PM, Shih-Chiang Chien wrote:

 Hi Joshua,

 Great job for working on this! However I found that the coverage doesn't
 include those ran on child process (e.g. ContentChild). It would be
 wonderful if we can add the support on it.


 The coverage files are emitted by a process when it exits via an atexit
 hook. If anything causes that hook not to fire (e.g., the process is still
 running at the time the testsuite exits, or if the process is killed by a
 segfault or other signal), then no coverage data would be emitted.

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

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

Re: PSA: Network 'jank' - get your blocking IO off of STS thread!

[Shih-Chiang Chien]

dom/network/UDPSocket doesn't use SocketTransportService directly so it
doesn't create exception. It should be ok to leave it outside of Necko.

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

On Thu, Mar 26, 2015 at 11:37 PM, Randell Jesup rjesup.n...@jesup.org
wrote:

 Can we stop exposing the socket transport service's nsIEventTarget outside
 of Necko?

 If we move media/mtransport to necko... or make an exception for it (and
 dom/network/UDPSocket and TCPSocket, etc).  Things that remove loaded
 footguns (or at least lock them down) are good.

 Glad the major real problem was too-similar-names (I'd never heard of
 STREAMTRANSPORTSERVICE (or if I had, it had been long-forgotten, or
 mis-read as SOCKETTRANSPORTSERVICE)).

 --
 Randell Jesup, Mozilla Corp
 remove news for personal email
 ___
 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: New e10s tests on tinderbox

[Shih-Chiang Chien]

Hi Bill,

Many thanks for working on the M-e10s. Does it means we can remove all these 
“test_ipc.html” mochitests? AFAIK these test cases are manually emulating an 
e10s environment with some hacks.

Here is the list of test_ipc.html:
http://dxr.mozilla.org/mozilla-central/source/content/media/webspeech/synth/ipc/test/test_ipc.html
http://dxr.mozilla.org/mozilla-central/source/dom/devicestorage/ipc/test_ipc.html
http://dxr.mozilla.org/mozilla-central/source/dom/indexedDB/ipc/test_ipc.html
http://dxr.mozilla.org/mozilla-central/source/dom/media/tests/ipc/test_ipc.html

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

On Apr 9, 2014, at 5:28 AM, Bill McCloskey wmcclos...@mozilla.com wrote:

 Hi everyone,
 
 Starting today, we have new mochitests that show up as M-e10s (1 2 3 4 5). 
 These are mochitests-plain running inside an e10s content process. Aside from 
 being in a separate process, they work pretty much the same as normal. Some 
 tests have been disabled for e10s. If you add a new test and it doesn't work 
 in e10s mode, you can disable it with the following mochitest.ini gunk:
 
 [your_test.html]
 skip-if = e10s
 
 We have about 85% of mochitests-plain running right now. I'm hoping to make a 
 big push to get this number up to 100%, but there are still some prerequisite 
 bugs that I want to fix first. In the meantime, we can at least identify 
 regressions in the tests that run.
 
 Right now, these tests are running on inbound, central, try, fx-team, and 
 b2g-inbound. In a few days, they'll be running on all trunk trees. If you do 
 a try push, e10s tests will run iff mochitests-plain run. We don't have a 
 specific trychooser syntax for them yet.
 
 The tests are restricted to Linux and Linux64 opt builds right now. 
 Eventually we'll expand them to debug builds and maybe to other platforms. We 
 also want to get other test suites running in e10s. As testing ramps up, 
 we're going to have more and more test suites running e10s side-by-side with 
 non-e10s. The eventual goal is of course to disable non-e10s tests once we've 
 shipped an e10s browser. Until then, we'll have to balance resource usage 
 with test coverage.
 
 If you want to run in e10s mode locally, it's pretty simple:
 
 mach mochitest-plain --e10s
 
 As usual, you can pass in specific tests or directories as well as chunking 
 options. Debugging in e10s is a little harder. Passing the --debugger=gdb 
 option will only attach the debugger to the parent process. If you want to 
 debug the content process, set the environment variable 
 MOZ_DEBUG_CHILD_PROCESS=1. When the child starts up, it will go to sleep 
 after printing its PID:
 
 CHILDCHILDCHILDCHILD
  debug me @ pid
 
 At that point you can run gdb as follows:
 
 gdb $OBJDIR/dist/bin/plugin-container pid
 
 Then you can set breakpoints in the child and resume it with continue.
 
 Most of the work for this was done by Ted, Armen, Aki, and Mark Hammond. 
 Thanks guys!
 
 -Bill
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: B2G emulator issues

[Shih-Chiang Chien]

Why don’t we just switch to x86 emulator? x86 emulator runs way faster than the 
ARM emulator.

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

On Apr 8, 2014, at 8:49 AM, Ehsan Akhgari ehsan.akhg...@gmail.com wrote:

 On 2014-04-07, 8:03 PM, Robert O'Callahan wrote:
 When you say debug, you mean the emulator is running a FirefoxOS debug
 build, not that the emulator itself is built debug --- right?
 
 Given that, is it a correct summary to say that the problem is that the
 emulator is just too slow?
 
 Applying time dilation might make tests green but we'd be left with the
 problem of the tests still taking a long time to run.
 
 Maybe we should identify a subset of the tests that are more likely to
 suffer B2G-specific breaking and only run those?
 
 Do we disable all compiler optimizations for those debug builds?  Can we turn 
 them on, let's say, build with --enable-optimize and --enable-debug which 
 gives us a -O2 optimized debug build?
 
 ___
 dev-platform mailing list
 dev-platform@lists.mozilla.org
 https://lists.mozilla.org/listinfo/dev-platform



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform

Re: Toolkit sub-module Preferred Reviewers who are not Toolkit Peers

[Shih-Chiang Chien]

I added a component for captive portal detection about a year ago. Should I 
update https://wiki.mozilla.org/Toolkit/Submodules myself?

Best Regards,
Shih-Chiang Chien
Mozilla Taiwan

On Jan 20, 2014, at 8:17 AM, Tom Schuster t...@schuster.me wrote:

 I refactorted and debugged most of the findbar code. Mike seems to the de
 facto owner, so I think it makes sense for me to do reviews. I doubt
 anybody else knows much about the code. There seems to be no submodule for
 it anyway?
 On Jan 19, 2014 10:40 PM, Matthew N. ma...@mozilla.com wrote:
 
 Thanks for clarifying.
 
 Myself, Jared Wein, and Paolo Amadini (Download Manager Owner) seem to be
 missing from the Toolkit peer list then.
 
 Thanks,
 Matthew
 
 On 1/19/14, 8:47 PM, Dave Townsend wrote:
 
 Everyone who is a preferred reviewer should be a peer, if they aren't it's
 likely because I forgot to update the appropriate lists. Who do you see
 who
 is absent from the peer list?
 
 
 On Sat, Jan 18, 2014 at 11:51 AM, Matthew N. ma...@mozilla.com wrote:
 
 Hello,
 
 What does it mean to be a Preferred Reviewer (previously called a
 peer) in a Toolkit sub-module[1] and not be on the list of Toolkit
 Peers[2]? The Toolkit Code Review page[3] doesn't seem to cover this
 case.
 
 Specifically:
 1) Can a Preferred Reviewer review code in the related submodule
 without
 oversight from the sub-module owner?
 2) Is a sub-module Preferred Reviewer considered a Toolkit reviewer
 for the purposes of [3]?
 
 Thanks,
 MattN
 
 [1] https://wiki.mozilla.org/Toolkit/Submodules
 [2] https://wiki.mozilla.org/Modules/Toolkit
 [3] https://wiki.mozilla.org/Toolkit/Code_Review
 ___
 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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform