I'm sure this is a dumb question, but why not modify the actual
implementation of innerHTML in the core DOM if you're doing a modified
try-run anyway?
~ Gijs
On 18/06/2015 13:37, Frederik Braun wrote:
Hi,
I am planning to do a little analysis of FxOS Gaia to identify instances
of innerHTML
The W3C is proposing a revised charter for:
WebRTC Working Group
http://www.w3.org/2015/06/webrtc-charter.html
https://lists.w3.org/Archives/Public/public-new-work/2015Jun/0009.html
Mozilla has the opportunity to send comments or objections through
Sunday, July 19.
Please reply to this
Hi,
I am planning to do a little analysis of FxOS Gaia to identify instances
of innerHTML assignments at runtime[1]. I am hoping this gives me a more
precise number about hot paths (in contrast to just looking at the
source code).
In an ideal world I would write a script along the lines of
On 18.06.2015 14:56, Gijs Kruitbosch wrote:
I'm sure this is a dumb question, but why not modify the actual
implementation of innerHTML in the core DOM if you're doing a modified
try-run anyway?
This is actually a very good question.
Unfortunately, I'm not that great at C/C++ and was hoping
Next week I plan to enable the Cache API by default. It has been developed
behind the dom.caches.enabled pref. This pref has been enabled by default
on nightly and aurora since FF39. Next week I plan to remove the pref
completely so the feature will ride the trains to release.
The Cache API is
On 18.06.2015 15:51, smaug wrote:
On 06/18/2015 03:37 PM, Frederik Braun wrote:
Hi,
I am planning to do a little analysis of FxOS Gaia to identify instances
of innerHTML assignments at runtime[1]. I am hoping this gives me a more
precise number about hot paths (in contrast to just looking at
On 06/18/2015 03:37 PM, Frederik Braun wrote:
Hi,
I am planning to do a little analysis of FxOS Gaia to identify instances
of innerHTML assignments at runtime[1]. I am hoping this gives me a more
precise number about hot paths (in contrast to just looking at the
source code).
What kind of
On Wednesday, June 17, 2015 at 9:57:12 PM UTC-4, Gregory Szorc wrote:
First thing is first: what are the blockers to mass rewriting
mozilla-central with clang-format's output?
For the record I'm in favour of auto-clang-formatting the codebase, but the
last time I tried running clang-format on
You can add a listener for DOMWindowCreated on the iframe, or
content-document-global-created from the XPCOM preferences service in order
to get notifications when globals are being created.
On Thu, Jun 18, 2015 at 7:07 AM, Frederik Braun fbr...@mozilla.com wrote:
On 18.06.2015 15:51, smaug
The
graphene-41.0a1.en-US.win64.zip
Doesn't package with icu dlls
--
此致
礼
罗勇刚
Yours
sincerely,
Yonggang Luo
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On Thursday, June 18, 2015 at 7:28:44 AM UTC-7, kgu...@mozilla.com wrote:
1) Comments that exceed the 80-char limit get wrapped blindly, rather than
being rewrapped properly. This results in comment blocks that look like this:
// This is a comment that was previously just over the eighty
//
On Wednesday, June 17, 2015 at 10:29:24 PM UTC+5:30, Adrian Kalla wrote:
W dniu 06/17/2015 o 06:33 PM, Abhay Kumar Somani pisze:
Hi, I am working in a company and we are using XULRunner to deploy our app.
Now we have decided to upgrade our app to 64bit. While upgrading we got to
know that
This landed as the mach try command. For more details run |./mach help try|
(excerpted below) and see the discussion in bug 1149670. The highlights
here are partly automated try syntax generation for testing changes
relevant to tests in certain directories, and pushing try syntax to the try
server
On Thu, Jun 18, 2015 at 8:36 PM, Eric Rahm er...@mozilla.com wrote:
2) MOZ_BEGIN_NESTED_ENUM_CLASS seems to trip up the formatter and it
misformats the code after that.
AFAICT there's no such thing as MOZ_BEGIN_NESTED_ENUM_CLASS
It was removed in bug 290.
Cheers,
Botond
Dear friends with large codebases—
You are heartily invited to a DXR 2.0 pony show and design session next Friday
in Whistler, where we'll demonstrate the new abilities of this near-rewrite,
answer questions, and figure out what goes next on the roadmap.
For those not familiar with it, DXR is
It sounds like there are three use cases for WEBGL_debug_renderer_info:
1. Correlating GPU info with bug reports (e.g. YouTube).
2. Web content workarounds for GPU bugs.
3. Fingerprinting for user tracking.
To get #1, some of #2, and none of #3, can we just whitelist
WEBGL_debug_renderer_info
The Treeherder devs will be on-hand for a hacking session in Whistler
Thursday next week. If you've curious to get your hands into the
Treeherder code, or have a workflow you'd like to improve, please stop
by. This session will be two-track: One for the Treeherder UI, the
other aimed at data
On 18/06/2015 12:15, ISHIKAWA,chiaki wrote:
Unfortunately, it does not handle the particular coding style of
#if,#else,#endif in JavaScript source files since
use of C-style macro preprocessor is not quite standard.
Nobody seems to have written a emacs mode for this C-style macro use in
On 18-06-15 11:31, smaug wrote:
One common auto usage I've seen is for storing the result of a
static_cast. In this scenario, it lets you avoid repeating yourself
and makes for more concise code.
It still hurts readability.
Whenever a variable is declared using auto as type, it forces
On 06/02/2015 11:56 PM, Daniel Holbert wrote:
On 06/02/2015 12:58 PM, smaug wrote:
So, I'd like to understand why people think 'auto' is a good thing to use.
(bz mentioned it having some use inside bindings' codegenerator, and
sure, I can see that being rather
valid case.)
One common auto
On 06/02/2015 11:56 PM, Daniel Holbert wrote:
On 06/02/2015 12:58 PM, smaug wrote:
So, I'd like to understand why people think 'auto' is a good thing to use.
(bz mentioned it having some use inside bindings' codegenerator, and
sure, I can see that being rather
valid case.)
One common auto
21 matches
Mail list logo
