Re: [whatwg] C:\fakepath\ in HTML5
Image.src as resolved by the browser. In IE, Chrome and FF I noted today (something different than it was a year or so ago) that for content served from the local drive space (in Windows anyhow), document.images[x].src resolves to file:///C:/ [path]. In Opera, it still resolves to file://localpath:/ . With the risk of not being compliant with other OS's, but isn't using file://localpath/real_file_name.extension (so using file://localpath/ by default) the solution for the original suggestion? This ensures not breaking anything on existing websites and is a far more logical name for the whole workaround. my 2cents - Original Message - From: ddailey ddai...@zoominternet.net To: Ian Hickson i...@hixie.ch; wha...@whatwg.org Sent: Wednesday, March 25, 2009 11:26 PM Subject: Re: [whatwg] C:\fakepath\ in HTML5 While on the topic, something vaguely similar came to mind. If we make a puzzle of 2n-squared minus 1 (e.g. a puzzle of 15) in which web site visitors can slide tiles around through a grid, we might wish to detect, through script, when the puzzle has been solved. This means interrogating the value of Image.src as resolved by the browser. In IE, Chrome and FF I noted today (something different than it was a year or so ago) that for content served from the local drive space (in Windows anyhow), document.images[x].src resolves to file:///C:/ [path]. In Opera, it still resolves to file://localpath:/ . Hence, script to determine if the puzzle has been solved has to resort to a wee bit of mischief to untangle the issue. Over the past nine years or so, I've seen at least a half dozen different strategies employed by various browsers to deal with the issue, ranging from the sensible to the bizarre, varying as a function of where the file is found (in local drive space, networked files, or even files served from the web). Where might we expect things to settle down ultimately? cheers David P.S. I gather from what you've written here, that indeed the spec will simplify access to local drive space through input type=file eventually, hence allowing client-side image manipulation for web applications? Will this solution propagate outward into SVG as well, where it will also be quite useful, or only if the SVG is inlined in HTML? - Original Message - From: Ian Hickson i...@hixie.ch To: wha...@whatwg.org Sent: Wednesday, March 25, 2009 5:39 PM Subject: Re: [whatwg] C:\fakepath\ in HTML5 The long and short of it with the c:\fakepath\ issue is that some browser vendors have reported compatibility problems with not having this. I acknowledge that there is some skepticism about whether this is a serious enough issue to warrant this ugly hack, but given that the concerns were raised by two browser vendors independently, it seems likely that we should heed their advice. I don't think is a huge issue because we will in due course (when Arun's spec is ready) be adding an API to input type=file that exposes the actual files, filenames, types, etc, and the .value API will be vestigial. (The .value API has other issues, like only exposing the first file in a multiple-file upload widget.) On Tue, 24 Mar 2009, Boris Zbarsky wrote: Ian Hickson wrote: 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. 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. Realistically speaking, that seems unlikely to be practical. I wouldn't be really surprised that someone would want to upgrade the firmware on a device ten years from now, for instance. We never know. 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. We both know that evanglisation efforts don't have a great success rate. 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. Indeed, I wouldn't be surprised if this was why Opera and IE have seen this problem, but Mozilla has not. On Tue, 24 Mar 2009, Alex Henrie wrote: Example: A site lets a user
Re: [whatwg] AppCache and SharedWorkers?
On 26.03.2009, at 1:01, Drew Wilson wrote: * Shared (or persistent) worker contexts should be associated with an appcache according to the same resource loading and cache selection logic used for top-level browsing contexts. (So just like navigating a window.) That may make sense for Shared workers, I think. For persistent workers I think this is a problem - persistent workers need a way to manage their own app cache, since they are not guaranteed to have any open windows/documents associated with them. My concern about this is that app cache manifests are only specified via manifest html tags, which makes them only applicable to HTML documents (you can't associate a manifest with a worker since there's no document to put the manifest tag in). Letting faceless background processes update themselves without user consent is not necessarily desirable. I think that they need browser UI for this, and/or associated HTML configuration pages that could (among other duties) trigger application cache update. So in my opinion, this is pretty much a sub-task of defining what UI is necessary for persistent workers in the browser, not a question of exposing application cache APIs to them. - WBR, Alexey Proskuryakov
Re: [whatwg] AppCache and SharedWorkers?
On Thu, Mar 26, 2009 at 3:58 AM, Alexey Proskuryakov a...@webkit.org wrote: Letting faceless background processes update themselves without user consent is not necessarily desirable. I think that they need browser UI for this, and/or associated HTML configuration pages that could (among other duties) trigger application cache update. I'd be curious about why you think this is a problem, especially given the existence of importScripts() and XHR which allow workers to load scripts dynamically anyway. ApplicationCache for persistent workers would enable them to continue running even when offline - I don't see that it introduces any new security/permission wrinkles, though. If you don't provide something like that, then you'll have workers doing things like using XHR to download script, store it in the data store, then eval() it at load time to roll their own manual offline support.
[whatwg] URL decomposition on HTMLAnchorElement interface
It seems that major browsers all support URL decomposition on HTMLAnchorElement, but this doesn't seem to be stated anywhere in the HTML5 spec. The jQuery/tabs library seems to depend on this (specifically, on the hash property) being available. Could the HTMLAnchorElement interface be updated to reflect this? Cheers, kats
Re: [whatwg] URL decomposition on HTMLAnchorElement interface
Browsers also support partially setting each of the url fields separately, although error handling between all of them is very inconsistent. Note: if you specify this behavior, then you need to specify what happens for http:, https:, data:, mailto: and unknown: On Thu, 26 Mar 2009 19:32:46 +0100, Kartikaya Gupta lists.wha...@stakface.com wrote: It seems that major browsers all support URL decomposition on HTMLAnchorElement, but this doesn't seem to be stated anywhere in the HTML5 spec. The jQuery/tabs library seems to depend on this (specifically, on the hash property) being available. Could the HTMLAnchorElement interface be updated to reflect this? Cheers, kats -- João Eiras Core Developer, Opera Software ASA, http://www.opera.com/
Re: [whatwg] URL decomposition on HTMLAnchorElement interface
João Eiras wrote: Browsers also support partially setting each of the url fields separately, although error handling between all of them is very inconsistent. Note: if you specify this behavior, then you need to specify what happens for http:, https:, data:, mailto: and unknown: If you specify the setters then you also need to specify how this affects the value of the href attribute in the DOM. For example, in Gecko if you have an a href=foo#bar which has base URI http://example.com/; and you set anchor.hash on that anchor to baz, then the attribute value is changed to http://example.com/foo#baz;. I can't speak to what happens in other browsers. -Boris
Re: [whatwg] AppCache and SharedWorkers?
On 26.03.2009, at 19:26, Drew Wilson wrote: Letting faceless background processes update themselves without user consent is not necessarily desirable. I think that they need browser UI for this, and/or associated HTML configuration pages that could (among other duties) trigger application cache update. I'd be curious about why you think this is a problem, especially given the existence of importScripts() and XHR which allow workers to load scripts dynamically anyway. importScripts() will only allow dynamic loading if any URL prefixes are designated as NETWORK in the manifest, which security sensitive users may potentially detect and block. The level of support for this in browsers, firewalls, anti-viruses and other software will obviously depend on future usage patterns and threats, but the possibility is there. But I was looking at this in terms of a model for users, not any specific security threats - if we think of persistent workers as an equivalent of native applications that need installation, then we should consider that native applications don't usually update themselves without user consent. - WBR, Alexey Proskuryakov
Re: [whatwg] AppCache and SharedWorkers?
On Thu, Mar 26, 2009 at 1:19 PM, Alexey Proskuryakov a...@webkit.org wrote: But I was looking at this in terms of a model for users, not any specific security threats - if we think of persistent workers as an equivalent of native applications that need installation, then we should consider that native applications don't usually update themselves without user consent. It seems like a common model is for offline-enabled applications to store their javascript in the ApplicationCache, and encourage users to create desktop links to access those apps even when offline. Should these applications (which for all intents are installed) also prompt users before updating? Are you suggesting that user agents may want to require explicit user permission when any application invokes ApplicationCache.update()? That might be a reasonable approach if a given user agent wants to enforce some kind of no silent update policy... -atw
Re: [whatwg] URL decomposition on HTMLAnchorElement interface
Boris wrote:
If you specify the setters then you also need to specify how this
affects the value of the href attribute in the DOM. For example, in
Gecko if you have an a href=foo#bar which has base URI
http://example.com/; and you set anchor.hash on that anchor to baz,
then the attribute value is changed to http://example.com/foo#baz;.
I was trying different things to see what happens and came across some
particularly weird behavior in Gecko/2009021910 Firefox/3.0.7:
var a = document.createElement('a');
a.setAttribute('href', 'http://example.org:123/foo?bar#baz');
a.hostname = null;
alert(a.hostname); // displays foo
alert(a.href); // displays http://foo/?bar#baz;
a.setAttribute('href', 'scheme://host/path');
a.host = null;
alert(a.host); // displays
alert(a.pathname); // displays
alert(a.href); // displays scheme:host/path
This behavior seems rather inconsistent and possibly buggy. I tried looking in
Bugzilla to see if anything turned up but my search keywords just kept hitting
a lot of unrelated stuff so I didn't try too hard.
Cheers,
kats
Re: [whatwg] URL decomposition on HTMLAnchorElement interface
On Thu, Mar 26, 2009 at 5:26 PM, Kartikaya Gupta
This behavior seems rather inconsistent and possibly buggy.
At first look I also thought it is inconsistent
But later I found Firefox is very consistent.
I think reason why it happening like that is because Firefox clean up
URL by removing extra slash before host name
and adding a slash after host name and also convert host name to lowercase.
Try this
var a = document.createElement('a');
a.setAttribute('href', 'http:/Example.org:123/foo?bar#baz'); //Case 1
alert(a.href);
a.setAttribute('href', 'http:example.org:123/foo?bar#baz');//Case 2
alert(a.href);
a.setAttribute('href', 'http:///example.org:123/foo?bar#baz');//Case 3
alert(a.href);
a.setAttribute('href', 'http:/example.org:123/foo?bar#baz');//Case 4
alert(a.href);
Firefox clean up the URL
and all shows http://example.org:123/foo?bar#baz;
So now when you set host as null, I ASSUME following is happening
http://example.org:123/foo?bar#baz;
===
http://blank/foo?bar#baz
===
http:///foo?bar#baz;
===
http://foo/?bar#baz;
Firefox do this same for protocols http, https, ftp for others it wont
allow hostname change.
Setting
a.hash = null;
a.search = null;
are allowed for http, https, ftp, file and jar
(may be for data: also, I have not tested it)
You can use a null string instead of null.
And I know host name can not be set to space or a string containing space.
But it is allowing invalid characters like !$%^*( etc.
Get confused when it find @#? as hostname
Now question is do we need to allow to set host to a null or ?
PS: Jar protocol example
jar:http://example.org:123/foo!/?bar#baz;
[whatwg] fileList vs files
I have a poor memory, hence not good in spelling, if there is not much gain with a change, i wish every thing follow a similar pattern and with short spelling, which make my life little easier. On C:\fakepath\ in HTML5 thread Anne mentioned fileList for input type=file multiple On Tue, Mar 24, 2009 at 10:15 AM, Anne van Kesteren ann...@opera.com wrote: application developers...) Furthermore, once we get interoperable support for input type=file multiple and the fileList proposal starts moving we Can we call it files instead of fileList, this will make it consistent with existing names like arguments document.links selection_element.options document.plugins document.embeds document.anchors document.forms document.applets document.images on firefox we fixed it https://bugzilla.mozilla.org/show_bug.cgi?id=405741
Re: [whatwg] fileList vs files
On Thu, Mar 26, 2009 at 8:26 PM, Biju bijumaill...@gmail.com wrote: I have a poor memory, hence not good in spelling, if there is not much gain with a change, i wish every thing follow a similar pattern and with short spelling, which make my life little easier. On C:\fakepath\ in HTML5 thread Anne mentioned fileList for input type=file multiple On Tue, Mar 24, 2009 at 10:15 AM, Anne van Kesteren ann...@opera.com wrote: application developers...) Furthermore, once we get interoperable support for input type=file multiple and the fileList proposal starts moving we Can we call it files instead of fileList, this will make it consistent with existing names like arguments document.links selection_element.options document.plugins document.embeds document.anchors document.forms document.applets document.images on firefox we fixed it https://bugzilla.mozilla.org/show_bug.cgi?id=405741 I agree that the property should be called .files. However given that we don't have any property at all specced yet, it feels a little bit early to start debating the name :) / Jonas
