Guess we should plan a mozillabuild release.
- Kyle
On Wed, Feb 20, 2013 at 12:34 AM, Jonathan Watt wrote:
> Earlier today I noticed that hg annotate was messed up on m-c for
> nsSVGFilters.cpp. Turns out this was due to a bug that has been fixed in
> Mercurial 2.5. Please update to version 2.5
On 19/02/13 23:52, Robert O'Callahan wrote:
> I think my idea for an anti-flood state makes this unnecessary.
There are two distinct use cases:
1. You only care where the mouse currently is.
2. You need to know both where the mouse is and how it got there.
We really have to choices:
A. Provide an
Earlier today I noticed that hg annotate was messed up on m-c for
nsSVGFilters.cpp. Turns out this was due to a bug that has been fixed in
Mercurial 2.5. Please update to version 2.5.1 to help us avoid this problem in
future.
Details for those that are interested:
http://bz.selenic.com/show_b
Today's MemShrink meeting will be brought to you by recently-purged non-visible
images:
https://bugzilla.mozilla.org/show_bug.cgi?id=784591
The wiki page for this meeting is at:
https://wiki.mozilla.org/Performance/MemShrink
Agenda:
* Discuss 2013 Memshrink Objectives
* Prioritize unprioriti
On Tue, Feb 19, 2013 at 7:24 PM, Jonas Sicking wrote:
> But I would expect that in the majority of other cases, each mousemove
> event will not leave persisted data and dispatching more mouse moves
> will simply mean that the page will redo the same calculations over
> and over only. The result i
On Tue, Feb 19, 2013 at 8:42 PM, Justin Dolske wrote:
> On 2/18/13 10:24 PM, Jonas Sicking wrote:
>
> One possible solution is to allow pages to opt in to high-precision
>> mousemove events. Then a drawing program could do that on the
>> mousedown event end opt out again on mouseup.
>>
>
> Hmm,
6 matches
Mail list logo