Why do we flush layout in nsDocumentViewer::LoadComplete?

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

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

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

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

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

Re: In the new e10s multiprocess model, is that possible to calling XPCOM in the client process?

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,

Re: In the new e10s multiprocess model, is that possible to calling XPCOM in the client process?

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

Re: Using browser stored credentials for http://mywebsi.de also on https://mywebsi.de

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

Re: Dan Stillman's concerns about Extension Signing

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 >>

Re: Dan Stillman's concerns about Extension Signing

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

Improving quality on Nightly and Aurora

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

Re: Dan Stillman's concerns about Extension Signing

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

Re: Dan Stillman's concerns about Extension Signing

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

Re: Dan Stillman's concerns about Extension Signing

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

Re: Dan Stillman's concerns about Extension Signing

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

Re: Dan Stillman's concerns about Extension Signing

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

Re: Dan Stillman's concerns about Extension Signing

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

Re: Dan Stillman's concerns about Extension Signing

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

Re: Dan Stillman's concerns about Extension Signing

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

Re: Dan Stillman's concerns about Extension Signing

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

Re: Dan Stillman's concerns about Extension Signing

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

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

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

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

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.

Re: Why do we flush layout in nsDocumentViewer::LoadComplete?

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 --