On 2017/02/14 8:37, gsquel...@mozilla.com wrote:
On Tuesday, February 14, 2017 at 3:25:05 AM UTC+11, Ehsan Akhgari wrote:
On 2017-02-11 3:27 AM, ISHIKAWA,chiaki wrote:
On 2017/02/11 7:07, Botond Ballo wrote:
On Fri, Feb 10, 2017 at 3:45 PM, Milan Sreckovic
wrote:
First step needs to happen c
On Tuesday, February 14, 2017 at 3:25:05 AM UTC+11, Ehsan Akhgari wrote:
> On 2017-02-11 3:27 AM, ISHIKAWA,chiaki wrote:
> > On 2017/02/11 7:07, Botond Ballo wrote:
> >> On Fri, Feb 10, 2017 at 3:45 PM, Milan Sreckovic
> >> wrote:
> >>> First step needs to happen completely before the second step
On 2017-02-11 3:27 AM, ISHIKAWA,chiaki wrote:
> On 2017/02/11 7:07, Botond Ballo wrote:
>> On Fri, Feb 10, 2017 at 3:45 PM, Milan Sreckovic
>> wrote:
>>> First step needs to happen completely before the second step does, so I
>>> guess the danger is that we start and give up before we get to step
On 2017/02/11 7:07, Botond Ballo wrote:
On Fri, Feb 10, 2017 at 3:45 PM, Milan Sreckovic wrote:
First step needs to happen completely before the second step does, so I
guess the danger is that we start and give up before we get to step 2. I
don't think that will happen, but it is something we
On Fri, Feb 10, 2017 at 3:45 PM, Milan Sreckovic wrote:
> First step needs to happen completely before the second step does, so I
> guess the danger is that we start and give up before we get to step 2. I
> don't think that will happen, but it is something we should always think
> about.
It may
Reducing overflow risk and simplifying intersection both seem worth
it, but godspeed whoever works on this!
On Fri, Feb 10, 2017 at 12:45 PM, Milan Sreckovic
wrote:
> First step needs to happen completely before the second step does, so I
> guess the danger is that we start and give up before we
First step needs to happen completely before the second step does, so I
guess the danger is that we start and give up before we get to step 2.
I don't think that will happen, but it is something we should always
think about.
Third step - sure, I can see this not getting completed - examining
My concern is that this will get partially done but never completed, and
we'll end up in a situation where we have two styles in place. We have a
bad track record with that sort of thing.
Nick
On Thu, Feb 9, 2017 at 1:45 PM, Jeff Muizelaar wrote:
> It's not very easy to reason about overflow i
It's not very easy to reason about overflow issues with our current
representation. This means that we currently just pretend that they
don't happen. The idea for changing the representation came up in
response to a security bug where we didn't really have a better
solution.
Changing to x1, x2, y1
On 02/09/2017 03:26 AM, Botond Ballo wrote:
As far as I can tell, ISize and BSize are methods on
mozilla::LogicalRect, which does not derive from BaseRect, and as such
would not be affected.
Here's LogicalRect::ISize():
https://dxr.mozilla.org/mozilla-central/rev/5e17f9181c6cb0968966280d1c1d96e
>> - Replace direct accesses to the 'width' and 'height' fields
>> throughout the codebase with calls to getter and setter methods. (There
>> aren't that many - on the order of a few dozen, last I checked.)
>
> I think you must have made a mistake, width/height and *Size things
> are used in a gazi
Is there a specific problem that's being solved by this proposal? It would
be helpful to make this a bit more concrete, like "these benchmarks go x%
faster", or "here's a list of overflow bugs that will just vanish", or
"here's some upcoming work that this would facilitate".
On Thu, Feb 9, 2017 at
On 02/09/2017 01:56 AM, Botond Ballo wrote:
- Replace direct accesses to the 'width' and 'height' fields
throughout the codebase with calls to getter and setter methods. (There
aren't that many - on the order of a few dozen, last I checked.)
I think you must have made a mistake, width/height an
13 matches
Mail list logo
