Re: Where can i download firefox-sdk

't use it for anything that requires running in the same address space as Firefox. Even if that remains possible for the foreseeable future (hopefully it won't), I can more or less guarantee you it won't be accepted if you submit your add-on for signing. -- Kris Maglione Firefox Add-ons Engineer M

Re: ESLint is now available in the entire tree

On Fri, Nov 27, 2015 at 02:53:35PM -0800, Dave Townsend wrote: Going forwards we'd like to enable it in more directories and turn on more rules. You can help! If there is a directory you work in a lot try removing it from the top-level .eslintignore file and see what fails, then fix it. Mostly

Re: nsIProtocolHandler in Electrolysis?

On Mon, Jan 04, 2016 at 06:29:26PM -0800, Kris Maglione wrote: I think that doing this in an add-on is asking for trouble. I don't think I've ever seen nsIChannel implemented in JavaScript. I take that back. I see Overbite is indeed implemented this way. It still seems like asking for trouble

Re: nsIProtocolHandler in Electrolysis?

still open a modal from the parent process, but probably not without running into problems. -- Kris Maglione Firefox Add-ons Engineer Mozilla Corporation Lisp has jokingly been called "the most intelligent way to misuse a computer". I think that description is a great complime

Re: nsIProtocolHandler in Electrolysis?

On Mon, Jan 04, 2016 at 08:27:59PM -0500, Jason Duell wrote: In the child we hand out a stub channel (HttpChannelChild) that looks and smells like an nsIHttpChannel, but actually uses IPDL (our C++ cross-platform messaging language) to essentially shunt all the real work to the parent. When

Re: Startup cache and resource:// urls

On Tue, Nov 24, 2015 at 02:22:44PM +0900, Mike Hommey wrote: Note the startup cache only matters on the first startup for a given build, and that might be a reason why we fail to track its performance impact. Presumably also when we flush the startup cache for changes in add-ons? Most

Re: Startup cache and resource:// urls

On Tue, Nov 24, 2015 at 04:08:56PM +0900, Mike Hommey wrote: ... which seems to be a *very* old thing because: - resource://app might have pointed to the plain Firefox directory where you could find the omnijar a long time ago (I don't remember if that ever was actually true), but it points

Re: How badly out of date is this?

On Wed, Jun 01, 2016 at 11:23:58AM -0400, Kartikaya Gupta wrote: On Wed, Jun 1, 2016 at 10:06 AM, Mike Hoye wrote: On 2016-06-01 5:02 AM, L. David Baron wrote: So I tend to think it's worth keeping, but with a preface that clearly labels it as historical and no longer good

Re: Unsafe CPOWs are about to be outlawed in browser code

On Tue, Feb 02, 2016 at 01:39:00AM +0300, Dmitry Gutov wrote: On 02/02/2016 12:29 AM, Kris Maglione wrote: That falls into the category of "unless it is calling browser code and making it do something unsafe". That's too bad. I'm just reusing a querying function from there, and

Re: Setting property on the element is no longer working on Firefox 45

On Thu, Mar 10, 2016 at 10:44:24AM -0800, Devan Shah wrote: This happens in side extension only (works fine on web standalone), i will try to extract a simple reproducible scenario. Is there any way to simulate a extension env on web? If your problem is happening in an extension, then filing

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thu, Apr 21, 2016 at 11:07:21AM +1000, Nicholas Nethercote wrote: Instead, we would do this: nsresult rv; T ts(rv); if (NS_FAILED(rv)) { return rv; } T* th = new T(rv); if (NS_FAILED(rv)) { delete th; return rv; } If we do this, can we please use |nsresult*| rather than

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Wed, Apr 20, 2016 at 10:02:47PM -0700, Kyle Huey wrote: On Wed, Apr 20, 2016 at 9:52 PM, Kris Maglione <kmagli...@mozilla.com> There isn't a strict guarantee of non-nullness for reference parameters. This is an extreme example, but technically valid: T th(*(nsresult*)0);

Re: Proposal: use nsresult& outparams in constructors to represent failure

On Thu, Apr 21, 2016 at 02:10:59PM +1000, Nicholas Nethercote wrote: On Thu, Apr 21, 2016 at 1:23 PM, Kris Maglione <kmagli...@mozilla.com> wrote: If we do this, can we please use |nsresult*| rather than |nsresult&|? I prefer a reference because of the guarantee of non-nullness. B

Re: Please use Add*VarCache and not Get* when reading pref values in any even possibly warm code paths

On Wed, Feb 22, 2017 at 01:18:33PM +0200, smaug wrote: Preferences::GetBool is a slow hashtable lookup and has been showing up in performance profiles in many places. Please use Preferences::AddBoolVarCache. Same with other pref types. Or if the pref needs to be read just once, store the value

Re: Deprecating XUL in new UI

On Tue, Jan 17, 2017 at 02:51:47PM -0600, J. Ryan Stinnett wrote: I am not very familiar with the details of XUL prototype cache, but my understanding of bug 1286082[1] is that currently the XUL prototype cache is not actually working correctly (and possibly has been broken since bug 592943[2]

Re: So, what's the point of Cu.import, these days?

On Sun, Sep 25, 2016 at 12:13:41AM +0200, David Teller wrote: So, can anybody think of good reason to not do this? One major problem I see with this is that we currently lazily import most modules the first time that a symbol they export is referenced. If we move to CommonJS or ES6 modules,

Re: Retrieving all bookmarks using WebExtensions API

atform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Kris Maglione Firefox Add-ons Engineer Mozilla Corporation Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each

Re: File() constructor with a string argument no longer works since Firefox 52a?

See https://bugzil.la/1303518 On Wed, Nov 23, 2016 at 01:48:43PM +0800, 段垚 wrote: Hi, In Firefox 51 chrome code, this code works: `new File(path_to_file)` , if `path_to_file` exists. However in Firefox 52a (2016-11-22)，an execption is thrown: "TypeError: Not enough arguments to File". I

Re: Some recent Treeherder improvements

On Wed, Jan 04, 2017 at 01:06:25PM -0500, William Lachance wrote: * As of today, we have a completely rewritten logviewer which (among other things) has vastly improved scrolling behaviour, making it much faster to diagnose the cause of a failing job. Many thanks to Eli Perelman and Hassan

Re: Introducing mozilla::Result for better error handling

rm mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Kris Maglione Firefox Add-ons Engineer Mozilla Corp

Re: Introducing mozilla::Result for better error handling

. In isolation, I might worry more about it leading to new early return errors, but in context, I think it's clearly a step in the right direction. On Wed, Dec 21, 2016 at 10:59 PM, Kris Maglione <kmagli...@mozilla.com> wrote: On Wed, Dec 21, 2016 at 10:53:45PM -0800, Eric Rahm wrote:

Re: Switching to async/await from Task.jsm/yield

On Mon, Mar 27, 2017 at 12:42:46PM -0700, Dave Townsend wrote: It looks like the main concern raised about switching over to async/await where possible is bug 1242505. I personally wouldn't consider this a blocker. I'm all for it being fixed, but the benefit of not having Promise.jsm noise in

Re: intent to remove: standalone about:addons UI and tests

On Thu, Mar 23, 2017 at 08:33:56AM +0900, Mike Hommey wrote: On Wed, Mar 22, 2017 at 02:36:31PM -0700, Robert Helmer wrote: Currently we support running the about:addons UI in both a standalone window, and also in a browser tab. Firefox has only used the latter for many years, but we've

Re: intent to remove: standalone about:addons UI and tests

maintenance burden and also the time it takes tests to run. This removal is being tracked in bug 1349723. -rhelmer ___ Dev-addons mailing list dev-add...@mozilla.org https://mail.mozilla.org/listinfo/dev-addons -- Kris Maglione Firefox Add-ons Engineer

Re: Tracking bug for removals after XPCOM extensions are no more?

On Wed, Mar 15, 2017 at 11:35:10PM +0200, Henri Sivonen wrote: What's the current outlook on letting chrome JS read ArrayBuffers as opposed to JS strings where the high 8 bits are zero and the low 8 bits are the byte values from XPCOM streams? (Or letting chrome JS access things that are

Re: Switching to async/await from Task.jsm/yield

On Fri, Mar 17, 2017 at 10:19:02AM -0700, Dave Townsend wrote: One issue I have just spotted is that Task.jsm uses a JavaScript implementation of promises under the hood while async/await obviously uses our native implementation in the JS engine. This may mean the two have slightly different

Re: Tracking bug for removals after XPCOM extensions are no more?

On Fri, Mar 17, 2017 at 11:44:08AM +0200, Henri Sivonen wrote: On Thu, Mar 16, 2017 at 8:12 PM, Kris Maglione <kmagli...@mozilla.com> wrote: On Wed, Mar 15, 2017 at 11:35:10PM +0200, Henri Sivonen wrote: What's the current outlook on letting chrome JS read ArrayBuffers as opposed to JS s

Re: Switching to async/await from Task.jsm/yield

On Fri, Mar 17, 2017 at 07:30:46PM -0400, Ehsan Akhgari wrote: Have we measured the performance of our async/await implementation? I think we should definitely do some extensive testing of the performance of any new ES primitives before deciding to switch to using them in the front-end code en

Re: Quantum Flow Engineering Newsletter #2

On Thu, Mar 16, 2017 at 11:07:19AM -0400, Ehsan Akhgari wrote: This is why a while ago we decided to disallow the addition of new synchronous IPC messages by default (bug 1336919) to avoid programmers adding more issues of this nature to the code base. Are there any plans to do something

Re: Switching to async/await from Task.jsm/yield

On Thu, Mar 16, 2017 at 03:29:15PM -0700, Dave Townsend wrote: Writing code in standard JS is always better for the web, makes it easier to onboard new engineers and allows for better support in developer tools. So I'd like to propose that we switch to the standard way of writing these functions

Re: Switching to async/await from Task.jsm/yield

definitely a difference in the way we collect async stacks in async/await code vs. with the Promise.jsm promises that Task.jsm uses, but that shouldn't show up much on release. On Thu, Mar 16, 2017 at 5:33 PM, Kris Maglione <kmagli...@mozilla.com> wrote: On Thu, Mar 16, 2017 at 03:29:15PM

Re: Tracking bug for removals after XPCOM extensions are no more?

On Wed, Mar 15, 2017 at 03:26:19PM -0400, Botond Ballo wrote: What will happen to WebExtension Experiments once these APIs start being removed? My understanding is that WebExtension Experiments use the same XPCOM APIs as XUL addons. The APIs that we're talking about removing have largely been

Re: Switching to async/await from Task.jsm/yield

On Thu, Mar 16, 2017 at 09:08:24PM -0400, Michael Layzell wrote: Can we pass async functions everywhere where we use `add_task` in tests already? If we can't, is there a tracking bug for converting all of the test systems to support it? Yes, add_task accepts any function which returns a

Re: All the processes

On Sat, Mar 04, 2017 at 11:15:29AM +1100, Nicholas Nethercote wrote: Hi, I want to understand all the different processes that we can and will have in Firefox. Here's a list I constructed off the top of my head. - main process - content process(es): 1 on release for most users; 2 on Nightly

Re: Tracking bug for removals after XPCOM extensions are no more?

On Mon, Mar 13, 2017 at 08:36:05AM -0700, Steve Fink wrote: For the record, there's some nonobvious stuff I can remove from the rooting hazard analysis due to this -- currently, it conservatively assumes that just about any nsISupports subclass's method could be implemented in a binary

Re: Sheriff Highlights and Summary in February 2017

On Fri, Mar 10, 2017 at 01:55:40PM +, David Burns wrote: I went back and did some checks with autoland to servo and the results are negligible. So from 01 February 2017 to 10 March 2017 (as of sending this email). I have removed merge commits from the numbers. Autoland: Total Servo Sync

Re: All the processes

On Tue, Mar 07, 2017 at 09:12:55AM +1100, Nicholas Nethercote wrote: Now for the reason I raised this: the major downside of using multiple processes is that it increases memory usage. Recent-ish measurements showed that for e10s-multi we could probably go up to 4 content processes without

Re: Heads Up: /storage upgraded from version 1.0 to 2.0

On Tue, Mar 07, 2017 at 08:02:47PM -0500, Ben Kelly wrote: As an example of why "backup the db" is harder than it sounds, you would need to backup the entire storage subsystem. If you lose data in IDB, but don't lose data in other sub-systems like cache API, then an origin can find itself in a

Re: Project Stockwell (reducing intermittents) - March 2017 update

On Tue, Mar 07, 2017 at 11:15:54AM -0800, Kris Maglione wrote: It would be nice if, rather than disabling the test, we could just annotate so that it would still run, and show up in Orange Factor, but wouldn't turn the job orange. Which might be as simple as moving those jobs

Re: Project Stockwell (reducing intermittents) - March 2017 update

On Tue, Mar 07, 2017 at 06:26:28AM -0800, jma...@mozilla.com wrote: In March, we want to find a way to disable the teststhat are causing the most pain or are most likely not to be fixed, without unduly jeopardizing the chance that these bugs will be fixed. We propose: 1) all high frequency

Re: Actually-Infallible Fallible Allocations

that the Vector class promotes (and is used extensively throughout Spidermonkey) is all three. On Tue, Aug 1, 2017 at 2:10 PM, Kris Maglione <kmagli...@mozilla.com> wrote: On Tue, Aug 01, 2017 at 01:28:37PM -0700, Eric Rahm wrote: Both AppendElements and SetLength default initialize the values, t

Re: Actually-Infallible Fallible Allocations

pointer access, placement `new`s, and an intermediate state where we have a bunch of indexable but uninitialized elements in the array. That's been my experience when reading and writing code using the various approaches, anyway. On Tue, Aug 1, 2017 at 12:18 PM, Kris Maglione <kmagli...@

Re: Actually-Infallible Fallible Allocations

&&), but that wouldn't really help in this case. It's possible we could add that of course! -e On Tue, Aug 1, 2017 at 1:11 PM, Kris Maglione <kmagli...@mozilla.com> wrote: On Tue, Aug 01, 2017 at 12:57:31PM -0700, Eric Rahm wrote: nsTArray has various Append methods, in this c

Re: Care in the use of MOZ_CRASH_UNSAFE_* macros: data review needed

On Mon, Jul 17, 2017 at 09:52:55AM -0700, Bobby Holley wrote: On Mon, Jul 17, 2017 at 9:42 AM, Benjamin Smedberg wrote: I don't know really anything about how rust panics get reflected into crash-data. Who would be the right person to talk to about that? Rust panics

Re: Switching to per-channel profiles

On Tue, Jun 27, 2017 at 01:48:33PM -0400, Ehsan Akhgari wrote: On 06/27/2017 01:36 PM, Milan Sreckovic wrote: I don't know how common this workflow is for others, but I do find I often need to use release/beta to "fix" experimental preferences when things go wrong. For features that are

Re: More Rust code

On Mon, Jul 10, 2017 at 08:29:59PM +1000, Nicholas Nethercote wrote: I think this is an excellent trend, and I've been thinking about how to accelerate it... - Interop with existing components can be difficult. IPDL codegen rust bindings could be a big help. So far, this has been my biggest

Re: removing "the old way" of signing add-ons

On Thu, Jul 20, 2017 at 10:32:27AM +0200, Frank-Rainer Grahl wrote: Given all this, the question is do we still need this second API? Does Thunderbird or SeaMonkey use it for any reason, or can we simplify the code-base, reduce build size, etc.? I looked at the code and don't see any use

Re: OS/2 still supported ?

On Tue, Jul 25, 2017 at 01:13:42AM +, Enrico Weigelt, metux IT consult wrote: On 25.07.2017 00:32, Mike Hoye wrote: On 2017-07-24 8:27 PM, Enrico Weigelt, metux IT consult wrote: Hi folks, I see lots of #ifdef XP_OS2 ... is OS/2 still supported at all ? Our list of supported platforms

Re: removing "the old way" of signing add-ons

On Wed, Jul 19, 2017 at 05:02:23PM -0700, R Kent James wrote: On 7/19/2017 4:06 PM, David Keeler wrote: [dev-apps-thunderbird and dev-apps-seamonkey cc'd, but please discuss on dev-platform] ... Given all this, the question is do we still need this second API? Does Thunderbird or SeaMonkey

Re: inlining JS code at build time

of loading the file via JSM or XPCOM interfaces. Is there anything like a RollupJS in our build system? Or is there any plan to add it? -- Kris Maglione Senior Firefox Add-ons Engineer Mozilla Corporation Of all the preposterous assumptions of humanity over humanity, nothing exceeds most

Re: Intent to unship: tree pseudo-element selectors from web content (::-moz-tree-*)

On Fri, Jul 07, 2017 at 04:05:35PM +1000, Xidorn Quan wrote: On Fri, Jul 7, 2017, at 03:55 PM, Frank-Rainer Grahl wrote: Not using it but will this break remote XUL? XUL shouldn't be usable in content at all. Chrome document which have access to XUL should not be affected. Web content can

Figuring out and controlling what tasks run before first paint

One of my biggest frustrations in profiling startup performance has been the fact that exactly which code runs during before or after first paint changes based on arbitrary timing factors. If I make a 5ms improvement to one section of code, a 100ms chunk of code winds up running after first

Re: Changing .idl files

On Mon, Aug 07, 2017 at 10:58:11PM -0400, Boris Zbarsky wrote: On 8/7/17 6:17 PM, Nicholas Nethercote wrote: Is there going to be a clear point in time when legacy extensions stop working in Nightly? I was under the impression that there is, and I strongly feel there should be. There

Re: Changing .idl files

On Mon, Aug 07, 2017 at 08:50:38PM -0700, Fabrice Desre wrote: On 08/07/2017 08:17 PM, Kris Maglione wrote: Yes, that means that some users and developers will continue to use them, and continue to get upset when they break, but that's what they're signing up for when they flip the preference

Re: Figuring out and controlling what tasks run before first paint

know where to start. On Tue, Aug 8, 2017 at 5:42 PM, Kris Maglione <kmagli...@mozilla.com> wrote: One of my biggest frustrations in profiling startup performance has been the fact that exactly which code runs during before or after first paint changes based on arbitrary timing factors. If

Re: Actually-Infallible Fallible Allocations

On Tue, Aug 01, 2017 at 12:31:24PM -0400, Alexis Beingessner wrote: I was recently searching through our codebase to look at all the ways we use fallible allocations, and was startled when I came across several lines that looked like this: dom::SocketElement = *sockets.AppendElement(fallible);

Re: Changing .idl files

On Mon, Aug 07, 2017 at 07:03:52PM +0100, Jonathan Kew wrote: On 07/08/2017 18:05, Kris Maglione wrote: At the moment, legacy add-ons are allowed on nightly, but are officially unsupported. We're planning to disable them by default on nightlies, but it will still be possible to enable them

Re: Changing .idl files

On Mon, Aug 07, 2017 at 12:31:30PM -0400, Boris Zbarsky wrote: On 6/14/17 9:02 AM, Benjamin Smedberg wrote: Given that old-style addons are going away for 57, if it's possible to delay addon-breaking IDL changes by one release until 57 that's probably the easiest way to deal with this. We're

Re: Mixing nsresult and Result code

On Tue, May 09, 2017 at 12:50:26PM +, Nicolas B. Pierron wrote: On 05/07/2017 07:34 PM, Kris Maglione wrote: static inline Result<Ok, nsresult> WrapNSResult(PRStatus aRv) { if (aRv != PR_SUCCESS) { return Err(NS_ERROR_FAILURE); } return Ok(); } static

Re: Improving visibility of compiler warnings

On Sat, May 20, 2017 at 08:36:13PM +1000, Martin Thomson wrote: On Sat, May 20, 2017 at 4:55 AM, Kris Maglione <kmagli...@mozilla.com> wrote: Can we make some effort to get clean warnings output at the end of standard builds? A huge chunk of the warnings come from NSS and NSPR, and

Re: Switching to async/await from Task.jsm/yield

ng list firefox-...@mozilla.org https://mail.mozilla.org/listinfo/firefox-dev ___ firefox-dev mailing list firefox-...@mozilla.org https://mail.mozilla.org/listinfo/firefox-dev -- Kris Maglione Senior Firefox Add-ons Engineer Mozilla Corporation The ca

Re: Is it OK to make allocations that intentionally aren't freed? (was: Re: Is Big5 form submission fast enough?)

On Fri, May 19, 2017 at 08:44:58AM +0300, Henri Sivonen wrote: The downsides would be that the memory for the tables wouldn't be reclaimed if the tables aren't needed anymore (the browser can't predict the future) and executions where any of the tables has been created wouldn't be

Re: Improving visibility of compiler warnings

tps://mzl.la/2qFN0me and https://mzl.la/2rAkWR5 [3] https://treeherder.mozilla.org/#/jobs?repo=autoland=100509284 ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Kris Maglione Senior Fi

Re: Improving visibility of compiler warnings

e. ALLOW_COMPILER_WARNINGS usage is now only in external libraries (I'm counting NSS and NSPR as "external" for this purpose since I can't land code to m-c directly). On Fri, May 19, 2017, at 02:55 PM, Kris Maglione wrote: > I've actually been meaning to post about this, with some quest

Re: Changing .idl files

On Wed, Jun 14, 2017 at 01:49:28PM -0400, Boris Zbarsky wrote: On 6/14/17 12:23 PM, Andrew Swan wrote: I would hope that if we have promising or widely used webextension experiments, that the relevant peers would be aware of them when reviewing changes that might affect them I don't see how

Re: JSBC: JavaScript Start-up Bytecode Cache

On Tue, Jun 13, 2017 at 11:54:17PM -0400, Boris Zbarsky wrote: On 6/13/17 5:23 PM, Kris Maglione wrote: For

Mixing nsresult and Result code

I've been trying to write most of my new code to use Result.h as much as possible. When I have to mix Result-based code with nsresult-based code, though, things tend to get ugly, and I wind up writing helpers. At this point I've wound up writing the same helpers in 3 or 4 different places, so

Re: Improving visibility of compiler warnings

On Thu, May 25, 2017 at 08:31:24AM -0400, Ehsan Akhgari wrote: What was the motivation behind this change? Was there a complaint from a significant number of developers about it being difficult fixing compiler warnings grepping for things like "warning:" or using ./mach warnings-list? Was the

Re: Quantum Flow Engineering Newsletter #25

lerts?id=9542> and memory usage <https://treeherder.mozilla.org/perf.html#/alerts?id=9586> wins on Android like desktop above. - Olli Pettay fixed a recent regression <https://bugzilla.mozilla.org/show_bug.cgi?id=1398605> from one of my patches <https://bugzilla.mozilla

Re: Reminder on Try usage and infrastructure resources

te an intermittent), often I end up running all the mochitest-browser tests, looking at every log until I find the chunk where the test is, and retrigger just that chunk. The chunk number changes based on the platform and debug/opt, so it's painful. Is there a way to trigger only the chunk tha

Re: Intent to unship: Visibility of window.content to untrusted code

On Thu, Sep 14, 2017 at 05:37:58PM -0400, Boris Zbarsky wrote: On 9/14/17 5:33 PM, Ehsan Akhgari wrote: I think either of these two ideas would be good, but I think unshipping in 57 is premature without having an understanding of how much the Web depends on this for UA sniffing. OK. Do you

Re: Creating a content process during shutdown...

On Wed, Sep 20, 2017 at 02:38:23PM -0400, Milan Sreckovic wrote: I've spoken to some of you about this, but at this point need a larger audience to make sure we're covering all the bases. Do we have code in Firefox that would cause us to create a new content process, after we've entered

Re: Intent to require `mach try` for submitting to Try

as you file bugs, you shouldn't need to worry. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Kris Maglione Senior Firefox Add-ons Engineer Mozilla Corporation He hoped and praye

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Wed, Oct 04, 2017 at 12:42:22AM -0400, Boris Zbarsky wrote: On 10/2/17 9:50 PM, Kris Maglione wrote: For the pretty simple micro-benchmark below, here are the in-document and out-of-document numbers for three runs without the subject principal: Sorry, I should have been clearer: I meant

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Mon, Oct 02, 2017 at 11:39:21AM -0700, Kris Maglione wrote: On Mon, Oct 02, 2017 at 11:13:20AM -0400, Boris Zbarsky wrote: Passing along a JSContext would work. We could have something like "null means no scripted caller, otherwise caller's compartment is the part that ma

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Mon, Oct 02, 2017 at 09:07:09PM -0400, Boris Zbarsky wrote: On 10/2/17 5:35 PM, Kris Maglione wrote: So far it doesn't look like there's any significant difference on any talos test from adding [NeedsCallerPrincipal] to setAttribute/setAttributeNS/Attr.value, OK. That's a minimum bar

Re: #pragma once?

On Wed, Oct 11, 2017 at 11:45:54AM +0200, Emilio Cobos Álvarez wrote: Hi, I'm adding a header to the build, and I'm wondering: Can we use pragma once? I don't see it anywhere in the build except third-party paths and: dom/svg/nsISVGPoint.h xpcom/io/nsAnonymousTemporaryFile.h The last time

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Fri, Sep 29, 2017 at 11:33:08PM -0400, Boris Zbarsky wrote: On 9/29/17 3:32 PM, Kris Maglione wrote: For instance, the following should all capture the caller principal for the `src` URL at call time:    document.write(`http://example.com/favicon.ico;>`);    div.innerHTML = `h

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Mon, Oct 02, 2017 at 07:50:41AM -0700, Daniel Veditz wrote: On Fri, Sep 29, 2017 at 8:33 PM, Boris Zbarsky <bzbar...@mit.edu> wrote: On 9/29/17 3:32 PM, Kris Maglione wrote: For instance, the following should all capture the caller principal for the `src` URL at cal

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Mon, Oct 02, 2017 at 11:13:20AM -0400, Boris Zbarsky wrote: Passing along a JSContext would work. We could have something like "null means no scripted caller, otherwise caller's compartment is the part that matters". This relies on no one on the setattr path messing with the compartment,

Re: Intent to implement and ship: CSP exemptions for content injected by privileged callers

On Sun, Oct 01, 2017 at 12:54:26PM -0700, Luke Crouch wrote: On Friday, September 29, 2017 at 2:32:57 PM UTC-5, Kris Maglione wrote: Security & privacy concerns: This change will allow extensions to inject content into sites which can (and probably will) cause security and privacy is

Intent to implement and ship: CSP exemptions for content injected by privileged callers

Summary: All content injected into web content pages is currently subject to the same Content Security Policy, regardless of who injected it. For privileged callers, such as extension content scripts, this means that some functionality can behave erratically, depending on the page they're

Re: New string types: nsAutoStringN<> and nsAutoCStringN<>

On Mon, Aug 21, 2017 at 05:31:14PM -0700, Eric Rahm wrote: I'm not sure how much backing that has -- we'd be going from nsString => String which is pretty close to std::string -- it would be interesting to get some feedback. It's already a pretty common practice to have MFBT identifiers with

Re: Eiminating nsIDOM* interfaces and brand checks

On Fri, Sep 01, 2017 at 11:01:51AM -0400, Boris Zbarsky wrote: Now that we control all the code that can attempt to touch Components.interfaces.nsIDOM*, we can try to get rid of these interfaces and their corresponding bloat. The main issue is that we have consumers that use these for testing

Re: Stylesheet wait timeout?

On Fri, Sep 01, 2017 at 10:52:30AM -0400, Ehsan Akhgari wrote: On 09/01/2017 09:54 AM, Boris Zbarsky wrote: On 9/1/17 7:02 AM, Gervase Markham wrote: Restarting with no extensions causes my browser to feel a whole lot faster (I'd love to know why that is, but that's a separate issue!) Worth

Re: Stylesheet wait timeout?

illa.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.moz

Re: Eiminating nsIDOM* interfaces and brand checks

On Fri, Sep 01, 2017 at 04:43:31PM -0400, Ehsan Akhgari wrote: On 09/01/2017 01:18 PM, Boris Zbarsky wrote: That has the unfortunate side-effect of allocating a new JS string for every call, but we can probably optimize it if it becomes necessary. We could add a hasClassName if we wanted.

PSA: MOZ_TRY() now works with nsresult values and in nsresult-valued functions

As of the landing of bug 1366511, it's now possible to use MOZ_TRY with and from functions that return nsresult values. This means that, among other things, it's now easy to use mozilla::Result from XPCOM methods, and vice versa, as long as the Result error type is nsresult: #include

Re: Eiminating nsIDOM* interfaces and brand checks

On Fri, Sep 01, 2017 at 01:18:12PM -0400, Boris Zbarsky wrote: That has the unfortunate side-effect of allocating a new JS string for every call, but we can probably optimize it if it becomes necessary. We could add a hasClassName if we wanted. That's an interesting idea. It would also

Re: Stylesheet wait timeout?

On Sun, Sep 03, 2017 at 12:40:04PM -0400, Dustin Mitchell wrote: I just reproduced it with a random page from my history: https://github.com/taskcluster/taskcluster-cli/issues/49. Any github page will do, and it seems to have to do with caching. if I delete today's history, I can reproduce.

Re: Incoming JS module (JSM) / component loader changes

31, 2017 at 11:14:34AM -0700, Kris Maglione wrote: A quick heads-up on some incoming changes to the JS component loader that may affect some existing JSM or JS component code: 1) As of bug 1394556[1], all JS module and component scripts are automatically compiled in strict mode[2]. While I fixed

Incoming JS module (JSM) / component loader changes

A quick heads-up on some incoming changes to the JS component loader that may affect some existing JSM or JS component code: 1) As of bug 1394556[1], all JS module and component scripts are automatically compiled in strict mode[2]. While I fixed all of the resulting issues that showed up in

Re: Stylesheet wait timeout?

On Thu, Aug 31, 2017 at 02:00:49PM -0500, Michael Froman wrote: I’ve seen this behavior too on OSX. I did a restart with all add-ons disabled and could not reproduce. Restarted with all add-ons on, and can reproduce. I narrowed it down to Ghostery. If I disable Ghostery, it no long appears

Re: We need better canaries for JS code

On Wed, Oct 18, 2017 at 07:22:09PM -0700, Daniel Veditz wrote: On Wed, Oct 18, 2017 at 4:51 AM, Mark Banner wrote: I did an experiment, and the only way I got an error out was to have "javascript.options.strict" on and Why isn't it a code-style/review requirement that

Re: Change: Performance bugs handling and triaging

On Thu, Oct 19, 2017 at 03:40:53PM -0400, Boris Zbarsky wrote: Naveed, Thank you for continuing work on performance! New profiles that require analysis should be assigned to relevant domain experts. Do we have a plan for _generating_ profiles, or at least incentivizing generation thereof?

Re: FF57 Web Extension Content Script ReferenceError

This is probably bug 1408996. On Wed, Nov 15, 2017 at 01:34:44PM -0800, Jip de Beer wrote: This simple web extension used to work on FF51 and still works on Google Chrome. But it no longer works reliably on FF57 when loading the content script for https://vk.com/. I get the following error:

Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code

On Thu, Nov 30, 2017 at 11:09:07AM +1300, Karl Tomlinson wrote: The native bytes may not be valid UTF-8, and so if the character encoding is UTF-8, then there may not be a valid `path` that can be encoded to produce the same `nativePath`. I think you mean "is not UTF-8"? It is

Re: Please do not use GetNativePath and GetNativeTarget in XP code and Windows-specific code

-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform -- Kris Maglione Senior Firefox Add-ons Engineer Mozilla Corporation Doing linear scans over an associative array is like trying to club someone to death with a loaded Uzi. --Larry Wall

Re: Firefox 55.* in Windows/Ubuntu - every day CPU 100%/Hangs Up. Please to do something!

On Tue, Nov 21, 2017 at 02:22:26PM -0500, Ted Mielczarek wrote: On Tue, Nov 21, 2017, at 06:54 AM, Alexey Zvyagin wrote: Hi! I made some crashes by hands (crashfirefox.exe) in Windows 7 and in Unix through kill -ABRT What are the symptoms? In random moments the Firefox v56.* has only-one core

Re: Firefox 55.* in Windows/Ubuntu - every day CPU 100%/Hangs Up. Please to do something!

are using legacy extensions, that can do whatever they wish with our APIs, including some of the slow paths we removed in 57 and 58 beta. Please let me know if you have any news, also, tracking this in a bug could be useful, regardless of the final outcome. On Tue, Nov 21, 2017 at 9:32 PM, Kri

  1   2   3   >