Re: Intent to implement and ship: document.execCommand("cut"/"copy")

On Mon, May 25, 2015, at 11:04 AM, Ehsan Akhgari wrote: > On 2015-05-23 5:02 AM, Jesper Kristensen wrote: > > Very nice, I am looking very much forward to using this. > > > > It would be nice of you could also support paste. I agree that it is > > more sensitive, so maybe you could go with a user

FileIt has moved

FileIt (a tool for quickly finding the product/component for filing a bug) has been moved from Heather's github account to mine, since she no longer wishes to maintain it. It can now be found here: https://edmorley.github.io/fileit/ (Unfortunately Github doesn't set up HTTP redirects for a transf

Re: Intent to implement and ship: document.execCommand("cut"/"copy")

Den 26-05-2015 kl. 13:13 skrev Ted Mielczarek: Additionally, the 'paste' event from the spec already works, which seems like it provides pretty useful functionality for webapps. The user can use Ctrl+V or Edit->Paste or whatever existing UI mechanism the browser has to trigger a paste, and the pa

Re: Intent to implement and ship: document.execCommand("cut"/"copy")

On 2015-05-26 10:42 AM, Jesper Kristensen wrote: It would be much faster if I could just present a "Paste data" or "Upload from clipboard" button, which could load the data from the clipboard directly into a JavaScript string without first trying to render it. I feel that doing this by handling t

MemShrink Meeting - Today, 26 May 2015 at 4:00PM PDT

Today's MemShrink meeting is brought to you by memory.report_concurrency: https://bugzilla.mozilla.org/show_bug.cgi?id=1154053 The wiki page for this meeting is at: https://wiki.mozilla.org/Performance/MemShrink Agenda: * Prioritize unprioritized MemShrink bugs. * Discuss how we measure progre

Re: Intent to implement and ship: document.execCommand("cut"/"copy")

On 2015-05-26 10:42 AM, Jesper Kristensen wrote: Den 26-05-2015 kl. 13:13 skrev Ted Mielczarek: Additionally, the 'paste' event from the spec already works, which seems like it provides pretty useful functionality for webapps. The user can use Ctrl+V or Edit->Paste or whatever existing UI mechan

Updated mozilla-central code coverage

I've posted updated code coverage information for mozilla-central to . This data is accurate as of yesterday. For those of you who are unaware, I periodically run these code coverage statistics by use of the try server and instrumented runs. This has be

Re: Updated mozilla-central code coverage

Does this coverage info also include gtests? From a quick glance it looks like not. On Tuesday, May 26, 2015 at 2:59:16 PM UTC-4, Joshua Cranmer 🐧 wrote: > I've posted updated code coverage information for mozilla-central to > . This data is accurate as

Re: Updated mozilla-central code coverage

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

Re: Updated mozilla-central code coverage

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

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:

Re: Updated mozilla-central code coverage

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

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

Re: Updated mozilla-central code coverage

On 5/26/2015 10:20 PM, Shih-Chiang Chien wrote: Thanks for the explanation. IIRC content process is closed by SIGKILL in Gecko. Looks like we'll have to tweak the timing. A SIGKILL would definitely not trigger the information to be dumped. -- Joshua Cranmer Thunderbird and DXR developer Source

Re: Replacing PR_LOG levels

>Thanks Randell, these are good points. I'll address a few of your comments >that have not already been covered in the rest of the conversation. > >> This is used extensively in WebRTC and related media bits to enable >> *huge* amounts of debugs (like every-frame debugs for audio or video or >> per

Re: Replacing PR_LOG levels

>Thanks Adam, these are good points. > >On Friday, May 22, 2015 at 2:08:33 PM UTC-7, Adam Roach wrote: >> On 5/22/15 15:51, Eric Rahm wrote: >> > I agree, we shouldn't make it harder to turn on logging. The easy >> > solution is just to add a separate logger for verbose messages (if we >> > choose

Re: Replacing PR_LOG levels

>On Sat, May 23, 2015 at 4:46 AM, Randell Jesup wrote: >> This is used extensively in WebRTC and related media bits to enable >> *huge* amounts of debugs (like every-frame debugs for audio or video or >> per-network-packet debugs, which will swamp a system normally), and since >> people are used t