On 8/2/12 1:44 AM, Andreas Gal wrote:
Reporting of the results and integration is very lacking, and until those
pieces fall into place (e.g. try integration), the developer experience is
going to suck a lot if we enforce the rule below (backout).
That's the concern, yes.
Basically, if we're
On 8/16/12 12:07 PM, Ehsan Akhgari wrote:
I agree with Benjamin here. In fact, I think if we take out item 4
completely Aryeh's proposal still makes sense. Where the tests live in
our tree should not really matter.
It matters insofar as it makes it more complicated to export our tests
to
Right now, attribute getters always get prefixed with Get in the
WebIDL bindings. So readonly attribute long foo becomes int32_t
GetFoo() in the C++.
Would it make sense to drop the Get in certain cases? In particular, in
cases in which:
1) The getter is infallible.
2) The return value
On 8/30/12 4:16 AM, Ms2ger wrote:
It certainly looks nicer, but I'm not a big fan of complicating the
rules for assembling the C++ signature from the WebIDL. XPIDL's
consistency here, IMO, saves time when implementing an interface: you
can focus on the actual implementation, rather than the
On 8/30/12 8:26 AM, Jonas Sicking wrote:
What would
readonly attribute long? bin;
compile into? If it compiles into something called GetBin then we'd
have a nice consistency that any getters for nullable types are named
GetX and any getters for non-nullable types are named X.
I was going
On 9/25/12 7:54 AM, Paul Rouget wrote:
let win = gBrowser.contentWindow;
let gIOService =
Components.classes[@mozilla.org/network/io-service;1].getService(Components.interfaces.nsIIOService);
let windowUtils =
On 10/5/12 8:55 PM, Jonas Sicking wrote:
With WebIDL you don't even need to use XPCOM interfaces to expose something to
javascript!
Indeed. As of a few days ago, you don't even need to inherit from
nsISupports. ;)
-Boris
___
dev-platform
On 10/9/12 6:46 PM, Jonas Sicking wrote:
On Tue, Oct 9, 2012 at 2:43 AM, Aryeh Gregor a...@aryeh.name wrote:
If it's a pain to write a particular file in testharness.js, it can be
kept as mochitest. In my experience, quite a lot of tests boil down
to like ten lines, which would take about
On 10/10/12 12:23 AM, Ian Bicking wrote:
Here's how I think you'd write a simple XHR test in both:
// SimpleTest aka MochiTest
req = new XMLHttpRequest();
req.open(GET, /example.json);
How did example.json get there?
What if you need to test CORS?
With mochitest at this point you're doing
On 10/11/12 3:05 AM, Tim Taubert wrote:
Also, I'm not sure how this affects Telemetry results. In terms of perf
measurements we'd probably need to completely ignore everything from
non-release builds as the results might differ heavily for some use
cases.
I'm not following.
The suggestion, as
On 10/15/12 10:28 AM, alexander.alis...@gmail.com wrote:
Any properly licensed TrueType/OpenType/Open Font Format file can
be packaged in WOFF format for Web use.
anybody else see problems here.
No, explain?
i think Mozilla's Jonathan Kew, needs to stick this where it does not
shine
On 10/25/12 11:51 AM, Rob Campbell wrote:
You won't have browser-chrome living next to xpcshell in the same location
(pretty sure, please correct me if I'm wrong).
http://mxr.mozilla.org/mozilla-central/source/docshell/test/
It's got xpcshell tests, xpcshell-ipc tests, browser tests,
On 11/9/12 8:11 PM, Benoit Jacob wrote:
The only issue I see is using namespace at file scope in a _header
file_. I would support a coding style rule against that.
https://developer.mozilla.org/en-US/docs/Developer_Guide/Coding_Style#Namespaces
says:
No using statements are allowed in
On 11/9/12 8:03 PM, Zack Weinberg wrote:
I challenge your presuppositions. The average file should need no more
than one or two `using SYMBOL;` lines per header it includes.
That depends on the structure of the code, no?
For example, until we finish moving over all of the DOM to live inside
On 11/9/12 12:52 AM, James Graham wrote:
I know Mozilla use a system where all the tests in a file should pass,
but I don't see how that will work well when you don't control the
tests. If you are manually editing every file when you import it, I
imagine that updating tests will be so time
On 11/21/12 9:50 AM, Honza Bambas wrote:
The question is: where is a good place where nsGlobalWindow already
knows its associated principal to trigger the preload?
Outer window, or inner window?
Also, do you need to know the exact principal, or just not system?
-Boris
On 11/22/12 3:48 AM, Jan Honza Odvarko wrote:
I can create a simple extension, but it'll require having patch from
bug 800799 applied.
That's fine. I'm pretty good at applying patches. ;)
Should I create a new bug report for this?
Please!
-Boris
On 12/11/12 7:18 AM, Henri Sivonen wrote:
On Wed, Dec 5, 2012 at 5:37 AM, John Daggett
moz.li...@windingwisteria.com wrote:
Fonts are loaded when used so font loading won't start until the
contents using a particular font are laid out.
That seems like a problem for JS-driven display.
It's
On 12/14/12 1:48 AM, Justin Lebar wrote:
FWIW, I once tried changing all of our atomic string refcounting to
non-atomic operations and could not eke out a performance (or
stability) difference on x64. This was despite the fact that I was
able to generate profiles where the atomic string
On 12/20/12 12:14 PM, Jeff Walden wrote:
Setting it creates a shadowing property on window itself, using the exact
value passed in.
// Current Gecko
alert(typeof window.screenX); // number
window.screenX = 123;
alert(typeof window.screenX); // string, not number
Er... no. If
On 12/20/12 12:14 PM, Jeff Walden wrote:
WebKit gives the old behavior, but only for some of the listed properties -- it
doesn't for status or name.
OK. Given that, I think we should just go ahead and make these
non-replaceable. Given WebKit doesn't make status and name
replaceable, the
We have a bunch of chrome and extension code that does things like
instanceof HTMLAnchorElement (and likewise with other DOM interfaces).
The problem is that per WebIDL spec and general ECMAScript sanity this
shouldn't work: instanceof goes up the proto chain looking for the thing
on the
On 12/27/12 1:54 PM, Neil wrote:
More importantly it suggests 311 for the similar instanceof
Components.interfaces.nsIDOMHTMLAnchorElement (or equivalent) often
used in components and modules of course.
Yeah. We'd obviously need to do something about that...
Presumably there's no easy way
On 12/27/12 2:49 PM, Justin Dolske wrote:
Hmm. My first reaction is to gently challenge if this really has to
change
Well, it really has to change as exposed to web content (or we have to
convince every single other browser to change behavior and get the
ECMAScript spec changed and so
On 12/28/12 4:12 AM, Neil wrote:
In the interim I believe foo.constructor.name == Array was popular,
but I see that doesn't work for (e.g.) new Image().
This should work (modulo bugs in exactly the cases where we've hacked
the instanceof behavior) for WebIDL bindings, actually. We could also
On 12/28/12 2:00 PM, Neil wrote:
But if you're keeping nsIDOMNode, then you might as well keep the most
popular interface that derives from it.
Probably true, unless we decide we don't care _that_ much about editor
perf and move it to a tearoff
-Boris
On 12/29/12 11:19 AM, smaug wrote:
And doesn't work for data documents which don't have defaultView
Hrm... Yes.
You mean something like Node.is(element, HTMLAnchorElement); ?
Or HTMLAnchorElement.isHTMLAnchorElement(element) or
HTMLAnchorElement.is(element) or something
-Boris
On 12/30/12 10:34 PM, Andreas Gal wrote:
In this sea of terrible choices, how about making HTMLAnchorElement an actual function,
but having it return object for typeof?
Apart from being an ES violation (which we're in the business of anyway,
at the moment), what does that actually buy us?
On 12/30/12 11:14 PM, Bobby Holley wrote:
1) How do we want this to work going forward for chrome touching content?
|obj instanceof Node| should return true.
2) How do we want this to work going forward for web pages touching other
web pages?
|obj instanceof Node| should return false
On 12/31/12 4:26 PM, Bobby Holley wrote:
Well, if we're talking about JS-implemented WebAPIs, then that stuff should
be running as chrome, potentially in the content process (unless I'm
mistaken - I'm still a bit behind on all the b2g architecture). If we're
talking about web apps, then they're
On 12/31/12 8:25 PM, Boris Zbarsky wrote:
They were, as roc points out, apathetic. Or rather, there was some talk
about it being a good idea but no concrete proposals and nothing
actually happening.
That said, I posted one more time on public-script-coord (and bcced
es-discuss) just to see
On 1/20/13 4:01 PM, Joshua Cranmer wrote:
If it were
possible to have strings cross-compartments that don't require
flattening and excessive copying, that would make the lives of add-on
authors in a CPG world much easier.
Please make sure bugs are filed?
-Boris
On 1/20/13 2:37 PM, Gregory Szorc wrote:
* Have all or most of chrome-privileged JS share the same compartment
(like on B2G). It's my understanding the CPG decision was largely driven
by content/security requirements and chrome just got caught up in it.
What's not clear to me is whether this
On 1/23/13 3:39 PM, edgar.am...@gmail.com wrote:
also, the the angularJS app is in my localhost port 81, the php file is in my
localhost, different port.
Then they're not same-origin and can't call back and forth directly.
I suggest using postMessage to send the data across.
-Boris
On 1/31/13 10:33 AM, Till Schneidereit wrote:
Do we think the planned optimizations cause the gains through PGO to
be less pronounced?
It... depends. There are a few things at play here.
First of all, our current profiling at least for DOM and layout stuff is
largely looking for the wallet
On 2/1/13 10:50 AM, Nathan Froyd wrote:
Do you have examples that you can point to?
This certainly used to be the case for Mozilla code at one point, but it
may be worth remeasuring. Lots of gcc (and MSVC, and Mozilla code)
changes since then.
-Boris
On 2/1/13 10:52 AM, Jean-Marc Desperrier wrote:
The trouble with going 64-bits is that the jit would then see some
significant regression, for cache pressure/instruction set related
reasons
Do you have numbers here?
I'm aware of some regressions for things that involve traversing DOM
trees
On 2/22/13 7:25 PM, bernhardr...@gmail.com wrote:
const unsigned long LOAD_NOCOOKIES = 1 15;
... just stop sending / accepting cookies at this request
115 is LOAD_FRESH_CONNECTION, no?
const unsigned long LOAD_NOAUTH = 1 16;
... don't add authentification headers automatically
116 is
On 2/24/13 12:44 PM, matt...@salsitasoft.com wrote:
Unfortunately I'm relying on DOMWindowCreated to inject my symbols into the
window, and this is no longer fired in FF19 with the type set to chrome.
Uh code inspection and basic testing over here suggest it fires just
fine, for what
On 2/25/13 12:36 PM, matt...@salsitasoft.com wrote:
As discussed in https://groups.google.com/d/topic/mozilla.dev.platform/E4MG_hTv6Zw/discussion,
I am not getting the DOMWindowCreated message when I use a browser element with type
set to chrome
Depending on what you're doing, you could just
On 2/25/13 1:46 PM, matt...@salsitasoft.com wrote:
I tried adding properties to the window before the load (under the hypothesis
that the inner window is being reused), but they don't seem to be there after
the load.
Then the inner window is not being reused.
You can set your channel's
On 2/28/13 9:37 PM, bernhardr...@gmail.com wrote:
i have run hg pull and hg update on mozilla central and still have no
LOAD_DOCUMENT_URI.
Are you looking in the right file?
The problem seems to be that this patch breaks the WHOLE Cookie handling of
firefox.
Because your LOAD_NO_COOKIES
On 3/3/13 10:12 PM, Zack Weinberg wrote:
If an event is dispatched from C++ using
nsContentUtils::DispatchTrustedEvent with both the 'bubbles' and
'cancelable' flags set false, what precisely is the difference between
targeting it at a document's window and targeting it at the document's
On 3/4/13 6:26 AM, gNeandr wrote:
Any idea how to fix that problem, any workaround .. catching the
response NOT to throw it to the console?
If you control the server, make sure the Content-Type it returns is not
an XML type (like the fruux.com server does).
If you control the caller and
On 3/4/13 9:10 AM, Zack Weinberg wrote:
So I guess the next question is where does one put a capturing event
handler so that it will see *all* events of the relevant type regardless
of which window it was dispatched to or the contents of that window
I don't think such a thing is possible in a
On 3/4/13 8:15 AM, Jim Mathies wrote:
So to work around this I’ve been putting together some basic perf tests I can
use to measure performance using the mochitest framework.
How are you dealing with the fact that mochitest runs on heterogeneous
hardware (including VMs and the like last I
On 3/4/13 1:08 PM, Zack Weinberg wrote:
It only needs to be certain of seeing the event despite anything content
can do,
In that case, a capturing handler on the chrome event listener will work
fine.
-Boris
___
dev-platform mailing list
On 3/5/13 12:01 PM, Bobby Holley wrote:
They were embarrassed and fixed their code
They weren't embarrassed and didn't fix their code. And since we
relanded netscape they don't really have incentive to...
Of course now their sniffing relies on at least three separate things
all of which
On 3/11/13 12:27 PM, Gavin Sharp wrote:
But firefox is just sending 'filename' parameter encoded with the page
encoding or the form accept-charset, this is, it is sending raw UTF-8 or
the choosen encoding.
Which is the reason for this?
The main reason is that it's what Netscape and IE did 12
On 3/27/13 8:08 PM, Steve Fink wrote:
Yes, it does depend on a mostly undocumented try syntax feature from bug
802937. I've at least added these example pushes to
https://wiki.mozilla.org/ReleaseEngineering/TryChooser.
Adding either a link to that, or examples directly, to
On 3/31/13 8:05 AM, ISHIKAWA, Chiaki wrote:
Has mozilla considered using this free service before?
Yes. You can query bugzilla for coverity-based bug reports...
The false positive rate was very very high, last time it was tried.
-Boris
___
On 4/22/13 4:37 AM, Matthew Gertner wrote:
However, the sandbox lives on if it contains DOM event handlers that have not
been removed.
Event handlers, or event listeners?
For event listeners, this happens because they're not holding
cross-compartment wrappers, presumably... and that's not
On 4/21/13 7:51 PM, Justin Lebar wrote:
Since most of these features implemented in JS seem to be DOM features, I'm
particularly interested in the opinions of the DOM folks.
Opinions differ. ;)
I think for DOM features that are not invoked on most pages,
implementing them in JS seems like a
On 4/22/13 5:22 PM, Jeff Muizelaar wrote:
I don't know if there's anything surprising here. Calling into JS from C++ goes
through xpconnect which is a long standing slowness.
_That_ we can try to fix by converting to JS-implemented WebIDL. Right
now that performs about the same, but we know
On 4/23/13 11:18 AM, Ehsan Akhgari wrote:
Does this also apply to code holding on to JSObject*s?
If you're holding them on the heap... sigh. Just trace them and use
fromMarkedLocation as needed; there is nothing better at the moment.
You can't use JS::Rooted on the heap.
Can the stuff in
On 4/23/13 1:17 PM, David Keeler wrote:
I would like to know a bit more about this. Is our list of supported
toolchains so diverse that building with one version versus another will
report so many false positives as to be useless?
Yes. For example a typical clang+ccache build of the tree with
On 4/26/13 6:26 PM, Nicholas Nethercote wrote:
If I have a patch ready to land when inbound closes, what would be the
sequence of steps that I need to do to land it on inbound2?
The following steps assume that the default and default-push for your
repo are both appropriate versions of inbound
On 4/29/13 11:05 AM, Kyle Huey wrote:
Our (ostensibly) weekly DOM bindings meetings continue on Monday April 29th
at 12:30 PM PDT.
Per discussion of the meeting, here's a strawman plan for converting
Window to WebIDL: https://etherpad.mozilla.org/WebIDL-Window
Please add anything I missed
On 5/1/13 6:48 PM, Matthew Gertner wrote:
Is it normal that subresources loaded by a stylesheet from a privileged channel
do not trigger the content policy
Yes. Content policy checks are skipped when the loader has system
principal.
If so, is there any way around this other than to not
On 5/2/13 10:09 AM, Matt Brubeck wrote:
The suggested workflow
with inbound2 would lead to almost-identical multi-headed repos in
developers' local clones anyway.
Only temporary ones, until inbound and inbound2 merge.
-Boris
___
dev-platform mailing
On 4/23/13 11:18 AM, Ehsan Akhgari wrote:
Can the stuff in objdir/dom/bindings be fixed whole-sale by changing the
WebIDL codegen?
This is nearly done: we're down to the issues in bug 868715, which
largely affect the js-implemented codegen at the moment, and the problem
of what to do with
On 5/6/13 7:27 AM, Benoit Jacob wrote:
I guess I don't see the usefulness of allowing to apply style to individual
parts of an equation
Styling parts of an equation with different colors can be _extremely_
useful for readability. It's rarely done in print, of course, and I
assume there are
On 5/16/13 3:15 PM, Ted Mielczarek wrote:
TL;DR: PGO on MSVC is now opt-in per-source-directory.
This is awesome. Thank you, Ehsan and Ted, for getting this sorted out!
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 5/28/13 8:22 AM, Benoit Jacob wrote:
When I started this thread, I didn't even conceive that one would want to
apply style to individual pieces of an equation. Someone gave the example
of applying a color to e.g. a square root sign, to highlight it; I don't
believe much in the pedagogic value
On 5/24/13 10:50 AM, Justin Lebar wrote:
Consider for example how much better harthur's fileit and dashboard
tools [1] [2] are than bugzilla's built-in equivalents.
[2] http://harthur.github.io/bugzilla-todos/
So I actually tried using the dashboard you link to for the last week.
It's
I know we already try to be, but it's worth seeing things like
https://groups.google.com/a/chromium.org/forum/#!msg/chromium-dev/wDV9JHs0mBA/0iw5vRDThXYJ
to be reminded that others may not realize that we are... Now the
particular examples Greg cites are, I think, not really applicable, but
On 7/9/13 3:14 PM, Taras Glek wrote:
Conversely, poor code review practices hold us back.
Agreed. At the same time, poor patch practices make reviews _much_
harder. We should generally expect good patch practices from
established contributors; obviously expecting them from new contributors
On 5/31/13 3:20 PM, Matt Brubeck wrote:
blame mobile/android/chrome/content/browser.xul:
git 1.015s
hg 0.830s
Was this a git blame -C (which would be more similar to hg blame), or
just a git blame?
-Boris
___
dev-platform mailing list
On 7/9/13 4:29 PM, Chris Peterson wrote:
I've seen people change their Bugzilla name to include a comment about
being on PTO.
Sure. As a simple example, I did that on June 20th. I got about 20
review requests over the course of the following week and a half, and
that's with most of the
On 7/9/13 6:11 PM, therealbrendane...@gmail.com wrote:
I've said this before, not sure it's written in wiki-stone, maybe it should be:
if you get a review request, respond same-day either with the actual review, or
an ETA or promise to review by a certain date.
Again, this is not viable
On 6/13/13 11:56 PM, Robert O'Callahan wrote:
Bug 875060 made me wonder whether we should disable XUL 'display' values on
the Web, perhaps starting with -moz-stack and -moz-inline-stack. They do
very little that can't be done with absolute positioning. Perhaps we would
leave XUL 'display' values
On 7/10/13 1:58 PM, Mark Côté wrote:
The BMO team is again considering switching to ReviewBoard, which should
fix this problem
How does ReviewBoard address this?
Again, what we have in the bug is diff 1 against changeset A and diff 2
against changeset B that incorporates the review changes.
On 7/10/13 12:56 PM, msrecko...@mozilla.com wrote:
Why not?
Because submitting a first patch is scary enough as it is that we should
try to minimize the roadblocks involved in it.
This is also why the reviewer in cases like that should handle setting
the checkin-needed keyword (or just
On 6/14/13 10:19 AM, Eric Shepherd wrote:
We have just thrown the switch, and if you're logged into MDN, you
should now have a new Email me article changes button next to the Edit
button near the top of the page.
Thank you for making this happen!
-Boris
On 6/24/13 5:49 PM, Ehsan Akhgari wrote:
What about changes made in order to improve compliance with a spec not
developed by Mozilla?
This is a tough call. My experience is that most specs out there are
buggy in their use of WebIDL and in their general API design, so such a
change would
On 7/10/13 8:31 AM, Mark Banner wrote:
The problem is, that doesn't work on the patch submission forms.
Or on bzexport. I can't recall the last time I used the Bugzilla UI for
requesting review...
but I think it would be good
to have the option to provide a warning with a little bit of
On 7/11/13 7:59 AM, Gervase Markham wrote:
Hey, if we had a PTO app that tracked all absences, we could integrate
with it...
sigh
Just in case you were talking about the moco PTO app, it doesn't track
absences for non-MoCo employees, and even for employees it does not
track non-PTO absences
On 7/11/13 9:23 AM, Justin Lebar wrote:
One thing I've been thinking about is /why/ people are slow at reviews.
Here are some possible reasons I've encountered myself:
1) Feeling overwhelmed because you have too many reviews pending and
therefore just staying away from your list of reviews.
On 7/11/13 11:37 AM, Robert O'Callahan wrote:
While I think your observations are useful, I think (hope!) you are a
massive outlier
Somewhat. My list was based on not only what makes my reviews slow but
what I've heard people mention as making reviews slow.
I do agree we shouldn't design a
On 7/11/13 2:41 PM, Chris Pearce wrote:
Maybe you need to start farming out reviews to other/newer members of
the teams you work on?
Oh, that's been happening. A lot.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
On 7/15/13 2:58 PM, Steve Fink wrote:
Even for the case of dependent patches (ones with separate parts that
cannot be landed together, but are usefully split up for review)?
Assuming s/cannot/must/, that's why I said generally, not always. ;)
Perhaps that's wrong of me, but it seems like
On 7/18/13 9:27 PM, Benjamin Smedberg wrote:
My opinion is still that we should rip out most or
all of this mechanism, and replace it with an opt-in mechanism for
methods that actually do exception passthrough.
For what it's worth, that's how the mechanism for calling JS from C++
via WebIDL
On 7/22/13 10:45 AM, Andrea Marchesini wrote:
I know that we don't want to convert all the existing interfaces to WebIDL, but
I still think this report is useful to choose which interface is available to
be converted.
I think it would be useful to have a report like this but restricted to
On 7/23/13 10:38 AM, Jan Odvarko wrote:
Is the method removed?
No.
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
On 7/30/13 7:43 AM, Boris Zbarsky wrote:
On 7/30/13 7:20 AM, janjongb...@gmail.com wrote:
But is it possible to have a promise as a return type in my .idl file
(b2g)?
Just list it as nsISupports in the .idl. XPConnect will do the right
thing.
Ignore the above; I thought you were talking
On 7/30/13 11:13 AM, Dave Townsend wrote:
The JS promise implementation came out of a desire to use promises in
add-ons and devtools amongst others. I believe the C++ implementation came
out of the DOM spec. I'm not sure why we need both.
OK. Given that there is also a desire to be able to
On 7/30/13 1:37 PM, Gavin Sharp wrote:
We'll need to investigate whether the implementations
are compatible, though
That's fair. DOM Promises are definitely modeled after Promises/A+, but
the APIs might not quite match up. :(
-Boris
___
On 8/2/13 8:14 PM, Brian Smith wrote:
The risk that any developer would need to
waste time on ESR just to support a product that isn't even Firefox on a
platform that virtually nobody uses, and the risk that comes with making
any changes to the security fix that you are trying to backport.
I
On 8/5/13 2:05 AM, Justin Lebar wrote:
Nick, when you made changes to the JS engine's #includes, did you
observe a change in build times?
Just for data, when khuey just reduced the number of includes in
bindings code, that did in fact affect build times.
On 8/5/13 1:46 AM, Joshua Cranmer wrote:
DOMJSProxyHandler.h [2614, #197] includes xpcpublic.h [2645, #188]
includes nsIURI [3295, #121]. DOMJSProxyHandler appears to include
xpcpublic.h solely for IsDOMProxy; xpcpublic.h appears to include nsIURI
because it uses it as an nsCOMPtr in the
On 8/9/13 5:54 AM, Neil wrote:
(For instance I suspect it might be feasible for DOM promises
to report any pending exception when they get garbage collected.)
Oh, that is a _very_ interesting idea. I wonder whether we can get that
specced, or at least allowed by the spec.
-Boris
There is a proposal in
https://bugzilla.mozilla.org/show_bug.cgi?id=903372 to remove xml:base
support.
Do we actually use this for anything? I thought we used to set it for
xbl stuff, but I don't see obvious code doing that.
If we can, it would be great to rip this out: it would
On 8/9/13 9:27 AM, Boris Zbarsky wrote:
I think we should definitely report to the error console.
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=903419
-Boris
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https
On 8/19/13 8:15 PM, Nicholas Nethercote wrote:
Unfortunately, this work will only go so far because
xpcpublic.h, BindingUtils.h, and DOMJSClass.h all (unavoidably)
include jsapi.h, and they are headers that are large and included in
lots of places. I'd love to hear suggestions as to how they
On 8/26/13 6:31 PM, Mike Hommey wrote:
Not necessarily. You can take that as being exactly the point being
made, and it has some value. If your preprocessed source is 40 times
bigger than the plain source, there might be something wrong.
Mmm...
We pretty commonly have files whose .i is 40x
On 9/5/13 11:15 AM, Adam Roach wrote:
I would argue that we do, to some degree, already do this for things
like Content-Encoding. For example, if a website attempts to send
gzip-encoded bodies without a Content-Encoding header, we don't simply
display the compressed body as if it were encoded
On 9/5/13 10:41 PM, digitalc...@gmail.com wrote:
I'm creating a FF extension that needs to detect whether a window was opened
via javascript with the window.open() command.
Generally, testing .opener on the relevant window will work. However
note that pages can explicitly null this out to
On 9/7/13 12:56 PM, Benoit Jacob wrote:
https://bugzilla.mozilla.org/show_bug.cgi?id=913847 moves NS_IsMainThread
to a new MainThreadUtils.h header that's cheaper to include, and in
particular is all what BindingUtils.h needs (there was a helpful comment
about that in BindingUtils.h).
On 9/7/13 8:49 PM, Nicholas Nethercote wrote:
I've been focusing entirely on jsapi.h includes. We're down to ~1480
rebuilt files when it gets touched; we started at ~2600. It's
getting hard to improve, because there's a tangled clump of
widely-included files that include it still either
On 9/8/13 7:29 PM, Nicholas Cameron wrote:
I timed builds to see if this makes a significant difference and it did not..
The other thing that reducing .i size helps is Windows PGO memory usage.
See graph at
1 - 100 of 952 matches
Mail list logo
