On Wednesday, February 17, 2016 at 10:35:10 AM UTC-8, Benoit Girard wrote:
> Currently APZ does not cause scrollbar initiated scrolling to be async.
> I've been working in fixing this and I'd like some help testing it out
> before enabling it on Nightly. If you're interested please flip
> 'apz.drag
What to call these has been a long thread in the document comments, but I'm
starting to lean towards:
FIX-FOR-RELEASE
FIX-SOON
and
BACKLOG
as well as adding (see the proposed edit) a FEATURE resolution for bugs
which are feature tracking and individual features. I'd consider adding a
consistency
On Thu, Mar 31, 2016 at 12:28 PM, Milan Sreckovic
wrote:
> Or, I could start arguing in the bug, that this should be higher priority,
> and fill up the comments with non-technical information.
This reminds me, we have filtering tools to mute abusive and unproductive
comments in bugs.
https:/
I've responded to a similar comment in the google doc, but I'll repeat it
here.
Priority sounds like a great choice, but given that everyone's using the
Priority field their own way, there's enough heterogeneity in how it's used
to make it difficult.
If I was to take that approach, I'm concerned
On 3/31/16 3:22 PM, Daniel Veditz wrote:
We get that now, with no marker at all. The only real difference I see
with a marker is that people will catch on sooner whereas now it takes a
while until they realize they are being ignored. They eventually get
discouraged or upset either way. Might ev
On Thu, Mar 31, 2016 at 12:28 PM, Milan Sreckovic
wrote:
> I’m going to start and keep arguing that we do not want to have an
> explicit name for that largest bucket of “wishlist” bugs, and should
> instead have it marked by the absence of a tag.
What distinguishes a bug that has not been tria
This message serves as a notice that the *SSH host keys* for
hg.mozilla.org will be rotated in the next ~24 hours.
When connecting to hg.mozilla.org over SSH, your SSH client should warn
that host keys have changed and refuse to connect until
accepting/trusting the new host key. After 1st host key
This may be somewhat long winded. I will make it in the context of Gecko
graphics, because that’s where I have the most data and experience. It may or
may not apply to other components.
Reviewing all the incoming bugs, in a timely matter, is very important to us.
Over the past few years, the
On 24/03/2016 00:08, Tobias B. Besemer wrote:
But what is this:
user_pref("extensions.checkCompatibility.37.0a", true);
user_pref("extensions.checkCompatibility.nightly", true);
Preferences relating to how/whether the add-on manager checks for
compatibility with a particular release. Not sure
On Thu, Mar 31, 2016 at 3:19 AM, Honza Bambas wrote:
> On 3/30/2016 20:21, Kyle Huey wrote:
>
>> In the department-of-paying-down-technical-debt, I'm planning to remove
>> much of the Chromium event loop over the next few months. You can follow
>> along in bug 1260828.
>>
>> The rough outline:
>>
On 3/31/16 8:08 AM, Gabriele Svelto wrote:
On this topic, did anyone experiment with trying to lighten the
synchronization burden when handling nsEventQueues?
This has come up in profiles recently too. For example
https://bugzilla.mozilla.org/show_bug.cgi?id=1254240#c6 shows us
acquiring and
Softvision also makes use of the feature keyword as one way to identify new
feature work to test in upcoming releases.
Lawrence
On Thu, Mar 31, 2016 at 10:49 AM, Milan Sreckovic
wrote:
> We do have a feature keyword today. While it may be most used for the
> documentation purposes, the feedbac
We do have a feature keyword today. While it may be most used for the
documentation purposes, the feedback graphics team got when we started using it
to tag feature requests was positive. As in, it’s OK to use for that.
—
- Milan
> On Mar 29, 2016, at 22:32 , Emma Humphries wrote:
>
> On
On 31-03-16 15:17, Jim Mathies wrote:
> On Wednesday, March 30, 2016 at 1:28:18 PM UTC-5, Kyle Huey wrote:
>> The other types (TYPE_UI, TYPE_IO, and
>> TYPE_MOZILLA_NONMAINUITHREAD) involve varying levels of platform
>> specific event loop or API integration that will probably be more
>> difficult
On Thu, Mar 31, 2016 at 6:43 AM, Nathan Froyd wrote:
> On Thu, Mar 31, 2016 at 8:08 AM, Gabriele Svelto
> wrote:
> > On this topic, did anyone experiment with trying to lighten the
> > synchronization burden when handling nsEventQueues? Both nsThread and
> > nsThreadPool acquire a mutex each tim
On Thu, Mar 31, 2016 at 8:08 AM, Gabriele Svelto wrote:
> On this topic, did anyone experiment with trying to lighten the
> synchronization burden when handling nsEventQueues? Both nsThread and
> nsThreadPool acquire a mutex each time we need to get the next runnable;
> we could pull out all pendi
On Wednesday, March 30, 2016 at 1:28:18 PM UTC-5, Kyle Huey wrote:
> The other types (TYPE_UI, TYPE_IO, and TYPE_MOZILLA_NONMAINUITHREAD)
> involve varying levels of platform specific event loop or API integration
> that will probably be more difficult to untangle. They also won't block my
> long-t
On 31/03/2016 07:42, Kyle Huey wrote:
> I'll pose to you the same question I posed bsmedberg, is this actually
> worth fiddling with all the existing runnables.
I did some testing around a couple of years ago and the answer is the
same as usual: it depends. On modern x86 machines I doubt one would
On 3/30/2016 20:21, Kyle Huey wrote:
In the department-of-paying-down-technical-debt, I'm planning to remove
much of the Chromium event loop over the next few months. You can follow
along in bug 1260828.
The rough outline:
Step 1: Replace Task with nsIRunnable, without changing any other
semant
19 matches
Mail list logo
