How to building the xpt file from multiple idl files
Now I am trying to building a xpcom components, but it have multiple .idl file to compiled into a single xpt component, how to do that? I am using XULRunner 31 sdk/bin ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
On Mon, Aug 11, 2014 at 5:16 PM, Karl Dubost kdub...@mozilla.com wrote: Jonas, Le 12 août 2014 à 08:33, Jonas Sicking jo...@sicking.cc a écrit : However in some cases we can do better than that by loading a template page that can be used for multiple of the search results. This I'm not sure to understand how that would be working. Let's say be any page on the Web. How do you know in advance the template for the page? I might have missed something. I think we are indeed talking past each other. The goal of the prerendering API is to enable a webpage to include something like link rel=prerender url=http://somewebsite.com/page.html; This would tell the UA to load the above URL, as well as any resources that is required to render the resulting page, and construct the DOM and layout datastructures which are needed to display the page. All of this is done in the hope that if the user navigates to http://somewebsite.com/page.html, the UA can detect that a prerendering has already been created and then display that page *really* quickly. This feature is useful in many scenarios. It's useful for the google search page because they can use the above markup to point to whatever search result they think the user is going to navigate to. It's useful in a news article to point to the next page of the article. It's useful for reddit because it can preload whatever link they think the user is likely to click. However, as the feature stands today, it can't be used by for example the bugzilla search page. After a user visits the bugzilla search page, they almost always visit the search results page. However the exact URL of the search results page vary greatly since it depends on the search parameters that were entered. So the search page couldn't add a link rel=prerender in order to prerender anything, since it would have no idea what URL to stick in there. This despite the fact that whichever search result page URL is loaded, there are a lot of common parts. There's a common header and footer, the same CSS files and JS files need to be loaded. The same styles are applied to largely the same set of elements. Wouldn't it be great if those pieces could be preloaded and prerendered, such that the only thing that had to be loaded and rendered once the user pressed the search button was the actual search results. In this case the prerendered search results page acts as a template page for any search result page that ends up being loaded. Of course, if the user ends up not doing a search at all, then we'll have to drop that prerendered page and instead do a new load from scratch. Just like with any mispredicted link rel=prerender. Similarly, the bugzilla search result page can't currently take advantage of the prerender feature. Even though it's very likely that the user is going to click a link to a bug, and even though all bug pages share large parts of their resources and layout, there is no way for the bugzilla search result page to load and prerender those common parts. Wouldn't it be great if the search result page could ask a generic bug page to be loaded, such that if the user clicks a bug link, we could just load the data that's specific to the clicked bug and insert that data into the generic bug page. I.e. the generic bug page would act as a template page for any bug page. Of course, if the user doesn't find any of the search results interesting, and goes somewhere different than a bug page, then the prerendering was for naught and we will have to do a new load from scratch. I think the solution to these problems consist of two parts: 1. Make it possible for a page that contains a link rel=prerender to initiate a postMessage-based conversation with the prerendered page. 2. Define that the prerendered page is used if the navigation destination URL matches the prerendered page's URL (which can be modified using replaceState), rather than if the URL in the link rel=prerender. Redirects might make this a bit more complicated. This way we can even do such things as tell the prerendered page to start loading search results, using an XHR request, even before the user has actually clicked search. And update those search results any time the user modifies any search parameters. If the user ends up modifying the search parameters those results can simply be thrown away without ever getting used, while still allowing the prerendered search results template page to be used no matter which search ends up being the final one. Similarly the bugzilla serach results page could ask the prerendered bug page to start preloading the relevant bug data as soon as a bug link is hovered. Again, if the user ends up clicking something else, the data can be thrown out and the correct data can be loaded. All of this would be driven by webpage logic. The only part the platform would provide is the prerendering feature and the two additions listed above. / Jonas ___
Re: Intent to implement: Prerendering API
On 2014-08-11, 6:03 PM, Jonas Sicking wrote: Very exited to see this happening. Implementation issues aside, I have two comments: * This is something that we really need on FirefoxOS. I hope that the implementation strategy will work there too? Yes, the majority of the code is going to be shared between desktop/Android (where xul:browser is used for rendering content) and Firefox OS (where mozbrowser iframes are used for rendering content.) * A use-case that we came upon pretty quickly when we were looking at using prerendering in FirefoxOS is that we might not know the exact URL that the user is likely to navigate to, but we have a pretty good guess about what template page it's going to be. Consider for example bugzilla. After the user has done a search query, they are likely to click on one of the bug links. Each bug has a different URL, but all bugs share much of the page UI. It would be really awesome if bugzilla could ask to prerender a URL like https://bugzilla.mozilla.org/show_bug.cgi?justLoadTemplate=true;. Then when the user clicks a bugzilla URL like https://bugzilla.mozilla.org/show_bug.cgi?id=123456;, we would enable webpage logic to somehow force the prerendered page to be used, even though the URLs don't match. One way to do this would be to enable some way for the current page to talk to the prerendered page. The current page could then tell the prerendered page the user just clicked bug 123456, at which point the prerendered page could use replaceState to change its URL to https://bugzilla.mozilla.org/show_bug.cgi?id=123456;, at which point we would see that the URLs matched. Another solution would be to enable the prerendered page to say i'm able to act as a prerender page for any URLs that match pattern https://bugzilla.mozilla.org/show_bug.cgi?id=*;. Would be great if someone could bring up this use case with the prerender editors and make sure it gets covered and that a specced solution is defined. So I've been thinking about this use case. Here are a number of thoughts that I have so far: * The page which asks the UA to prerender the document is responsible for telling the UA which URL patterns the prerendered page should handle. As you note above, you typically want to render a different page (e.g., https://bugzilla.mozilla.org/show_bug.cgi?justLoadTemplate=true) which knows how to handle the dynamic fetching of the resources it needs when it's taken out of prerendering mode. But the controlling page also knows what URLs on that page may be loaded into this prerendered document. So far I've been thinking of an API like this: var prerenderedDoc = new PrerenderedDocument( // url to the document being loaded https://bugzilla.mozilla.org/show_bug.cgi?justLoadTemplate=true;, // url scope for what it can handle https://bugzilla.mozilla.org/show_bug.cgi?id=;); * The two pages need to talk to each other. For that purpose, I think we should add a postMessage API to PrerenderedDocument which will allow the controlling document to either use it for single direction communication, or post a MessagePort to the prerendered page for bidirectional communication. * The prerendered page needs to know when it's taken out of prerendering mode. This is already possible through the visibilitychange event. However the page also needs to know what URL ended up being loaded in the controlling document. Because the prerendered page may get activated as a result of a user initiated navigation, we cannot rely on the controlling document having an opportunity to notify the prerendered page. One option would be to extend the event object for visibilitychange with a URL argument that is the URL that ends up being loaded inside the page. * The target page's URL actually needs to change in order to avoid surprises as you navigate pages. I'm going back and forth between expecting the prerendered page to call replaceState correctly, or specifying that replaceState will get called after the visibilitychange event gets dispatched. I haven't yet made up my mind on which approach is the better one... * Once we have the PrerenderedDocument interface, we can extend it with a number of useful events, such as load which tells you when the prerendered document's load event has been dispatched, and prerenderabort to notify the controlling document if prerendering was aborted (as a result of a call to let's say window.alert). * The existing prerendering implementation in IE and Chrome is opportunistic, i.e., the UA will be able to ignore the link rel=prerender based on a number of heuristics (for example I think Chrome prerenders at most one document at a time.) I think this is a nice model to make sure that the UA has the option of avoiding prerendering for memory consumption/responsive reasons, but I am not yet sure if we need to introduce this notion on PrerenderedDocument... * In order to simplify the implementation, there will
Re: Telemetry alerts for histograms
On Thursday, August 7, 2014 9:19:09 AM UTC+1, Gian-Carlo Pascutto wrote: Does this filter on any cpp_guards? No, it doesn't. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Expiration versions for Telemetry probes.
On 12 Aug 2014, at 15:33, Benjamin Smedberg benja...@smedbergs.us wrote: Is it possible to email the people who added/reviewed the probe and let them know Probe X which you added will be set to expire unless you take action? I expect that generic announcements to dev.platform won't get the attention of the right set of people in all cases. Just using ‘hg blame’ might not be sufficient, some authors are gone and others are not the rightful owners of those probes, it might still be worth the shot though. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Telemetry alerts for histograms
From now on all alerts will be sent by default also to telemetry-ale...@mozilla.com. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Getting rid of already_AddRefed?
Just reading bug 1052477, and I'm wondering about what are intentions are for already_AddRefed. In that bug it's proposed to change the return type of NS_NewAtom from already_AddRefed to nsCOMPtr. I don't think that actually saves any addref/release pairs if done properly, since you'd typically .forget() into the return value anyway. But it does make it slightly safer at callsites, because the compiler will guarantee that the return value is always released instead of us relying on every already_AddRefed being saved into a nsCOMPtr. But now that nsCOMPtr/nsRefPtr support proper move constructors, is there any reason for already_AddRefed to exist at all in our codebase? Could we replace every already_AddRefed return value with a nsCOMPtr? --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On Tue, Aug 12, 2014 at 5:59 PM, Benjamin Smedberg benja...@smedbergs.us wrote: Just reading bug 1052477, and I'm wondering about what are intentions are for already_AddRefed. In that bug it's proposed to change the return type of NS_NewAtom from already_AddRefed to nsCOMPtr. I don't think that actually saves any addref/release pairs if done properly, since you'd typically .forget() into the return value anyway. But it does make it slightly safer at callsites, because the compiler will guarantee that the return value is always released instead of us relying on every already_AddRefed being saved into a nsCOMPtr. Correct, it doesn't save addref/release pairs. Some advantages of converting already_AddRefed to just returning raw nsCOMPtr/nsRefPtr are: 1) You can use the return value directly without assigning it to an nsCOMPtr/nsRefPtr. For instance, pass it to a function that wants a raw pointer, or compare it against a different value. 2) It's easier to use, as evidenced by the patches in bugs 1015114 and 1052477. No .forget() is needed, a raw pointer can be returned directly, even things like do_QueryInterface can be returned directly without a temporary nsCOMPtr (since the return type creates the temporary for you). You can just return whatever you like and the compiler will figure out if an addref is needed. There's a noticeable decrease in LoC when converting to use it. 3) We can get rid of a class, which simplifies the codebase. 4) If the callee already holds a strong reference in a local variable, it can just return that reference instead of a raw pointer. This saves an addref/release if the caller puts the result in an nsCOMPtr. Currently you could do this by returning an already_AddRefed, but that's annoying because of (1) above, so people don't always do so. 5) Callees that don't care about the risk of an extra addref/release can just return nsCOMPtr instead of raw pointers across the board. This avoids a potentially sec-critical use-after-free vulnerability that can occur if a function returns a raw pointer, then the caller passes it to a function that takes a raw pointer, then the second function does something to release it. This is very easy to do by mistake, because the bug just looks like SomeFunction(GetThing());. Again, in theory you could already use already_AddRefed for this, but this change makes it painless. 6) In theory, the compiler can use RVO to elide the construction of the temporary altogether, although I'm not at all sure this is useful in practice. IMO, already_AddRefed is exactly the sort of use-case move constructors are meant to solve, and it's no longer needed once we have working move constructors for nsCOMPtr/nsRefPtr. I was planning to write up an informational post once bug 1015114 landed explaining the benefits and telling people how to convert everything. But now that nsCOMPtr/nsRefPtr support proper move constructors, is there any reason for already_AddRefed to exist at all in our codebase? Could we replace every already_AddRefed return value with a nsCOMPtr? I've put some thought into this. Simple returns of already_AddRefed can definitely be converted without much effort, and it reduces LoC too. A bit more thought will be needed to get rid of the class entirely, I think. For one thing, we'd need a replacement for dont_AddRef(). Also, the move constructors themselves will need to be rewritten, because they use .forget() (a few friend declarations should do it). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On Tuesday 2014-08-12 10:59 -0400, Benjamin Smedberg wrote: Just reading bug 1052477, and I'm wondering about what are intentions are for already_AddRefed. In that bug it's proposed to change the return type of NS_NewAtom from already_AddRefed to nsCOMPtr. I don't think that actually saves any addref/release pairs if done properly, since you'd typically .forget() into the return value anyway. But it does make it slightly safer at callsites, because the compiler will guarantee that the return value is always released instead of us relying on every already_AddRefed being saved into a nsCOMPtr. Bug 967364 did already add assertions to guarantee this. But now that nsCOMPtr/nsRefPtr support proper move constructors, is there any reason for already_AddRefed to exist at all in our codebase? Could we replace every already_AddRefed return value with a nsCOMPtr? Two thoughts: (1) I think it introduces a somewhat major coding style risk, in that it makes it possible to accidentally assign the value of a function that returns a reference into a raw pointer, which isn't possible with already_AddRefed. In other words, today, you can write: T* t = GetT() and know that as long as the code is following conventions correctly and using already_AddRefed when a reference is returned, this won't compile if an nsCOMPtr is required. If we change to returning nsCOMPtr instead of returning already_AddRefed, this won't be the case, and the code will end up having a dangling pointer to a potentially-deleted object. (2) If we agree it's a good idea from a coding style perspective, it's probably worth having a look that the generated code is equally efficient, given how widely used it is in our codebase. Because of (1), I probably lean against this change (and against bug 1052477), unless I'm missing something that makes (1) not be true. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
As far as I know, the only downside in replacing already_AddRefed by nsCOMPtr would be to incur more useless calls to AddRef and Release. In the case of threadsafe i.e. atomic refcounting, these use atomic instructions, which might be expensive enough on certain ARM CPUs that this might matter. So if you're interested, you could take a low-end ARM CPU that we care about and see if replacing already_AddRefed by nsCOMPtr causes any measurable performance regression. Benoit 2014-08-12 10:59 GMT-04:00 Benjamin Smedberg benja...@smedbergs.us: Just reading bug 1052477, and I'm wondering about what are intentions are for already_AddRefed. In that bug it's proposed to change the return type of NS_NewAtom from already_AddRefed to nsCOMPtr. I don't think that actually saves any addref/release pairs if done properly, since you'd typically .forget() into the return value anyway. But it does make it slightly safer at callsites, because the compiler will guarantee that the return value is always released instead of us relying on every already_AddRefed being saved into a nsCOMPtr. But now that nsCOMPtr/nsRefPtr support proper move constructors, is there any reason for already_AddRefed to exist at all in our codebase? Could we replace every already_AddRefed return value with a nsCOMPtr? --BDS ___ 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.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On Tue, Aug 12, 2014 at 6:14 PM, L. David Baron dba...@dbaron.org wrote: Bug 967364 did already add assertions to guarantee this. Yes, if I'm not mistaken, already_AddRefed these days is quite safe. Two thoughts: (1) I think it introduces a somewhat major coding style risk, in that it makes it possible to accidentally assign the value of a function that returns a reference into a raw pointer, which isn't possible with already_AddRefed. In other words, today, you can write: T* t = GetT() and know that as long as the code is following conventions correctly and using already_AddRefed when a reference is returned, this won't compile if an nsCOMPtr is required. If we change to returning nsCOMPtr instead of returning already_AddRefed, this won't be the case, and the code will end up having a dangling pointer to a potentially-deleted object. For refcounted types, isn't a raw pointer in a local variable a red flag to reviewers to begin with? If GetT() returns a raw pointer today, like nsINode::GetFirstChild() or something, storing the result in a raw pointer is a potential use-after-free, and that definitely has happened already. Reviewers need to make sure that refcounted types aren't ever kept in raw pointers in local variables, unless perhaps it's very clear from the code that nothing can possibly call Release() (although it still makes me nervous). (2) If we agree it's a good idea from a coding style perspective, it's probably worth having a look that the generated code is equally efficient, given how widely used it is in our codebase. The implementation includes a simple test-case that verifies that there are no unexpected addrefs when relying on move constructors. Beyond that (actual assembly instructions) I don't know. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On Tue, Aug 12, 2014 at 6:16 PM, Benoit Jacob jacob.benoi...@gmail.com wrote: As far as I know, the only downside in replacing already_AddRefed by nsCOMPtr would be to incur more useless calls to AddRef and Release. In the case of threadsafe i.e. atomic refcounting, these use atomic instructions, which might be expensive enough on certain ARM CPUs that this might matter. So if you're interested, you could take a low-end ARM CPU that we care about and see if replacing already_AddRefed by nsCOMPtr causes any measurable performance regression. Bug 1015114 removes those extra addrefs using C++11 move semantics, so assuming that lands, it's not an issue. (IIRC, Boris has previously said that excessive addref/release is a real performance problem and needs to be avoided.) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On Tuesday 2014-08-12 18:15 +0300, Aryeh Gregor wrote: 1) You can use the return value directly without assigning it to an nsCOMPtr/nsRefPtr. For instance, pass it to a function that wants a raw pointer, or compare it against a different value. I consider this a disadvantage, as I pointed out in my previous post. It removes one of the major safety features of nsCOMPtr. 4) If the callee already holds a strong reference in a local variable, it can just return that reference instead of a raw pointer. This saves an addref/release if the caller puts the result in an nsCOMPtr. Currently you could do this by returning an already_AddRefed, but that's annoying because of (1) above, so people don't always do so. How does this save an addref/release? Is the compiler allowed to use move constructors rather than copy constructors when constructing the return value of a function from a local variable in that function? -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On Tuesday 2014-08-12 18:22 +0300, Aryeh Gregor wrote: On Tue, Aug 12, 2014 at 6:14 PM, L. David Baron dba...@dbaron.org wrote: Two thoughts: (1) I think it introduces a somewhat major coding style risk, in that it makes it possible to accidentally assign the value of a function that returns a reference into a raw pointer, which isn't possible with already_AddRefed. In other words, today, you can write: T* t = GetT() and know that as long as the code is following conventions correctly and using already_AddRefed when a reference is returned, this won't compile if an nsCOMPtr is required. If we change to returning nsCOMPtr instead of returning already_AddRefed, this won't be the case, and the code will end up having a dangling pointer to a potentially-deleted object. For refcounted types, isn't a raw pointer in a local variable a red flag to reviewers to begin with? If GetT() returns a raw pointer today, like nsINode::GetFirstChild() or something, storing the result in a raw pointer is a potential use-after-free, and that definitely has happened already. Reviewers need to make sure that refcounted types aren't ever kept in raw pointers in local variables, unless perhaps it's very clear from the code that nothing can possibly call Release() (although it still makes me nervous). This is done very commonly when we know some other data structure (or the lifetime of |this|) owns the object, and will continue to across the lifetime of the function. For example, if I open content/base/src/Element.cpp, I see this pattern 5 times in the first 325 lines of the file. (Three nsIDocument*, one nsIContent*, one nsIPresShell*.) -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: How to building the xpt file from multiple idl files
On 8/12/14 12:08 AM, Yonggang Luo wrote: Now I am trying to building a xpcom components, but it have multiple .idl file to compiled into a single xpt component, how to do that? Here is the code the build system uses for XPIDLs: http://dxr.mozilla.org/mozilla-central/source/python/mozbuild/mozbuild/action/xpidl-process.py The low-level code for linking XPTs (including the xpt_link function) is in xpt.py: http://dxr.mozilla.org/mozilla-central/source/xpcom/typelib/xpt/tools/xpt.py ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
This templated prerendereing sounds like a complicated API. Is there any advantage of this over what is possible today with a single page application using history.pushState? Den 12-08-2014 kl. 00:03 skrev Jonas Sicking: Very exited to see this happening. Implementation issues aside, I have two comments: * This is something that we really need on FirefoxOS. I hope that the implementation strategy will work there too? * A use-case that we came upon pretty quickly when we were looking at using prerendering in FirefoxOS is that we might not know the exact URL that the user is likely to navigate to, but we have a pretty good guess about what template page it's going to be. Consider for example bugzilla. After the user has done a search query, they are likely to click on one of the bug links. Each bug has a different URL, but all bugs share much of the page UI. It would be really awesome if bugzilla could ask to prerender a URL like https://bugzilla.mozilla.org/show_bug.cgi?justLoadTemplate=true;. Then when the user clicks a bugzilla URL like https://bugzilla.mozilla.org/show_bug.cgi?id=123456;, we would enable webpage logic to somehow force the prerendered page to be used, even though the URLs don't match. One way to do this would be to enable some way for the current page to talk to the prerendered page. The current page could then tell the prerendered page the user just clicked bug 123456, at which point the prerendered page could use replaceState to change its URL to https://bugzilla.mozilla.org/show_bug.cgi?id=123456;, at which point we would see that the URLs matched. Another solution would be to enable the prerendered page to say i'm able to act as a prerender page for any URLs that match pattern https://bugzilla.mozilla.org/show_bug.cgi?id=*;. Would be great if someone could bring up this use case with the prerender editors and make sure it gets covered and that a specced solution is defined. / Jonas On Mon, Aug 11, 2014 at 11:47 AM, Roshan Vidyashankar roshan...@gmail.com wrote: Summary: The Prerendering API allows the rendering engine to start loading and rendering a web page without any visible UI until the page needs to be displayed to the user. It's a gecko API that consumers can choose to use. For now, we're not talking about exposing this to web pages yet, or even using it in any of our products, we're just working on the implementation. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=730101 Link to standard: At some point we are going to be contributing to a spec but there are a number of unknown things which we're hoping to find out through the implementation - like what APIs need to be blacklisted in prerendering (audio, window.open etc). Chrome and IE have shipped their own implementations of prerendering. Platform coverage: All Estimated or target release: Unknown Preference behind which this will be implemented: dom.prerendering.enabled Implementation Plan There are two big parts to the implementation. 1. How do we handle the prerendering itself in a way that works both for desktop and b2g For this, we're thinking about adding a boolean flag to nsDocShell which together with mIsActive will constitute a tri-state: active, inactive and prerendered. As far as the outside code is concerned, prerendered docshells are treated as inactive ones for the most part. This means that we'd basically need to not modify nsDocShell::GetIsActive, and audit all of its callers and find the potential consumers who would want to treat prerendered and inactive differently (I don't expect there to be any such consumers actually but we'll see). We'd use the prerendered state to reflect the correct status reflected through the page visibility API. The prerendered docshell masquerading as inactive will also mean that it won't get a rendering on b2g for example because that's how we hide mozbrowser iframes there. In order for gaia and XUL based consumers to be able to control the prerendering, I think we'd need to use the nsIFrameLoader swapping facilities that we currently have for the xul:browser swapDocShells method and extend those to make them usable with the mozbrowser frameLoader as well. That way we can expose the prerendering API through both mozbrowser and xul:browser while sharing hopefully most of the code between these different consumers, and we'd get the ability to swap the frame loaders when we need to actually render a prerendered document. 2. What do we do with the APIs that have undesirable side-effects in prerendered pages (audio, window.open etc). We first need to decide what we're going to do when a page calls into an API which has undesired side effects (and that is a blurry line -- I hope as part of this we come up with an actual list of what those actions are!). Chrome basically aborts the execution of scripts on the page and throws out the prerendered content as soon as any such APIs are called. IE's documentation claims that they
Re: Getting rid of already_AddRefed?
On Tue, Aug 12, 2014 at 6:25 PM, L. David Baron dba...@dbaron.org wrote:
On Tuesday 2014-08-12 18:15 +0300, Aryeh Gregor wrote:
1) You can use the return value directly without assigning it to an 4) If
the callee already holds a strong reference in a local variable,
it can just return that reference instead of a raw pointer. This
saves an addref/release if the caller puts the result in an nsCOMPtr.
Currently you could do this by returning an already_AddRefed, but
that's annoying because of (1) above, so people don't always do so.
How does this save an addref/release? Is the compiler allowed to
use move constructors rather than copy constructors when
constructing the return value of a function from a local variable in
that function?
The compiler is required to use the move constructor (if one exists)
instead of the copy constructor when constructing the return value of
a function, and also when initializing an object from the return value
of a function, or assigning the return value of a function. So if you
have
Foo GetFoo() { Foo f(1, 2, 7); /* do lots of stuff to f */ return f; }
void MyFunction() { Foo f = GetFoo(); }
the copy constructor of Foo will not get called anywhere. This is why
with the patch, you can just return an nsCOMPtr without the forget()
and it won't cause any extra addrefs.
On Tue, Aug 12, 2014 at 6:29 PM, L. David Baron dba...@dbaron.org wrote:
This is done very commonly when we know some other data structure
(or the lifetime of |this|) owns the object, and will continue to
across the lifetime of the function.
For example, if I open content/base/src/Element.cpp, I see this
pattern 5 times in the first 325 lines of the file. (Three
nsIDocument*, one nsIContent*, one nsIPresShell*.)
If you know something else is holding a strong reference, why is it a
problem to assign the result of a function that returns
already_AddRefedT to a local variable of type T*? If the local
variable's usage is otherwise legitimate, that assignment is perfectly
safe and there's no reason for any compiler errors.
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On Tuesday 2014-08-12 18:40 +0300, Aryeh Gregor wrote: On Tue, Aug 12, 2014 at 6:29 PM, L. David Baron dba...@dbaron.org wrote: This is done very commonly when we know some other data structure (or the lifetime of |this|) owns the object, and will continue to across the lifetime of the function. For example, if I open content/base/src/Element.cpp, I see this pattern 5 times in the first 325 lines of the file. (Three nsIDocument*, one nsIContent*, one nsIPresShell*.) If you know something else is holding a strong reference, why is it a problem to assign the result of a function that returns already_AddRefedT to a local variable of type T*? If the local variable's usage is otherwise legitimate, that assignment is perfectly safe and there's no reason for any compiler errors. In these cases we document that it's likely safe for callers to do this by having those getters return raw pointers. Getters that require reference-counting return already_AddRefed. Thus the designer of the API makes a choice about whether the caller is required to reference-count the result. Our initial switch to use getters with raw pointers rather than reference-counting getters (as part of deCOMtamination) was a substantial performance win (probably at least 10% on general across-the-board performance metrics). On the other hand, getters that might return a new object must return already_AddRefedT to ensure the caller takes ownership of that reference. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) signature.asc Description: Digital signature ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
hghooks repository merged into version-control-tools
The server-side Mercurial hooks living in https://hg.mozilla.org/hgcustom/hghooks/ have been migrated to the hghooks/ directory of https://hg.mozilla.org/hgcustom/version-control-tools/. This change will enable: * Code/hook sharing between client and server (version-control-tools is already installed as part of mach mercurial-setup) * A more unified development and testing story for everything Mercurial at Mozilla. This will help us move faster. As part of the push, a number of old bugs were updated with commit URLs inside the version-control-tools repository. This is merely for tracking purposes. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
PSA: Windows builds will default to XPCOM_DEBUG_BREAK=warn
I'm about to land bug 1046222, which changes the default behaviour of XPCOM_DEBUG_BREAK on Windows to warn, instead of trap. If run under the debugger, trap will cause the debugger to stop as if it hit a breakpoint in debug builds. This would be useful behaviour if we didn't still have a whole ton of assertions, but as it is it's an unnecessary papercut for windows developers, or people doing testing/debugging on windows -- some of whom may not know that they should set XPCOM_DEBUG_BREAK in the debugger, and are instead clicking continue through tons of assertions until they get to what they care about! The change will bring Windows assertion behaviour in line with other platforms. - Vlad ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On Tuesday, August 12, 2014 11:22:05 AM UTC-4, Aryeh Gregor wrote: For refcounted types, isn't a raw pointer in a local variable a red flag to reviewers to begin with? If GetT() returns a raw pointer today, like nsINode::GetFirstChild() or something, storing the result in a raw pointer is a potential use-after-free, and that definitely has happened already. Reviewers need to make sure that refcounted types aren't ever kept in raw pointers in local variables, unless perhaps it's very clear from the code that nothing can possibly call Release() (although it still makes me nervous). Putting the burden on reviewers when something can be automatically checked doesn't seem like a good idea -- it requires reviewers to know that GetT() *does* return a refcounted type, for example. As dbaron pointed out, there are cases where we do actually return and keep things around as bare pointers. It's unfortunate that we can't create a nsCOMPtr that will disallow assignment to a bare pointer without an explicit .get(), but will still allow conversion to a bare pointer for arg passing purposes. (Or can we? I admit my C++-fu is not that strong in this area...) It would definitely be nice to get rid of already_AddRefed (not least because the spelling of Refed always grates when I see it :). - Vlad ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
On 2014-08-12, 11:39 AM, Jesper Kristensen wrote: This templated prerendereing sounds like a complicated API. Is there any advantage of this over what is possible today with a single page application using history.pushState? Yes, I think so. The idea of single page applications is nice, but it doesn't eliminate the need for this API because: 1) That means rewriting large existing applications, and 2) Parts of this idea (for example for providing a way to communicate with the prerendered content) would still be needed even fr single page apps. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On 8/12/2014 9:59 AM, Benjamin Smedberg wrote: Just reading bug 1052477, and I'm wondering about what are intentions are for already_AddRefed. In that bug it's proposed to change the return type of NS_NewAtom from already_AddRefed to nsCOMPtr. I don't think that actually saves any addref/release pairs if done properly, since you'd typically .forget() into the return value anyway. But it does make it slightly safer at callsites, because the compiler will guarantee that the return value is always released instead of us relying on every already_AddRefed being saved into a nsCOMPtr. But now that nsCOMPtr/nsRefPtr support proper move constructors, is there any reason for already_AddRefed to exist at all in our codebase? Could we replace every already_AddRefed return value with a nsCOMPtr? The rationale for why we still had it was that: nsIFoo *foobar = ReturnsACOMPtr(); silently leaks. I've pointed out before that we could fix this by adding a nsCOMPtrT::operator T*() = delete; operator, but that's a gcc 4.8.1/msvc 2013 November CTP minimum requirement. -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On Tue, Aug 12, 2014 at 6:46 PM, L. David Baron dba...@dbaron.org wrote: In these cases we document that it's likely safe for callers to do this by having those getters return raw pointers. Getters that require reference-counting return already_AddRefed. Thus the designer of the API makes a choice about whether the caller is required to reference-count the result. How is this code safe? nsIContent* child = node-GetFirstChild(); // Do some stuff with child It compiles fine, but if any subsequent code causes the child to be removed from its parent, it could get freed. In particular, this can happen if anything indirectly triggers mutation observers, and I distinctly remember a sec-critical bug caused by exactly that. Reviewers already have to carefully scrutinize any use of such a local variable. Does returning already_AddRefed really make such a difference to the degree of review required? Put it this way -- if we had rvalue references available when already_AddRefed was invented, would anyone have suggested making a whole new class that's significantly more cumbersome to use just to avoid making an inherently dangerous usage pattern (raw pointers to refcounted variables) a little less dangerous? Or is this just status quo bias? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On 8/12/2014 12:28 PM, Joshua Cranmer wrote: But now that nsCOMPtr/nsRefPtr support proper move constructors, is there any reason for already_AddRefed to exist at all in our codebase? Could we replace every already_AddRefed return value with a nsCOMPtr? The rationale for why we still had it was that: nsIFoo *foobar = ReturnsACOMPtr(); silently leaks. Really? I thought that in this case there would be no leak because the (temporary-returned) nsCOMPtr destructor would properly free the object. The problem is that `foobar` potentially points to an object which has already been released. --BDS ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On Tue, Aug 12, 2014 at 9:35 AM, Aryeh Gregor a...@aryeh.name wrote: On Tue, Aug 12, 2014 at 6:46 PM, L. David Baron dba...@dbaron.org wrote: In these cases we document that it's likely safe for callers to do this by having those getters return raw pointers. Getters that require reference-counting return already_AddRefed. Thus the designer of the API makes a choice about whether the caller is required to reference-count the result. How is this code safe? nsIContent* child = node-GetFirstChild(); // Do some stuff with child It compiles fine, but if any subsequent code causes the child to be removed from its parent, it could get freed. In particular, this can happen if anything indirectly triggers mutation observers, and I distinctly remember a sec-critical bug caused by exactly that. Reviewers already have to carefully scrutinize any use of such a local variable. Does returning already_AddRefed really make such a difference to the degree of review required? Put it this way -- if we had rvalue references available when already_AddRefed was invented, would anyone have suggested making a whole new class that's significantly more cumbersome to use just to avoid making an inherently dangerous usage pattern (raw pointers to refcounted variables) a little less dangerous? Or is this just status quo bias? ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform If that function returns already_AddRefed it forces the caller to root the return value which means you do not have to review as closely for use-after-free issues. We use raw pointers where we can because reference counting can be expensive, especially in tight loops. smaug can share some history here. - Kyle ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On Tue, Aug 12, 2014 at 7:12 PM, Vladimir Vukicevic vladi...@pobox.com wrote: It's unfortunate that we can't create a nsCOMPtr that will disallow assignment to a bare pointer without an explicit .get(), but will still allow conversion to a bare pointer for arg passing purposes. (Or can we? I admit my C++-fu is not that strong in this area...) We could do this if we instituted a new type and mandated that type be used instead of raw pointers for local variables. Call it RawPointerT or something. Using raw pointers like this is still inherently dangerous for nontrivial code -- including code that's subsequently changed to be nontrivial -- but if this bit of extra safety is important, it would be possible to get it this way. Of course, then review would have to check that RawPointerT is used instead of T*, unless we can get static analysis to do it. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On Tue, Aug 12, 2014 at 7:37 PM, Benjamin Smedberg benja...@smedbergs.us wrote: On 8/12/2014 12:28 PM, Joshua Cranmer wrote: The rationale for why we still had it was that: nsIFoo *foobar = ReturnsACOMPtr(); silently leaks. Really? I thought that in this case there would be no leak because the (temporary-returned) nsCOMPtr destructor would properly free the object. The problem is that `foobar` potentially points to an object which has already been released. Correct. I assume that's what he meant. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On 8/12/2014 11:12 AM, Vladimir Vukicevic wrote: It's unfortunate that we can't create a nsCOMPtr that will disallow assignment to a bare pointer without an explicit .get(), but will still allow conversion to a bare pointer for arg passing purposes. (Or can we? I admit my C++-fu is not that strong in this area...) It would definitely be nice to get rid of already_AddRefed (not least because the spelling of Refed always grates when I see it :). The use of a method like operator T*() = delete; causes the conversion to fail if the nsCOMPtr is an rvalue (most temporaries). It still allows T *foo = localVariable; (there's no easy way around that). -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On 8/12/2014 11:40 AM, Aryeh Gregor wrote: On Tue, Aug 12, 2014 at 7:37 PM, Benjamin Smedberg benja...@smedbergs.us wrote: On 8/12/2014 12:28 PM, Joshua Cranmer wrote: The rationale for why we still had it was that: nsIFoo *foobar = ReturnsACOMPtr(); silently leaks. Really? I thought that in this case there would be no leak because the (temporary-returned) nsCOMPtr destructor would properly free the object. The problem is that `foobar` potentially points to an object which has already been released. Correct. I assume that's what he meant. Er, yes. I remembered there was a problem, I forgot the actual problem. :-[ -- Joshua Cranmer Thunderbird and DXR developer Source code archæologist ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Upcoming changes to Mac package layout, signing
Hi all, Apple recently announced changes to how OS X applications must be packaged and signed (https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG205) in order for them to function correctly on OS X 10.9.5 and 10.10. The tl;dr version of this is only mach-O binaries may live in .app/Contents/MacOS, and signing must be done on 10.9 or later. Without any changes, future versions of Firefox will cease to function out-of-the-box on OS X 10.9.5 and 10.10. We do not have a release date for either of these OS X versions yet. Changes required: * Move all non-mach-O files out of .app/Contents/MacOS. Most of these will move to .app/Contents/Resources, but files that could legitimately change at runtime (eg: everything in defaults/) will move to .app/MozResources (which can be modified without breaking the signature): https://bugzilla.mozilla.org/showdependencytree.cgi?id=1046906hide_resolved=1. This work is in progress, but no patches are ready yet. * Add new features to the client side update code to allow partner repacks to continue to work. (https://bugzilla.mozilla.org/show_bug.cgi?id=1048921) * Create and use 10.9 signing servers for these new-style apps. We still need to use our existing 10.6 signing servers for any builds without these changes. (https://bugzilla.mozilla.org/show_bug.cgi?id=1046749 and https://bugzilla.mozilla.org/show_bug.cgi?id=1049595) * Update signing server code to support new v2 signatures. Timeline: We are intending to ship the required changes with Gecko 34, which ships on November 25th, 2014. The changes required are very invasive, and we don't feel that they can be safely backported to any earlier version quickly enough without major risk of regressions. We are still looking at whether or not we'll backport to ESR 31. To this end, we've asked that Apple whitelist Firefox and Thunderbird versions that will not have the necessary changes in them. We're still working with them to confirm whether or not this can happen. This has been cross posted a few places - please send all follow-ups to the mozilla.dev.platform newsgroup. - Ben ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On 2014-08-12, 12:41 PM, Joshua Cranmer wrote: On 8/12/2014 11:12 AM, Vladimir Vukicevic wrote: It's unfortunate that we can't create a nsCOMPtr that will disallow assignment to a bare pointer without an explicit .get(), but will still allow conversion to a bare pointer for arg passing purposes. (Or can we? I admit my C++-fu is not that strong in this area...) It would definitely be nice to get rid of already_AddRefed (not least because the spelling of Refed always grates when I see it :). The use of a method like operator T*() = delete; causes the conversion to fail if the nsCOMPtr is an rvalue (most temporaries). It still allows T *foo = localVariable; (there's no easy way around that). It could also be solved with making operator T*() explicit, but neither of these options are something that we can use in our code base today. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Evaluating adding JOSE and JWS to mozilla-central
The possibility of using JavaScript Object Signing and Encryption (JOSE) - specifically the verification part of the JSON Web Signature (JWS) component - came up as part of planning a JavaScript-based feature I'm working on. We don't appear to have an implementation in mozilla-central yet. I'm trying to weigh whether to spend extra effort to add JWS support to the tree or to try to shoehorn existing signing solutions to fit my need. First, does anyone know of an existing browser-side implementation of JWS used by Mozilla? I know we have Python in Marketplace doing signing. We /may/ have parts of Firefox OS doing client-side signing verification. My requirement is for chrome-privileged JS to do X509 signing verification. I'll settle for an XPIDL interface to NSS. Second, would having JWS support in m-c be beneficial to anyone else? If this isn't easy to add, I'll probably be lazy and leverage an existing solution. Convince me it is worth doing. Gregory ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On 2014-08-12, 11:25 AM, L. David Baron wrote: On Tuesday 2014-08-12 18:15 +0300, Aryeh Gregor wrote: 1) You can use the return value directly without assigning it to an nsCOMPtr/nsRefPtr. For instance, pass it to a function that wants a raw pointer, or compare it against a different value. I consider this a disadvantage, as I pointed out in my previous post. It removes one of the major safety features of nsCOMPtr. I am also strongly against the removal of already_AddRefed because of this. I am not convinced that we can rely on reviewers to enforce this. Cheers, Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Evaluating adding JOSE and JWS to mozilla-central
+rbarnes is responsible for adding WebCrypto, which includes some JOSE features. On 2014-08-12, at 10:22, Gregory Szorc g...@mozilla.com wrote: The possibility of using JavaScript Object Signing and Encryption (JOSE) - specifically the verification part of the JSON Web Signature (JWS) component - came up as part of planning a JavaScript-based feature I'm working on. We don't appear to have an implementation in mozilla-central yet. I'm trying to weigh whether to spend extra effort to add JWS support to the tree or to try to shoehorn existing signing solutions to fit my need. First, does anyone know of an existing browser-side implementation of JWS used by Mozilla? I know we have Python in Marketplace doing signing. We /may/ have parts of Firefox OS doing client-side signing verification. My requirement is for chrome-privileged JS to do X509 signing verification. I'll settle for an XPIDL interface to NSS. Second, would having JWS support in m-c be beneficial to anyone else? If this isn't easy to add, I'll probably be lazy and leverage an existing solution. Convince me it is worth doing. Gregory ___ 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.mozilla.org/listinfo/dev-platform
Re: Evaluating adding JOSE and JWS to mozilla-central
On Tuesday, August 12, 2014 1:22:28 PM UTC-4, Gregory Szorc wrote: The possibility of using JavaScript Object Signing and Encryption (JOSE) - specifically the verification part of the JSON Web Signature (JWS) component - came up as part of planning a JavaScript-based feature I'm working on. We don't appear to have an implementation in mozilla-central yet. I'm trying to weigh whether to spend extra effort to add JWS support to the tree or to try to shoehorn existing signing solutions to fit my need. First, does anyone know of an existing browser-side implementation of JWS used by Mozilla? I know we have Python in Marketplace doing signing. We /may/ have parts of Firefox OS doing client-side signing verification. My requirement is for chrome-privileged JS to do X509 signing verification. I'll settle for an XPIDL interface to NSS. Second, would having JWS support in m-c be beneficial to anyone else? If this isn't easy to add, I'll probably be lazy and leverage an existing solution. Convince me it is worth doing. Gregory Once you have the right crypto, the JWS bits should be easy to do in JS. (X.509 only slightly harder, due to DER parsing.) WebCrypto *should* be accessible from privileged JS. If you've got a window object, ask for window.crypto.subtle. --Richard ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
On Tuesday, August 12, 2014 8:39:11 AM UTC-7, Jesper Kristensen wrote: This templated prerendereing sounds like a complicated API. Is there any advantage of this over what is possible today with a single page application using history.pushState? I'm still trying to wrap my head around the use case, but I'm with you on this so far... In order to support the proposed behavior, you would need to: (1) implement an endpoint that returns a base template page (2) implement page logic to receive the message, fetch right data, and render it If you have (1) and (2) implemented, you've effectively implemented the single-page app model. It seems like there are two cases to consider here: (a) You're on a page with the same base template as destination (b) You're navigating to a page with a different base template For (a), you're best off reusing the current context (it's already rendered, after all), and issuing a fetch for updated content and rendering it in place - with pushState, etc. Whereas for (b) you can also do it in place by prefetching the template and then issuing a data request for relevant data once you know the exact URL... Which, of course, is exactly how single-page apps work today. In short, seems like this is inventing a derivative single-page app model for building pages/apps, and that makes me wonder because it doesn't seem to make it any easier. Everything described here can be achieved with current tools, but perhaps could be made better with some smart(er) prefetch/prerender strategies? For example, prerender should not be limited to HTML: https://igrigorik.github.io/resource-hints/#prerender In your single-page app, you should be able to inject multiple prerender hints for images, CSS, JS, and let the UA fetch and process those ahead of time. Then, when the user triggers the action, just inject them into the doc and update the UI as necessary. ig ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
An alternative solution to templates for this use case is the following: 1) In the prerendered page's html, group preloaded resources (LINK rel=subresource currently) into base and extended hints. This can be accomplished by a new LINK attribute, for example. 2) The prerenderer can then fetch the html of the page and then only pre-download the subresources in the base group. Given the above, the base group would include subresources associated with all bugs in bugzilla and so only these resources would be included in the prerender. Peter On Tuesday, August 12, 2014 4:04:50 PM UTC-4, Ilya Grigorik wrote: On Tuesday, August 12, 2014 8:39:11 AM UTC-7, Jesper Kristensen wrote: This templated prerendereing sounds like a complicated API. Is there any advantage of this over what is possible today with a single page application using history.pushState? I'm still trying to wrap my head around the use case, but I'm with you on this so far... In order to support the proposed behavior, you would need to: (1) implement an endpoint that returns a base template page (2) implement page logic to receive the message, fetch right data, and render it If you have (1) and (2) implemented, you've effectively implemented the single-page app model. It seems like there are two cases to consider here: (a) You're on a page with the same base template as destination (b) You're navigating to a page with a different base template For (a), you're best off reusing the current context (it's already rendered, after all), and issuing a fetch for updated content and rendering it in place - with pushState, etc. Whereas for (b) you can also do it in place by prefetching the template and then issuing a data request for relevant data once you know the exact URL... Which, of course, is exactly how single-page apps work today. In short, seems like this is inventing a derivative single-page app model for building pages/apps, and that makes me wonder because it doesn't seem to make it any easier. Everything described here can be achieved with current tools, but perhaps could be made better with some smart(er) prefetch/prerender strategies? For example, prerender should not be limited to HTML: https://igrigorik.github.io/resource-hints/#prerender In your single-page app, you should be able to inject multiple prerender hints for images, CSS, JS, and let the UA fetch and process those ahead of time. Then, when the user triggers the action, just inject them into the doc and update the UI as necessary. ig ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
On Tue, Aug 12, 2014 at 1:04 PM, Ilya Grigorik igrigo...@gmail.com wrote: I'm still trying to wrap my head around the use case, but I'm with you on this so far... [snip] It seems like there are two cases to consider here: (a) You're on a page with the same base template as destination (b) You're navigating to a page with a different base template Agreed. For (a), you're best off reusing the current context (it's already rendered, after all), and issuing a fetch for updated content and rendering it in place - with pushState, etc. Yup. Whereas for (b) you can also do it in place by prefetching the template and then issuing a data request for relevant data once you know the exact URL... Which, of course, is exactly how single-page apps work today. I don't understand what you are saying here. The point of (b) is that the different base templates. So it'd be very hard to use pushState and DOM mutations to morph the current page into the destination page. The fact that the destination page is template based doesn't make it any easier. Consider for example google search and google calendar. The google search page is very template based. I.e. while the contents of a search result is varies, there's a lot of template content that is shared between all search result pages. If Google calendar included a search the web box, which when used would navigate the user to a google search result page. It would be very hard for google calendar to use pushState and DOM mutations to transform a calendar page into a search result page. Not only would the DOM need to be replaced. You'd also need to load any scripts that google search depends on. And unload any script state that google calendar had created and that might interfere with the google search scripts. This is essentially as hard as morphing the current page into a completely different non-template-based webpage unless I'm missing something. It would be much more practically doable for calendar instead to prerender a blank search result page, and then once the user commits the search tell that prerendered page what the search parameters are such that the page can load and render the appropriate search data. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
Jonas, thanks for the explanations so far. It helps a lot to understand and sorry for the naive questions. There is still something I do not get: Le 13 août 2014 à 07:17, Jonas Sicking jo...@sicking.cc a écrit : It would be much more practically doable for calendar instead to prerender a blank search result page, and then once the user commits the search tell that prerendered page what the search parameters are such that the page can load and render the appropriate search data. Here you seem to talk about partial rendering. I thought pre-render features were here to enable to show instantly a page when the user decides to follow a link. Aka the page is just ready to be shown. Here in your explanation you seem to say that the DOM is partially built but the painting is not done or at least has to be redone before displaying the page. Do we lose part of the benefits by doing that? Or maybe a more appropriate question is what is the gain in between a prefetch and a prerender in this case? Another thought: There is something very similar in between prefetch, prerender and the old next/prev values. That could revive those. link rel='next' href=''/ link rel='prev' href=''/ -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
Aryeh Gregor wrote: 2) It's easier to use, as evidenced by the patches in bugs 1015114 and 1052477. No .forget() is needed, a raw pointer can be returned directly, even things like do_QueryInterface can be returned directly without a temporary nsCOMPtr (since the return type creates the temporary for you). You can just return whatever you like and the compiler will figure out if an addref is needed. There's a noticeable decrease in LoC when converting to use it. Do you have to name the temporary nsCOMPtr? For example, in the code nsCOMPtrnsIAtom atom = GetAtomValue() return atom.forget(); Can this be rewritten to return nsCOMPtrnsIAtom(GetAtomValue()).forget(); Or better still, if this counts as an rvalue, can we define a move constructor from nsCOMPtrT and write return nsCOMPtrnsIAtom(GetAtomValue()); -- Warning: May contain traces of nuts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
On Wed, Aug 13, 2014 at 4:35 AM, Aryeh Gregor a...@aryeh.name wrote: On Tue, Aug 12, 2014 at 6:46 PM, L. David Baron dba...@dbaron.org wrote: In these cases we document that it's likely safe for callers to do this by having those getters return raw pointers. Getters that require reference-counting return already_AddRefed. Thus the designer of the API makes a choice about whether the caller is required to reference-count the result. How is this code safe? nsIContent* child = node-GetFirstChild(); // Do some stuff with child It compiles fine, but if any subsequent code causes the child to be removed from its parent, it could get freed. In particular, this can happen if anything indirectly triggers mutation observers, and I distinctly remember a sec-critical bug caused by exactly that. There are huge swathes of code where we know DOM mutation should not happen. Reflow and painting for example. Rob -- oIo otoeololo oyooouo otohoaoto oaonoyooonoeo owohooo oioso oaonogoroyo owoiotoho oao oboroootohoeoro oooro osoiosotoeoro owoiololo oboeo osouobojoeocoto otooo ojouodogomoeonoto.o oAogoaoiono,o oaonoyooonoeo owohooo osoaoyoso otooo oao oboroootohoeoro oooro osoiosotoeoro,o o‘oRoaocoao,o’o oioso oaonosowoeoroaoboloeo otooo otohoeo ocooouoroto.o oAonodo oaonoyooonoeo owohooo osoaoyoso,o o‘oYooouo ofolo!o’o owoiololo oboeo oiono odoaonogoeoro ooofo otohoeo ofoioroeo ooofo ohoeololo. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
One thing to test heavily would be background updates which rely somewhat on the structure of these files abd directories... Cheers, Ehsan On Aug 12, 2014 1:05 PM, Ben Hearsum bhear...@mozilla.com wrote: Hi all, Apple recently announced changes to how OS X applications must be packaged and signed ( https://developer.apple.com/library/mac/technotes/tn2206/_index.html#//apple_ref/doc/uid/DTS40007919-CH1-TNTAG205) in order for them to function correctly on OS X 10.9.5 and 10.10. The tl;dr version of this is only mach-O binaries may live in .app/Contents/MacOS, and signing must be done on 10.9 or later. Without any changes, future versions of Firefox will cease to function out-of-the-box on OS X 10.9.5 and 10.10. We do not have a release date for either of these OS X versions yet. Changes required: * Move all non-mach-O files out of .app/Contents/MacOS. Most of these will move to .app/Contents/Resources, but files that could legitimately change at runtime (eg: everything in defaults/) will move to .app/MozResources (which can be modified without breaking the signature): https://bugzilla.mozilla.org/showdependencytree.cgi?id=1046906hide_resolved=1. This work is in progress, but no patches are ready yet. * Add new features to the client side update code to allow partner repacks to continue to work. (https://bugzilla.mozilla.org/show_bug.cgi?id=1048921 ) * Create and use 10.9 signing servers for these new-style apps. We still need to use our existing 10.6 signing servers for any builds without these changes. (https://bugzilla.mozilla.org/show_bug.cgi?id=1046749 and https://bugzilla.mozilla.org/show_bug.cgi?id=1049595) * Update signing server code to support new v2 signatures. Timeline: We are intending to ship the required changes with Gecko 34, which ships on November 25th, 2014. The changes required are very invasive, and we don't feel that they can be safely backported to any earlier version quickly enough without major risk of regressions. We are still looking at whether or not we'll backport to ESR 31. To this end, we've asked that Apple whitelist Firefox and Thunderbird versions that will not have the necessary changes in them. We're still working with them to confirm whether or not this can happen. This has been cross posted a few places - please send all follow-ups to the mozilla.dev.platform newsgroup. - Ben ___ 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.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
Ben Hearsum wrote: Apple recently announced changes to how OS X applications must be packaged and signed Does this also apply if you run .app/Contents/MacOS/firefox binary manually rather than opening the .app? If developers do update their OS to 10.9.5 when it's released, is there a way to override this check? Otherwise it's going to make it difficult to run older builds (e.g. manually testing old builds for regressions, or using mozregression that does Nightly build bisection). ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
Le 13 août 2014 à 09:13, Jonas Sicking jo...@sicking.cc a écrit : The goal of prerender is to improve performance when navigating to a new page. my understanding too. I'm talking about doing a full rendering of a template page. I.e. a normal webpage which the website can then use JavaScript to mutate into the page that the user wanted to navigate to. [cut the explanation] So I guess I'm getting confused by the term 'prerender' and the scope. It looks like indeed more like a single page app (with all the caveats of client side generated pages) or a rel='template' more than a rel='prerender'. What would be the markup for the scenario you are explaining? And what would be the fallback for non JS user agents (cue accessibility and HTTP scripting here)? If I do link rel='prerender' href='http://example.org/nextbug0001.html'/ How the server knows it has to send the template or the full HTML page? What is the HTTP caching story with regards to this URI http://example.org/nextbug0001.html? And how does it help with http://example.org/nextbug0002.html in terms of caching? -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
RE: Upcoming changes to Mac package layout, signing
Yes, this is very much on our radar. Cheers, Robert -Original Message- From: dev-platform [mailto:dev-platform-bounces+rstrong=mozilla@lists.mozilla.org] On Behalf Of Ehsan Akhgari Sent: Tuesday, August 12, 2014 5:33 PM To: Ben Hearsum Cc: dev-platform@lists.mozilla.org Subject: Re: Upcoming changes to Mac package layout, signing One thing to test heavily would be background updates which rely somewhat on the structure of these files abd directories... Cheers, Ehsan On Aug 12, 2014 1:05 PM, Ben Hearsum bhear...@mozilla.com wrote: Hi all, Apple recently announced changes to how OS X applications must be packaged and signed ( https://developer.apple.com/library/mac/technotes/tn2206/_index.html#/ /apple_ref/doc/uid/DTS40007919-CH1-TNTAG205) in order for them to function correctly on OS X 10.9.5 and 10.10. The tl;dr version of this is only mach-O binaries may live in .app/Contents/MacOS, and signing must be done on 10.9 or later. Without any changes, future versions of Firefox will cease to function out-of-the-box on OS X 10.9.5 and 10.10. We do not have a release date for either of these OS X versions yet. Changes required: * Move all non-mach-O files out of .app/Contents/MacOS. Most of these will move to .app/Contents/Resources, but files that could legitimately change at runtime (eg: everything in defaults/) will move to .app/MozResources (which can be modified without breaking the signature): https://bugzilla.mozilla.org/showdependencytree.cgi?id=1046906hide_resolv ed=1. This work is in progress, but no patches are ready yet. * Add new features to the client side update code to allow partner repacks to continue to work. (https://bugzilla.mozilla.org/show_bug.cgi?id=1048921 ) * Create and use 10.9 signing servers for these new-style apps. We still need to use our existing 10.6 signing servers for any builds without these changes. (https://bugzilla.mozilla.org/show_bug.cgi?id=1046749 and https://bugzilla.mozilla.org/show_bug.cgi?id=1049595) * Update signing server code to support new v2 signatures. Timeline: We are intending to ship the required changes with Gecko 34, which ships on November 25th, 2014. The changes required are very invasive, and we don't feel that they can be safely backported to any earlier version quickly enough without major risk of regressions. We are still looking at whether or not we'll backport to ESR 31. To this end, we've asked that Apple whitelist Firefox and Thunderbird versions that will not have the necessary changes in them. We're still working with them to confirm whether or not this can happen. This has been cross posted a few places - please send all follow-ups to the mozilla.dev.platform newsgroup. - Ben ___ 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.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
On 08/12/2014 04:04 PM, Ilya Grigorik wrote: In short, seems like this is inventing a derivative single-page app model for building pages/apps, and that makes me wonder because it doesn't seem to make it any easier. Everything described here can be achieved with current tools, but perhaps could be made better with some smart(er) prefetch/prerender strategies? :vingtetun can probably speak to it better than I can, but my understanding was that for Firefox OS and the Haida UX effort (https://wiki.mozilla.org/FirefoxOS/Haida) targeting mobile phones, there were some practical benefits foreseen: - Consistent in-app page/card transitions. Each Gaia app has a custom/ad-hoc solution right now. The effort to make more reusable components will likely address this, but then a consistent platform UX still depends on apps effectively making themself Firefox OS specific by using the Firefox building blocks/etc. - Consistent support of/use of edge gestures inside the app. https://wiki.mozilla.org/FirefoxOS/Haida#Edge_Gestures_Between_Open_Content - Improved resource usage patterns by every page being an iframe with only a little stuff in it. It's harder to accidentally leak memory or get burnt by heap fragmentation if you're only doing a few things and cleaned up entirely as you are superseded. However the assumption was that these iframes would be talking to SharedWorkers which presumably would have the same problem. While Haida apps designed for the phone form factor would never be usable on a desktop device as-is, it's neat that the pre-render mechanism makes the same underlying implementation workable for both cases, especially since it makes a many simple pages approach viable. Right now if you want a performant implementation, you are inevitably driven to the single-page app implementation approach. Andrew ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
On Tue, Aug 12, 2014 at 5:47 PM, Karl Dubost kdub...@mozilla.com wrote: Le 13 août 2014 à 09:13, Jonas Sicking jo...@sicking.cc a écrit : The goal of prerender is to improve performance when navigating to a new page. my understanding too. I'm talking about doing a full rendering of a template page. I.e. a normal webpage which the website can then use JavaScript to mutate into the page that the user wanted to navigate to. [cut the explanation] So I guess I'm getting confused by the term 'prerender' and the scope. It looks like indeed more like a single page app (with all the caveats of client side generated pages) or a rel='template' more than a rel='prerender'. I don't understand why a separate rel value would be beneficial. What would be the markup for the scenario you are explaining? Exactly the same as any other time when prerendering is used. Like I said, no magic needed. So I believe the markup would be link rel=prerender href=... And what would be the fallback for non JS user agents (cue accessibility and HTTP scripting here)? The same as any other time when prerendering is used. The fallback would simply be that the next page is loaded at normal speed, rather than being prerendered. The only thing that the page would have to do special here when the initial page attempts to send a message to the prerendered page about which bug's data to load, if the API for talking to the message channel is missing, don't do anything. If I do link rel='prerender' href='http://example.org/nextbug0001.html'/ How the server knows it has to send the template or the full HTML page? You include that information in the URL. See the examples I've used in the explanations so far. What is the HTTP caching story with regards to this URI http://example.org/nextbug0001.html? And how does it help with http://example.org/nextbug0002.html in terms of caching? The same as for any other time prerendering is used. I'm definitely getting the impression that we're still talking past each other. I guess maybe me or you are misunderstanding how the prerendering spec is defined. / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
Just to be clear I have *read* http://code.google.com/chrome/whitepapers/prerender.html So my understanding of pretender is based on this whitepaper. :) Le 13 août 2014 à 10:09, Jonas Sicking jo...@sicking.cc a écrit : And what would be the fallback for non JS user agents (cue accessibility and HTTP scripting here)? The same as any other time when prerendering is used. The fallback would simply be that the next page is loaded at normal speed, rather than being prerendered. The only thing that the page would have to do special here when the initial page attempts to send a message to the prerendered page about which bug's data to load, if the API for talking to the message channel is missing, don't do anything. !doctype html html titlebug/title link rel='prerender' href='http://bugzilla.mozilla.org/show_bug.cgi?justLoadTemplate=1'/ a href=/bug0001my next bug/a and a href=/bug0002my next next bug/a /html In your scenario, this would not work without scripting. I can see how useful it could be with Firefox OS and transitions between different states of an application. On the Web, it means that we get yet another dependency on JS for this to be working for capturing the click event and sending a XHR with Accept: application/json. On the other hand if no JS, the server receives the HTTP GET requests on the resource, but then without pre-rendering. :) I guess it's why I'm asking questions to be sure how it would be working. I was asking questions about the caching because once http://bugzilla.mozilla.org/show_bug.cgi?justLoadTemplate=1 is downloaded, rendered and cached. It could be reused for all subsequent requests with the same pattern. But in return it means we create an issue for Web developers for developing and testing, or just modifying the cache. I guess people can rely to cache busting techniques such as timestamp parameters in URIs. I'm definitely getting the impression that we're still talking past each other. I guess maybe me or you are misunderstanding how the prerendering spec is defined. I understand what you are saying. :) But maybe we are assuming different things for the Web and/or have read a different spec. It's ok. Thanks Jonas. No more questions. :) -- Karl Dubost, Mozilla http://www.la-grange.net/karl/moz ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to implement: Prerendering API
On Tue, Aug 12, 2014 at 6:53 PM, Karl Dubost kdub...@mozilla.com wrote: Le 13 août 2014 à 10:09, Jonas Sicking jo...@sicking.cc a écrit : And what would be the fallback for non JS user agents (cue accessibility and HTTP scripting here)? The same as any other time when prerendering is used. The fallback would simply be that the next page is loaded at normal speed, rather than being prerendered. The only thing that the page would have to do special here when the initial page attempts to send a message to the prerendered page about which bug's data to load, if the API for talking to the message channel is missing, don't do anything. !doctype html html titlebug/title link rel='prerender' href='http://bugzilla.mozilla.org/show_bug.cgi?justLoadTemplate=1'/ a href=/bug0001my next bug/a and a href=/bug0002my next next bug/a /html In your scenario, this would not work without scripting. I can see how useful it could be with Firefox OS and transitions between different states of an application. Note that the example I used was bugzilla. So this is definitely useful outside of FirefoxOS. But yes, this depends on scripting. It sounds like between the two of us we have three goals * Enable fast navigation between webpages in websites like bugzilla. * When a search result page is loaded, avoid loading and prerendering a separate DOM for each bug. * Avoid relying on JS. I can only think of solutions which fulfill two of those goals at the same time. Which two would be left up to the bugzilla web developers. If you have ideas for how to solve all three at the same time I'm all ears. I was asking questions about the caching because once http://bugzilla.mozilla.org/show_bug.cgi?justLoadTemplate=1 is downloaded, rendered and cached. Note that I don't think anyone is (yet) proposing caching of a prerendered *page*. The individual resources that are loaded to make up the prerendered page will be loaded through the normal http stack, which means that those resources might get cached, or be loaded from cache. But the only thing that's cached is the bytes coming from the network. No parsed datastructures are cached. The parsed and rendered DOM will either be used immediately, or thrown away completely. It could be reused for all subsequent requests with the same pattern. For now the HTML resource will only be reused for other loads to http://bugzilla.mozilla.org/show_bug.cgi?justLoadTemplate=1. Which likely it mean it will only be used when a page is prerendered. It will not be used if the user simply navigates to a bug page like http://bugzilla.mozilla.org/show_bug.cgi?id=123456 / Jonas ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Upcoming changes to Mac package layout, signing
On 8/12/14, 8:46 PM, Cameron McCormack wrote: Ben Hearsum wrote: Apple recently announced changes to how OS X applications must be packaged and signed Does this also apply if you run .app/Contents/MacOS/firefox binary manually rather than opening the .app? As best as I can tell, no. You should be able to run the firefox binary manually without a warning dialog. If developers do update their OS to 10.9.5 when it's released, is there a way to override this check? Otherwise it's going to make it difficult to run older builds (e.g. manually testing old builds for regressions, or using mozregression that does Nightly build bisection). The most bullet-proof way to override this behavior is to change the Gatekeeper setting. This can be done in System Preferences Security Privacy by setting Allow apps downloaded from: to Anywhere. This obviously comes with the downside that the Gatekeeper will be disabled for all apps. If apps should be allowed individually, simply right-click the bundle and select Open. The warning dialog should no longer appear on subsequent launch attempts. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Getting rid of already_AddRefed?
Aryeh Gregor writes:
The compiler is required to use the move constructor (if one exists)
instead of the copy constructor when constructing the return value of
a function, and also when initializing an object from the return value
of a function, or assigning the return value of a function. So if you
have
Foo GetFoo() { Foo f(1, 2, 7); /* do lots of stuff to f */ return f; }
void MyFunction() { Foo f = GetFoo(); }
the copy constructor of Foo will not get called anywhere.
I guess that means that with
struct Bar {
Bar(Foo f) : mF(f) {}
Foo GetFoo() { return mF; }
Foo mF;
}
GetFoo() would give away what mF owns?
If so, can we require that be more explicit somehow?
___
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
Re: Telemetry alerts for histograms
I would prefer a public list available over NNTP like mozilla.dev.tree-management so I don't have to get the large volume of mail in my inbox. MattN On 8/12/14 5:17 PM, Gavin Sharp wrote: What does that alias point to? Seems to me a public mailman mailing list would be a better choice, since then people can subscribe/unsubscribe on their own. Gavin On Tue, Aug 12, 2014 at 7:57 AM, rviti...@mozilla.com wrote: From now on all alerts will be sent by default also to telemetry-ale...@mozilla.com. ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
