Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Tue, Jan 8, 2013 at 5:56 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/8/13 8:14 AM, Boris Zbarsky wrote: On 1/8/13 2:09 AM, Ian Hickson wrote: In the spec's security model, origins are never relevant for elements except when we're looking at the element's data. Yes. I think the spec's security model is not viable long-term, for what it's worth, and think we should be designing a security model that is instead... Just to clarify this. You may want to talk to sicking and Mounir about what they discovered about security models in the course of getting partially-elevated-privileges web apps to work. I suspect we'll need more of that sort of thing as time goes on. Which means the security model will likely need to evolve. I'm not convinced of that. I understand that Gecko need to deal with these complications because of a number of Mozilla-proprietary APIs, but I don't know of anything in the web platform that forces other browsers to deal with these issues. If and when features are added to the platform that cause these sorts of problems, we can deal with the consequences. In the mean time, I don't think we should force other browser engines to implement a more complicated security model than necessary for the platform as it stands. Which in turn means that I believe we should not be designing APIs and other functionality around the current security model, especially if the dependency is non-obvious (and I would argue that any dependency not spelled out in the section describing the security model is non-obvious, because it's too easy to miss it when updating the security model). What I think we ahould be doing instead is designing with the assumption that some core set of things is true (and we can argue about what set that is), but making as few assumptions as possible in general. This paragraph was too abstract for me to understand. Do you have a concrete example? Put another way, I think we have good evidence that the security model in the spec, as well as that in every browser, Gecko included, is wrong in the same sense that Newtonian mechanics is wrong. The problem is that we don't know what our equivalent of special relativity is yet. I don't understand the analogy. The security model in the spec is the same one we implement in WebKit and it's been working well for WebKit for a while. If there are security vulnerabilities, hopefully Chromium's security bounty will encourage you to report them. :) More seriously, life gets complicated when you introduce an asymmetric access relation, which I understand exists in Gecko. However, the open web platform contains only a symmetric access relation, and I intent to argue against any attempt to introduce an asymmetric access relation into the platform. Reasoning about security in this context of a symmetric access relation is relatively straightforward, and to check that new APIs don't screw up the model consists only of checking that they don't contain objects that are visibile to multiple origins. We have a handful of legacy objects that are already visible to multiple origins, and it's true that they're annoying to deal with, but we've already invested the engineering effort required to make them secure in the current security model. Maybe I've lost the thread here, but I don't understand the problem you're trying to solve with this thread. The simplest solution is for contentDocument to return null when accessed from a different origin. Grepping WebKit's IDL files for [CheckSecurityForNode], it looks like this check is needed for contentDocument attribute and the getSVGDocument() method on the various interfaces that contain them. Adam
Re: [whatwg] Script-related feedback
On Mon, Jan 7, 2013 at 7:51 PM, Ian Hickson i...@hixie.ch wrote:
On Mon, 7 Jan 2013, Adam Barth wrote:
Why not just introduce a keyword or pragma to JavaScript that tells
the user agent to act as if the end of the Program production had been
reached, and that it should treat the remainder of the file as another
Program?
This could even be done in a backwards-compatible fashion by having
the syntax to do this be something that down-level clients ignore,
e.g.:
/*@BREAK*/
...or some such.
That approach is an in-band signal, which means it's vulnerable to
injection attacks.
If you can inject this, you can inject arbitrary code, so I don't see how
this would be a problem.
For example, consider a server that produces a JavaScript file of the
following form:
[...]
var userData = ?php echo santize($userData) ?;
[...]
Currently, the rules for sanitizing using input are relatively
straightforward (essentially, you just need to worry about a few special
characters).
Those simple rules would prevent anyone from inserting a pragma-like
comment, too, so that's fine.
However, if we implemented an in-band signaling we might well break
these sanitation algorithms.
How? I'm not suggesting changing any JS syntax, just making existing JS
syntax be used as a signal.
If making a comment do this is too dodgy, make it something like this:
breakParsing();
...and for down-level support, define an explicit breakParsing function
that does nothing. If someone can insert a function call into JS, you've
definitely lost already.
Working through some examples, that seems really strange:
foo();
breakParsing();
bar();
In this case, breakParsing() works a bit like yield() in other
programming languages: first foo() executes, then the event loop
spins, then bar() executes. However, if we wrap the code in an
anonymous function block (as would make sense for JavaScript):
(function() {
foo();
breakParsing();
bar();
})();
Now I get either get a parse error, if breakParsing() actually breaks
up the parsing, or breakParsing() does nothing, both of which are
surprising. Worse, other seemingly trivial syntactic transformation
also break the magic:
foo();
breakParsing.call();
bar();
Now the JavaScript parse won't recognize the magic breakParsing();
production, and my script executes slowly.
I guess I don't understand the advantage of trying to cram this into
JavaScript syntax. It's really got nothing to do with JavaScript as a
language and everything to do with providing an efficient way for web
sites to ask the browser to execute several JavaScript programs in
sequence.
HTTP already has an efficient mechanism for delivering several
JavaScript programs in sequence: multipart. Given that img and
iframe already support multipart, it seems much simpler just to make
script support multipart as well.
Adam
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 3:11 AM, Adam Barth wrote: I'm not convinced of that. I understand that Gecko need to deal with these complications because of a number of Mozilla-proprietary APIs, Actually, what I'm talking about here has nothing to do with APIs but everything to do with wanting to write web applications that have slightly more privileges than your typical web page. Again, you may want to talk to Jonas and Mounir for details. If and when features are added to the platform that cause these sorts of problems, we can deal with the consequences. My argument is that we should not lock ourselves out of adding such features in the future. In the mean time, I don't think we should force other browser engines to implement a more complicated security model than necessary for the platform as it stands. I'm not saying we should force anyone to implement any particular security model. I'm saying we shouldn't design/spec things that become completely insecure if the security model ever changes in any way and hence prevent evolution of the security model. Which means that we should assume as little as possible about what the security model guarantees us when specifying things. In my opinion. This paragraph was too abstract for me to understand. Do you have a concrete example? For example, Ian's argument is that you can skip security checks in various places because the security model does that already. My counter-argument is that we should define the behavior of those places by referencing the security model explicitly, so that if the security model changes we won't have to hunt down all the places that had implicit dependencies on it. Does that make more sense? Put another way, I think we have good evidence that the security model in the spec, as well as that in every browser, Gecko included, is wrong in the same sense that Newtonian mechanics is wrong. The problem is that we don't know what our equivalent of special relativity is yet. I don't understand the analogy. The current security model describes most common cases, but not some edge cases (see above about a slightly-elevated-privileges web app that can, say, touch nodes from one and only one different origin). More seriously, life gets complicated when you introduce an asymmetric access relation I agree. I believe, however, that for many apps based on web technology you in fact might need this. Again, Sicking and Mounir would know more. https://bugzilla.mozilla.org/show_bug.cgi?id=734891 has some of the things in it, but I'm not sure it's all of them. However, the open web platform contains only a symmetric access relation Yes, I understand that's how it stands now. I'm questioning the viability of this going forward, and especially questioning to what extent we should be intentionally making it impossible to change away from this model. and I intent to argue against any attempt to introduce an asymmetric access That is, of course, your right. ;) Maybe I've lost the thread here, but I don't understand the problem you're trying to solve with this thread. The simplest solution is for contentDocument to return null when accessed from a different origin. That's not enough. Window has the same problem: the document IDL getter needs to check that you're allowed to get the document of the relevant window, for example. Is the check you describe for contentDocument based on origin or effective script origin? -Boris
[whatwg] Canvas 2D memory management
Some developers are starting to design large scale games using our HTML5 game engine, and we're finding we're running in to memory management issues. Consider a device with 50mb of texture memory available. A game might contain 100mb of texture assets, but only use a maximum of 30mb of them at a time (e.g. if there are three levels each using 30mb of different assets, and a menu that uses 10mb of assets). This game ought to fit in memory at all times, but if a user agent is not smart about how image loading is handled, it could run out of memory. We have a WebGL renderer which solves this by explicitly creating and deleting textures as necessary when switching levels, which guarantees that memory is managed efficiently. It also has the additional benefit that all necessary textures are pre-loaded, so there's no janking during the game as the first drawImage() of a particular asset in the level uploads a texture. I would like to suggest memory management features for the canvas 2D rendering context. By explicitly pre-loading images and releasing them at the end of the level we can guarantee that devices will not run out of memory, as well as making gameplay smoother. Some ideas: 1) add new functions to the canvas 2D context, such as: ctx.load(image): cache an image in memory so it can be immediately drawn when drawImage() is first used ctx.unload(image): release the image from memory 2) we can drawImage() every image on startup to force lazy-loading browsers to load everything that will be used, but there's still no way to indicate which images should be released at the end of a level. This could be left for the browser to determine (perhaps releasing by least-recently-used), but perhaps this should be required in the specification? 3) leave current behavior as it is and suggest WebGL for this type of application My preference is option 1, but I don't know if this works for all use cases and will work nicely with implementations. Any thoughts? Ashley Gullen Scirra.com
Re: [whatwg] Proposal: Add CanvasRenderingContext2D.fillRule with nonzero (default) and evenodd options
On 09/01/2013, at 4:08 PM, Dirk Schulze dschu...@adobe.com wrote:
On Jan 8, 2013, at 9:35 AM, Rik Cabanier caban...@gmail.com wrote:
I looked at pdf2js which is using this fillRule property. As I expected,
introduction of the property results in code like this:
eoFill: function CanvasGraphics_eoFill() {
var savedFillRule = this.setEOFillRule();
this.fill();
this.restoreFillRule(savedFillRule);
},
...
// We generally keep the canvas context set for
// nonzero-winding, and just set evenodd for the operations
// that need them.
setEOFillRule: function CanvasGraphics_setEOFillRule() {
var savedFillRule = this.ctx.mozFillRule;
this.ctx.mozFillRule = 'evenodd';
return savedFillRule;
},
restoreFillRule: function CanvasGraphics_restoreFillRule(rule) {
this.ctx.mozFillRule = rule;
},
So, for even odd winding, all this code needs to run. With my proposal, this
gets much simpler:
eoFill: function CanvasGraphics_eoFill() {
this.eoFill();
},
You can find a pull request with the needed changes to pdf2js here:
https://github.com/cabanier/pdf.js/commit/8e80b086376013a5438087714a4d2abb6fe67de1
For PDF.js it would probably be easier to set the fillRule every time right
before a fill or clip operation, then checking and storing the fill rule in
the background. This would reduce the code a lot more.
I also created patches (with test files) for WebKit and mozilla:
https://bugs.webkit.org/show_bug.cgi?id=106188
https://bugzilla.mozilla.org/show_bug.cgi?id=827053
I looked at the patch for webkit. There are two parts where I would disagree
and that are potentially confusing.
eoFill(), eoClip()
It is not obvious what these functions do and how they are different to
fill() and clip(). The name should be clear about the usage. But I don't
think that introducing two new functions to the Canvas API is a lot better
either. An alternative proposal instead of new functions or attributes could
be an optional argument for the fill() and stroke() functions. This argument
would be an enumeration of 'nonzero' and 'evenodd'.
ctx.fill(); // fill with 'nonzero'
ctx.fill('nonzero') // fill with 'nonzero' as well
ctx.fill('evenodd') // fill with winding rule 'evenodd'
I prefer this approach over new methods.
In general, I tend to agree with Rik that winding rule is a geometric
operation, rather than a context style. It's a shame that this may introduce
inconsistency (I appreciate Ian's point on that).
Dean
The boolean argument in isPointInPath seems not to be very descriptive as
well:
boolean isPointInPath(unrestricted double x, unrestricted double y,
boolean windingRule);
It is not obvious if 'true' means 'nonzero' or 'evenodd'. I would recommend
to use an optional enumeration here, with the default value 'nonzero'.
You mentioned that the winding rule should be a part of the Path object. I
can see the use case that you want to address with it. And things like a
union path of two path object with different winding rules (as you suggested
before) is possible, as long as the union path just needs to get drawn (can
be done with compositing or masking in the implementation). But the SVG WG
would like to use the Path object as a way to share path data between Canvas
and SVG. In this case, the implementation must be able to flatten a path and
provide the path data directly. This is beyond the capability of current
graphic libraries and requires third party planarizer. This needs to be
considered before adding this functionality to the Path API.
Greetings,
Dirk
On Thu, Jan 3, 2013 at 3:38 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 10 Jun 2011, Chris Jones wrote:
In 2D canvas, determining whether a point is inside a path is
currently always done using the non-zero winding rule. I propose
extending 2D canvas to allow determining inside-ness using the even-odd
rule.
I've added this to the spec.
On Wed, 2 Jan 2013, Dirk Schulze wrote:
There was a complain on the webkit bug report if fillRule should be part
of the graphics state or not. Did you investigate what current 2d
graphics libraries do (qt, Cairo, CG, ...)? Is it part of the graphics
state there?
I have made it be part of the graphics state in the spec; it would be
unusual in the API for it not to be. However, if this doesn't match
implementations, please let me know.
On Wed, 2 Jan 2013, Rik Cabanier wrote:
this features is not a trivial as it seems. Adding this will necessitate
updates to the algorithms that deal with paths and the outlining of
strokes and text.
Can you elaborate on what updates are needed? I couldn't see any that
actually needed to be changed.
As Dirk mentioned, instead of making it part of the graphics state, it's
more likely better to make it part of the fill or clip operator like
SVG, PDF and
Re: [whatwg] Proposal: Add CanvasRenderingContext2D.fillRule with nonzero (default) and evenodd options
Thanks for investigating this!
I opened a moderately complex file [1] and it had 19200 fills. The overhead
in ms then becomes
enumboolean
Firefox .5 .25
Safari.9 .6
Chrome 1.1 8
Opera3 1.6
This is assuming that the extra parsing time and validation on the c++ side
take no time.
A quick search on the web shows that mobile browsers are about 8 times
slower.
Considering that the file takes a couple of seconds to render, it seems
that the overhead is negligible.
1:
http://wwwimages.adobe.com/www.adobe.com/content/dam/Adobe/en/showcase/illustrator/pdfs/magic-paintbrush-howto.pdf
On Wed, Jan 9, 2013 at 9:13 AM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/9/13 1:20 AM, Rik Cabanier wrote:
Also, would there be a performance impact of having a string
argument for a call that happens very frequently?
That's an excellent question. The answer is that it depends.
Here's a testcase that exercises setting a property to a WebIDL enum and
measures the time in ns per property set:
script
var xhr = new XMLHttpRequest;
xhr.open(GET, );
var count = 100;
var start = new Date;
for (var i = 0; i count; ++i) {
xhr.responseType = text;
}
var stop = new Date;
alert((stop - start) / count * 1e6);
/script
What I see on my hardware in a current Firefox nightly is that this takes
about 27ns per set (this is on a 6-month-old fast laptop, for context, but
of course you can measure on the hardware of your choice). About 8-10ns of
that is the general overhead associated with the loop counter, the setter
invocation, etc. If my profiler is not lying to me, another several ns is
the actual implementation of the C++ responseType setter. The rest of the
time is spent dealing with the string. For what it's worth, it's possible
we could make the string bit faster for cases when a constant string is
being used, as above; I'd have to think about it a bit.
Here's a similar testcase that exercises a boolean:
script
var xhr = new XMLHttpRequest;
xhr.open(GET, );
var count = 100;
var start = new Date;
for (var i = 0; i count; ++i) {
xhr.withCredentials = false;
}
var stop = new Date;
alert((stop - start) / count * 1e6);
/script
The time I see now is closer to 12-13ns. So there is definitely overhead
associated with the string: about 15ns per call. How many calls are we
expecting people to make here?
But as I said, it depends. The numbers are quite different in other UAs.
Testing a Chrome 25 dev channel build, a WebKit nightly (labeled Safari
below), and and Opera build that claims to be 12.50 internal, I get
numbers like so, in ns (all with a few ns plus or minus; I'm leaving off
the error bars):
enumboolean
Firefox 27 13
Safari51 33
Chrome58 40
Opera158 82
so how long this stuff takes is clearly pretty implementation-dependent.
And note that these are upper bounds, since I have no guarantees that the
time taken by the actual C++ setters is negligible in these case (except
for Firefox, where profiles show that it is). For example, Chrome gets
about 30% slower if I set responseType to document instead of text, as
far as I can tell, and that might be due to the C++ side.
Hope that helps,
Boris
P.S. For a real fun time, try doing xhr.responseType = false, as I
accidentally did at some point while testing this and look at the resulting
numbers. ;)
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
It seems like your arguments all originate from wanting to support an asymmetric access relation. Supporting an asymmetric access relation is a bad idea, and we shouldn't do it. I understand that Mozilla already has technology for implementing an asymmetric access relation and that you're using it to implement a number of current and future Mozilla-proprietary features. That's fine, of course, but if you're interested in having those features become part of the web platform, please don't be surprised when other browser vendors refuse to implement them because of their asymmetric access relation. As a consequence, I would recommend that you do not use asymmetric access relations in features that you would like other browser vendors to implement in the future. Adam On Wed, Jan 9, 2013 at 7:16 AM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/9/13 3:11 AM, Adam Barth wrote: I'm not convinced of that. I understand that Gecko need to deal with these complications because of a number of Mozilla-proprietary APIs, Actually, what I'm talking about here has nothing to do with APIs but everything to do with wanting to write web applications that have slightly more privileges than your typical web page. Again, you may want to talk to Jonas and Mounir for details. If and when features are added to the platform that cause these sorts of problems, we can deal with the consequences. My argument is that we should not lock ourselves out of adding such features in the future. In the mean time, I don't think we should force other browser engines to implement a more complicated security model than necessary for the platform as it stands. I'm not saying we should force anyone to implement any particular security model. I'm saying we shouldn't design/spec things that become completely insecure if the security model ever changes in any way and hence prevent evolution of the security model. Which means that we should assume as little as possible about what the security model guarantees us when specifying things. In my opinion. This paragraph was too abstract for me to understand. Do you have a concrete example? For example, Ian's argument is that you can skip security checks in various places because the security model does that already. My counter-argument is that we should define the behavior of those places by referencing the security model explicitly, so that if the security model changes we won't have to hunt down all the places that had implicit dependencies on it. Does that make more sense? Put another way, I think we have good evidence that the security model in the spec, as well as that in every browser, Gecko included, is wrong in the same sense that Newtonian mechanics is wrong. The problem is that we don't know what our equivalent of special relativity is yet. I don't understand the analogy. The current security model describes most common cases, but not some edge cases (see above about a slightly-elevated-privileges web app that can, say, touch nodes from one and only one different origin). More seriously, life gets complicated when you introduce an asymmetric access relation I agree. I believe, however, that for many apps based on web technology you in fact might need this. Again, Sicking and Mounir would know more. https://bugzilla.mozilla.org/show_bug.cgi?id=734891 has some of the things in it, but I'm not sure it's all of them. However, the open web platform contains only a symmetric access relation Yes, I understand that's how it stands now. I'm questioning the viability of this going forward, and especially questioning to what extent we should be intentionally making it impossible to change away from this model. and I intent to argue against any attempt to introduce an asymmetric access That is, of course, your right. ;) Maybe I've lost the thread here, but I don't understand the problem you're trying to solve with this thread. The simplest solution is for contentDocument to return null when accessed from a different origin. That's not enough. Window has the same problem: the document IDL getter needs to check that you're allowed to get the document of the relevant window, for example. Is the check you describe for contentDocument based on origin or effective script origin? -Boris
Re: [whatwg] Proposal: Add CanvasRenderingContext2D.fillRule with nonzero (default) and evenodd options
On Wed, Jan 9, 2013 at 10:27 AM, Dean Jackson d...@apple.com wrote:
On 09/01/2013, at 4:08 PM, Dirk Schulze dschu...@adobe.com wrote:
On Jan 8, 2013, at 9:35 AM, Rik Cabanier caban...@gmail.com wrote:
I looked at pdf2js which is using this fillRule property. As I
expected, introduction of the property results in code like this:
eoFill: function CanvasGraphics_eoFill() {
var savedFillRule = this.setEOFillRule();
this.fill();
this.restoreFillRule(savedFillRule);
},
...
// We generally keep the canvas context set for
// nonzero-winding, and just set evenodd for the operations
// that need them.
setEOFillRule: function CanvasGraphics_setEOFillRule() {
var savedFillRule = this.ctx.mozFillRule;
this.ctx.mozFillRule = 'evenodd';
return savedFillRule;
},
restoreFillRule: function CanvasGraphics_restoreFillRule(rule) {
this.ctx.mozFillRule = rule;
},
So, for even odd winding, all this code needs to run. With my proposal,
this gets much simpler:
eoFill: function CanvasGraphics_eoFill() {
this.eoFill();
},
You can find a pull request with the needed changes to pdf2js here:
https://github.com/cabanier/pdf.js/commit/8e80b086376013a5438087714a4d2abb6fe67de1
For PDF.js it would probably be easier to set the fillRule every time
right before a fill or clip operation, then checking and storing the fill
rule in the background. This would reduce the code a lot more.
I also created patches (with test files) for WebKit and mozilla:
https://bugs.webkit.org/show_bug.cgi?id=106188
https://bugzilla.mozilla.org/show_bug.cgi?id=827053
I looked at the patch for webkit. There are two parts where I would
disagree and that are potentially confusing.
eoFill(), eoClip()
It is not obvious what these functions do and how they are different to
fill() and clip(). The name should be clear about the usage. But I don't
think that introducing two new functions to the Canvas API is a lot better
either. An alternative proposal instead of new functions or attributes
could be an optional argument for the fill() and stroke() functions. This
argument would be an enumeration of 'nonzero' and 'evenodd'.
ctx.fill(); // fill with 'nonzero'
ctx.fill('nonzero') // fill with 'nonzero' as well
ctx.fill('evenodd') // fill with winding rule 'evenodd'
I prefer this approach over new methods.
In general, I tend to agree with Rik that winding rule is a geometric
operation, rather than a context style. It's a shame that this may
introduce inconsistency (I appreciate Ian's point on that).
Thanks Dean!
Do people have an opinion on a boolean value vs an enum?
A boolean value is slightly faster to execute and type while an enum is
more descriptive.
So far, canvas has not used enum values before.
The boolean argument in isPointInPath seems not to be very descriptive
as well:
boolean isPointInPath(unrestricted double x, unrestricted double
y, boolean windingRule);
It is not obvious if 'true' means 'nonzero' or 'evenodd'. I would
recommend to use an optional enumeration here, with the default value
'nonzero'.
You mentioned that the winding rule should be a part of the Path object.
I can see the use case that you want to address with it. And things like a
union path of two path object with different winding rules (as you
suggested before) is possible, as long as the union path just needs to get
drawn (can be done with compositing or masking in the implementation). But
the SVG WG would like to use the Path object as a way to share path data
between Canvas and SVG. In this case, the implementation must be able to
flatten a path and provide the path data directly. This is beyond the
capability of current graphic libraries and requires third party
planarizer. This needs to be considered before adding this functionality to
the Path API.
Greetings,
Dirk
On Thu, Jan 3, 2013 at 3:38 PM, Ian Hickson i...@hixie.ch wrote:
On Fri, 10 Jun 2011, Chris Jones wrote:
In 2D canvas, determining whether a point is inside a path is
currently always done using the non-zero winding rule. I propose
extending 2D canvas to allow determining inside-ness using the even-odd
rule.
I've added this to the spec.
On Wed, 2 Jan 2013, Dirk Schulze wrote:
There was a complain on the webkit bug report if fillRule should be
part
of the graphics state or not. Did you investigate what current 2d
graphics libraries do (qt, Cairo, CG, ...)? Is it part of the graphics
state there?
I have made it be part of the graphics state in the spec; it would be
unusual in the API for it not to be. However, if this doesn't match
implementations, please let me know.
On Wed, 2 Jan 2013, Rik Cabanier wrote:
this features is not a trivial as it seems. Adding this will
necessitate
updates to the algorithms that deal
Re: [whatwg] Canvas in Workers
On Thu, Jan 3, 2013 at 7:46 PM, Gregg Tavares g...@google.com wrote:
On Tue, Dec 11, 2012 at 9:04 AM, Ian Hickson i...@hixie.ch wrote:
On Tue, 11 Dec 2012, Gregg Tavares (社ç~T¨) wrote:
discussion seems to have died down here but I'd like to bring up
another
issue
In WebGL land we have creation attributes on the drawingbuffer made
for a
canvas. Example
gl = canvas.getContext(webgl, { preserveDrawingBuffer: false });
We're working out the details on how to set those options for the case
where we have 1 context and multiple canvases.
The particular option above would apparently be a huge perf win for
canvas 2d for mobile. Which suggests that whatever API is decided on it
would be nice if it worked for both APIs the same.
What does it do?
Effectively it makes the canvas double buffered.
Right now by 2d canvases are effectively single buffered. At the
appropriate time a copy
of the canvas is made and passed to the compositor. This copy is slow,
especially on
mobile.
Currently, to lower the VRAM footprint and improve performance, we don't do
a copy in 2d canvas. We temporarily transfer ownership of the texture to
the compositor at commit time, and block the renderer until the composite
is complete. That may change, however.
Stephen
Apple requested that for WebGL the default be for double buffering. When
double buffered, when the canvas is composited (when the current JavaScript
event exits)
the canvas's buffer is given to the compositor and the canvas is given a
new buffer (or
an old one). That new buffer is cleared, meaning the contents is gone. It's
up to the app to
draw stuff into again. If nothing is drawn the compositor will continue to
use the
buffer it acquired earlier.
In WebGL you can opt into the slower copy path. For Canvas 2D while the
default
has to remain the slow copy path it would be nice to be able to opt into
the faster
swap double buffered path.
In the 2D canvas, whenever you bind to a new canvas, the context is reset
to its default state, the context's hit region list is reset, and the
context's bitmap is reset. The next time the context is flushed, the
canvas itself is always reset (since flushing the context causes the
bitmap and hit region list to be pushed to the canvas, replacing whatever
was there before).
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Proposal: Add CanvasRenderingContext2D.fillRule with nonzero (default) and evenodd options
On Jan 9, 2013, at 11:42 AM, Rik Cabanier
caban...@gmail.commailto:caban...@gmail.com wrote:
On Wed, Jan 9, 2013 at 10:27 AM, Dean Jackson
d...@apple.commailto:d...@apple.com wrote:
On 09/01/2013, at 4:08 PM, Dirk Schulze
dschu...@adobe.commailto:dschu...@adobe.com wrote:
On Jan 8, 2013, at 9:35 AM, Rik Cabanier
caban...@gmail.commailto:caban...@gmail.com wrote:
I looked at pdf2js which is using this fillRule property. As I expected,
introduction of the property results in code like this:
eoFill: function CanvasGraphics_eoFill() {
var savedFillRule = this.setEOFillRule();
this.fill();
this.restoreFillRule(savedFillRule);
},
...
// We generally keep the canvas context set for
// nonzero-winding, and just set evenodd for the operations
// that need them.
setEOFillRule: function CanvasGraphics_setEOFillRule() {
var savedFillRule = this.ctx.mozFillRule;
this.ctx.mozFillRule = 'evenodd';
return savedFillRule;
},
restoreFillRule: function CanvasGraphics_restoreFillRule(rule) {
this.ctx.mozFillRule = rule;
},
So, for even odd winding, all this code needs to run. With my proposal, this
gets much simpler:
eoFill: function CanvasGraphics_eoFill() {
this.eoFill();
},
You can find a pull request with the needed changes to pdf2js here:
https://github.com/cabanier/pdf.js/commit/8e80b086376013a5438087714a4d2abb6fe67de1
For PDF.js it would probably be easier to set the fillRule every time right
before a fill or clip operation, then checking and storing the fill rule in
the background. This would reduce the code a lot more.
I also created patches (with test files) for WebKit and mozilla:
https://bugs.webkit.org/show_bug.cgi?id=106188
https://bugzilla.mozilla.org/show_bug.cgi?id=827053
I looked at the patch for webkit. There are two parts where I would disagree
and that are potentially confusing.
eoFill(), eoClip()
It is not obvious what these functions do and how they are different to
fill() and clip(). The name should be clear about the usage. But I don't
think that introducing two new functions to the Canvas API is a lot better
either. An alternative proposal instead of new functions or attributes could
be an optional argument for the fill() and stroke() functions. This argument
would be an enumeration of 'nonzero' and 'evenodd'.
ctx.fill(); // fill with 'nonzero'
ctx.fill('nonzero') // fill with 'nonzero' as well
ctx.fill('evenodd') // fill with winding rule 'evenodd'
I prefer this approach over new methods.
In general, I tend to agree with Rik that winding rule is a geometric
operation, rather than a context style. It's a shame that this may introduce
inconsistency (I appreciate Ian's point on that).
Thanks Dean!
Do people have an opinion on a boolean value vs an enum?
A boolean value is slightly faster to execute and type while an enum is more
descriptive.
So far, canvas has not used enum values before.
I definitely agree that an enum is more descriptive. I would not necessary
expect that EO is used a lot anyway. A Boolean on the other side can also be
easier to handle for authors. But how would we decide if 'false' stands for
even odd or nonzero? How can it be done so that it is easy to remember for
authors which Boolean to use for which fill rule?
Greetings
Dirk
The boolean argument in isPointInPath seems not to be very descriptive as
well:
boolean isPointInPath(unrestricted double x, unrestricted double y,
boolean windingRule);
It is not obvious if 'true' means 'nonzero' or 'evenodd'. I would recommend
to use an optional enumeration here, with the default value 'nonzero'.
You mentioned that the winding rule should be a part of the Path object. I
can see the use case that you want to address with it. And things like a
union path of two path object with different winding rules (as you suggested
before) is possible, as long as the union path just needs to get drawn (can
be done with compositing or masking in the implementation). But the SVG WG
would like to use the Path object as a way to share path data between Canvas
and SVG. In this case, the implementation must be able to flatten a path and
provide the path data directly. This is beyond the capability of current
graphic libraries and requires third party planarizer. This needs to be
considered before adding this functionality to the Path API.
Greetings,
Dirk
On Thu, Jan 3, 2013 at 3:38 PM, Ian Hickson
i...@hixie.chmailto:i...@hixie.ch wrote:
On Fri, 10 Jun 2011, Chris Jones wrote:
In 2D canvas, determining whether a point is inside a path is
currently always done using the non-zero winding rule. I propose
extending 2D canvas to allow determining inside-ness using the even-odd
rule.
I've added this to the spec.
On Wed, 2 Jan 2013, Dirk Schulze wrote:
There was a complain on the webkit bug report if fillRule should
Re: [whatwg] Canvas in Workers
On Wed, 9 Jan 2013, Stephen White wrote: Right now by 2d canvases are effectively single buffered. At the appropriate time a copy of the canvas is made and passed to the compositor. This copy is slow, especially on mobile. Currently, to lower the VRAM footprint and improve performance, we don't do a copy in 2d canvas. We temporarily transfer ownership of the texture to the compositor at commit time, and block the renderer until the composite is complete. That may change, however. Good to know, thanks. Should this change, or should there be a desire for a mode where it looks like after the commit the buffer is cleared, please do let me know. Would still love input from any other vendors, too. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 2:30 PM, Adam Barth wrote: As a consequence, I would recommend that you do not use asymmetric access relations in features that you would like other browser vendors to implement in the future. Browsers have asymmetric access relations all the time; they just have some of the code in C++. The question is why this should be restricted to C++ code. -Boris
Re: [whatwg] Canvas in Workers
On Wed, Jan 9, 2013 at 2:50 PM, Stephen White senorbla...@chromium.orgwrote: Currently, to lower the VRAM footprint and improve performance, we don't do a copy in 2d canvas. We temporarily transfer ownership of the texture to the compositor at commit time, and block the renderer until the composite is complete. That may change, however. Stephen To be more accurate, the renderer only blocks if it needs to access the texture, for example if getImageData is called before the composite is complete. All write operations are non-blocking because they can be recorded an deferred until the composite is complete.
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 3:12 PM, Adam Barth wrote:
As I've stated several times on this thread (any many times over the
years), my opinion is that we should not expose an asymmetric access
relation to the web platform.
OK, let's agree to disagree on this one for now.
Do we at least agree that this code:
window.addEventListener.call(otherWindow, click, function() {});
should throw if and only window and otherWindow are not same-origin (for
some definition of same-origin, now that we have several different
origins involved...)? And if we do, do we agree that this needs to be
specified somewhere?
-Boris
Re: [whatwg] Script-related feedback
On Wed, 9 Jan 2013, Adam Barth wrote:
Working through some examples, that seems really strange:
foo();
breakParsing();
bar();
In this case, breakParsing() works a bit like yield() in other
programming languages: first foo() executes, then the event loop
spins, then bar() executes. However, if we wrap the code in an
anonymous function block (as would make sense for JavaScript):
(function() {
foo();
breakParsing();
bar();
})();
Now I get either get a parse error, if breakParsing() actually breaks up
the parsing, or breakParsing() does nothing, both of which are
surprising.
That's why I originally proposed it as a pragma comment (which I'm pretty
sure would be just as safe, because anything that stops someone from
escaping a string injection in any way will stop both identifiers and
comments, and it seems highly unlike that someone would go out of their
way to let you escape a string literal and be allowed to inject a comment
but not be allowed to inject a division or method call or whatnot).
Worse, other seemingly trivial syntactic transformation also break the
magic:
foo();
breakParsing.call();
bar();
Now the JavaScript parse won't recognize the magic breakParsing();
production, and my script executes slowly.
So let's not use something that looks like a method call -- I agree that
isn't ergonomically or aesthetically pleasing.
/*@BREAK*/
I guess I don't understand the advantage of trying to cram this into
JavaScript syntax.
Advantages of putting this in JS over multipart:
- it's backwards-compatible
- it's easier to parse a static barrier than a multipart/*'s wacky
syntax.
- it doesn't impact any of the current fetching logic, since it's
still just one resource instead of introducing a layer in between
script's logic and the JS logic.
- it automatically works anywhere you can use JS, not just where HTTP is
involved.
- it can be shimmed more easily (if you trust the JS not to have
arbitrary injection and be written with the shim in mind, especially).
- it doesn't run into weird problems like what if a part has the wrong
MIME type.
- it's way easier to deploy (authors hate having to set MIME types).
- it doesn't run into the problem that all UAs have historically ignored
the MIME type of script.
HTTP already has an efficient mechanism for delivering several
JavaScript programs in sequence: multipart.
Efficient isn't the word I would have used.
Given that img and iframe already support multipart, it seems much
simpler just to make script support multipart as well.
Given how much pain multipart was to handle in img and iframe,
avoiding it like the plague seems like the more appropriate lesson. :-)
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Canvas in Workers
On Wed, 9 Jan 2013, James Robinson wrote: On Wed, Jan 9, 2013 at 11:59 AM, Ian Hickson i...@hixie.ch wrote: On Wed, 9 Jan 2013, Stephen White wrote: Right now by 2d canvases are effectively single buffered. At the appropriate time a copy of the canvas is made and passed to the compositor. This copy is slow, especially on mobile. Currently, to lower the VRAM footprint and improve performance, we don't do a copy in 2d canvas. We temporarily transfer ownership of the texture to the compositor at commit time, and block the renderer until the composite is complete. That may change, however. Good to know, thanks. Should this change, or should there be a desire for a mode where it looks like after the commit the buffer is cleared, please do let me know. We (chromium) would really appreciate a way for the author to express clear-after-commit. I think this would match up with what authors frequently want, since many canvas pages clear the canvas at the start of the next frame anyway, but allow for more flexibility and optimizations in our implementation. Noted: http://wiki.whatwg.org/wiki/New_Features_Awaiting_Implementation_Interest -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, Jan 9, 2013 at 12:23 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 1/9/13 3:12 PM, Adam Barth wrote:
As I've stated several times on this thread (any many times over the
years), my opinion is that we should not expose an asymmetric access
relation to the web platform.
OK, let's agree to disagree on this one for now.
Do we at least agree that this code:
window.addEventListener.call(otherWindow, click, function() {});
should throw if and only window and otherWindow are not same-origin (for
some definition of same-origin, now that we have several different origins
involved...)?
This example does not appear to throw an exception in Chrome. It
appears to just returns undefined without doing anything (except
logging a security error to the debug console).
And if we do, do we agree that this needs to be specified somewhere?
Yes, but this example is unrelated to the example you started this
thread with. The WindowProxy and Location objects are special,
magical objects that work differently from other interfaces because
they are visible across origins. The Document interface (which is
what we started this thread discussing) is never visible across
origins and so does not have any of these complexities. Earlier in
this thread, you wrote that you didn't want to discuss Location:
---8---
I'm not touching Location with a 10-foot pole. That's all Bobby. ;)
Seriously, though, fitting Location into any sort of security setup is
somewhat hard.
---8---
The WindowProxy object is even more complex than the Location object.
I agree that fitting Location and WindowProxy into any sort of
security setup is difficult. That's why I don't want to infect the
rest of the platform with their complexity. (I again, I understand
that Gecko has already jumped of the cliff in this regard---I'm just
not interested in jump off as well.)
Adam
Re: [whatwg] Proposal: Add CanvasRenderingContext2D.fillRule with nonzero (default) and evenodd options
Thanks for your feedback!
Based on this, I propose the following:
1. create an enum for the winding rule:
enum CanvasWindingRule { nonzero
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-nonzero,
evenodd
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-evenodd
};
Since this enum will likely be used by the path syntax (and possibly SVG),
maybe we can leave the 'Canvas' portion off
2. extend fill:
void fill
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fill(optional
CanvasWindingRule w = nonzero
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-nonzero);
3. extend clip:
void c
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-filllip(optional
CanvasWindingRule w = nonzero
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-nonzero);
4. extend isPointInPath:
boolean isPointInPath
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-ispointinpath(unrestricted
double x, unrestricted double y, optional CanvasWindingRule w =
nonzero
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-nonzero);
Rik
On Wed, Jan 9, 2013 at 11:59 AM, Tab Atkins Jr. jackalm...@gmail.comwrote:
On Wed, Jan 9, 2013 at 11:42 AM, Rik Cabanier caban...@gmail.com wrote:
Do people have an opinion on a boolean value vs an enum?
A boolean value is slightly faster to execute and type while an enum is
more descriptive.
So far, canvas has not used enum values before.
I strongly prefer enums for cases where it's not a simple yes/no, and
this clearly qualifies.
(I also prefer enums generally even when this is true, but that's my
CSS experience talking, where we have a history of changing things
that were once booleans into multi-state when people ask for more
features later.)
~TJ
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, 9 Jan 2013, Adam Barth wrote: The Document interface (which is what we started this thread discussing) is never visible across origins and so does not have any of these complexities. Actually Document objects can be visible across origins per spec, but none of their properties ever are. The four magic interfaces are Window, Document, Storage, and Location. They each have slightly different magic. But as far as this thread goes, the solution for all four is basically the same; calling code on any of them should just run the same check as is run when access properties on them. I'm happy to spec this, but IMHO the right spec is for WebIDL to introduce some hook I can use to make sure I catch all the relevant places. I don't really want the HTML spec to enumerate all the things here like getters and setters and methods and so forth that are relevant, I'd like it to just hook all of them at once, providing the algorithm for each of the above four interfaces, just like we do now for direct accesses. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Tue, Jan 8, 2013 at 7:46 AM, Boris Zbarsky bzbar...@mit.edu wrote: Actually, that's not enough. You have to security-check arguments too. Otherwise this: document.createTreeWalker(crossFrameDoc, etc); would be bad. (Note that right now the DOM spec fails to handle this, which is about what I would expect out of people creating APIs, which is why I would really prefer we define this on a low level where people can't screw up by forgetting it.) You didn't file a bug on this I think. I did think HTML handled this already though which is why it is not addressed in the DOM specification. -- http://annevankesteren.nl/
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, Jan 9, 2013 at 1:28 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 9 Jan 2013, Adam Barth wrote: The Document interface (which is what we started this thread discussing) is never visible across origins and so does not have any of these complexities. Actually Document objects can be visible across origins per spec, but none of their properties ever are. For what it's worth, that doesn't appear to be necessary for web compatibility. Any time WebKit would return a Document to a script in another origin, WebKit returns null instead. Adam
Re: [whatwg] seamless iframes and event propagation
On Tue, Jan 8, 2013 at 6:32 PM, Dimitri Glazkov dglaz...@chromium.org wrote: 1) For a tree a -- [shadow root] - b -- [shadow root] - c (where - denotes child-parent relationship and -- denotes host-root relationship) 2) if an event is dispatched on c 3) where is the event target's adjusted? If that's the question, then it needs to be adjusted twice: at b (the adjusted target becomes b) and at a (the adjusted target becomes a). My bad, I actually meant if a's associated shadow tree had an insertion point through which a's child, which is b, would go and then the event would be dispatched in b's associated shadow tree. (I phrased that beyond poorly however and only tried to make up for it on IRC.) 3) Also when invoking event listeners (http://dom.spec.whatwg.org/#concept-event-listener-invoke), between steps 3 and 4, we have to: a) if the type of event is MouseEvent, adjust offsetX and offsetY relative to relative target. b) If the type of event has a relatedTarget attribute (MouseEvent, FocusEvent), adjust it using http://dvcs.w3.org/hg/webcomponents/raw-file/tip/spec/shadow/index.html#dfn-related-target-algorithm. Are you sure this happens at that point? Because at that point the DOM could have completely changed due to event callbacks. That's a good point. In WebKit implementation, the tuple mentioned in #1 also contains relatedTarget, but I neglected to mention this in the spec. Filed https://www.w3.org/Bugs/Public/show_bug.cgi?id=20604. So why are offsetX and offsetY not calculated in advance? Those would be affected by DOM manipulation in event listeners too. (If you have all those attributes being different, would it not be easier to use a different event object?) Incidentally, was there any progress made on the magic list of events that should not leak out of the upper boundary? If that list is based on implementation experience of certain widgets in WebKit, maybe it would be better if those widgets instead themselves took care of those events not leaking through by having the appropriate event listeners? Hmm, I guess that might not work for capturing... :/ -- http://annevankesteren.nl/
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 4:12 PM, Adam Barth wrote:
window.addEventListener.call(otherWindow, click, function() {});
This example does not appear to throw an exception in Chrome. It
appears to just returns undefined without doing anything (except
logging a security error to the debug console).
Hmm. I may be able to convince that turning security errors like this
into silent no-ops returning undefined is ok, but throwing an exception
seems like a much better idea to me if you're going to completely not do
what you were asked to do... The other option introduces hard-to-debug
bugs.
Yes, but this example is unrelated to the example you started this
thread with.
How so? The example was that IDL methods need to do security checks on
their arguments in various cases.
The WindowProxy and Location objects are special,
magical objects that work differently from other interfaces because
they are visible across origins.
However you prefer to think of it.
The Document interface (which is
what we started this thread discussing) is never visible across
origins
It is in the current spec.
The WindowProxy object is even more complex than the Location object.
It's actually simpler, in the aspects that matter for WebIDL security,
because underlying it is an actual Window object that you're same-origin
with or not, and you can just do security checks on it as needed. And
since the WebIDL is defined to work on the Window, it has to be able to
get to the Window from the WindowProxy anyway.
-Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 4:33 PM, Adam Barth wrote: For what it's worth, that doesn't appear to be necessary for web compatibility. Any time WebKit would return a Document to a script in another origin, WebKit returns null instead. The HTML spec requires that property access on documents use effective script origin for checks. Effective script origins are mutable. It is in fact possible to get your hands on a document in a different effective script origin in WebKit (thanks, document.domain). Just saying, Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 4:28 PM, Anne van Kesteren wrote: You didn't file a bug on this I think. Yes, because the DOM spec is not the right place to address it, imo. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On 1/9/13 5:19 PM, Adam Barth wrote: Those checks are neither required for compatibility nor security. The spec might say to perform the checks, but they aren't needed to build a secure, compatible browser. OK. So what checks do you believe are required, then? Just effective script origin checks on Window? I would really appreciate it if you would actually describe the security model you think the spec should have instead of us having to guess what parts you think are needed and which parts you think are not needed, with more gotchas and details all the time. -Boris
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, 9 Jan 2013, Boris Zbarsky wrote:
On 1/9/13 4:12 PM, Adam Barth wrote:
window.addEventListener.call(otherWindow, click, function() {});
This example does not appear to throw an exception in Chrome. It
appears to just returns undefined without doing anything (except
logging a security error to the debug console).
Hmm. I may be able to convince that turning security errors like this into
silent no-ops returning undefined is ok, but throwing an exception seems like
a much better idea to me if you're going to completely not do what you were
asked to do... The other option introduces hard-to-debug bugs.
FWIW I have run into this behaviour in WebKit in the context of using the
platform, and I considered it very user-hostile.
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, Jan 9, 2013 at 2:18 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/9/13 4:33 PM, Adam Barth wrote: For what it's worth, that doesn't appear to be necessary for web compatibility. Any time WebKit would return a Document to a script in another origin, WebKit returns null instead. The HTML spec requires that property access on documents use effective script origin for checks. Effective script origins are mutable. It is in fact possible to get your hands on a document in a different effective script origin in WebKit (thanks, document.domain). Those checks are neither required for compatibility nor security. The spec might say to perform the checks, but they aren't needed to build a secure, compatible browser. Adam
Re: [whatwg] Including HTML more directly into SVG
On Fri, Dec 28, 2012 at 8:59 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 10 Sep 2012, Tab Atkins Jr. wrote: 1. Check out http://www.xanthir.com/etc/railroad-diagrams/example.html . See all those boxes full of text in the diagrams? Looks simple, right? Just a box filled with text, with a border and background set on it. Wrong! SVG doesn't have any primitives like that. Instead, you have to position the text, measure its dimensions (or, like I've done, guess at the dimensions based on the font-size and such), then create and position an *independent* rect element behind it, so that it *looks* like there's a box with text inside of it. Well, you can just put the text in a foreignObject with a div, and style that. Your bigger problem is going to be positioning the lines on the other side of the rect/foreignObject. This would be a lot easier if I could somehow invoke the CSS box model inside of SVG, but the text element doesn't allow that. That's what foreignObject is for. I agree. When we discussed this a couple of months ago, people did not like the name. Why is HTML considered 'foreign'? Also, browser have identified multiple security issues with foreignObject. AFAIK the SVG spec doesn't mention any of them. I think a new tag in SVG is needed that just support inclusion of HTML. In addition, it needs to define the security model and allow the HTML to draw outside of its box. Closely related to this, SVG doesn't do automatic linebreaking at all. If you want text to break, you have to do it manually, not only determining the break points but also manually setting the line-spacing separation for each individual line. Again, it would be cool to invoke the CSS box model here, so we get full-power inline layout. foreignObject does that too. [...] there is an a11y tool that lets low-vision users interact better with SVG diagrams. They can print out an SVG, attach it over a pressure-sensitive touchpad, then bring up the diagram on the screen as well. Using the touchpad, they can then zoom/pan the SVG, or even ask the computer to read out text at the location they've pressed. Unfortunately, the textual semantics in SVG are pretty impoverished right now; there *aren't* any semantics, besides here is text. It seems pretty obvious that you'd sometimes want to, say, emphasize a span of text inside a larger text block in a diagram, but right now the only way to do that is by using tspan style=font-style:italic; and hoping that the reader supports enough CSS to guess that italicized text should be emphasized. How common is it for text in a diagram to be emphasised to the point where you definitely need a clear indication in a speech-synthesis rendering done in conjunction with a visual display? It seems like it'd be rare enough that the mere visual indication of italics would make it pretty obvious to the user what was going on... It would be pretty nice if you could use em or the other textual HTML elements here, for the same reason it's nice to use them in HTML rather than relying on visual presentation. In the cases where you need this, isn't foreignObject enough? 3. Related to the above, it seems useful to be able to embed special elements like input type=date, video, or details into SVG, for the same reasons you'd include them in HTML. Or MathML, indeed. Again, this seems reasonably easy with foreignObject. Which you point out: Right now, all three of the above *could* be done by using the foreignContent element. Right. :-) This is a horrible solution, though. To use foreignContent, you need to specify a width and height (and we're back to measuring or guessing at the dimensions...) and specify a namespace. This is a lot of weight to put into a document when all you want to do is include some simple text. You don't have to specify a namespace in text/html, but agreed about the width and height. Even worse, IMHO, is having to use the name foreignObject, which is highly unwieldy. It would definitely be nice to have an element in SVG with a short name that introduced an HTML context in text/html, and that was shrink-wrap enabled. Even better would then to be able to reference the dimensions from other elements, so that you wouldn't have to measure the element anyway (e.g. to position the line in your example above). I would recommend calling this element svg:div, for what it's worth. (I had an xbl:div for similar reasons). But any short name would do, e.g. html, or block, or flow, or whatever. Another solution could be SVG inventing their own elements for these kinds of things. That doesn't seem like a good plan, as you point out. My preferred solution is to simply include HTML directly into SVG. I presume you don't mean duplicating the elements in both namespaces, but making the text/html parser detect which elements are where? This solves #1 perfectly
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, Jan 9, 2013 at 2:24 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 1/9/13 5:19 PM, Adam Barth wrote: Those checks are neither required for compatibility nor security. The spec might say to perform the checks, but they aren't needed to build a secure, compatible browser. OK. So what checks do you believe are required, then? Just effective script origin checks on Window? I would really appreciate it if you would actually describe the security model you think the spec should have instead of us having to guess what parts you think are needed and which parts you think are not needed, with more gotchas and details all the time. Answering this question in detail would take a great deal of time. I can try to summarize how WebKit handles this issues. In general WebKit tries to follow the spec's approach to these security checks, although there are some difference for historical reasons (e.g., not throwing exceptions, exposing or not exposing certain properties across origins). Generally speaking, I'd recommend exposing as few things across origins as possible. For example, I view WebKit's not exposing Document across origins as better than the spec's exposing it, whereas I view WebKit's exposing window.history across origins as worse than the spec's not exposing it. IMHO, we should aim for exposing the minimal set of things across origins. To gather this information, I grepped the WebKit IDL files for CheckSecurity. Here's what I learned: 1) By default, DOMWindow (which might translate into Window or WindowProxy in the spec---I'd need to study that issue more carefully) needs to perform access checks. There are a number of properties that are white listed, similar to what's described in the spec (cross-origin readers get fresh copies of the underlying interfaces regardless of any changes made to the DOMWindow in JavaScript and these fresh copies have prototype chains that connect up with the *caller's* JavaScript prototypes, not the DOMWindow's JavaScript prototypes). 2) window.history, window.location, window.focus, window.blur, window.close, window.closed, window.length, window.window, window.frames, window.opener, window.parent, window.top, window.postMessage, and window.toString are whitelisted to be exposed across origins (often just the getters, not the setters). There's some additional complexity related to the names of nested browsing context and the indexed property getter, but I believe the description in the current spec is accurate. 3) The History interfaces works much like the DOMWindow interface (properties are blocked by default and certain whitelisted properties are visible across origins on the same fresh, pristine basis as the properties on DOMWindow). 4) history.back, history.forward, and history.go are whitelisted. 5) The Location interface works much like DOMWindow and History, but the only whitelisted property is the location.href setter. 6) In addition, the following APIs have extra security checks. All these APIs return a Node. Before returning the Node, they check whether the Node's document's origin is the same origin as the script calling the API. If not, they return null instead of the node. (We could potentially throw an exception here, but I'm just describing what WebKit does, not what I think the optimum design is.) A) HTMLEmbedObject#getSVGDocument() B) HTMLFrameElement#contentDocument C) HTMLFrameElement#getSVGDocument() D) HTMLIFrameElement#contentDocument E) HTMLIFrameElement#getSVGDocument() F) HTMLObjectElement#contentDocument G) HTMLObjectElement#getSVGDocument() H) DOMWindow#frameElement With regards to your original question about using Function.prototype.call to manipulate the this value passed to function, I don't remember the details of how we dealt with that issue. I'd have to write some careful test cases to study WebKit's behavior to give you a definitive answer. We might have either ignored the this value entirely (and always operated on the object that held the property originally) or we might have insisted on always checking whether the calling script was same-origin with the this parameter for the three interfaces (DOMWindow, Location, and History) where the caller could possibly have a reference to a cross-origin object to pass as this. In addition to everything described above, there are some additional security issues related to operator eval and function eval, but I've left them out here because they're not relevant for the HTML spec. I should also say that it's entirely possible we've screwed up our implementation of this security model. If you discover that we have, I'd prefer if you filed a security bug rather than telling the world on this public mailing list. :) Adam
[whatwg] `window.location.origin` in sandboxed IFrames.
Hello! In WebKit, loading 'iframe sandbox=allow-scripts src=frame.html/iframe' with a framed document containing 'scriptalert(window.location.origin);/script' alerts the actual origin of the document, which wasn't what I expected. I'm not sure what's intended, but I expected that treating the framed document as existing in a unique origin would have some effect on the string output as it's location's origin. Adam explained that WebKit currently treats the 'origin' attribute as the origin of the document's location, not the origin of the document[1]. This is generally benign, but surprised me in the sandboxed case. What should the expected behavior in this case be? Given the way that MessageEvent sets the origin of a message from a sandboxed frame to the string null, that seems like a reasonable option here as well. WDYT? [1]: https://bugs.webkit.org/show_bug.cgi?id=106488#c1 -- Mike West mk...@google.com, Developer Advocate Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany Google+: https://mkw.st/+, Twitter: @mikewest, Cell: +49 162 10 255 91
Re: [whatwg] Including HTML more directly into SVG
On Jan 9, 2013, at 2:18 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Dec 28, 2012 at 8:59 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 10 Sep 2012, Tab Atkins Jr. wrote: 1. Check out http://www.xanthir.com/etc/railroad-diagrams/example.html . See all those boxes full of text in the diagrams? Looks simple, right? Just a box filled with text, with a border and background set on it. Wrong! SVG doesn't have any primitives like that. Instead, you have to position the text, measure its dimensions (or, like I've done, guess at the dimensions based on the font-size and such), then create and position an *independent* rect element behind it, so that it *looks* like there's a box with text inside of it. Well, you can just put the text in a foreignObject with a div, and style that. Your bigger problem is going to be positioning the lines on the other side of the rect/foreignObject. This would be a lot easier if I could somehow invoke the CSS box model inside of SVG, but the text element doesn't allow that. That's what foreignObject is for. I agree. When we discussed this a couple of months ago, people did not like the name. Why is HTML considered 'foreign'? Also, browser have identified multiple security issues with foreignObject. AFAIK the SVG spec doesn't mention any of them. I think a new tag in SVG is needed that just support inclusion of HTML. In addition, it needs to define the security model and allow the HTML to draw outside of its box. I guess you mean things like shadows and filter output should not be clipped? In this case the new element would not interact as some kind of iframe, but as an integral part of SVG, allowing to better mix SVG and HTML. I think this is a good way to go and should be implementable. The reason why it is not so easy to allow HTML elements to be embedded into SVG directly are the different kind of concepts. HTML elements contribute to the CSS Boxing Model with relative positioning and layout. SVG elements need information about the coordinates and dimension. While I could imagine that SVG elements can contribute to the CSS Boxing Model when they would be put into HTML content without surrounding them with an svg elements, the other way around is more difficult. Turning a relative positioned, layout based element into a coordinate, size based context is not so easy. A new element as you both describe it here can help a lot. Greetings, Dirk Closely related to this, SVG doesn't do automatic linebreaking at all. If you want text to break, you have to do it manually, not only determining the break points but also manually setting the line-spacing separation for each individual line. Again, it would be cool to invoke the CSS box model here, so we get full-power inline layout. foreignObject does that too. [...] there is an a11y tool that lets low-vision users interact better with SVG diagrams. They can print out an SVG, attach it over a pressure-sensitive touchpad, then bring up the diagram on the screen as well. Using the touchpad, they can then zoom/pan the SVG, or even ask the computer to read out text at the location they've pressed. Unfortunately, the textual semantics in SVG are pretty impoverished right now; there *aren't* any semantics, besides here is text. It seems pretty obvious that you'd sometimes want to, say, emphasize a span of text inside a larger text block in a diagram, but right now the only way to do that is by using tspan style=font-style:italic; and hoping that the reader supports enough CSS to guess that italicized text should be emphasized. How common is it for text in a diagram to be emphasised to the point where you definitely need a clear indication in a speech-synthesis rendering done in conjunction with a visual display? It seems like it'd be rare enough that the mere visual indication of italics would make it pretty obvious to the user what was going on... It would be pretty nice if you could use em or the other textual HTML elements here, for the same reason it's nice to use them in HTML rather than relying on visual presentation. In the cases where you need this, isn't foreignObject enough? 3. Related to the above, it seems useful to be able to embed special elements like input type=date, video, or details into SVG, for the same reasons you'd include them in HTML. Or MathML, indeed. Again, this seems reasonably easy with foreignObject. Which you point out: Right now, all three of the above *could* be done by using the foreignContent element. Right. :-) This is a horrible solution, though. To use foreignContent, you need to specify a width and height (and we're back to measuring or guessing at the dimensions...) and specify a namespace. This is a lot of weight to put into a document when all you want to do is include some simple text. You don't have to specify a namespace in text/html, but agreed
Re: [whatwg] Including HTML more directly into SVG
On Wed, Jan 9, 2013 at 3:26 PM, Dirk Schulze dschu...@adobe.com wrote: On Jan 9, 2013, at 2:18 PM, Rik Cabanier caban...@gmail.com wrote: On Fri, Dec 28, 2012 at 8:59 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 10 Sep 2012, Tab Atkins Jr. wrote: 1. Check out http://www.xanthir.com/etc/railroad-diagrams/example.html . See all those boxes full of text in the diagrams? Looks simple, right? Just a box filled with text, with a border and background set on it. Wrong! SVG doesn't have any primitives like that. Instead, you have to position the text, measure its dimensions (or, like I've done, guess at the dimensions based on the font-size and such), then create and position an *independent* rect element behind it, so that it *looks* like there's a box with text inside of it. Well, you can just put the text in a foreignObject with a div, and style that. Your bigger problem is going to be positioning the lines on the other side of the rect/foreignObject. This would be a lot easier if I could somehow invoke the CSS box model inside of SVG, but the text element doesn't allow that. That's what foreignObject is for. I agree. When we discussed this a couple of months ago, people did not like the name. Why is HTML considered 'foreign'? Also, browser have identified multiple security issues with foreignObject. AFAIK the SVG spec doesn't mention any of them. I think a new tag in SVG is needed that just support inclusion of HTML. In addition, it needs to define the security model and allow the HTML to draw outside of its box. I guess you mean things like shadows and filter output should not be clipped? In this case the new element would not interact as some kind of iframe, but as an integral part of SVG, allowing to better mix SVG and HTML. I think this is a good way to go and should be implementable. Yes, if the embedded HTML is just a single p element and if it has a border or a shadow, those should not be clipped. Even a transform should be able to move the p box without it being clipped. The reason why it is not so easy to allow HTML elements to be embedded into SVG directly are the different kind of concepts. HTML elements contribute to the CSS Boxing Model with relative positioning and layout. SVG elements need information about the coordinates and dimension. While I could imagine that SVG elements can contribute to the CSS Boxing Model when they would be put into HTML content without surrounding them with an svg elements, the other way around is more difficult. Turning a relative positioned, layout based element into a coordinate, size based context is not so easy. A new element as you both describe it here can help a lot. I agree. This is why the new element (just like foreignObject) will need a width and height so the UA can do layout in that area. Closely related to this, SVG doesn't do automatic linebreaking at all. If you want text to break, you have to do it manually, not only determining the break points but also manually setting the line-spacing separation for each individual line. Again, it would be cool to invoke the CSS box model here, so we get full-power inline layout. foreignObject does that too. [...] there is an a11y tool that lets low-vision users interact better with SVG diagrams. They can print out an SVG, attach it over a pressure-sensitive touchpad, then bring up the diagram on the screen as well. Using the touchpad, they can then zoom/pan the SVG, or even ask the computer to read out text at the location they've pressed. Unfortunately, the textual semantics in SVG are pretty impoverished right now; there *aren't* any semantics, besides here is text. It seems pretty obvious that you'd sometimes want to, say, emphasize a span of text inside a larger text block in a diagram, but right now the only way to do that is by using tspan style=font-style:italic; and hoping that the reader supports enough CSS to guess that italicized text should be emphasized. How common is it for text in a diagram to be emphasised to the point where you definitely need a clear indication in a speech-synthesis rendering done in conjunction with a visual display? It seems like it'd be rare enough that the mere visual indication of italics would make it pretty obvious to the user what was going on... It would be pretty nice if you could use em or the other textual HTML elements here, for the same reason it's nice to use them in HTML rather than relying on visual presentation. In the cases where you need this, isn't foreignObject enough? 3. Related to the above, it seems useful to be able to embed special elements like input type=date, video, or details into SVG, for the same reasons you'd include them in HTML. Or MathML, indeed. Again, this seems reasonably easy with foreignObject. Which you point out: Right
Re: [whatwg] Proposal: Add CanvasRenderingContext2D.fillRule with nonzero (default) and evenodd options
Hi,
Thanks Rik for your counter proposal and thanks everyone for helping to
refine it. I am in full agreement that an evenodd or nonzero argument to
the fill() and clip() operations is better than a state property. The only
thing I can think of in favor of the fillRule property that prompted this
discussion is for client code to discover whether the feature is
implemented.
pdf.js seems like a great example of a need for this. They are going to
need to check whether the fill() operation supports setting the winding
rule and fall back to the mozFillRule property if not. Some website might
need to detect that neither feature is present and fall back to server-side
rendering.
How can the presence of the winding rule parameter of the fill() and clip()
operations be detected by client code? Perhaps I missed something in the
discussion.
Regards,
James
P.S. Looks like I might not get my first patch into WebKit as I had hoped.
I am still happy to help out coding some of this and writing up test cases
so please let me know if there is something you think I can contribute.
On 9 January 2013 21:20, Rik Cabanier caban...@gmail.com wrote:
Thanks for your feedback!
Based on this, I propose the following:
1. create an enum for the winding rule:
enum CanvasWindingRule { nonzero
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-nonzero
,
evenodd
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-evenodd
};
Since this enum will likely be used by the path syntax (and possibly SVG),
maybe we can leave the 'Canvas' portion off
2. extend fill:
void fill
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fill
(optional
CanvasWindingRule w = nonzero
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-nonzero
);
3. extend clip:
void c
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fill
lip(optional
CanvasWindingRule w = nonzero
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-nonzero
);
4. extend isPointInPath:
boolean isPointInPath
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-ispointinpath
(unrestricted
double x, unrestricted double y, optional CanvasWindingRule w =
nonzero
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-nonzero
);
Rik
On Wed, Jan 9, 2013 at 11:59 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Wed, Jan 9, 2013 at 11:42 AM, Rik Cabanier caban...@gmail.com
wrote:
Do people have an opinion on a boolean value vs an enum?
A boolean value is slightly faster to execute and type while an enum is
more descriptive.
So far, canvas has not used enum values before.
I strongly prefer enums for cases where it's not a simple yes/no, and
this clearly qualifies.
(I also prefer enums generally even when this is true, but that's my
CSS experience talking, where we have a history of changing things
that were once booleans into multi-state when people ask for more
features later.)
~TJ
Re: [whatwg] Proposal: Add CanvasRenderingContext2D.fillRule with nonzero (default) and evenodd options
On Wed, Jan 9, 2013 at 3:56 PM, James Ascroft-Leigh j...@jwal.me.uk wrote:
Hi,
Thanks Rik for your counter proposal and thanks everyone for helping to
refine it. I am in full agreement that an evenodd or nonzero argument to
the fill() and clip() operations is better than a state property. The only
thing I can think of in favor of the fillRule property that prompted this
discussion is for client code to discover whether the feature is
implemented.
pdf.js seems like a great example of a need for this. They are going to
need to check whether the fill() operation supports setting the winding
rule and fall back to the mozFillRule property if not. Some website might
need to detect that neither feature is present and fall back to server-side
rendering.
How can the presence of the winding rule parameter of the fill() and
clip() operations be detected by client code? Perhaps I missed something
in the discussion.
We did not discuss it. You can use 'isPointInPath' with the 'evenOdd'
parameter to see if it's being honored.
Regards,
James
P.S. Looks like I might not get my first patch into WebKit as I had hoped.
I am still happy to help out coding some of this and writing up test cases
so please let me know if there is something you think I can contribute.
Do you want to take over my patch?
On 9 January 2013 21:20, Rik Cabanier caban...@gmail.com wrote:
Thanks for your feedback!
Based on this, I propose the following:
1. create an enum for the winding rule:
enum CanvasWindingRule { nonzero
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-nonzero
,
evenodd
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-evenodd
};
Since this enum will likely be used by the path syntax (and possibly SVG),
maybe we can leave the 'Canvas' portion off
2. extend fill:
void fill
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fill
(optional
CanvasWindingRule w = nonzero
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-nonzero
);
3. extend clip:
void c
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fill
lip(optional
CanvasWindingRule w = nonzero
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-nonzero
);
4. extend isPointInPath:
boolean isPointInPath
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-ispointinpath
(unrestricted
double x, unrestricted double y, optional CanvasWindingRule w =
nonzero
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#dom-context-2d-fillrule-nonzero
);
Rik
On Wed, Jan 9, 2013 at 11:59 AM, Tab Atkins Jr. jackalm...@gmail.com
wrote:
On Wed, Jan 9, 2013 at 11:42 AM, Rik Cabanier caban...@gmail.com
wrote:
Do people have an opinion on a boolean value vs an enum?
A boolean value is slightly faster to execute and type while an enum
is
more descriptive.
So far, canvas has not used enum values before.
I strongly prefer enums for cases where it's not a simple yes/no, and
this clearly qualifies.
(I also prefer enums generally even when this is true, but that's my
CSS experience talking, where we have a history of changing things
that were once booleans into multi-state when people ask for more
features later.)
~TJ
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, 9 Jan 2013, Adam Barth wrote: On Wed, Jan 9, 2013 at 1:28 PM, Ian Hickson i...@hixie.ch wrote: On Wed, 9 Jan 2013, Adam Barth wrote: The Document interface (which is what we started this thread discussing) is never visible across origins and so does not have any of these complexities. Actually Document objects can be visible across origins per spec, but none of their properties ever are. For what it's worth, that doesn't appear to be necessary for web compatibility. Any time WebKit would return a Document to a script in another origin, WebKit returns null instead. That's interesting. Would other browser vendors be willing to do that? I'm certainly eager to make it null if we can get away with it. Would reduce the number of objects that need magic from 4 to 3. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, 9 Jan 2013, Boris Zbarsky wrote: On 1/9/13 4:33 PM, Adam Barth wrote: For what it's worth, that doesn't appear to be necessary for web compatibility. Any time WebKit would return a Document to a script in another origin, WebKit returns null instead. The HTML spec requires that property access on documents use effective script origin for checks. Effective script origins are mutable. It is in fact possible to get your hands on a document in a different effective script origin in WebKit (thanks, document.domain). Yeah but in that particular situation it's not a big deal to not have the security check as far as I can tell. So if we can just return null instead, it would allow us to remove those checks. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, 9 Jan 2013, James Graham wrote:
On Wed, 9 Jan 2013, Boris Zbarsky wrote:
On 1/9/13 4:12 PM, Adam Barth wrote:
window.addEventListener.call(otherWindow, click, function()
{});
This example does not appear to throw an exception in Chrome. It
appears to just returns undefined without doing anything (except
logging a security error to the debug console).
Hmm. I may be able to convince that turning security errors like this
into silent no-ops returning undefined is ok, but throwing an
exception seems like a much better idea to me if you're going to
completely not do what you were asked to do... The other option
introduces hard-to-debug bugs.
FWIW I have run into this behaviour in WebKit in the context of using
the platform, and I considered it very user-hostile.
Yeah, we should throw SecurityError exception in these cases IMHO.
--
Ian Hickson U+1047E)\._.,--,'``.fL
http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,.
Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
On Wed, 9 Jan 2013, Anne van Kesteren wrote: On Tue, Jan 8, 2013 at 7:46 AM, Boris Zbarsky bzbar...@mit.edu wrote: Actually, that's not enough. You have to security-check arguments too. Otherwise this: document.createTreeWalker(crossFrameDoc, etc); would be bad. (Note that right now the DOM spec fails to handle this, which is about what I would expect out of people creating APIs, which is why I would really prefer we define this on a low level where people can't screw up by forgetting it.) You didn't file a bug on this I think. I did think HTML handled this already though which is why it is not addressed in the DOM specification. If we can make Window.document and contentDocument on iframe, frame, and object return null when cross-origin, we can drop the security checks on Document and createTreeWalker(), as far as I can tell. That would maybe simplify matters a little. It's an orthogonal move relative to what bz has been advocating for in terms of what security model we should have, and it's more like what Chrome has. But do Opera and Microsoft want to go in that direction? I'm not over the moon about changing the security model without more buy-in. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
[whatwg] Canvas: compositing and blending operator as enumeration?
Hi,
After all the discussions about winding rules and the new introduced
enumeration for nonzero and even odd, I wonder if the the compositing and
blending modes should be two enumerations as well.
enum CanvasCompositingMode {
source-over,
source-in,
…
}
and
enum CanvasBlendingMode {
normal,
multiply,
...
}
This wouldn't actually change the behavior or definition a lot, but might help
to cleanup a bit. I am happy about other names if they are not good enough.
Greetings,
Dirk
[whatwg] Reporting errors during Web Worker startup
http://www.whatwg.org/specs/web-apps/current-work/multipage/workers.html#creating-workers doesn't seem to define what happens if there aren't enough resources to create a separate parallel execution environment. Would it be legal for a UA to consider this as violating a policy decision and throw SecurityError? Or is that step intended to reflect a static decision, such as whether the UA allows workers to run at all? If this behavior isn't specified, could some graceful failure mode be specified? Currently some UAs terminate the execution of the page attempting to start the worker, which is obviously undesirable. Thanks, -Ken
Re: [whatwg] Need to define same-origin policy for WebIDL operations/getters/setters
Adam, thank you for taking the time to put this together. I really appreciate it. There are lots of things here where we can converge behavior no matter what happens with other pieces of the platform. On 1/9/13 5:58 PM, Adam Barth wrote: Generally speaking, I'd recommend exposing as few things across origins as possible. Yes, agreed. For what it's worth, I believe Gecko recently made history not accessible cross-origin anymore, so with any luck you'll be able to make this change too if desired... 6) In addition, the following APIs have extra security checks. All these APIs return a Node. Before returning the Node, they check whether the Node's document's origin is the same origin as the script calling the API. If not, they return null instead of the node. (We could potentially throw an exception here, but I'm just describing what WebKit does, not what I think the optimum design is.) Returning null for these is probably fine. I think I'd support making this list of things return null cross-origin. Just to check, do you make this determination based on the origin or the effective script origin (in spec terms)? I should also say that it's entirely possible we've screwed up our implementation of this security model. If you discover that we have, I'd prefer if you filed a security bug rather than telling the world on this public mailing list. :) Indeed. ;) -Boris
Re: [whatwg] Canvas: compositing and blending operator as enumeration?
Hi Dirk,
the 'globalCompositeOperation' property takes the same syntax as the css
'mix' so I don't think an enum will work.
Rik
On Wed, Jan 9, 2013 at 6:18 PM, Dirk Schulze dschu...@adobe.com wrote:
Hi,
After all the discussions about winding rules and the new introduced
enumeration for nonzero and even odd, I wonder if the the compositing
and blending modes should be two enumerations as well.
enum CanvasCompositingMode {
source-over,
source-in,
…
}
and
enum CanvasBlendingMode {
normal,
multiply,
...
}
This wouldn't actually change the behavior or definition a lot, but might
help to cleanup a bit. I am happy about other names if they are not good
enough.
Greetings,
Dirk
Re: [whatwg] Registration points for elements
Ian Hickson, 2013-01-08 18:23 (Europe/Helsinki):
You can do this with anything in HTML, using absolute positioning: set
just one of the coordinates in each direction, and leave the other on
'auto'. As in:
div { position: absolute: bottom: 10em; right: 10em; width: auto;
height: auto; left; auto; top: auto; margin: 0; }
That will work if you only want to use one of the element's corners as
the anchored point. However, CSS does not provide a way to position the
center of the element and use width: auto and height: auto. Even
more advanced would be a feature to define anchored point to be some
percentage of the width and height and then absolutely position that.
However, that feature is missing, too.
--
Mikko
