Hi all,
For web-platform-test, it seems some people still update manifest.json
manually, instead of running "--manifest-update" mach command. Running
"--manifest-update" assures the manifest to be in lexicographic order;
however, manually updating manifest may sometimes accidentally add test
info
+1 for streamlining Telemetry deployment
I think we'd still want to:
1. broadcast when experiments are shipping, with a specific start/end/goal,
and what data is collected
2. define scope: Nightly/Aurora/Beta (with a higher approval bar for each,)
+ Desktop/Mobile/Other
3. track bugs that distingu
On 2016/04/20 5:14, Nils Ohlmeier wrote:
On Apr 18, 2016, at 09:56, Milan Sreckovic wrote:
What’s the “XP tax”? Graphics usually tries to simplify the playing field as
much as possible, but I can’t say that XP has been causing any trouble, or that
we have been getting too many XP specific
On Tuesday, April 19, 2016 at 1:20:56 PM UTC-7, Ted Mielczarek wrote:
> On Tue, Apr 19, 2016, at 04:14 PM, Nils Ohlmeier wrote:
> > The good news is that dxr does not find anything using IsXPSP3OrLater().
> > But this looks like we have a bit of version specific code in our tree:
> > https://dxr.mo
Wow, these features look great! Is it possible to release a new version of mach
on PyPi? I use mach for a couple projects and it'd be great if I could just pip
install it instead of vendoring it everywhere. Thanks!
On Tuesday, April 12, 2016 at 9:09:14 PM UTC-4, Andrew Halberstadt wrote:
> Hey a
On Tuesday, 19 April 2016 22:03:48 UTC+9, smaug wrote:
> > This is a temporary situation because I don't want to have to back out the
> > whole Element.animate feature due to compat issues from the 'Animation'
> > interface name. After we have shipped Element.animate we can ship the
> > Animatio
(Cross-posted to dev-platform and release-management)
Hi all,
Not too long ago I ran a telemetry experiment [1] to figure out how to
tune some of our code to get the best in-the-wild behaviour. While I
got the data I wanted, I found the process of getting the experiment
going to be very heavyweig
On Tue, Apr 19, 2016 at 1:20 PM, Ted Mielczarek wrote:
> On Tue, Apr 19, 2016, at 04:14 PM, Nils Ohlmeier wrote:
> > The good news is that dxr does not find anything using IsXPSP3OrLater().
> > But this looks like we have a bit of version specific code in our tree:
> >
> https://dxr.mozilla.org/m
On Tue, Apr 19, 2016, at 04:14 PM, Nils Ohlmeier wrote:
> The good news is that dxr does not find anything using IsXPSP3OrLater().
> But this looks like we have a bit of version specific code in our tree:
> https://dxr.mozilla.org/mozilla-central/search?q=XP_WIN&redirect=false&case=true
FYI, the "
> On Apr 18, 2016, at 09:56, Milan Sreckovic wrote:
>
> What’s the “XP tax”? Graphics usually tries to simplify the playing field as
> much as possible, but I can’t say that XP has been causing any trouble, or
> that we have been getting too many XP specific problems (certainly fewer than
>
On 4/19/16 2:44 PM, Tantek Çelik wrote:
The key question to consider about delaying |summary::marker| support
is whether or not we (e.g. you) think the spec for ::marker is
"stable" and "good" enough to ship.
The key question before that one is whether we want to block shipping
details and sum
On Tue, Apr 19, 2016 at 12:00 PM, Boris Zbarsky wrote:
> On 4/19/16 2:44 PM, Tantek Çelik wrote:
>>
>> The key question to consider about delaying |summary::marker| support
>> is whether or not we (e.g. you) think the spec for ::marker is
>> "stable" and "good" enough to ship.
>
>
> The key questi
On 4/19/16 1:43 PM, Mike Taylor wrote:
Given that 48 moves to Dev Edition in ~1 week, is there any reason to
not wait for the 49 cycle to let it bake a full Nightly cycle (and
potentially let us find compat bustage)?
That doesn't seem unreasonable to me.
-Boris
On Tue, Apr 19, 2016 at 8:41 AM, Ting-Yu Lin wrote:
> To summarize the feedback so far, I'd still like to ship and
> without |summary::marker| because
>
> 1) No other browsers support summary::marker yet.
This is a reason to ship *with* it IMO, per showing standards
leadership, something Firefo
On 4/19/16 9:13 AM, Boris Zbarsky wrote:
On 4/19/16 3:53 AM, Florin Mezei wrote:
Sounds like this may cause WebCompatibility issues?
How worried are we about this?
Mildly but not desperately.
Given that 48 moves to Dev Edition in ~1 week, is there any reason to
not wait for the 49 cycle to
On 4/19/16 1:58 AM, Panos Astithas wrote:
Why should we be the ones to take the web compat hit on this?
>
> is the fundamentally biggest issue.
>
I realize I'm late to this thread and the discussion has moved the original
proposal towards something more refined and hence more likely to succeed,
Summary:
Add an API on Window for requesting a callback when the user agent is
idle.
With requestIdleCallback web developers will be able to schedule
background computation tasks on the event loop that has a better
chance of not interfering with other more time-critical operations.
Bug: https://b
Release engineering is working on this decision, stay tuned.
—
- Milan
> On Apr 19, 2016, at 12:02 , Nicolas Silva wrote:
>
> Re-re-ping.
> Being able to use a more recent standard library would simplify a lot of
> things on our end. For example updating 3rd party libraries such as
> skia, whi
Re-re-ping.
Being able to use a more recent standard library would simplify a lot of
things on our end. For example updating 3rd party libraries such as
skia, which depends on a modern stl, is a pain, and there are plenty of
other examples.
Cheers,
Nical
On Mon, Apr 4, 2016, at 07:33 PM, a...@im
To summarize the feedback so far, I'd still like to ship and
without |summary::marker| because
1) No other browsers support summary::marker yet.
2) From the webcompat point of view, even if we support summary::marker,
our usage to customize the triangle will still be different from the
|summary:
On Tue, Apr 19, 2016 at 10:15 PM, Boris Zbarsky wrote:
> On 4/19/16 1:09 AM, Ting-Yu Lin wrote:
>
>> Yes. supports the same set of "list-style-type" property values
>> as because our default style for is "display: list-item".
>>
>
> OK. And the "counter" involved has the value 0, right?
Yes
On 04/19/2016 04:03 PM, smaug wrote:
On 04/19/2016 03:29 AM, bbirt...@mozilla.com wrote:
On Tuesday, 19 April 2016 02:23:54 UTC+9, smaug wrote:
On 04/18/2016 05:12 AM, Brian Birtles wrote:
In Firefox 48 I intend to turn Element.animate on by default.
We have been developing the Web Animation
On 4/19/16 1:09 AM, Ting-Yu Lin wrote:
Yes. supports the same set of "list-style-type" property values
as because our default style for is "display: list-item".
OK. And the "counter" involved has the value 0, right?
-Boris
___
dev-platform maili
On 4/19/16 10:17 AM, Aryeh Gregor wrote:
Couldn't we add telemetry probes to alert when they hit circumstances
that would cause a problem?
I have no idea until we come up with a possible list of such
circumstances...
But the most obvious failure mode is a library that does something like:
On Tue, Apr 19, 2016 at 5:13 PM, Boris Zbarsky wrote:
> We could try to mitigate through searching web content for the relevant
> method names, but I believe that was already done when writing the spec. I
> could be wrong, of course
>
> Past that, I'm not sure how to design a test plan that w
On 4/19/16 3:53 AM, Florin Mezei wrote:
Sounds like this may cause WebCompatibility issues?
In theory, yes. We've tried to mitigate to some extent by making these
[Unscopable], which should prevent issues from bareword usage in event
handler attributes, at least.
But if some library define
On 19/04/2016 14:41, Jip de Beer wrote:
I followed your steps exactly and uses this code to add a canvas on a page with
jQuery:
var myCanvas = document.createElement('canvas');
var width = $(document).width()
myCanvas.width = width;
var height = $(document).height()
myC
I followed your steps exactly and uses this code to add a canvas on a page with
jQuery:
var myCanvas = document.createElement('canvas');
var width = $(document).width()
myCanvas.width = width;
var height = $(document).height()
myCanvas.height = height;
var ctx = myCanvas.g
Hi,
for quite some time I'm not really working with Qt anymore. So from my
very own perspective I have to say I cannot care about it anymore
realistically. So if other people are caring and want to become peers it
would even be better for everyone to remove myself from the module.
Wolfgang
Am 18
Hi Botond thanks for replying,
I just checked and calling drawWindow() doesn't output the entire page in the
display-list dumps. It's as if this operation doesn't trigger the same things a
regular render operation does.
But your reply got me thinking. If I can force Firefox to always render the
On 04/19/2016 03:29 AM, bbirt...@mozilla.com wrote:
On Tuesday, 19 April 2016 02:23:54 UTC+9, smaug wrote:
On 04/18/2016 05:12 AM, Brian Birtles wrote:
In Firefox 48 I intend to turn Element.animate on by default.
We have been developing the Web Animations API behind the
dom.animations-api.c
Hi everyone,
Here's the list of new issues found and filed by the Desktop Release QA
team last week, *April 11th - April 15th* (week 15).
Additional details on the team's priorities last week, as well as the
plans for the current week are available at:
https://public.etherpad-mozilla.org
On Mon, Apr 18, 2016 at 9:02 PM, Chris Peterson wrote:
> OTOH, if an XP users doesn't mind running an unpatched OS, then they
> probably won't care/know about running an unpatched Chrome browser.
Gmail nags you if you use an outdated Chrome version. I know someone
who asked me to take a look at
On Fri, Apr 15, 2016 at 5:47 PM, Tantek Çelik
wrote:
> However, As EKR pointed out, Kyle Huey's
>
> > Why should we be the ones to take the web compat hit on this?
>
> is the fundamentally biggest issue.
>
I realize I'm late to this thread and the discussion has moved the original
proposal towar
Hi
Am 18.04.2016 um 20:02 schrieb Chris Peterson:
> On 4/18/16 6:46 AM, Thomas Zimmermann wrote:
>> Am 18.04.2016 um 15:18 schrieb Kyle Huey:
>>> > 12% of our users are on Windows XP.
>> And XP still runs on ~10% of all desktops. That's an opportunity to
>> convert some of the users to Firefox.
>
Sounds like this may cause WebCompatibility issues? How worried are we about
this? Can we mitigate this through testing?
Regards,
Florin.
-Original Message-
From: dev-platform
[mailto:dev-platform-bounces+florin.mezei=softvisioninc...@lists.mozilla.org
] On Behalf Of smaug
Sent: Monday, A
On Tue, Apr 19, 2016 at 11:02 AM, Karl Dubost wrote:
>
> Le 14 avr. 2016 à 18:24, Ting-Yu Lin a écrit :
> > On Thu, Apr 14, 2016 at 5:03 PM, Xidorn Quan
> wrote:
> >> Shouldn't "summary { list-style-type: none; }" be enough?
> > Yes. With Bug 1258657 <
> https://bugzilla.mozilla.org/show_bug.cg
37 matches
Mail list logo
