On 7/23/2013 6:22 PM, Avi Halachmi wrote:
TL;DR: Talos tsvg,tscroll are affected by timing much more than by rendering
performance because they don't stress Firefox. tsvgx,tscrollx stress firefox:
their results are different, better, noisier than the old tests. Will soon
replace the old
The Rendering meeting is about all things Gfx, Image, Layout, and Media.
It takes place every second Monday, alternating between 2:30pm PDT and 5:30pm
PDT.
The next meeting will take place today, Monday, July 29 at 2:30 PM US/Pacific
The agenda is here:
We're moving the meeting 2 hours earlier!
8 AM in California
11 AM in Toronto and New York, etc.
16:00 in the UK and Portugal
17:00 in most parts of Europe
23:00 in Taipei
http://www.timeanddate.com/worldclock/fixedtime.html?msg=WebAPI+meetingiso=20130730T08p1=224am=30
Meeting
Our (ostensibly) weekly DOM bindings meetings continue on Monday July 29th
at 12:30 PM PDT.
Meeting details:
* Monday, July 29, 2013, 12:30 PM PDT (3:30 PM EDT/9:30 PM CEST)
* Conference room 7-N, San Francisco office, 7th floor.
* Dial-in Info:
- Vidyo room: Boris Zbarsky
- In office or soft
This will be going live tomorrow Tuesday 30th.
On 2013-07-23 4:38 PM, Armen Zambrano G. wrote:
I need these new changesets to spread across the FF25 trees before going
ahead with this:
https://hg.mozilla.org/integration/mozilla-inbound/rev/0d4ab37e3f3e
I don't particularly care for our model of a single Mercurial repository
per logical entity. I think it makes sense for things like twigs and to
some extent integration repositories - you can do your work in your own
little world without disrupting others. But for all the release
branches, I
On 7/29/2013 1:43 PM, Gregory Szorc wrote:
I don't particularly care for our model of a single Mercurial
repository per logical entity. I think it makes sense for things like
twigs and to some extent integration repositories - you can do your
work in your own little world without disrupting
Intent to implement seems premature. Why wouldn't we wait to see how
this goes and let Google do that. I really dislike the idea of rushing
into this API.
A programatic API that does something like AppCache is a good idea --
only in that it is better than the declarative shit AppCache is.
On 2013-07-29 2:46 PM, Doug Turner wrote:
Intent to implement seems premature. Why wouldn't we wait to see how
this goes and let Google do that. I really dislike the idea of rushing
into this API.
What is the reason you think we should not implement this? We're not
exactly rushing into
On 2013-07-29 2:06 PM, Benjamin Smedberg wrote:
Given all the things that we could be doing instead, why is this
important to do now?
I share Benjamin's concern.
Also, before we can discuss this, we need to make sure that every
Mercurial command handles bookmarks sanely. Last I checked,
On Mon, Jul 29, 2013 at 11:46 AM, Doug Turner doug.tur...@gmail.com wrote:
I would feel much better if we continued to monitor this api and not rush
here. Let Google do the rushing, lets implement later.
Didn't Jonas have a proposal for the 'offline' use case?
We did discuss at the last
On 7/29/13 12:49 PM, Ehsan Akhgari wrote:
On 2013-07-29 2:06 PM, Benjamin Smedberg wrote:
Given all the things that we could be doing instead, why is this
important to do now?
I share Benjamin's concern.
Legit concern. Probably low priority. I wanted to have a discussion on
it because I
Do you think that NC is the right soluction here?
Anne van Kesteren wrote:
Offline not working seems like the #1 problem
of the web platform,
There are lots of problems with the web platform. Offline support is
one of them, yes. :)
so working on this API does not really feel
premature
Implementation detail, but I presume that you will also replace the
existing appcache impl with NC, right?
Ehsan Akhgari wrote:
Offline not working seems like the #1 problem
of the web platform, so working on this API does not really feel
premature to me.
14 matches
Mail list logo
