On 10/3/12 11:04 PM, Boris Zbarsky wrote:
I decided it wasn't worth punishing our users further if no one else in
the world cared about this.
Oh, and for the record we added gsp support in standards mode in Firefox
14. We kept the warning when it was used until Firefox 15, somewhat
On 10/5/12 4:23 AM, Anne van Kesteren wrote:
Note that you can append such an img to a different document later
(e.g. the one that executes the script) so fetching it is probably
smart.
It can also lead to privacy leaks and very upset web developers and
performance problems... So it's not
On 10/5/12 4:09 PM, Anne van Kesteren wrote:
Yeah sure, I'm not opposed to that. But that seems like a somewhat
bigger change, no? E.g. then you would also change a.click() be a
no-op I suppose? Or form.submit().
Are they not already?
-Boris
On 10/5/12 4:59 PM, Glenn Maynard wrote:
(I hope the other browser vendors' rationale isn't actually not caring
about it.)
Some of them simply care about backwards compat more than about getting
rid of the global scope polluter.
But some, as far as I can tell, really don't care at all.
On 10/5/12 6:04 PM, Glenn Maynard wrote:
On Fri, Oct 5, 2012 at 4:15 PM, Boris Zbarsky bzbar...@mit.edu
mailto:bzbar...@mit.edu wrote:
On 10/5/12 4:09 PM, Anne van Kesteren wrote:
Yeah sure, I'm not opposed to that. But that seems like a somewhat
bigger change, no? E.g
On 10/7/12 6:32 AM, David Bruant wrote:
1) what are the rules for popup blockers?
Browser-dependent.
Gecko uses a combination of several heuristics to block popups, based on
what sort of platform event are being processed when the window.open
call happens, how many popups are already open,
On 10/9/12 12:09 AM, Cameron Zemek wrote:
How is it not web-compatible?
Because shipping it breaks sites. As in, makes them render
differently than they do in current browsers, sufficiently so that it's
a problem.
Yeah I don't have any numbers to see if this is the case or not.
As Anne
On 10/12/12 6:02 PM, Glenn Maynard wrote:
We're throwing away a ton if we suddenly decide not to take advantage of
JavaScript's native syntax for dictionary-like object access.
As you might have noticed, JS started adding things like Map in part
because the native dictionary-like access has
On 10/13/12 11:53 AM, Glenn Maynard wrote:
You mean, people putting extra properties on things like Object.prototype
or DOMStringMap.prototype, and breaking code doing for(a in {})? I don't
find that to be a problem: that's nuts, so I don't do it.
Yes, but lots of libraries do. But even
On 10/22/12 1:38 PM, Adam Barth wrote:
To answer these questions, you need to reverse engineer the behavior
of various user agents, compare them
Bobby did that already, in the first mail in this thread. See
http://lists.w3.org/Archives/Public/public-script-coord/2012OctDec/0014.html
in case
On 10/23/12 5:45 PM, Ian Hickson wrote:
heycam, bz, what's the conclusion on this?
I don't think we ever reached one...
Should I
define a valueOf and make just that, the toString serializer, and href
unforgeable?
In the end, all properties and methods that let you read stuff out of
On 10/27/12 3:35 PM, Anne van Kesteren wrote:
This is covered as we do this for all URLs currently with a relative
scheme (http/ws/...). I know you indicated this as potentially
problematic
Let's have that fight separately. ;)
2) file:// URIs are parsed as a no authority URL in Gecko.
On 10/29/12 5:00 AM, Anne van Kesteren wrote:
But note that it would be a bit odd of file://c:/ claimed to have a host of
c with a default port or some such...
Maybe I should introduce a file host state that supports colons in
the host name (or special case the host state further, but the
On 10/29/12 10:53 AM, Anne van Kesteren wrote:
But at that point in a URL you cannot have a path. A path starts with
a slash after the host.
The point is that on Windows, Gecko parses file://c:/something as
file:///c:/something
As in, it's an exception to the general if there are two
On 10/29/12 8:58 PM, Johan Sundström wrote:
Serializing a complete HTML document DOM to a string is surprisingly
hard in javascript.
I thought there were plans to put innerHTML on Document. Did that go
nowhere?
As a fairly seasoned javascript hacker I figured
this might do it:
On 10/30/12 12:25 PM, Anne van Kesteren wrote:
Thanks, I missed that. It seems however we could have that parsing
rule for all platforms without issue, no?
Hmm. Possibly, yes. I'd love feedback from other UAs here!
-Boris
On 10/30/12 11:43 AM, Simon Pieters wrote:
The above applies to what gets sent over the wire when using the
WebSocket(...) constructor. For a href, the results are different:
http://simon.html5.org/test/url/url-encoding.html
I don't have an opinion at this point about what to do here.
In
On 10/31/12 4:27 AM, Mikko Rantalainen wrote:
(1) file://c:/foo tries to connect to server c: and request shared
entity foo.
I don't think that's really acceptable, but see below.
I understand that (1) would behave different from some legacy user
agents
Well, it would behave differently
On 10/31/12 9:52 AM, Anne van Kesteren wrote:
I think bz made it pretty clear we need to treat as if you typed
file:///c:/foo (at least on Windows, my preference is all
platforms). Not sure what the rules are exactly, but I believe they
are if you have a single ASCII letter followed by : or |.
On 11/6/12 11:39 AM, Ojan Vafai wrote:
This is a use-case that I absolutely think it makes sense to address.
Agreed. Not that I can commit to implementing, necessarily, but I do
think this is a common want.
A couple thoughts off the top of my head:
1. Would sorting actually reorder the
On 11/8/12 6:09 PM, Adam Barth wrote:
I don't think I quite understand what you mean, but the way this works
in WebKit is that each Window object has its own Location object.
That's not how it works in Presto and Trident, as far as we can tell
based on testing with ==. In those, each
On 11/9/12 2:05 PM, Adam Barth wrote:
The approach we use in WebKit is quite simple---we just perform an
access check before doing any sensitive operations.
The issue in Gecko, as I understand, is that security checks from C++
code require introspecting running JS to figure out what the
On 11/12/12 1:55 AM, Boris Zbarsky wrote:
Consider the attached testcase, which calls setTimeout on a window and
passes in a function from a different window.
Note that I observe the same behavior if I set onclick on another window
too... It seems just as bizarre there. :(
-Boris
On 11/12/12 2:00 AM, Boris Zbarsky wrote:
On 11/12/12 1:55 AM, Boris Zbarsky wrote:
Consider the attached testcase, which calls setTimeout on a window and
passes in a function from a different window.
Note that I observe the same behavior if I set onclick on another window
too
Consider the attached testcase, which calls setTimeout on a window and
passes in a function from a different window.
When this function is then called, it throws.
Gecko, WebKit, and Presto all seem to trigger the onerror handler of the
window setTimeout was called on in this case.
Per spec,
On 11/12/12 11:48 AM, Boris Zbarsky wrote:
So I did a bit more experimenting, and at first glance when the function
runs, even though the function's global is actually window A the this
object seems to be set to window B... _That_'s not specced anywhere
either, afaict.
And in fact what
On 11/12/12 4:17 PM, Boris Zbarsky wrote:
Still looking into what IE does in terms of which onerror handler is called.
Looks like IE, in all the modes I can test, does what the spec says
right now.
I'll be changing Gecko to align with IE and the spec (and, arguably,
sanity) here.
-Boris
On 11/13/12 3:31 AM, Simon Pieters wrote:
onload=function(){
onerror=function(a,b,c){alert('parent: '+[a,b,c].join(' '));};
frames[0].onerror=function(){alert('child: '+[a,b,c].join(' '));};
frames[0].setTimeout(function(){ throw 'oops' }, 0);
};
...
Opera and Chrome use child and
On 11/14/12 10:35 AM, Anne van Kesteren wrote:
Chrome's implementation (except for parsing invalid IPv4) makes a lot
of sense I think as it allows for minimizing what needs to be stored
internally. It only requires a sequence of eight 16-bit components.
I believe Gecko simply stores the
On 11/15/12 5:45 AM, Anne van Kesteren wrote:
Well and it is validated. You definitely parse the string
Yes, absolutely.
but I can
see how that is cheaper than transforming the string. And that string
is then passed to the DNS layer?
I don't know offhand. I'd have to go dig...
We could
Are setCapture/releaseCapture specified on document anywhere? The last
thing I see about it is
http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2008-November/017415.html
and then nothing...
Note that I suspect we do need a releaseCapture() so pages can call it
without throwing, even if
On 11/19/12 2:36 AM, David Bruant wrote:
An ES6 proxy could do the trick here.
But then it's not a Map at all, right? It's a proxy for maybe a Map,
maybe something else. In what sense would it be a Map at that point?
I suppose the same goes for ES6 Map.
As Tab suggested, a Map subclass
On 11/19/12 11:00 AM, David Bruant wrote:
How close are subclasses to not being vaporware (both in spec and
implementation terms)?
I don't understand what you mean by vaporware. ES6 Maps are a reality in
Firefox and Chrome (behind a flag for the latter).
Yes, I know that.
Subclassing of ES6
On 11/19/12 11:16 AM, Tab Atkins Jr. wrote:
Subclasses aren't anything new - we're just referring to the standard
prototype-based subclassing.
OK. That's different from ES6 classes/subclasses, so it might be good
to get terminology straight here to reduce confusion
-Boris
On 11/19/12 11:20 AM, Tab Atkins Jr. wrote:
To a first approximation, they shouldn't be. ES6 classes desugar into
functions and prototypes.
Hmm. They didn't completely at some point, but maybe something got
changed since I last looked.
first approximation is not great if we actually
On 11/19/12 1:26 PM, Allen Wirfs-Brock wrote:
Classes and everything else in ES6 will be precisely specified within
interoperability being a paramount goal
Of course. My concern is with web specs handwavily specifying things
without defining them (which they have a regrettable tendency to
On 11/19/12 4:12 PM, Anne van Kesteren wrote:
3. Ignore percent-encoded bytes.
...
Firefox seems to do 3.
This actually causes problems; see
https://bugzilla.mozilla.org/show_bug.cgi?id=309671
So I don't think we should require this behavior.
-Boris
On 11/19/12 8:38 PM, Ian Hickson wrote:
For now I've tightened up the spec so it should be implementable, secure,
and Web-compatible
I don't believe it's secure as currently written, actually. Filed
https://www.w3.org/Bugs/Public/show_bug.cgi?id=20012
I'm also curious as to why figuring
On 11/20/12 1:23 AM, Ian Hickson wrote:
Could you elaborate in the bug? I've no idea what you think is wrong.
Done, but what's wrong is that the security checks described in the spec
check the origin of the wrong document.
You can maintain a stack of entry scripts. You can't use a global,
On 11/20/12 2:38 AM, Ian Hickson wrote:
IMHO there's no point us trying to keep things locked down when you set
document.domain.
I believe sites actually rely on a certain amount of lockdown in
situations like this... Adam can fill you in, I'm sure.
But in general, as people work more and
On 11/20/12 12:46 PM, Ian Hickson wrote:
Given the way JavaScript works, I just don't see a sane way to make a
non-symmetric model work.
How does JavaScript work in your mind? We have a good amount of
experience making a non-symmetric model work in Gecko, for what it's worth.
Any time you
On 11/21/12 11:07 AM, Nicolas Froidure wrote:
Indeed, the only way to access to the data chunk loaded is to keep a
reference to the previous value of xhr.responseText.
Nicolas, see
http://lists.w3.org/Archives/Public/public-webapps/2011JulSep/0741.html
(implemented in Gecko as the
On 11/24/12 5:49 PM, Chris Weber wrote:
There also appears to be some differences in Unicode normalization
(assuming I tested this enough), see:
http://web.lookout.net/2012/03/unicode-normalization-in-urls.html
A question. What OS or OSes did you test on? Unicode normalization
differs in
On 11/28/12 7:42 PM, Ian Hickson wrote:
Done, at least on the HTML side. For now it just makes .sheet return null
for cross-origin resources.
Pretty sure that's not web-compatible...
If that's not quite right, please update this
bug with the details:
On 11/28/12 11:03 PM, Boris Zbarsky wrote:
Inheriting the mode isn't so bad, all it really does is decide whether or
not to send an Origin header.
Not quite. It also affects what happens when the server doesn't respond
with an appropriate Allow-Origin.
Oh, I see. You've added this taint
On 11/29/12 1:30 AM, Gordon P. Hemsley wrote:
Based on my reading of the source code, it seems that Gecko treats a
resource served as 'application/octet-stream' as an unknown type which
is sniffed as if no Content-Type was specified.
Only for media (video and audio) loads. Note that the HTML
On 11/29/12 2:07 AM, Gordon P. Hemsley wrote:
So perhaps a more useful question would be what to do in situations
like that—should mimesniff treat application/octet-stream as a type
supported by the browser for the purposes of sniffing images, audio
or video, fonts, or other media types?
The
On 11/29/12 2:32 AM, Boris Zbarsky wrote:
On 11/29/12 2:07 AM, Gordon P. Hemsley wrote:
I imagine this ties in, too, to the issues with sniffing CSS files
that has been raised elsewhere:
https://bugzilla.mozilla.org/show_bug.cgi?id=560388
https://bugzilla.mozilla.org/show_bug.cgi?id=562377
On 11/29/12 2:53 AM, Gordon P. Hemsley wrote:
At one point it says, The MIME type application/octet-stream with
no parameters is never a type that the user agent knows it cannot
render. User agents must treat that type as equivalent to the lack of
any explicit Content-Type metadata when it is
On 11/29/12 12:45 PM, Gordon P. Hemsley wrote:
The apparent contradiction occurs when, e.g., an Opus file is tagged
as application/octet-stream.
If I understand correctly, a UA would return when canPlayType() is
called against such a file
canPlayType is not called against a file. It's
On 11/29/12 1:11 PM, Gordon P. Hemsley wrote:
So... are there any additional places where application/octet-stream
should be treated as if the media type was undefined? Or is this
conversation moot now?
To my knowledge, the only places in the web platform that special-case
way?
On Wed, 28 Nov 2012, Boris Zbarsky wrote:
Oh, I see. You've added this taint thing, which you're using for the
CSS bit.
That only applies when there's no crossorigin= attribute, unless I made
a mistake in the speccing.
Oh, ok. Sorry. Reading diffs of HTML is a pain. :(
Well
On 11/29/12 9:44 PM, Ian Hickson wrote:
The behaviour called tainting in this context in the spec just means
treat as a cross-origin resource
Right. My point was that cross-origin for the case of stylesheet at
least in Gecko depends on the origin of the script that tries to modify
them, not
On 11/30/12 2:23 PM, Tab Atkins Jr. wrote:
It would be somewhat cleaner if she could simply construct a
DOMStringMap and assign it, like so:
for(var i = 0; i cards.length; i++) {
cards[i].dataset = new DOMStringMap(carddata[i]);
So this would copy the DOMStringMap into the dataset, not
On 11/30/12 7:07 PM, Tab Atkins Jr. wrote:
Sure. I presume you're afraid of multiple elements sharing the same object?
We can call it afraid or we can call it nonsensical since the object
is just syntactic sugar on top of the (not shared) attributes the
objects have ;)
Really, what
Consider this testcase:
var desc = Object.getOwnPropertyDescriptor(HTMLElement.prototype,
onscroll);
desc.set.call(document.body, function() { alert(this); });
Is the listener added on the body, or the window?
The relevant parts of the spec are:
On 12/3/12 2:05 PM, Ian Hickson wrote:
What do browsers do?
WebKit and Opera don't put the property on the prototype at all, so the
whole issue is not even testable there. This obviously doesn't follow
WebIDL, but that's not relevant here.
It looks like Gecko currently doesn't allow the
On 12/3/12 7:33 PM, Ian Hickson wrote:
Note that onerror has a different type on HTMLElement and HTMLBodyElement.
Yes, indeed. That's the biggest problem with forwarding to Window for
the HTMLElement.prototype case for onerror here: the types are different.
onscroll is a case where
On 12/3/12 8:16 PM, Cameron McCormack wrote:
On 4/12/12 12:11 PM, Boris Zbarsky wrote:
Hmm. That, as phrased, is pretty complicated to implement in a
performant way, if the two methods/getters/setters have the same
signatures...
Since I'm not terribly familiar with our generated bindings
On 12/15/12 8:39 PM, Jonas Sicking wrote:
myFileInput.files = [ablob, afile, anotherblob, new Blob([foo])];
There's no way to express that in WebIDL, but I think that's a bug we
should fix in WebIDL. We should allow getters and setters for
attributes to accept different IDL types...
On 12/15/12 8:33 PM, Jonas Sicking wrote:
An easy solution would be to just return null for .contentDocument
in the case of cross-origin iframes.
Even if that were web-compatible (which is not obvious), that doesn't
solve the problem of doing the same sort of thing with .contentWindow.
On 12/18/12 3:53 PM, Ian Hickson wrote:
Per the spec, calls that would create a new browsing context are blocked
unless called from the handler of a trusted 'click' event.
That's not web-compatible...
I don't know if the spec is overly strict here; maybe it should also be
possible on other
On 12/18/12 3:25 PM, Ian Hickson wrote:
Looking at the spec and at browsers more carefully, it seems that this is
actually per spec (i.e. the spec says to follow the link).
Does it say to do that if the ownerDocument of the a has no associated
browsing context? What if it's not the currently
On 12/19/12 12:11 PM, Ian Hickson wrote:
So I've put in a block on the handling of a (and area) elements
specifically, making their activation behaviour nil if their doc doesn't
have a browsing context
Does a document that is in something like bfcache or has otherwise been
unloaded have a
On 12/19/12 12:37 PM, Ian Hickson wrote:
Yes, just not an active one.
OK. I don't think we want to activate links in unloaded documents,
personally
-Boris
On 12/19/12 12:55 PM, Ian Hickson wrote:
On Wed, 19 Dec 2012, Boris Zbarsky wrote:
On 12/19/12 12:37 PM, Ian Hickson wrote:
Yes, just not an active one.
OK. I don't think we want to activate links in unloaded documents,
personally
That's probably reasonable... Do you have a test case
On 12/20/12 9:54 AM, Ian Hickson wrote:
Everything in the Web platform already uses doubles.
Except WebGL. And Audio API wave tables, sample rates, AudioParams, PCM
data (though thankfully times in Audio API do use doubles). And
graphics libraries used to implement canvas, in many cases...
On 12/22/12 6:07 AM, Cameron McCormack wrote:
If we don't have the type checking of array elements, and also don't
need any noticing of individual element assignments, then we can just
have a reference to a plain Array object and look at its elements at the
time the dash array is needed.
Look
On 12/27/12 7:40 PM, Tab Atkins Jr. wrote:
In JS, the comparator passed to sort() can potentially mutate the array
that's being sorted, or delete it entirely. JS engines cope somehow.
Note that per spec the behavior if the comparator mutates the array is
undefined. Engines are allowed to go
On 12/28/12 1:42 PM, Jonas Grus Dinesen wrote:
I am looking for a feature to set the baseline of an object, fx an svg figure
(rectangle, triangle etc) which makes it possible to let fx height and width of
an object grow upwards and not downwards. Maybe by setting horisontal and
vertical
On 1/2/13 4:37 PM, Ian Hickson wrote:
Wait, Web Components isn't solving this? I thought this was one of the
main use cases of Web Components.
As far as I can tell, Web Components is doing the following:
1) Defining a way for authors to implement custom widgets.
2) Defining a way to maybe
On 1/3/13 12:10 AM, Ian Hickson wrote:
On Wed, 2 Jan 2013, Boris Zbarsky wrote:
On 1/2/13 4:37 PM, Ian Hickson wrote:
Wait, Web Components isn't solving this? I thought this was one of the
main use cases of Web Components.
[...] and it is certainly not doing:
4) Defining the browser
On 1/7/13 2:34 PM, Ian Hickson wrote:
Ok. I've left the spec as is here. Please do let me know if this is the
wrong thing to do after all
Will do once I actually manage to get this stuff into a build people are
using. For now, it runs afoul of script disabling for designMode and
other such
On 1/7/13 6:20 PM, Cameron McCormack wrote:
Why would this need to be on specific operations and not just be
enforced on every operation?
I believe Gecko currently enforces this sort of thing on every
operation, for what it's worth.
Or it it that only a limited set of objects is exposed
On 1/7/13 6:41 PM, Ian Hickson wrote:
Most things don't have an origin.
Pretty much everything has an origin in practice: it's associated with
some Window, hence can be treated as having the same origin as that Window.
Origin checks are only done in some very
specific places where you try
On 1/7/13 11:28 PM, Ian Hickson wrote:
Per spec, even Windows actually don't have an origin. Things that have
origins are URLs, Documents, images, audio and video elements, fonts, and
scripts. Many of those things can have origins that are not that of the
most obvious related (or in some cases
On 1/8/13 1:42 AM, Boris Zbarsky wrote:
On 1/7/13 11:28 PM, Ian Hickson wrote:
The check is the same -- if the Document that is the this to
which the property is being applied doesn't match the origin of the
script
that is doing the applying, throw SecurityError.
Actually, that's not enough
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
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
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:
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
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
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
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
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
On 1/11/13 1:29 AM, Adam Barth wrote:
On Wed, Jan 9, 2013 at 8:21 PM, Boris Zbarsky bzbar...@mit.edu wrote:
Yes, agreed. For what it's worth, I believe Gecko recently made history not
accessible cross-origin anymore
Do you have a link to the bug where that change was made?
https
On 1/18/13 8:40 AM, Anne van Kesteren wrote:
On Tue, Jan 15, 2013 at 2:44 PM, Markus Ernst derer...@gmx.ch wrote:
The allow-seamless mechanism is to be triggered at the side of the embedded
resource, which would also be the one affected by possible security risks
(if I get this right). The
On 1/29/13 11:37 PM, Rik Cabanier wrote:
So the API could be as follows:
...
unrestricted double? sx;
unrestricted double? sy;
Do these actually need to be nullable? What's the use case for setting
them to null?
Same thing for the rest of this dictionary's members.
-Boris
On 1/30/13 12:13 AM, Rik Cabanier wrote:
ah, sorry. I looked at the dictionary for hitregions
Sounds like we should consider fixing this hitregions thing whatever it is.
optional unrestricted double sx;
That's not actually valid WebIDL, with the optional.
And that's because all
On 1/30/13 12:37 AM, Rik Cabanier wrote:
enum CanvasMaskType { luminosity, alpha};
Last nits. Need quotes around the enum values. So:
enum CanvasMaskType { luminosity, alpha };
void maskImage(MaskOptions options);
I believe that has to be:
void maskImage(optional
On 1/30/13 12:55 AM, Rik Cabanier wrote:
void maskImage(optional MaskOptions options);
Why is it optional?
Because http://dev.w3.org/2006/webapi/WebIDL/#idl-operations says (if
you scroll down a ways):
If the type of an argument is a dictionary type or a union type that
has a
On 2/25/13 3:00 PM, Adam Barth wrote:
Yes, that's to defend against a different sort of attack. In some
browsers, like Firefox, data URLs inherit the security context of
their authors.
This is not the case for data: URLs that are the target of a redirect,
for what it's worth. At least in
The problem I'm trying to solve is sending Unicode text to consumers who
need base64-encoded input. Right now the only sane way to do it (and
I quote sane for obvious reasons) is something like the example at
https://developer.mozilla.org/en-US/docs/DOM/window.btoa#Unicode_Strings
It seems
I'm trying to understand why Document and HTMLDocument got merged. In
practice, UAs don't do that, and doing it imposes a performance penalty
on manipulating, say, XMLHttpRequest response documents (because the
name getter on HTMLDocument makes property access slower on that object).
So why
On 3/5/13 11:45 AM, Anne van Kesteren wrote:
On Tue, Mar 5, 2013 at 4:38 PM, Boris Zbarsky bzbar...@mit.edu wrote:
I'm trying to understand why Document and HTMLDocument got merged. In
practice, UAs don't do that, and doing it imposes a performance penalty on
manipulating, say, XMLHttpRequest
On 3/5/13 3:30 PM, Ian Hickson wrote:
I'd be fine with having a Document descendant that is used for Documents
that have global scopes / browsing contexts / the works, and one that is
used for Documents that don't (e.g. createDocument(), XHR); would that
address this issue?
It's one way to
On 3/11/13 7:28 PM, Kenneth Russell wrote:
Proposed IDL:
[NoInterfaceObject]
interface ImageDataFactories {
ImageData createImageData(Uint8ClampedArray data, double sw, double sh);
};
Window implements ImageDataFactories;
WorkerGlobalScope implements ImageDataFactories;
How about just:
On 3/11/13 11:58 PM, Rik Cabanier wrote:
If there are use cases for creating an ImageData, I recommend not making a
copy, so all this is doing is taking an existing ArrayBuffer and creating a
thin wrapper around the same buffer.
I think that would make implementations that defer rendering
On 3/12/13 12:56 AM, Glenn Maynard wrote:
(I suppose a simpler optimization is simply copy-on-access: make a copy of
the backing store if the .data property of ImageData is accessed.
This may actually be a harder optimization to make in practice.
For example, Gecko+SpiderMonkey has the .data
On 3/13/13 10:36 AM, Anne van Kesteren wrote:
For the data:text/html, case Gecko reports both 2 and 4. For
data:text/html,test you get 2, 3 test, 4 test. Chrome/Safari
dispatch 4 (without test) and then throw mentioning a synchronous
request. Seems very much like an implementation bug. IE10
901 - 1000 of 1308 matches
Mail list logo
