in function
nsContainerFrame::SyncWindowProperties(nsPresContext* aPresContext,
nsIFrame*aFrame,
nsView* aView,
nsRenderingContext* aRC)
Element* r
At the current time, pure html window doesn't support for
session and other things. Such
as setting the whole html's background to be transparent
with the operating system.
If we want to remove XUL completely from Mozilla source tree, what's left to do?
--
此致
礼
罗勇刚
Yours
sincerely,
On 6/2/15 6:28 PM, Boris Zbarsky wrote:
On 6/2/15 6:12 PM, Seth Fowler wrote:
If you write this:
auto val = Bar();
Foo(val);
I think to preserve the semantics of Foo(Bar()) you need:
auto& val = Bar();
Foo(val);
but apart from that nit, I totally agree.
This. Allow auto or lift the
On Friday, June 5, 2015 at 8:23:53 AM UTC-7, ISHIKAWA,chiaki wrote:
> After coping with voluminous messages in C-C TB |make mozmill| test
> suite log [much smaller volume than full FF logs],
> I think we should have NS_INFORMATION() macro that
> prints out an information for someone who is develop
Uncaught Promise rejections were made fatal and for the most part go
ignored when they fail intermittently. I'm not a huge fan of adding more
ways for tests to fail if people aren't willing to actually do something
about it when they do.
-Ryan
On 6/5/2015 6:08 AM, David Rajchenbach-Teller wro
If you want JS code to load into a context with something predefined,
you probably want to be using a sandbox and a subscript loader, not
JSM's.
For an example, check out this code that uses Thunderbird's fake-server
code that used to run in an xpcshell context but instead run it in a
sandbox (see
On 2015/06/04 21:38, Robert O'Callahan wrote:
Usually I use NS_WARNING to mean "something weird and unexpected is
happening, e.g. a bug in Web page code, but not necessarily a browser bug".
Sometimes I get useful hints from NS_WARNING spew leading up to a serious
failure, but for those usages cou
Hi Dan,
Thanks for the explanation. At this point, I really believe that Mozilla
needs to provide a link pointing to this explanation as well as a link to a
ticket with Oracle. The issue that makes makes me so frustrated (and I'm
guessing others like me who've read this thread) is the lack of
co
You need to look further up the stack. jemalloc_crash is not an
interesting stack frame.
- Kyle
On Fri, Jun 5, 2015 at 8:05 AM, Meenakshi Shankar
wrote:
> Hi,
>
> We are using Firefox SDKS for our FF extension (libs generated after
> compiling Firefox 39 beta 2 source using start-shell-msvc201
Hi,
We are using Firefox SDKS for our FF extension (libs generated after compiling
Firefox 39 beta 2 source using start-shell-msvc2013). With our extension
enabled in Firefox, we receive a "mozglue.dll!jemalloc_crash(...)" With
reference to "bugzilla 1168291" we used "mozcrt.lib for replacing
What exactly are you trying to do?
On 05/06/15 09:22, 罗勇刚(Yonggang Luo) wrote:
--
David Rajchenbach-Teller, PhD
Performance Team, Mozilla
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
>
> >> can we keep the
> >> snarkfest version running please until this is resolved?
>
> My main concern was because I inferred from the previous post that
> deprecation of snarkfest was scheduled on a timeline basis.
>
> Can we instead schedule on a when-its-ready basis, please?
>
yes- we ar
My patch introduces a new Warnings mechanism for JS. If this works
nicely, I'd like to extend this to C++.
Basically, whenever you encounter a situation that should never happen
in production but that is not quite fatal enough to warrant a crash, we
call (from the top of my head)
Warnings.warn("t
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
14 matches
Mail list logo
