There is a lost of falt in XUL, but still have something good, such as tree and
the XBL binding, besides, the window elements is also important, because we
need it to implement chromeless window, and titlebar, there is no equivalent in
HTML/JS, that's must be considerate when propose the
On Fri, Oct 17, 2014 at 1:32 AM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
On Thu, Oct 16, 2014 at 11:32 PM, Nicholas Nethercote
n.netherc...@gmail.com wrote:
I was wondering what people think is the worst piece of code in the
entire Mozilla codebase. I'll leave the exact meanings of
在 2014年10月17日星期五UTC+8下午2时39分54秒，Yonggang Luo写道：
There is a lost of falt in XUL, but still have something good, such as tree
and the XBL binding, besides, the window elements is also important, because
we need it to implement chromeless window, and titlebar, there is no
equivalent in
On 2014-10-16, 11:09 PM, Sean Lin wrote:
Platform coverage:
Initially on Firefox OS
FWIW we're trying to keep the implementation working with a dummy
backend on other platforms too, in the interest of keeping the API
testable on other platforms, but we are not planning to turn this API on
Since the html pages are already cached, why not also cache the JIT
compiled javascript while leaving a page? Shouldn't use too much space
than the text content of the embedding page. Much less space than the
image files embedded in a page.
___
This question returns every so often.
If I recall correctly:
- the JIT-compiled code is much, much, much larger than the JS source
code, and just reading it from the cache may actually slow down
execution of the page;
- in many pages, JIT-compiled code actually depends on the interactions
between
I have a short summary of why caching JIT code is not necessarily a clear win
for most JS in a blog post:
http://blog.mozilla.org/luke/2014/01/14/asm-js-aot-compilation-and-startup-performance/#caching
We do machine code for asm.js, though (as also described in the post).
More interesting
David,
Le 14 oct. 2014 à 07:29, L. David Baron dba...@dbaron.org a écrit :
Here is my current draft of the comments I plan to submit in about 12
hours (cc:ing the whole AC, I think). Sorry for not getting this out
for people to have a look at sooner.
Good summary of our discussions. Thanks.
Thank you Bobby and Josh for all your work to improve ImageLib!
I’m pushing hard on making it better still (with a lot of help from folks like
Timothy Nikkel and Michael Wu). Hopefully next time we try to decide what the
worst piece of Mozilla code is, ImageLib won’t be a candidate. =)
- Seth
On 16/10/2014 13:56, Robert O'Callahan wrote:
On Fri, Oct 17, 2014 at 9:45 AM, Gijs Kruitbosch gijskruitbo...@gmail.com
wrote:
There are also interesting height computation issues that I'm pretty sure
HTML (flexbox) doesn't have, e.g. bug 451997. I'm not sure that's a
function of the box
On 09/25/2014 10:29 AM, Ehsan Akhgari wrote:
I don't see this temporary difference as particularly problematic,
particularly given that pixelated is primarily an upscaling feature,
and given that we'll match them before too long. But if others
disagree, I'm open to holding off on shipping
Hi,
I posted the following message to mozilla.dev.builds newsgroup, but
I wonder if there is a mozilla-wide change to nsITreeView lately?
I noticed this while testing a patch to C-C TB locally.
(Considering that COMM-CENTRAL may have a slight delay in getting
M-C changes, it may be that
On Fri, Oct 17, 2014 at 4:19 PM, ISHIKAWA,chiaki ishik...@yk.rim.or.jp wrote:
Hi,
I posted the following message to mozilla.dev.builds newsgroup, but
I wonder if there is a mozilla-wide change to nsITreeView lately?
I noticed this while testing a patch to C-C TB locally.
(Considering that
Nicholas Nethercote wrote:
I was wondering what people think is the worst piece of code in the entire Mozilla codebase. I'll
leave the exact meanings of worst and piece of code unspecified...
When you get time, find someone to tell you about Morse code. (No, I
don't mean Samuel.)
--
Ehsan Akhgari wrote:
Speaking about code that causes correctness bugs that actually affect
our end users, the best example that I know is editor/.
Not just correctness, but the unique way it use pointers to nsCOMPtr all
over...
--
Warning: May contain traces of nuts.
Mike Hoye wrote:
I mean, if you find somebody in their office today curled up in a
ball, rocking back and forth and muttering mork, mork, mork over and
over again, that person's having a bad flashback. Call for help, stay
with them. Tell them we've got sqlite now and it's going to be OK.
Syd Polk wrote:
Does MSVC 2013 run on Windows XP? We still support Win XP for the browser; do
we support building on it?
You can't create a stock build on XP since the latest SDK is 7.1 and the
gamepad code needs 8.0 and the DirectX code would like it too.
--
Warning: May contain traces
Robert O'Callahan wrote:
I assume no-one's finding the Firefox libxul.dll and loading it from their own
.EXE
I assume people are finding the XULRunner libxul.dll and loading it from
their own .EXE
--
Warning: May contain traces of nuts.
___
18 matches
Mail list logo
