On Wed, Feb 12, 2014 at 7:14 PM, Ehsan Akhgari wrote:
> On 2/10/2014, 4:32 AM, Nicholas Nethercote wrote:
>>
>> Can we just allow hand-written fixes and move forward, please?
>
> Absolutely. I don't see any reason to enforce the usage of a tool as a
> criteria for accepting a patch.
In this spir
On 2/10/2014, 4:32 AM, Nicholas Nethercote wrote:
Can we just allow hand-written fixes and move forward, please?
Absolutely. I don't see any reason to enforce the usage of a tool as a
criteria for accepting a patch.
If somebody wants to contribute patches to clang-format to make it match
o
On 2/10/2014, 10:06 AM, David Rajchenbach-Teller wrote:
On 2/10/14 2:43 PM, Benjamin Smedberg wrote:
On 2/7/2014 10:31 AM, David Rajchenbach-Teller wrote:
Since main thread I/O keeps being added to the tree, for good or bad
reasons, I believe that we should adopt a convention of tagging
legitim
Hi,
In an effort to make build turnaround times better, we're working on
various things, on one which is the use of a shared compilation cache
instead of a per-slave ccache. The first milestone for this project is
reached, and this shared cache is now enabled for try builds for desktop
linux[0] bu
On 2/12/14 10:23 AM, Girish Sharma wrote:
I am wondering, is this why "google.co.in" also not emit an unload event on
the chrome vent event handler ?
Most likely, yes.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists
On Wed, Feb 12, 2014 at 8:22 PM, Boris Zbarsky wrote:
> On 2/12/14 9:44 AM, Gijs Kruitbosch wrote:
>
>> Dumb question: Could you listen for dom-window-destroyed
>>
>
> You could, but if the window gets bfcached that gets delayed somewhat
> indefinitely, no?
>
>
I am wondering, is this why "google
On 2/12/14 9:44 AM, Gijs Kruitbosch wrote:
Dumb question: Could you listen for dom-window-destroyed
You could, but if the window gets bfcached that gets delayed somewhat
indefinitely, no?
-Boris
___
dev-platform mailing list
dev-platform@lists.mozi
On Wed, Feb 12, 2014 at 8:14 PM, Gijs Kruitbosch
wrote:
> On 12/02/2014 14:30, Boris Zbarsky wrote:
>
>> On 2/12/14 8:44 AM, Girish Sharma wrote:
>>
>>> I want to track the creation and removal of docshells from a top level
>>> content docshell. Is it possible ?
>>>
>>
>> There are no built-in fac
On 12/02/2014 14:30, Boris Zbarsky wrote:
On 2/12/14 8:44 AM, Girish Sharma wrote:
I want to track the creation and removal of docshells from a top level
content docshell. Is it possible ?
There are no built-in facilities for this right now, as far as I can
tell. You could simply add somethin
On 2/12/14 8:44 AM, Girish Sharma wrote:
I want to track the creation and removal of docshells from a top level
content docshell. Is it possible ?
There are no built-in facilities for this right now, as far as I can
tell. You could simply add something
One option would be to watch windo
On 2/12/14 4:46 AM, Masayuki Nakano wrote:
I'm not sure which is the best name for the classes. E.g., DOMWheelEvent
vs. PointerEvent.
I believe in this case PointerEvent is correct, because
http://www.w3.org/TR/pointerevents/#pointerevent-interface but
DOMWheelEvent should probably be just Wh
Hi,
I want to track the creation and removal of docshells from a top level
content docshell. Is it possible ?
*TLDR;*
I am working on the backend of a Storage Inspector devtool to be able to
inspect storages like cookies, local storage etc. For this, I want to get a
list of all the inner windows
Hello.
A lot of classes under dom/events which were moved from content/events/*
are defined in global namespace.
However, now, a lot of classes in other modules are defined in mozilla
or its descendant namespace.
Therefore, *.h files in dom/events need to write type of arguments with
full
13 matches
Mail list logo
