Re: [whatwg] C:\fakepath\ in HTML5
On 24.03.2009, at 8:09, Ian Hickson wrote: (I would expect Firefox, Safari, and Chrome to follow suit; Firefox for compatibility, and Safari and Chrome for privacy.) FWIW, WebKit returns just the file name now. - WBR, Alexey Proskuryakov
Re: [whatwg] C:\fakepath\ in HTML5
On Mon, 23 Mar 2009, Alex Henrie wrote: On Mon, Mar 23, 2009 at 11:09 PM, Ian Hickson i...@hixie.ch wrote: I agree. Unfortunately, sometimes we are unable to make choices that end up with a nice language. :-( Well, why not? Is HTML5 supposed to be perfectly compatible with HTML4? No, but it _is_ intended to be compatible enough with existing content that user agents will be willing to implement it. On Tue, 24 Mar 2009, Boris Zbarsky wrote: I don't believe I've seen many bugs along these lines for Firefox... can't think of any, in fact. It seems that the number of such sites might be low enough that we don't need to cater to them. That's encouraging. According to Microsoft: http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx ...the problem was with a significant number of sites (e.g. education products, several movie sharing sites, etc) and devices (e.g. popular home routers). The blog post above includes a screenshot of a firmware upgrade screen that has this problem. This is not a site that could be fixed. Maybe someone from Opera could let us know which sites caused them to do this? Was it many, as with Microsoft? This was originally brought up in the W3C HTMLWG: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6529 -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] navigator.yield()? (Was: localStorage + worker processes)
On Tue, Mar 24, 2009 at 1:17 PM, Jonas Sicking jo...@sicking.cc wrote: On Mon, Mar 23, 2009 at 4:16 PM, Ian Hickson i...@hixie.ch wrote: On Mon, 23 Mar 2009, Jonas Sicking wrote: And that's not even touching on the stack space limitations that you're quite likely to run in to when you have an API specifically for nesting. I think any sane implementation of this would have to be non-recursive. That's part of why I think it'd be so hard to implement. Indeed, that'd be really hard to implement in the generic case. For example a navigator.yield() inside an event handler, or inside a callback. We'd basically have to redesign all the code that implements the DOM and all other APIs that are exposed to javascript. Or rewrite our code in a language that supports continuations, which C/C++ doesn't do. (no, setjmp and longjmp doesn't count :) ). Not necessarily, it depends on the semantics. For example, you might retain the option for yield to do nothing (i.e. it offers no liveness guarantees). In that case you would have the option of not yielding in difficult situations like event handlers or callbacks, or if recursion gets too deep. Or a spec could say which script executions allow yielding and which don't. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] C:\fakepath\ in HTML5
Ian Hickson wrote: That's encouraging. According to Microsoft: http://blogs.msdn.com/ie/archive/2009/03/20/rtm-platform-changes.aspx ...the problem was with a significant number of sites (e.g. education products, several movie sharing sites, etc) and devices (e.g. popular home routers). The blog post above includes a screenshot of a firmware upgrade screen that has this problem. This is not a site that could be fixed. Maybe someone from Opera could let us know which sites caused them to do this? Was it many, as with Microsoft? This was originally brought up in the W3C HTMLWG: http://www.w3.org/Bugs/Public/show_bug.cgi?id=6529 Speaking of which, if the value really needs a path separator, why not simply use ./filename instead of filename? BR, Julian
Re: [whatwg] localStorage + worker processes
I've updated the specs as follows:
- removed localStorage from Web Workers for now.
- extended the implicit lock mechanism that we had for storage to also
cover document.cookie, and made the language more explicit about how
it works.
- added navigator.releaseLock().
On Fri, 20 Mar 2009, Jeremy Orlow wrote:
Anyhow, the very first example in the spec (
http://dev.w3.org/html5/workers/#a-background-number-crunching-worker)
shows work that's being done in a infinite loop with postMessage being
called when each prime is found. If you called localStorage anywhere
within that loop (say, to periodically save all primes found), you would
not be able to safely call window.localStorage in any other worker or
the web page. This is because the task that started the script never
ends. And this its 'lock' (on other scripts using local storage) will
never be released.
I've removed localStorage from the Web Workers spec for now.
On Fri, 20 Mar 2009, Jonas Sicking wrote:
I do think it would be great if workers had access to some type of
structured storage. However I agree that the fact that both the main
thread and workers have synchronous access to the same storage is not
acceptable since that means that we're violating the
shared-nothing-message-passing design that makes workers not have to
deal with locks and other traditional multithread hazards.
Agreed. The Database API seems well-suited for this, though.
On Fri, 20 Mar 2009, Drew Wilson wrote:
One alternative I'd like to propose is to remove access to localStorage
for dedicated workers, and give SharedWorkers access to localStorage,
but have that storage be partitioned by the worker name (i.e. the worker
can access it, but it's not shared with web pages or any other workers
and so you don't have any synchronicity issues).
That's an interesting idea, and would be relatively easy to do. Do people
think it is worth it?
On Fri, 20 Mar 2009, Aaron Boodman wrote:
I think the best option is to make access to localstorage asynchronous
for workers. This reduces the amount of time a worker can hold the
localstore lock so that it shouldn't be a problem for normal pages. It
sucks to make such a simple and useful API aync though.
I don't think making it async helps here, since the problem isn't that it
is synchronous, but that workers don't return quickly (by design).
On Sat, 21 Mar 2009, Aaron Boodman wrote:
Actually, I don't believe that it is required that the callback run
asynchronously. All the callback is used for is establishing the lock
lifetime explicitly, and we assume that this will usually make the lock
lifetime short. So we can block while we wait for it to become
available. This is just like the behavior today without workers.
Nothing is to stop someone from just having a long callback, though.
On Sat, 21 Mar 2009, Jonas Sicking wrote:
As I understand the current API (on main window) to be defined, as soon
as someone accesses the .localStorage property, the implementation is
supposed to acquire a lock. This lock would be held on to until that
script returns to the event loop for that thread.
So if javascript in another window, running in another thread or
process, tries to access .localStorage for the same origin, the
.localStorage getter would try to acquire the same lock and block until
the first thread releases the lock.
Right.
On Sat, 21 Mar 2009, Jonas Sicking wrote:
The problem with synchronously grabbing the lock is that we can only
ever have one feature that uses synchronous locks, otherwise we'll risk
dead-locks.
Indeed. This is a problem with the current API for localStorage in windows
as well.
I've made the spec explicitly have a single shared lock for all features
that need locking (currently just .cookie and .localStorage).
On Sun, 22 Mar 2009, Michael Nordman wrote:
Given an async api, would it be possible to store values into
localStorage at onunload time? I expect that could be a useful time to
use this API.
function onunload() {
getLocalStorage(function(storage) {
// Will this ever execute?
});
}
Locking the storage until script completion isn't really necessary in
many cases. Maybe we're over engineering this? Suppose immutability
across calls was generally not guaranteed by the existing API. And we
add an async getLocalStorage(callback) which does provide immutability
for the duration of the callback if that is desired.
The problem is that people will walk into race conditions without
realising it, and they are amongst the hardest problems to debug.
On Sun, 22 Mar 2009, Drew Wilson wrote:
The problem is that .length is basically useless without some kind of
immutability guarantees.
Indeed.
On Sun, 22 Mar 2009, Drew Wilson wrote:
That's why I'm proposing that the most reasonable implementation is just
to have a simple lock like I describe above
This is what I've done.
Re: [whatwg] C:\fakepath\ in HTML5
Ian Hickson wrote:
Maybe someone from Opera could let us know which sites caused them to do
this? Was it many, as with Microsoft?
I did a quick search through our bugs and found this site that breaks if
only the filename is returned because there's an onsubmit script that
checks the value for the presence of either a slash or backslash.
https://www.freedfm.com/
Specifically, the following code:
if((strFileName.indexOf(\\) == -1) (strFileName.indexOf(/) == -1))
{
alert(Please do not type your filename. Click Browse and upload your
zip file.);
document.fileupload.UploadFileData.focus();
return false;
}
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] localStorage + worker processes
On Tue, Mar 24, 2009 at 10:11 PM, Ian Hickson i...@hixie.ch wrote: - extended the implicit lock mechanism that we had for storage to also cover document.cookie, and made the language more explicit about how it works. That's basically good. It's possible that people might want to implement something that's equivalent to the storage mutex in observable behaviour, but allows more parallelism, such as speculative execution or finer-grained locking when the implementation can prove it's safe. I assume implementors of HTML5 already understand that that's allowed. - added navigator.releaseLock(). This name could be confusing to developers, because there is no corresponding explicit acquireLock(), which there usually is in an API that exposes releaseLock(). navigator.allowInterruption() maybe? On Sat, 21 Mar 2009, Jonas Sicking wrote: As a side note, if we do go with this async lock acquiring, we could add an API like: getLockedFeatures(callback, 'localStore', 'cookie'); This would be an asynchronously grab locks to multiple features and only call the callback once all of them have been acquired. This would allow computations across data from multiple locations guaranteed to be in sync. The implementation would be responsible for grabbing the locks in a consistent order to prevent deadlocks. Why would we want more than one lock? Is the potential performance gain worth the complexity? The problem with going with an async approach is that it means changing the API, which is something we can't really do for cookie (and don't really want to do for localStorage, since IE8 has shipped it.) We we are going to need a synchronous locking mechanism anyway. It would be possible to use something like getLockedFeatures for workers while using implicit locking for the main thread. On Mon, 23 Mar 2009, Robert O'Callahan wrote: It has to be resolved in a way that doesn't expose asynchronous cookie or localStorage changes to Web developers. There is abundant evidence that race conditions and synchronization are too hard for developers to deal with. The spec should forbid asynchronously visible changes to cookies or localStorage. In fact, it should probably simply say that all script execution is serializable: always equivalent to some execution you could get with a single-threaded browser that runs all scripts to completion. Allowance could be made for explicit yield points if we need to, e.g. alert(). Generally speaking I have tried to maintain this invariant, but I have failed with cookies, and with localStorage in workers. Now, with the storage mutex, are there any cases you know of where serializability fails? If there are, it may be worth noting them in the spec. If there aren't, why not simply write serializability into the spec? User agents that share event loops between origins can't actually have any more than one lock total. Consider a case where there are three windows from three different origins, A, B, and C, where C contains a couple of iframes, and where A, B, and C are independent, but C share an event loop with whatever content is in its iframes. (This is the situation Chrome and IE are in, as I understand it, with event loops being per-window not per-origin, and it may be required because access to the frames[] hierarchy is synchronous.) Now, assume A and B have both obtained their respective locks, and are busy doing some long script. C is free to run more tasks from its event loop, which could include navigating one iframe to a page on either A and the other iframe to a page on B, meaning that the event loop of C is now beholden to two locks. If there is any manner in which to synchronously cause another origin to run script, this now means that C can attempt to obtain both locks; if we now imagine another window just like C that instead obtains the locks in the reverse order, we get deadlock. Interesting example! When two sets of unrelated browser contexts become related (e.g., C loads A into an iframe), I imagined you would join A's lock and C's lock into a single lock covering the new set of related browser contexts, which is safe to do if at most one of those locks is currently held. When this happens due to a document being created with origin A in C's iframe, it happens asynchronously in C, right? So at that point C's lock is not held by currently running script in C (although it might be held by code in another domain which is already related to C), and we can block the join operation in C until one of the two locks is released. Then in your example, suppose C loads A's document first. Then C's lock and A's lock are joined to make a CA-lock. Then suppose D (another window just like C) loads B's document; D's lock and B's lock are merged to make the DB-lock. Now suppose C loads B. The two remaining locks are merged to form a single CADB-lock. No deadlock is possible. If it can be shown that it is not ever
Re: [whatwg] C:\fakepath\ in HTML5
Which sites? Any site that *requires* a Windows path clearly isn't interested in inter-operating with other browsers/platforms; heck, it means they've limited their testing to just Windows/IE. Don't punish the rest of us for their poor testing/programming. My friend ! Welcome to the internet :) opera adopted this behavior because for a long time we were the only ones with only the file name. And for a long time we always had compatibility problems, and sites that simply refused to fix. I recall Orkut avatar upload (checked for : in input.value), and some router firmwares. So, while keeping the privacy of the user we added c:\fake_path for the reasons mentioned. It's a sad true, but it was necessary. - Bil -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [whatwg] Synchronized play/seek of multiple audio elements?
Hi Emil, On Tue, Mar 24, 2009 at 1:39 AM, Emil Tin e...@koblo.com wrote: i understand that SVG is meant for advanced timing etc. Maybe rather SMIL - that's where SVG got it from. but it would be very useful to have a simple mechanism in html/javascript for playing sounds together. conceptually, sounds would be placed on a timeline at a certain time. the sounds on the timeline can then be played back together and will start at the right times. As soon as you start going down this track, you run into complexity. By specifying something like your example ... audio src=pads.mp3 timeline=ambient time=0 id=my_song audio src=cello.mp3 timeline=ambient time=0 audio src=voice.mp3 timeline=ambient time=2000 audio src=bells.mp3 timeline=ambient time=5000 you have to tackle a lot of issues: * is this a group that is meant to go along the same timeline and therefore displays a single control element? * what if you only really want to play one element and not the others - can you pick one out and thus break the group? * can you define subgroups and e.g. mute them together? * what if you jump to a certain offset on the controls - how is the browser supposed to know which things are still playing in parallel and which aren't playing any longer? (getting the duration of files tends to be a difficult undertaking) * what if the source files all come from different servers with different download speeds - what's the buffering strategy? another idea would be to group the audio tags inside a timeline tag, but that might be a more complicated change? timeline id=ambient video time=0 audio time=400 audio time= 1200 /timeline This option is basically the option that SMIL has gone down. It has enclosing tags that specify what goes in sequence and what in parallel and has many richer constructs. For creating a audio-visual experience out of several separate audio / video files, SMIL is probably the best way to go right now with its seq, par and switch elements and having thought through all the issues that arise around them. I must say however that I do sympathise with a simpler approach than SMIL if it is possible and can deal with all the issues. I don't think the current version of HTML5 will take it but it would be a good thing to develop a composition approach for a second or third version of HTML5. The experience from SMIL should however be fully taken into account. Best Regards, Silvia. On 18/02/2009, at 11.20, Ian Hickson wrote: On Wed, 18 Feb 2009, Emil Tin wrote: However, I've been unable to find any information on how to trigger several audio files in a synchronized manner. Does the html 5 specification provide any way to to this? Not currently. -- Ian Hickson U+1047E )\._.,--,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] C:\fakepath\ in HTML5
Lachlan Hunt wrote:
https://www.freedfm.com/
Specifically, the following code:
if((strFileName.indexOf(\\) == -1) (strFileName.indexOf(/) == -1))
{
alert(Please do not type your filename. Click Browse and upload your
zip file.);
document.fileupload.UploadFileData.focus();
return false;
}
I just tried this in a current Firefox. The site worksforme, if we're
talking about the ZIP upload on the front page.
The code you mentioned is commented out in their JS, like so:
/* KRC 6/19/2008 #8234
...
*/
They still have various other silly checks (like requiring a filename
that's at least 6 characters long without telling the user that's what
they require), but that's not really relevant to this discussion.
-Boris
Re: [whatwg] C:\fakepath\ in HTML5
On Tue, 24 Mar 2009 15:07:39 +0100, Boris Zbarsky bzbar...@mit.edu wrote: Sure it is. You just need a browser that'll allow you to do a firmware upgrade to fix it. Which means that if one gets such an upgrade shipped before all browsers stop sending paths, things seem to be ok. I agree they're not as happy as they could be, but they're ok. In addition, is the expected lifetime of the affected device comparable to the expected time it takes to deploy the new behavior in browsers? If so, it's worth it to contact the device maker and ask them to fix things in their next model instead of working around them. Microsoft did. And nothing changed in well over a year. (They say so in a comment on the blog post.) As far as the significant number of sites above... I wonder whether there's UA sniffing going on here that causes some of these to assume certain things about IE only. We've certainly seen quite a number of issues along those lines: we fix a bug, and discover that sites had written special browser-specific code taking advantage of that bug. Opera was the first doing this and we hit a few issues as well so we decided to go with a simple prefix (C:\fake_path\ changed to C:\fakepath\ now per discussion with Microsoft). It looks a bit ugly, but it's not at all the issue that same make it out to be I think. (E.g. the initial email claimed this inconsistency between the DOM and HTTP would cause issues for Web application developers...) Furthermore, once we get interoperable support for input type=file multiple and the fileList proposal starts moving we can provide cleaner access directly to the file name there. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] C:\fakepath\ in HTML5
So instead of fixing the web, we're fixing the spec (and thus implementing
fakepath in browsers)?
- Original Message -
From: Lachlan Hunt lachlan.h...@lachy.id.au
To: Ian Hickson i...@hixie.ch
Cc: wha...@whatwg.org
Sent: Tuesday, March 24, 2009 11:00 AM
Subject: Re: [whatwg] C:\fakepath\ in HTML5
Ian Hickson wrote:
Maybe someone from Opera could let us know which sites caused them to do
this? Was it many, as with Microsoft?
I did a quick search through our bugs and found this site that breaks if
only the filename is returned because there's an onsubmit script that
checks the value for the presence of either a slash or backslash.
https://www.freedfm.com/
Specifically, the following code:
if((strFileName.indexOf(\\) == -1) (strFileName.indexOf(/) == -1))
{
alert(Please do not type your filename. Click Browse and upload your
zip file.);
document.fileupload.UploadFileData.focus();
return false; }
--
Lachlan Hunt - Opera Software
http://lachy.id.au/
http://www.opera.com/
Re: [whatwg] C:\fakepath\ in HTML5
Randy Drielinger wrote: So instead of fixing the web, we're fixing the spec (and thus implementing fakepath in browsers)? It's purely a question of what browser makers are prepared to implement. The spec has to reflect a consensus amongst browser makers so that it actualy gets implemented, otherwise it is no use to anyone. If you don't want the fakepath thing (and I agree it is ugly), try convincing the known-broken sites to change (citing the fact that they may break in Firefox could give you quite some leverage here). The fewer compat. reasons there are to keep the ugly solution, the easier it is to have the pretty solution.
Re: [whatwg] C:\fakepath\ in HTML5
Am Dienstag, den 24.03.2009, 16:06 +0100 schrieb James Graham: If you don't want the fakepath thing (and I agree it is ugly), try convincing the known-broken sites to change (citing the fact that they may break in Firefox could give you quite some leverage here). From what I remember, Opera were the ones that were good with statistics. Lan you provide a list on what major sites / routers / frameworks are broken or - if that is too much - how common this is ? Or should I ask MSFT ? IMHO, it would be a shame if this broken behaviour would be enshrined for centuries to come. Cheers -- Nils Dagsson Moskopp http://dieweltistgarnichtso.net
Re: [whatwg] C:\fakepath\ in HTML5
Ian Hickson wrote on 3/24/2009 12:09 AM: The original plan was to just have the filename. Unfortunately, it turns out that if you do that, there are certain sites that break, because they expect the path (and they expect a Windows path, no less). This is why Opera and IE8 return a fake path -- not because HTML5 says to do it. In fact I made HTML5 say it because they were doing it. I played with this a bit more, it turns out that IE8 returns C:\fakepath\filename.ext for sites in the Internet zone, but returns the real path for sites in the Trusted zone. So even if HTML5 requires returning just the file name and is implemented as such in IE, the user can still designate their router as a Trusted Zone and be able to update their firmware. - Bil
Re: [whatwg] C:\fakepath\ in HTML5
On Tue, Mar 24, 2009 at 8:15 AM, Anne van Kesteren ann...@opera.com wrote: On Tue, 24 Mar 2009 15:07:39 +0100, Boris Zbarsky bzbar...@mit.edu wrote: Sure it is. You just need a browser that'll allow you to do a firmware upgrade to fix it. Which means that if one gets such an upgrade shipped before all browsers stop sending paths, things seem to be ok. I agree they're not as happy as they could be, but they're ok. In addition, is the expected lifetime of the affected device comparable to the expected time it takes to deploy the new behavior in browsers? If so, it's worth it to contact the device maker and ask them to fix things in their next model instead of working around them. Microsoft did. And nothing changed in well over a year. (They say so in a comment on the blog post.) Perhaps the buggy code was only sent to IE, and Firefox got more reasonable code. If the firmware had working code for both Firefox and the latest stable version of IE, that would explain the company's reluctance to see a problem. Another reason might be that this firmware only runs on old routers and no firmware updates are being released for it, so few users would run into the problem with trying to update firmware. What firmware was this, exactly? Opera was the first doing this and we hit a few issues as well so we decided to go with a simple prefix (C:\fake_path\ changed to C:\fakepath\ now per discussion with Microsoft). It looks a bit ugly, but it's not at all the issue that same make it out to be I think. (E.g. the initial email claimed this inconsistency between the DOM and HTTP would cause issues for Web application developers...) Example: A site lets a user upload a file and write some comments associated with that file. On the browser side, a new input element is dynamically created with the name and id Notes for C:\fakepath\upload.txt. On the server side, the server receives upload.txt and looks for Notes for upload.txt to match. It of course is not there because the programmer had no idea that the browser would be adding appending a fake path in JavaScript but not in HTTP. -Alex
Re: [whatwg] C:\fakepath\ in HTML5
On Tue, 24 Mar 2009 17:23:20 +0100, Alex Henrie alexhenri...@gmail.com wrote: On Tue, Mar 24, 2009 at 8:15 AM, Anne van Kesteren ann...@opera.com wrote: Microsoft did. And nothing changed in well over a year. (They say so in a comment on the blog post.) Perhaps the buggy code was only sent to IE, and Firefox got more reasonable code. If the firmware had working code for both Firefox and the latest stable version of IE, that would explain the company's reluctance to see a problem. Maybe, maybe not. Another reason might be that this firmware only runs on old routers and no firmware updates are being released for it, so few users would run into the problem with trying to update firmware. What firmware was this, exactly? I have no idea. It just indicates issues are out there. Example: A site lets a user upload a file and write some comments associated with that file. On the browser side, a new input element is dynamically created with the name and id Notes for C:\fakepath\upload.txt. On the server side, the server receives upload.txt and looks for Notes for upload.txt to match. It of course is not there because the programmer had no idea that the browser would be adding appending a fake path in JavaScript but not in HTTP. I don't see how this example could work. Anyway, relying on .value to just return a filename is a bogus assumption anyway since lots of user agents out there are not doing that. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] C:\fakepath\ in HTML5
Bil Corry wrote on 3/24/2009 11:01 AM: Ian Hickson wrote on 3/24/2009 12:09 AM: The original plan was to just have the filename. Unfortunately, it turns out that if you do that, there are certain sites that break, because they expect the path (and they expect a Windows path, no less). This is why Opera and IE8 return a fake path -- not because HTML5 says to do it. In fact I made HTML5 say it because they were doing it. I played with this a bit more, it turns out that IE8 returns C:\fakepath\filename.ext for sites in the Internet zone, but returns the real path for sites in the Trusted zone. So even if HTML5 requires returning just the file name and is implemented as such in IE, the user can still designate their router as a Trusted Zone and be able to update their firmware. And when sending the file to the server, IE8 sends just the filename without the fake path for the Internet zone, and send the real path and filename for the Trusted zone. - Bil
Re: [whatwg] C:\fakepath\ in HTML5
On Tue, Mar 24, 2009 at 10:34 AM, Anne van Kesteren ann...@opera.com wrote: Example: A site lets a user upload a file and write some comments associated with that file. On the browser side, a new input element is dynamically created with the name and id Notes for C:\fakepath\upload.txt. On the server side, the server receives upload.txt and looks for Notes for upload.txt to match. It of course is not there because the programmer had no idea that the browser would be adding appending a fake path in JavaScript but not in HTTP. I don't see how this example could work. Anyway, relying on .value to just return a filename is a bogus assumption anyway since lots of user agents out there are not doing that. I mean, if the browser used C:\fakepath\upload.txt in both JavaScript and DOM then there would be no problem in this example. But mixing C:\fakepath\upload.txt and upload.txt creates additional complications. -Alex
Re: [whatwg] C:\fakepath\ in HTML5
On Tue, Mar 24, 2009 at 11:24 AM, Alex Henrie alexhenri...@gmail.com wrote: I mean, if the browser used C:\fakepath\upload.txt in both JavaScript and DOM then there would be no problem in this example. But mixing C:\fakepath\upload.txt and upload.txt creates additional complications. Whoops, that should have said JavaScript and HTTP, sorry. -Alex
Re: [whatwg] C:\fakepath\ in HTML5
On Mar 24, 2009, at 12:31 AM, Alexey Proskuryakov wrote: On 24.03.2009, at 8:09, Ian Hickson wrote: (I would expect Firefox, Safari, and Chrome to follow suit; Firefox for compatibility, and Safari and Chrome for privacy.) FWIW, WebKit returns just the file name now. It should also be noted that we have not received any compatibility bugs since making this change.
[whatwg] AppCache and SharedWorkers?
I'm trying to understand the ApplicationCache spec as it applies to workers, but I didn't find anything promising when I searched the archives. Is ApplicationCache intended to apply to workers? The application cache API isn't available to workers, but I'm guessing the intent is that if an application creates a dedicated worker then worker requests (like importScripts()) would come out of the cache inherited from the parent document. If not, then it seems impossible to support running workers when in offline mode. Since SharedWorkers are shared by multiple windows, there's some ambiguity about which app cache it should use (perhaps always the one from the creator window?) - it seems like an app might get different SharedWorkers() loading from different app caches depending on the order in which different windows create them, which seems like a dubious outcome. Has this been discussed previously? -atw
Re: [whatwg] Link.onload; defer on style, depends
On Fri, 13 Feb 2009, Boris Zbarsky wrote:
Ian Hickson wrote:
By the way, the spec doesn't yet require the blocking behavior. I
couldn't work out how to do it. Could you elaborate on when exactly in
the process the style sheet is waited on? Does it happen for all
scripts? For example, if a script inserts a style sheet and then a
script, does that script wait for the style sheet to load?
The current Gecko behavior is that any stylesheet load started by
parsing a style or link tag will increment a counter on the document
(well, on a per-document script loader object, to be more precise).
Completion of the load will decrement the counter. While the counter is
nonzero, script execution is blocked. When it goes back to 0, the
first pending script (if any) is run. If this increments the counter
again, no more scripts are run until the count goes to 0 again.
So it doesn't matter how the script is created/inserted, but the only
stylesheets that block scripts are ones that the parser knows about.
So only the ones present in the original source or added via
document.write. If you createElement a link and insert it into the
DOM, it won't block script execution. Also, link elements pointing to
alternate style sheets don't block script execution.
So testing this:
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/44
http://software.hixie.ch/utilities/js/live-dom-viewer/saved/45
(44 uses currentStyle, for IE/Opera, 45 uses getComputedStyle, for Opera/
Firefox/Safari)
It seems Gecko is the only engine that blocks here.
It would be interesting to hear from other browser vendors about their
opinions on this issue.
On Sun, 15 Feb 2009, Boris Zbarsky wrote:
So in this:
!DOCTYPE html
...
script
document.write('link rel=stylesheet href=style');
document.write('scripta();\/script');
b();
/script
...is the script paused after the second document.write() call, before a()
and b() execute?
No. What's paused is execution of new scripts, not of existing ones. So in
this case, b() executes immediately, while a() executes after the stylesheet
loads.
Woah, so this can affect the order of script execution?
That seems very dangerous. What if b() depends on a()? I would be
surprised if this didn't cause compatibility problems.
On Sat, 14 Feb 2009, Garrett Smith wrote:
Boris:
Garrett:
What would make it easier? I'd really like to know how to design my
pages so that they are faster and more responsive.
Well, one option is to stop worrying about micromanaging the load
order and assume that speculative parsing will solve your problems
will it?
Possibly. If the author could declare what a script depends on and let
the implementation determine what to load and when, would that be too
complicated?
It seems like this is in general an issue that would be best left up to
the browsers to optimise for, instead of having authors be able to
micromange this (as Boris put it).
In general, scripts shouldn't depend on style sheets anyway; if you are
writing code where you want things to be fast, just avoid breaking that
rule of thumb and then it will never matter.
On Sun, 15 Feb 2009, Garrett Smith wrote:
Ian wrote:
On Mon, 9 Feb 2009, Garrett Smith wrote:
There are two/three issues.
1) want to load stylesheets without having scripts block
Put the scripts first.
Then the scripts block. I explained this and showed this in examples.
If the script is deferred, it will wait for the stylesheet.
For the case where you just want scripts to load whenever they are ready
to load, you can use async=.
2) want to load stylesheets later, (infoPanel example)
Put the styles later.
The script blocks the stylesheet.
The alternative is to just let the browser manage this and load the style
sheets whenever they want.
3) (2), but want to make sure the stylesheet is loaded before the
script runs.
Put the styles first.
The stylesheet can be placed right before the script which depends on
it, right before closing body tag:
http://dhtmlkitchen.com/jstest/block/link-script-bottom.html
and the result will work in Firefox. However, that does not works
consistently in a wide enough range of current browsers. Particularly,
Webkit and Opera will alert('loaded') before getting the stylesheet.
Make the script not depend on the style sheet then.
In general, I don't think that this feature request is something that
really is necessary on the Web. The best way forward is really to just
design your scripts such that they don't depend on the style sheets (you
have no guarantee that the user will get the CSS anyway), and then to just
rely on the browser vendors to make the right decisions about when to
fetch each file.
On Sat, 14 Mar 2009, Greg Houston wrote:
This is a request for the link element to be given an onload attribute.
Often when
