Re: Proposed W3C Charter: Second Screen Working Group
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 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" 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 >> 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 >> 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 objection)? Note that I've tried to turn >> the >> >> > > comments
Re: Proposed W3C Charter: Second Screen Working Group
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 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&doc2=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&public=1&order=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: Intent to Unship: stream decoder for BinHex format
Lastest update: nsBinHexDecoder is going to be removed from both mozilla-central and comm-central. Patch for mozilla-central has been landed on Firefox 59 (see bug 1390708) and the work for comm-central will be tracked by Bug 1417187. Best Regards, Shih-Chiang Chien Mozilla Taiwan On Thu, Oct 26, 2017 at 3:45 AM, Eric Shepherd (Sheppy) < esheph...@mozilla.com> wrote: > Man… It’s weird that this makes me all nostalgic. :) > > > Eric Shepherd > Senior Technical Writer, MDN > MDN: https://developer.mozilla.org/ > Blog: https://www.bitstampede.com/ > > On October 18, 2017 at 8:50:20 AM, Joshua Cranmer 🐧 (pidgeo...@gmail.com) > wrote: > > FWIW, I've considered ripping out the binhex decoding from mailnews code > anyways. > ___ > 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: Website memory leaks
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 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,
Intent to Unship: stream decoder for BinHex format
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 ?
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, &rv);
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, &rv);
> 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)
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 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
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?
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, 段垚 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: Proposed W3C Charter: Second Screen Working Group
Support revised charter. The revised charter creates some flexibility for us to promote Flyweb as a new feature in Presentation API Level 2, which has been discussed in the F2F meeting of the WG this year. It also create a good structure to move non-WebAPI discussion to CG and keep WG focusing on the API development. [additional information on Mozilla's implementation plan] The current plan is to enable 1-UA implementation on Fennec on Nightly (release 52). No detailed engineering plan on Firefox desktop for now. We are cultivating some proposal to identify the usability of this API on desktop browser before dumping engineering resource on it. Best Regards, Shih-Chiang Chien Mozilla Taiwan On Sat, Oct 22, 2016 at 5:46 AM, Tantek Çelik wrote: > I have reviewed the charter and the current set of deliverables. The > work appears to be proceeding reasonably (pragmatically, with many > members/implementers including Apple and Google) and reasonably > minimally scoped. There is also the companion Second Screen Community > Group which appears to be used to incubate work before proceeding in > the working group, a pattern which we are generally supportive of. > > Support revised charter. > > I don't know of our current implementation plans on this WG's deliverables. > > The most recent discussion here of any of the deliverables of the WG > was on "PresentationAPI", in particular a "[PresentationAPI] Intend to > implement" thread here in 2014 September. > > Tantek > > > On Mon, Oct 17, 2016 at 12:28 PM, L. David Baron > wrote: > > The W3C is proposing a revised charter for: > > > > Second Screen Working Group > > https://lists.w3.org/Archives/Public/public-new-work/2016Sep/0011.html > > https://www.w3.org/2014/secondscreen/charter-2016.html > > > > Mozilla has the opportunity to send comments or objections through > > next Tuesday, October 25. > > > > 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. > > > > Mozilla does have participants in this group: > > https://www.w3.org/2000/09/dbwg/details?group=74168&public=1&order=org#_ > MozillaFoundation > > > > -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 > > > ___ > 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
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 wrote: > On Fri, Jan 8, 2016 at 8:32 PM, Eric Rahm 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
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 wrote: > On Sat, Jul 25, 2015 at 7:14 AM, Kershaw Chang > 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
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 🐧 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: Updated mozilla-central code coverage
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. Best Regards, Shih-Chiang Chien Mozilla Taiwan On Wed, May 27, 2015 at 6:28 AM, Mike Hommey wrote: > On Tue, May 26, 2015 at 03:48:06PM -0500, Joshua Cranmer ? wrote: > > On 5/26/2015 3:21 PM, kgu...@mozilla.com wrote: > > >Does this coverage info also include gtests? From a quick glance it > looks like not. > > > > The code coverage includes all tests run on Linux opt or Linux-64 opt > > excluding those run under check, marionette, web-platform tests, or > > luciddream. If gtests are being run under Linux opt cppunittests, then > they > > should be included. > > They are currently running during make check. > > 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: PSA: Network 'jank' - get your blocking IO off of STS thread!
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 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
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 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 @ > > At that point you can run gdb as follows: > > gdb $OBJDIR/dist/bin/plugin-container > > 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
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 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
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 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." 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. 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
Re: Poll: What do you need in MXR/DXR?
First of all, thanks you guys who working of DXR. It is my major tool for studying the Gecko code base and it helps a lot. I would like to have DXR lists all the implementation of a virtual function. This is quite handy when you are studying an interface which has more than one level of inheritance hierarchy. Best Regards, Shih-Chiang Chien Mozilla Taiwan On Oct 26, 2013, at 3:25 AM, Zack Weinberg wrote: > On 2013-10-25 11:10 AM, Ehsan Akhgari wrote: >> On 2013-10-25 10:45 AM, Erik Rose wrote: >>> ... would it be better, from your point of view, to >>> index the generated files or to magically turn up the IDL line >>> "attribute short foo" when you search for "function:GetFoo" or >>> "function:SetFoo"? (I'm not sure both are feasible; I just want to get >>> an early read.) >> >> The latter is better in my opinion! > > If I can have only one, I agree the latter is better -- but I want to mention > that sometimes I've needed to see what the I(P)DL compiler has produced from > a particular definition file in order to fix a bug. For instance, a few > years ago -- this may have been fixed since -- there were many gaps in the > documentation of what C++ types corresponded to IDL types and vice versa, so > one had to look at all three of the IDL, the generated .h, and the > hand-written .cpp that expected to implement an interface to understand what > was *really* going on. > > So, if you can make DXR do both, that would be better. (With a clear > indication that certain files are generated, and where the real source is, if > at all possible.) > > zw > ___ > 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
