Testing Requirements
Marcos Caceres from Opera started a wiki on Testing Requirements some time ago. I just updated it to include some more detail. I think the requirements are roughly the same for HTML and WebApps (apart from WebSockets) which is why I put both in the To field. http://www.w3.org/2008/webapps/wiki/Testing_Requirements Please update it with requirements I missed. -- Anne van Kesteren http://annevankesteren.nl/
Re: Discussion of File API at TPAC in Lyon
On Tue, 16 Nov 2010 01:35:05 +0100, Jonas Sicking jo...@sicking.cc wrote:
Ok, here is what I'll propose as the final solution:
FileAPI will define the following WebIDL:
[Supplemental]
interface URL {
static DOMString createObjectURL(in Blob blob);
static void revokeObjectURL(in DOMString url);
};
[...]
Unless I hear otherwise from people, I'll assume that everyone is
happy with this.
This looks great. Will this make it into Firefox 4?
--
Anne van Kesteren
http://annevankesteren.nl/
Re: Discussion of File API at TPAC in Lyon
On Tuesday, November 16, 2010, Anne van Kesteren ann...@opera.com wrote:
On Tue, 16 Nov 2010 01:35:05 +0100, Jonas Sicking jo...@sicking.cc wrote:
Ok, here is what I'll propose as the final solution:
FileAPI will define the following WebIDL:
[Supplemental]
interface URL {
static DOMString createObjectURL(in Blob blob);
static void revokeObjectURL(in DOMString url);
};
[...]
Unless I hear otherwise from people, I'll assume that everyone is
happy with this.
This looks great. Will this make it into Firefox 4?
Assuming we can get everyone to agree quickly enough, yes.
/ Jonas
Re: Discussion of File API at TPAC in Lyon
I have a clarifying question about how it would work:
How, if at all, the lifetime of the generated urls will be defined in case
of having those functions on URL interface object?
If those methods are on a global object, the lifetime of the urls created
would be gated by the lifetime of that global object, and in browser
implementations that lifetime is usually defined well - and used for other
things like lifetime of shared workers for example. There is certain times
when the document/page/window are 'closed and detached', and while it varies
in implementations and it is more complex then that, it provides a
well-understood lifetime boundary.
By having those methods on some static object, doesn't the lifetime becomes
unclear? Do we grab 'current context of the call'?
Dmitry
On Tue, Nov 16, 2010 at 8:10 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tuesday, November 16, 2010, Anne van Kesteren ann...@opera.com wrote:
On Tue, 16 Nov 2010 01:35:05 +0100, Jonas Sicking jo...@sicking.cc
wrote:
Ok, here is what I'll propose as the final solution:
FileAPI will define the following WebIDL:
[Supplemental]
interface URL {
static DOMString createObjectURL(in Blob blob);
static void revokeObjectURL(in DOMString url);
};
[...]
Unless I hear otherwise from people, I'll assume that everyone is
happy with this.
This looks great. Will this make it into Firefox 4?
Assuming we can get everyone to agree quickly enough, yes.
/ Jonas
Re: requestAnimationFrame
On Mon, Nov 15, 2010 at 7:24 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Nov 16, 2010 at 1:45 PM, Gregg Tavares (wrk) g...@google.comwrote: On Mon, Nov 15, 2010 at 4:07 PM, Robert O'Callahan rob...@ocallahan.orgwrote: On Tue, Nov 16, 2010 at 12:55 PM, Gregg Tavares (wrk) g...@google.comwrote: I've seen proposals for something more like element.setInternvalIfVisible(func, internval); Which is the same as setInterval but only gets called if the element is visible. With that kind of API there is no connection to rendering. Each area that needs animation can set the framerate it is hoping to get. The UA can throttle if it wants to. What happens if one element's event handler makes another element visible, will the second element's timer be able to fire or not? Does it matter? Yes, I think it probably does matter for interop. What happens now? With mozRequestAnimationFrame, visibility is not relevant to whether the callbacks fire, so the question does not arise. Now, with setInterval there is no connection to rendering. I set the code to update one element to have an interval of 16 and another to have an interval of 100. If the first one makes the second one visible that doesn't effect whether or not the second one's set interval function gets called. If there was a setIntervalIfVisible and that behavior was browser independent how would that make things worse than they are today? It seem like if visible is just a hint to the browser that it doesn't need to call the interval function if it doesn't want to. It doesn't need to be a guaranteed that it will be called when visible any more than the current setInterval is a guarantee that it will be called at the interval rate. mozRequestAnimationFrame actually guarantees that you will be called when the browser paints. Otherwise we can't guarantee that JS animations will stay in sync with declarative animations. So if the JS on the beforePaint takes a while to complete what happens to the browser? For example if you are resizing the browser? Is the browser forced not to be able to actually paint until JS returns? Now, when animation is happening on a separate compositor thread that guarantee has to be relaxed a bit. But we'll still try to meet it on a best-effort basis --- i.e. we'll run the JS animations once per composited frame, if the JS can keep up. So you're saying that there's no guarantee that requestAnimationFrame will actually keep things in sync? When an element becomes visible, does its timer fire immediately if the last firing was more than 'interval' ago? Yes? No? Does it matter? What happens now? I suspect it would matter for interop, yes. Again, with requestAnimationFrame the question does not arise. I'm not trying to be argumentative. I'm just not seeing the issue. Certainly I'd like various areas to be updated together, or in sync, or when visible but that seems like it could be up the UA. If one UA has a simple implementation and another UA as more complex one that gives a better user experience then that's reason to switch to that browser. As Boris mentioned, keeping multiple animations (including declarative animations) in sync was a design goal for requestAnimationFrame. This seems like you'd just pass in 0 for the interval. The UA can decide whether or not to call you as fast as it can or at 60hz or whatever it things is appropriate just as it does for setInterval today. OK. To summarize, I think you have raised two separate feature requests here: 1) Provide an API that lets authors specify a maximum frame rate 2) Provide an API that lets authors avoid getting a callback while a particular element is invisible I'm curious about the use-cases that require #1, and given it can be implemented on top of requestAnimationFrame, the question for any proposal is whether the extra convenience justifies the surface area. (And note that even something like setInternvalIfVisible requires some lines of code for the animation script to figure out which frame it should display.) I'm not sure how important #2 is. If your callback includes if (element.getBoundingClientRect().top window.innerHeight) return;, I think you'd be pretty close to the same effect. But if you have a lot of animated elements, most of which are not visible, I can see that native support could be helpful. Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: requestAnimationFrame
On Tue, Nov 16, 2010 at 10:52 AM, Gregg Tavares (wrk) g...@google.com wrote: On Mon, Nov 15, 2010 at 7:24 PM, Robert O'Callahan rob...@ocallahan.org wrote: Now, when animation is happening on a separate compositor thread that guarantee has to be relaxed a bit. But we'll still try to meet it on a best-effort basis --- i.e. we'll run the JS animations once per composited frame, if the JS can keep up. So you're saying that there's no guarantee that requestAnimationFrame will actually keep things in sync? Right; if the browser is trying to paint animation frames every 20ms, and two functions have both registered themselves for the next frame, but the first function takes 50ms to run, then of course the second one won't get to run at the same time. It'll be delayed until the 3rd frame after or so. ~TJ
Re: requestAnimationFrame
On 11/16/10 1:52 PM, Gregg Tavares (wrk) wrote: So if the JS on the beforePaint takes a while to complete what happens to the browser? For example if you are resizing the browser? Is the browser forced not to be able to actually paint until JS returns? I'll let roc talk about how he sees this working in the future, and in particular about your compositor thread question below, but in the current Gecko model, this is correct. The content area will not paint updates, change layout, etc, until the JS returns. Note that in your resize scenario I would in fact not expect the layout to change under a script while the script is running, so the browser couldn't relayout to the new size until the JS returns anyway. Now, when animation is happening on a separate compositor thread that guarantee has to be relaxed a bit. But we'll still try to meet it on a best-effort basis --- i.e. we'll run the JS animations once per composited frame, if the JS can keep up. So you're saying that there's no guarantee that requestAnimationFrame will actually keep things in sync? The guarantees we currently supply are: 1) Your requestAnimationFrame handler will be called before painting. 2) The handler is passed an argument (directly, if you used a function callback; as event.timeStamp if you used an event handler) that indicates the time that was or will be used to sample SMIL animations and CSS Transitions that will paint when the paint happens. This may be different from the current time, depending on what other animation frame handlers are involved and how long they take. Now your script knows the time that it's painting at wrt animations, and can compute the proper thing to be showing to be in sync with them. -Boris
revokeObjectURL behavior
Hi All, We have at length discussed what revokeObjectURL should be called, and where it should live. However we haven't yet discussed how it should behave. In particular, there is one edge case that I'm concerned about. Consider: myurl = window1.URL.createObjectURL(myblob); window2.URL.revokeObjectURL(myurl); in this example window1 and window2 are separate, but same origin, windows (for example window2 could be an iframe inside window1). The question is, should the call to revokeObjectURL succeed, do nothing, or throw an exception. One important aspect here is that if the two windows are not same origin, and the code in window2 simply guesses a url to revoke, then we definitely don't want the revoke to succeed. While implementations should take steps to make URLs unguessable, it is good to have extra layers of security by not allowing different origins to unregister each others URLs. Another concern I have is that silently doing nothing is bad for APIs that are intended to free resources. It makes it very easy to create the situation where a author think they are revoking a URL, but in reality are not. I think for safety, I'm leaning towards saying that different same-origin windows can unregister each others URLs. But if revokeObjectURL is called with a string that is not a same-origin URL, it does nothing (other than possibly warning in error consoles if the UA so desires). Let me know what you think. / Jonas
Re: Discussion of File API at TPAC in Lyon
On Tue, Nov 16, 2010 at 10:42 AM, Dmitry Titov dim...@chromium.org wrote:
I have a clarifying question about how it would work:
How, if at all, the lifetime of the generated urls will be defined in case
of having those functions on URL interface object?
If those methods are on a global object, the lifetime of the urls created
would be gated by the lifetime of that global object, and in browser
implementations that lifetime is usually defined well - and used for other
things like lifetime of shared workers for example. There is certain times
when the document/page/window are 'closed and detached', and while it varies
in implementations and it is more complex then that, it provides a
well-understood lifetime boundary.
By having those methods on some static object, doesn't the lifetime becomes
unclear? Do we grab 'current context of the call'?
The intent (as i understand it) was to not change the lifetime
semantics that had been devised when these methods were defined at the
global scope, just to put a 'namespace' around them (so to speak). The
goal being a little less clutter the global namespace.
Dmitry
On Tue, Nov 16, 2010 at 8:10 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tuesday, November 16, 2010, Anne van Kesteren ann...@opera.com wrote:
On Tue, 16 Nov 2010 01:35:05 +0100, Jonas Sicking jo...@sicking.cc
wrote:
Ok, here is what I'll propose as the final solution:
FileAPI will define the following WebIDL:
[Supplemental]
interface URL {
static DOMString createObjectURL(in Blob blob);
static void revokeObjectURL(in DOMString url);
};
[...]
Unless I hear otherwise from people, I'll assume that everyone is
happy with this.
This looks great. Will this make it into Firefox 4?
Assuming we can get everyone to agree quickly enough, yes.
/ Jonas
Re: Discussion of File API at TPAC in Lyon
Thanks Michael,
so the proposed change is this: window.createObjectURL -
window.URL.createObjectURL
and it means it's also possible to do something like this:
var otherWindow = window.open(...)
otherWindow.URL.createObjectURL(...)
Is this correct understanding?
Dmitry
On Tue, Nov 16, 2010 at 11:57 AM, Michael Nordman micha...@google.comwrote:
On Tue, Nov 16, 2010 at 10:42 AM, Dmitry Titov dim...@chromium.org
wrote:
I have a clarifying question about how it would work:
How, if at all, the lifetime of the generated urls will be defined in
case
of having those functions on URL interface object?
If those methods are on a global object, the lifetime of the urls created
would be gated by the lifetime of that global object, and in browser
implementations that lifetime is usually defined well - and used for
other
things like lifetime of shared workers for example. There is certain
times
when the document/page/window are 'closed and detached', and while it
varies
in implementations and it is more complex then that, it provides a
well-understood lifetime boundary.
By having those methods on some static object, doesn't the lifetime
becomes
unclear? Do we grab 'current context of the call'?
The intent (as i understand it) was to not change the lifetime
semantics that had been devised when these methods were defined at the
global scope, just to put a 'namespace' around them (so to speak). The
goal being a little less clutter the global namespace.
Dmitry
On Tue, Nov 16, 2010 at 8:10 AM, Jonas Sicking jo...@sicking.cc wrote:
On Tuesday, November 16, 2010, Anne van Kesteren ann...@opera.com
wrote:
On Tue, 16 Nov 2010 01:35:05 +0100, Jonas Sicking jo...@sicking.cc
wrote:
Ok, here is what I'll propose as the final solution:
FileAPI will define the following WebIDL:
[Supplemental]
interface URL {
static DOMString createObjectURL(in Blob blob);
static void revokeObjectURL(in DOMString url);
};
[...]
Unless I hear otherwise from people, I'll assume that everyone is
happy with this.
This looks great. Will this make it into Firefox 4?
Assuming we can get everyone to agree quickly enough, yes.
/ Jonas
Re: Discussion of File API at TPAC in Lyon
On Tue, Nov 16, 2010 at 10:42 AM, Dmitry Titov dim...@chromium.org wrote: I have a clarifying question about how it would work: How, if at all, the lifetime of the generated urls will be defined in case of having those functions on URL interface object? If those methods are on a global object, the lifetime of the urls created would be gated by the lifetime of that global object, and in browser implementations that lifetime is usually defined well - and used for other things like lifetime of shared workers for example. There is certain times when the document/page/window are 'closed and detached', and while it varies in implementations and it is more complex then that, it provides a well-understood lifetime boundary. By having those methods on some static object, doesn't the lifetime becomes unclear? Do we grab 'current context of the call'? We'll use the window object through which the URL object was retrieved. So for example: myurl1 = frames[0].URL.createObjectURL(blob); myurl2 = frames[1].URL.createObjectURL(blob); in this case lifetime of the two urls are bound to the lifetime of the two different windows. Does that make sense? This is similar to how base-uri resolving works in XMLHttpRequest where the base uri for a given XMLHttpRequest is determined by which constructor was used to create it, not based by who is calling .open or calling the constructor. / Jonas
Re: Discussion of File API at TPAC in Lyon
On Tue, Nov 16, 2010 at 12:07 PM, Dmitry Titov dim...@chromium.org wrote: Thanks Michael, so the proposed change is this: window.createObjectURL - window.URL.createObjectURL and it means it's also possible to do something like this: var otherWindow = window.open(...) otherWindow.URL.createObjectURL(...) Is this correct understanding? If you do this, then the lifetime of the URL is the lifetime of the Document in otherWindow. Actually since at the time you're calling createObjectURL otherWindow still contains an about:blank document, as soon as the url passed to window.open is loaded, the returned URL will expire. / Jonas
Re: requestAnimationFrame
On Wed, Nov 17, 2010 at 7:52 AM, Gregg Tavares (wrk) g...@google.comwrote: So if the JS on the beforePaint takes a while to complete what happens to the browser? For example if you are resizing the browser? Is the browser forced not to be able to actually paint until JS returns? Not necessarily. In Firefox 4, yes. In Mobile Firefox, which supports compositing in a separate process from the content, no. Now, when animation is happening on a separate compositor thread that guarantee has to be relaxed a bit. But we'll still try to meet it on a best-effort basis --- i.e. we'll run the JS animations once per composited frame, if the JS can keep up. So you're saying that there's no guarantee that requestAnimationFrame will actually keep things in sync? Right. A cast-iron guarantee that requestAnimationFrame callbacks will run to completion before painting is incompatible with the goal of being able to repaint the browser window even if scripts are running too long or completely hung. But we *can* guarantee that a) scripted animations stay in sync with each other, and b) if the HTML5 event loop is not too busy (e.g., animation scripts take much less time to complete than the interval between composited frames and the content process is otherwise idle), scripted animations will stay in sync with with declarative animations even if the declarative animations are being processed by an off-main-thread compositing framework. (OK, this is a bit speculative since we haven't implemented it yet, but the approach seems straightforward.) Rob -- Now the Bereans were of more noble character than the Thessalonians, for they received the message with great eagerness and examined the Scriptures every day to see if what Paul said was true. [Acts 17:11]
Re: Discussion of File API at TPAC in Lyon
On Tue, Nov 16, 2010 at 12:20 PM, Jonas Sicking jo...@sicking.cc wrote: On Tue, Nov 16, 2010 at 12:07 PM, Dmitry Titov dim...@chromium.org wrote: Thanks Michael, so the proposed change is this: window.createObjectURL - window.URL.createObjectURL and it means it's also possible to do something like this: var otherWindow = window.open(...) otherWindow.URL.createObjectURL(...) Is this correct understanding? If you do this, then the lifetime of the URL is the lifetime of the Document in otherWindow. Actually since at the time you're calling createObjectURL otherWindow still contains an about:blank document, as soon as the url passed to window.open is loaded, the returned URL will expire. That makes perfect sense, thanks!
RE: Discussion of File API at TPAC in Lyon
On Tuesday, November 16, 2010 8:11 AM, Jonas Sicking wrote:
On Tuesday, November 16, 2010, Anne van Kesteren ann...@opera.com
wrote:
On Tue, 16 Nov 2010 01:35:05 +0100, Jonas Sicking jo...@sicking.cc
wrote:
Ok, here is what I'll propose as the final solution:
FileAPI will define the following WebIDL:
[Supplemental]
interface URL {
static DOMString createObjectURL(in Blob blob);
static void revokeObjectURL(in DOMString url);
};
[...]
Unless I hear otherwise from people, I'll assume that everyone is
happy with this.
This looks great. Will this make it into Firefox 4?
Assuming we can get everyone to agree quickly enough, yes.
We're okay with this too, especially if it doesn't change. :)
