On Tuesday, March 4, 2014 1:26:15 AM UTC-8, somb...@gmail.com wrote:
> While we have a defense-in-depth strategy (CSP and iframe sandbox should
>
> be protecting us from the worst possible scenarios) and we're hopeful
>
> that Service Workers will eventually let us provide
>
> nsIContentPolic
On 2/28/14, 5:24 PM, Hal Wine wrote:
tl;dr: what is the balance point between pushes to try taking too long
and loosing repository history of recent try pushes?
Summary:
As most developers have experienced, pushing to try can sometimes take a
long time. Once it takes "too long" (as mea
The actual translation needs to happen at once, but that's ok if I can work
in the chunks incrementally, and only when everything is ready I send it
off to the translation service. What I need to find then is a good (and
fast) partitioning algorithm that will give me a list of several blocks to
tr
On Tuesday 2014-02-25 09:43 -0500, david bolter wrote:
> I support this W3C Recommendation.
Yep.
While I wasn't entirely happy with some of the history that led to
the current state, I agree we should support it.
(In particular, in the early days of ARIA I was told, in private
conversations, tha
On Mon, Mar 3, 2014 at 11:48 PM, Henri Sivonen wrote:
>
> Are static atoms and the HTML parser's pre-interned element name and
> attribute name objects that are on the heap shared between processes
> under Nuwa already? I.e. is the heap cloned with copy-on-write
> sharing? On the memory page granu
On 3/3/14, 12:54 PM, Jan Honza Odvarko wrote:
> URLs in stack traces for exception objects have been recently changed. There
> is a column number appended at the end (I am seeing this in Nightly, but it
> could be also in Aurora).
Code that parses error.stack now needs to handle the case where b
On Thu, Jan 23, 2014 at 4:29 PM, Ehsan Akhgari wrote:
> On 1/22/2014, 3:12 AM, Henri Sivonen wrote:
>>
>> On Tue, Jan 21, 2014 at 11:07 PM, Ehsan Akhgari
>> wrote:
>>>
>>> On 1/21/2014, 4:27 AM, Henri Sivonen wrote:
>>
>> ..
In general, though, it seems to me that having partners patch
On Wed, Mar 5, 2014 at 8:47 AM, Felipe G wrote:
> If I go with the clone route (to work on the snapshot'ed version of the
> data), how can I later associate the cloned nodes to the original nodes
> from the document? One way that I thought is to set a a userdata on the
> DOM nodes and then use t
On Tue, Mar 04, 2014 at 09:48:33AM +0200, Henri Sivonen wrote:
> On Fri, Feb 28, 2014 at 8:09 PM, L. David Baron wrote:
> > In other words, whenever you have a pointer in a static data
> > structure pointing to some other data, that pointer needs to get
> > fixed up when the library loads, which m
Thanks for the feedback so far!
If I go with the clone route (to work on the snapshot'ed version of the
data), how can I later associate the cloned nodes to the original nodes
from the document? One way that I thought is to set a a userdata on the
DOM nodes and then use the clone handler callback
Chrome imports a JS
On 03/04/2014 03:13 AM, Henri Sivonen wrote:
It saddens me that we are using non-compliant ad hoc parsers when we
already have two spec-compliant (at least at some point in time) ones.
Interesting! I assume you are referring to:
https://github.com/davidflanagan/html5/blob/master/html5parser.j
On Mon, Mar 3, 2014 at 10:19 PM, Boris Zbarsky wrote:
> How feasible is just doing .innerHTML to do that, then doing some sort of
> async parse (e.g. XHR or DOMParser) to get a DOM snapshot?
Seems more efficient to write the walk in C++, since the innerHTML
getter already includes the walk in C++
13 matches
Mail list logo
