I think that Mozilla should comment in favor of the PEWG charter. Mozilla has
been participating in the WG and it is doing important work for interop and
performance of pointer input handling.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
tl;dr:
We plan to enable Pointer Events for mouse and pen input in Firefox Nightly
builds within the next few weeks.
Background:
Pointer Events is a W3C recommendation that defines new DOM events for unified
handling of mouse, touch, and pen input. It also defines a new 'touch-action'
CSS pr
On 12/10/2013 4:15 PM, Brian R. Bondy wrote:
Is this the default right now? If someone follows the steps and gets the
Mozilla Build package on that page[1], will their build fail or succeed?
[1]:
https://developer.mozilla.org/en-US/docs/Developer_Guide/Build_Instructions/Windows_Prerequisites
On 11/8/2013 1:33 AM, fma spew wrote:
3- We haven't found any indication of Mozilla about alternatives for these
kind of plug-ins, meaning plug-ins that need access to, in this case,
Windows stuff. Google has provided alternatives though.
One alternative is a Firefox extension. Firefox extensi
On 10/17/2013 10:24 AM, Ehsan Akhgari wrote:
We used to have codesighs measurements (and perhaps still do) but
historically many people just ignored them.
We stopped collecting codesighs measurements in November 2012 (bug
803736). As Ehsan says, it was widely ignored. It "regressed"
constan
On 10/16/2013 1:24 PM, Karl Tomlinson wrote:
Many people use browsers for reading text, so I would like to
claim that text rendering quality is usually more important than
performance.
I apologize for not looking through the referenced bugs.
To repeat a point from my previous message: These bu
On 10/15/2013 1:36 PM, al...@yahoo.com wrote:
Why are these ignored?
I can't speak for anyone else, but I would guess it's because no one who
has looked at them has figured out any useful information to add, or
found the time to investigate further.
As to whether we should pull someone off
On 2013-08-12 6:14 PM, Matt Brubeck wrote:
I've posted a patch that would change how the graph server sends email
when a performance *improvement* is detected:
https://bugzilla.mozilla.org/show_bug.cgi?id=904250
I landed this patch, and it will go live with the next graph server
deplo
On 8/13/2013 1:57 PM, Jet Villegas wrote:
This is awesome! Is it possible to see a log of the recipients/patches?
Yes - all of the emails for both regressions and improvements are also
sent to the dev-tree-management list, which is archived at
https://groups.google.com/forum/#!forum/mozilla.dev
I've posted a patch that would change how the graph server sends email
when a performance *improvement* is detected:
https://bugzilla.mozilla.org/show_bug.cgi?id=904250
Emails about regressions would be unchanged. Emails about improvements
would now be sent to individual patch authors using th
On 7/31/2013 4:06 AM, Brian Smith wrote:
On Wed, Jul 31, 2013 at 12:34 PM, Mike Hommey wrote:
I strongly oppose to any requirement that would make ESR+2 (ESR31) not
build on the current Debian stable (gcc 4.7) and make ESR+1 (ESR24) not
build on the old Debian stable (gcc 4.4). We're not going
On 7/17/2013 4:26 AM, Ted Mielczarek wrote:
The only valuable thing we're losing from shutting this off is
tracemalloc coverage, which we don't have elsewhere. I don't have any
evidence to show that anyone has actually looked at the tracemalloc data
or done anything useful with it in recent histo
On 5/31/2013 12:32 PM, Boris Zbarsky wrote:
On 5/31/13 3:20 PM, Matt Brubeck wrote:
blame mobile/android/chrome/content/browser.xul:
git 1.015s
hg 0.830s
Was this a git blame -C (which would be more similar to hg blame), or
just a git blame?
Good catch. (Sorry, I missed your messages
On 6/17/2013 9:48 PM, Drew Willcoxon wrote:
The desktop Firefox team is building a new Toolkit module that captures
thumbnails of off-screen web pages. Critically, we want to avoid capturing any
data in these thumbnails that could identify the user. More generally, we're
looking for a way to v
On 6/3/2013 7:28 AM, jmaher wrote:
We have a top orange factor failure which is a talos timeout that only happens on windows XP
and predominately on the dromaeo_css test. What happens is we appear to complete the test
just fine, but the poller we have on the process used to manage firefox neve
On 5/30/2013 5:56 PM, Johnny Stenback wrote:
Some of the known issues with embracing git are:
* Performance of git on windows is sub-optimal (we're
already working on it).
This has become a bit of an urban legend; I often see it repeated but
seldom with actual measurements. I don't t
On 5/2/2013 6:21 AM, Ehsan Akhgari wrote:
On 2013-05-02 5:46 AM, Neil wrote:
Why do we need a separate repo? Can we not simply close the broken head
and start again at the last green changeset?
Multiheaded repos are evil. They're very hard to deal with, and I don't
think that buildbot can dea
On 4/27/2013 3:26 PM, al...@yahoo.com wrote:
... appear to be possible without the \ escape. In fact the \ can not be
present as it does not escape the newline but becomes a part of the string.
So it does not seem to follow js rules, so what is this format?
The format doesn't have a name tha
On 4/26/2013 4:14 PM, Justin Lebar wrote:
If I have a patch ready to land when inbound closes, what would be the
sequence of steps that I need to do to land it on inbound2? Would I
need to have an up-to-date inbound2 clone and transplant the patch
across?
I think mbrubeck or someone knows how
On 4/26/2013 11:43 AM, Gregory Szorc wrote:
Have you explored using IndexedDB?
Not seriously. The "this is an experimental technology" warning on MDN
is off-putting.
The largest audience for MDN is web developers, so we put that warning
on anything that's not ready for widespread use on the
On 4/26/2013 9:10 AM, Armen Zambrano G. wrote:
Just disabling debug and talos jobs for 10.7 should reduce more than 50%
of the load on 10.7. That might be sufficient for now.
I'd be happy for us to disable all Talos jobs on 10.7, on all trees.
I've been keeping track of Talos stuff recently an
On 4/18/2013 12:10 PM, Matt Brubeck wrote:
Since we run PGO builds only a few times a day, the ranges can be large.
For those that include m-c merges, you could narrow them down using
the m-c data. WebIDL seems to be a common theme.
I filed https://bugzilla.mozilla.org/show_bug.cgi?id
On 4/17/2013 3:07 PM, Matt Brubeck wrote:
analyze_talos.py does identify several real regressions in that dataset
-- but it suppresses emails for them because each one is an increase of
less than 2% (see bug 822249). Here are regressions identified by the
latest version of analyze.py:
In case
On 4/13/2013 1:28 AM, Mike Hommey wrote:
The first thing to notice in here is the 13 spikes down. The last one is
bug 860371. I wasn't aware of any of the 12 others. It might be worth
looking into them to understand why they happen. Interestingly, my
dev-tree-management archive doesn't show any n
On 4/17/2013 10:50 AM, Gavin Sharp wrote:
I think Rob was talking about the case where you would call e.g.:
"mach build browser/base"
mach could know that on Mac, that also requires the equivalent of
"mach build browser/app" for those changes to actually be repackaged
into the bundle in objdir/
On 4/15/2013 11:04 AM, Rob Campbell wrote:
On Mac, does mach do the right thing when you rebuild browser, does it also
rebuild browser/app so your application bundle gets updated?
"mach build browser" is the same as "make -C $objdir/browser"
(literally, it just executes that "make" command to d
On 4/10/2013 5:14 PM, Gregory Szorc wrote:
I don't really have much to say on the specifics of this post other than
a simple question: why don't we have a checkin hook or bot automatically
update Bugzilla flags when changesets are pushed? This would save
developer time and would reduce the error
Support for "outline-color: invert" was removed in Firefox 3, and a bug
to restore support was RESOLVED WONTFIX several years ago because it was
deemed infeasible while using hardware acceleration [1].
Since then, some developers have asked for reconsideration on the bug;
since some of their q
I recently landed a new feature for the "mach" build tool [1]. You can
now run mach from anywhere in the mozilla source tree.
To get started, add mach to your $PATH. You can do this by changing the
PATH environment variable to include the mozilla source directory, or by
copying the "mach" sc
I noticed a number of places in Mozilla code where setTimeout-like
functionality is needed, but DOM window.setTimeout is not available
because the code runs in a non-DOM context like a JSM. In a few places
we had created pure-JS implementations of window.setTimeout to solve
this problem.
Wit
On 2/7/2013 6:12 AM, Mike Hommey wrote:
- But really, what does it change for developers?
Almost nothing they shouldn't be doing already. The main difference is
that resource://app/ and resource://gre/ urls are not going to point to
the same location anymore, which means I won't have to file bug
Here is my personal suggestion for how we should handle this in our
"Metro" browser, and the reasoning behind my proposal. This is meant to
be a minimal step to bring Firefox for Metro in line with other
platforms, without making changes to any other products. It might need
to be tweaked if w
On 08/29/2012 04:03 PM, Ehsan Akhgari wrote:
I don't believe that the current situation is acceptable, especially
with the recent focus on performance (through the Snappy project), and I
would like to ask people if they have any ideas on what we can do to fix
this. The fix might be turning off s
On 08/29/2012 04:32 PM, Nicholas Nethercote wrote:
In my experience, a lot of those emails say "there was a regression
caused by one of the following 100 patches", and I will have written 1
of those patches. I usually ignore those ones (though it depends on
the nature of the patch).
But if I ge
34 matches
Mail list logo
