On Fri, Nov 27, 2015 at 8:29 PM, Xidorn Quan wrote:
> Our tests relying on this is probably because certain bugs are only
> detectable when we apply content/style change after a layout flush.
>
That's right. This change is likely to hide more bugs than it causes.
Rob
--
lbir ye,ea yer.tnietoeh
On Fri, Nov 27, 2015 at 6:15 PM, Axel Hecht wrote:
> On 11/27/15 4:09 AM, Robert O'Callahan wrote:
>>
>> On Fri, Nov 27, 2015 at 3:59 PM, Boris Zbarsky wrote:
>>
>>> On 11/26/15 9:24 PM, Robert O'Callahan wrote:
>>>
We've always done it, but I can't think of any good reasons.
>>>
>>> I'
On 11/27/15 4:09 AM, Robert O'Callahan wrote:
On Fri, Nov 27, 2015 at 3:59 PM, Boris Zbarsky wrote:
On 11/26/15 9:24 PM, Robert O'Callahan wrote:
We've always done it, but I can't think of any good reasons.
I've tried to fix this in the past and ran into two problems.
The first problem w
On Fri, Nov 27, 2015 at 3:59 PM, Boris Zbarsky wrote:
> On 11/26/15 9:24 PM, Robert O'Callahan wrote:
>
>> We've always done it, but I can't think of any good reasons.
>>
>
> I've tried to fix this in the past and ran into two problems.
>
> The first problem was that some tests failed as a result
On 11/26/15 9:24 PM, Robert O'Callahan wrote:
We've always done it, but I can't think of any good reasons.
I've tried to fix this in the past and ran into two problems.
The first problem was that some tests failed as a result. This is
somewhat minor, really.
The second problem, pointed out
We've always done it, but I can't think of any good reasons. I seem to
recall that one reason was we want onload to be usable to measure
page-load-and-layout time, but that would be a bad reason.
If we didn't do that, we could run onload scripts earlier and maybe do less
layout if they update the
On 11/26/15 11:51 AM, David Rajchenbach-Teller wrote:
> For what it's worth, this thread was not meant to point fingers, but
> specifically to get an answer from said team. I see concern about
> Extension Signing, and I see points made by add-on developers and which
> appear valid to me and which I
On 27/11/2015 00:07, Thomas Zimmermann wrote:
> I haven't followed the overall discussion closely, but I'm very
> concerned about this change and that we're driving away extension
> developers. I hope that some of the relevant people read this thread, as
> I'd like to propose a different strategy
For what it's worth, this thread was not meant to point fingers, but
specifically to get an answer from said team. I see concern about
Extension Signing, and I see points made by add-on developers and which
appear valid to me and which I am unable to answer.
That doesn't mean that we have done som
On 11/26/2015 11:07 AM, Thomas Zimmermann wrote:
Hi,
I haven't followed the overall discussion closely, but I'm very
concerned about this change and that we're driving away extension
developers. I hope that some of the relevant people read this thread, as
I'd like to propose a different strategy
On 2015-11-26 11:07 AM, Thomas Zimmermann wrote:
I haven't followed the overall discussion closely, but
This is not OK.
Does anyone here actually think that the team that's been busting their
asses over this for months _doesn't_ have better information and more
insight into this problem than
On 26/11/2015 16:07, Thomas Zimmermann wrote:
Hi,
I haven't followed the overall discussion closely, but I'm very
concerned about this change and that we're driving away extension
developers. I hope that some of the relevant people read this thread, as
I'd like to propose a different strategy fo
Hi,
I haven't followed the overall discussion closely, but I'm very
concerned about this change and that we're driving away extension
developers. I hope that some of the relevant people read this thread, as
I'd like to propose a different strategy for extension signing.
1) As dburns mentioned in
Another data point that we seem to have overlooked is that users want to be
able to side load their extensions for many different reasons. We see this
with apps on phones and with extensions currently. I appreciate that users
have grown to be warning blind but, as others have pointed out, this feel
On Thu, Nov 26, 2015 at 8:50 AM, Thomas Zimmermann
wrote:
> For anything non-AMO, the user is on
> their own.
>
I don't know if that would fly. As I understand it, a large part of
the purpose of extension signing is to protect users from malicious
add-ons that get installed by non-AMO means - sid
Hi
Am 26.11.2015 um 13:56 schrieb Till Schneidereit:
> I read the blog post, too, and if that were the final, uncontested word on
> the matter, I think I would agree. As it is, this assessment strikes me as
> awfully harsh: many people have put a lot of thought and effort into this,
> so calling
From the earlier thread about aurora uplifts on firefox-dev (I'm
crossposting to m.d.platform, please follow-up on fx-dev because that's
where the original thread was.):
On 22/11/2015 15:41, L. David Baron wrote:
Is a significant part of the instability on aurora related to things
that land on
On Thu, Nov 26, 2015 at 10:02 AM, Thomas Zimmermann wrote:
> Am 25.11.2015 um 20:16 schrieb Jeff Gilbert:
> > On Wed, Nov 25, 2015 at 3:16 AM, Till Schneidereit
> > wrote:
> >> FWIW, I received questions about this via private email and phone calls
> >> from two people working on extensions that
Am 25.11.2015 um 20:16 schrieb Jeff Gilbert:
> On Wed, Nov 25, 2015 at 3:16 AM, Till Schneidereit
> wrote:
>> FWIW, I received questions about this via private email and phone calls
>> from two people working on extensions that support their products. Their
>> extensions sit in the review queue wi
Am Mittwoch, 25. November 2015 23:30:13 UTC+2 schrieb Matthew N.:
> Emma is correct that this is the solution for your problem and we are
> aware that it's important for the adoption of HTTPS. We already
> implemented the first half to support the upgrade of the form @action
> from HTTP to HTTPS
I am care about the mozilla's mork db components, I hope those
to read/write mork files on separate process and do not block the main UI.
On Thu, Nov 26, 2015 at 4:05 PM, Dave Townsend
wrote:
> XPCOM is available in the child process but whether the specific
> component you want works there or
XPCOM is available in the child process but whether the specific
component you want works there or not is a different question. Some
components have proxies in the child process to make them work, some
work just fine and some don't work at all. Which component do you care
about?
On Wed, Nov 25, 20
22 matches
Mail list logo