On Thu, Jul 25, 2013 at 5:28 PM, Gregory Szorc wrote:
> It appears this proposal was generally well received and I guess that
> means it's time to officially enact it.
>
Thanks for starting this conversation and driving it through, Gregory!
> I've written up the review policy at [1] and filed
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: https://wiki.mozilla.org/Platform/GFX/2013
Thanks for asking about this; we have a lot of unnecessary unlinking
code in our JS,
Let me share how I investigated your question.
$ git grep -i addmessagelistener -- '*.cpp'
content/base/src/nsFrameMessageManager.cpp:nsFrameMessageManager::AddMessageListener(const
nsAString& aMessage,
Only one
We're planning to implement a prototype of the NavigationController
interface (see bug 898524). We will try to get feedback from web
developers on the prototype and will use that feedback to change the spec
and the implementation and iterate on the API. Our major goal for now is
coming up with a
+1 that is awesome! I can see some "interesting" use cases for us in gaia
where this would be helpful.
On Fri, Jul 26, 2013 at 10:29 AM, Ehsan Akhgari wrote:
> We're planning to implement a prototype of the NavigationController
> interface (see bug 898524). We will try to get feedback from web
Since I announced this on Monday, I've implemented:
* pushlog integration. Run |hg changesetpushes REV| to view when
changesets landed on all the different trees. It even reports the
version numbers of the beta and release versions when a changeset was
first active.
* Bug tracking. Run |hg b
On 7/26/13 9:30 AM, Ehsan Akhgari wrote:
I've written up the review policy at [1] and filed bug 898089 [2] to
enforce/communicate this policy via Mercurial hooks.
While I supported the review policy change here, I'm fairly strongly
opposed to the idea of the commit hook enforcing it. I've com
On 27/07/2013 2:53 AM, Justin Lebar wrote:
...
>
Whether or not we totally succeed in this endeavor is another question
entirely. You could instrument your build to count the number of live
nsFrameMessageManager objects and report the number of message
listeners in each -- one way to do this wou
> Just to be clear though, if I find they are *not* all being removed, I
> should open a bug on that rather than just removing the listeners myself and
> calling it done? ie, is it accurate to say that it *should* not be
> necessary to remove these handlers (and, if I verify that is true, that I
>
9 matches
Mail list logo
