Re: [whatwg] onclose events for MessagePort
On GC being a source of cross-browser difficulty: I think you can fix that by stating in the messageport spec when we guarantee to implicitly close the connection (when its host page closes) and when we provide no guarantees (when it loses all its references). On people relying on GC timing: Those people are being silly and deserve what they get, as they do in Java. Using destructors in that language is very nearly always a bad idea, but they still put them there and it was fine. I guess I think people who misinterpret the spec and do things which are obviously a bad idea are only to a limited extent our problem. The web needs to become a place where serious, large applications can be written, it's not going to get there if the standard we set ourselves for the APIs is "they can't possibly misuse this even if they've read no documentation and are just guessing". -Dave On Thu Oct 10 2013 at 1:00:54 PM, Boris Zbarsky wrote: > On 10/10/13 11:43 AM, David Barrett-Kahn wrote: > > Why is revealing when garbage collection happens such a terrible thing > > anyway? > > Because web pages can then start depending on GC timing, limiting the > kinds of GC optimizations browsers can do. > > -Boris >
Re: [whatwg] onclose events for MessagePort
This is a feature we've long wanted for Google Docs, but not for the most obvious reason. We have a situation where more than one tab can be visualizing the same document. Under those conditions, we have a requirement that one of the documents hold a lock which entitles it to do things with the locally stored version of the document which other tabs and workers in the system cannot. Implementing this locking system is painful and inefficient. One of the main reasons is that it's impossible to get a notification in the shared worker (where the lock 'lives') when the lock-holding tab has closed. We would use a message port onclose event for this, reducing the complexity of our current system (which involves polling loops and other very undesirable things) tremendously. Generally speaking it's just a disappointing moment when you discover message ports don't have this capability and you have to jury rig an unreliable workaround, like so many times before. A communications channel with no 'is connected' status on it is just... not finished. Why is revealing when garbage collection happens such a terrible thing anyway? Java does it... -Dave On Wed Oct 09 2013 at 1:11:09 AM, David Levin wrote: > On Tue, Oct 1, 2013 at 11:13 AM, Boris Zbarsky wrote: > > > On 10/1/13 2:11 PM, Ian Hickson wrote: > > > >> How often do we expect two tabs to be talking to each other though? > >> > > > > Or a page to an out-of-process subframe? > > > > How often do we expect MessageChannel to be used at all? > > > Speaking as an web developer, I've found MessageChannel to be pretty useful > when writing a complex web application because it allows you to isolate > different communication pathways and hop across multiple iframes in a > single bound (while only knowing about the next step at any one layer... it > is hard to explain why this is useful without having to dive into the app). > You can do this all on top of window.postMessage but it is more complicated > and fragile. (Due to this, I've had to write a a layer above these that > allows me to use either so that my code can work on browsers that don't > support MessageChannel but it will be easier to debug on those that do.) > > dave > > > > > > > > Is that even possible on phone browsers? > >> > > > > Sure is in Firefox and FirefoxOS. > > > > > > Anyway, I'm happy to support this in principle. > >> > > > > OK, good. ;) > > > > -Boris > > >
Re: [whatwg] Fwd: fallback section taking over for 4xx and 5xx responses while online
Generally speaking, this feature is useful where the error page is somewhat routine and contains information comprehensible and actionable by the user, which would otherwise be lost in the fallback. This was mainly about 404s, which docs will serve when a requested document id doesn't exist, which includes cases where it was deleted. All our offline application could say (once triggered) was that the document was not present in our local storage. It couldn't say the document didn't actually exist. We therefore wanted the server's version of the error page to be displayed. 401/403 were also of interest, mainly for cases where the user had previously had access to a document, but that access had been rescinded. Whether it's a good idea to divert 500s kind of depends on what they are, especially whether the served error page contains user-actionable information. The current generation of docs offline attempts to only engage the browser's offline machinery when truly offline. For example, the regular docs pages one interacts with when online do not bind appcaches. We have a fallback entry covering the entire origin which engages this machinery, loading a 'controller' style application which decides how to handle whatever URL was provided. We have this strict separation for two reasons. First, we were very keen to ensure that instability in the new offline technologies we were using never lead to disruption of the online solution, especially during early development. Second, the online start-up procedures used by our applications are complex and highly optimized, and fundamentally incompatible with appcache due to a 'blending' of the document and the application. We wanted to preserve those optimizations online and have a different startup procedure when offline. -Dave On Mon, Dec 17, 2012 at 3:30 PM, Ian Hickson wrote: > On Tue, 11 Dec 2012, David Barrett-Kahn wrote: > > > > We ran into this same problem on Google Docs offline. Our solution was > > to add a proprietary response header to Chrome which instructs the > > browser that the response is not to trigger the fallback entry, despite > > its response code. Something like it could be considered for > > standardization. I know there are some people on the Chrome team looking > > to advance some new appcache features, and that this use case is on > > their list. > > Can you elaborate on the need for this feature? Why would you ever send > the user to a 404 page intentionally (i.e. when the server isn't broken)? > Similarly, why would you not consider the server returning 500 a good > indication that the cache should be used? > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- -Dave
Re: [whatwg] Fwd: fallback section taking over for 4xx and 5xx responses while online
We ran into this same problem on Google Docs offline. Our solution was to add a proprietary response header to Chrome which instructs the browser that the response is not to trigger the fallback entry, despite its response code. Something like it could be considered for standardization. I know there are some people on the Chrome team looking to advance some new appcache features, and that this use case is on their list. For the time being, that header and the 'make everything a 200' solutions are the only ones I know of. https://bugs.webkit.org/show_bug.cgi?id=60493 -Dave On Mon, Dec 10, 2012 at 1:37 PM, Ian Hickson wrote: > On Fri, 24 Aug 2012, Josh Sharpe wrote: > > > > I have a manifest that looks something like this: > > > > CACHE MANIFEST > > # e4a75fb378cb627a0d51a80c1cc5684c2d918d93e267f5854a511aa3c8db5b1a > > /a/application.js > > /a/application.css > > > > NETWORK: > > * > > > > FALLBACK: > > / /offline > > > > Notably, it has a "/ /offline" fallback section which is, obviously, a > > prefix for every page on my site. This is good, because the goal is to > > have my users redirected to what's at /offline when they navigate to > > www.mydomain.com while offline. > > Note that the Offline Application Cache feature is for Offline > Applications, not Offline Sites. What you're trying to do here is not what > appcache was designed to do. > > Also, it's not clear what you mean by "offline". For the record, in the > spec, "offline" includes "I'm on wifi but there's a captive portal" and > "I'm online but the server is broken". > > > > As the fallback section is a prefix for everything, it's a prefix for any > > url/path that results in an error condition such as a 404 or 500 > response. > > These are cases where it's assumed that the server is broken, i.e. > offline, and the cache is therefore used. > > > > It seems that the application cache, when it encounters an error state > > such as a 404 or 500, doesn't check to see if the browser is still in > > the 'online' state, and immediately falls over to the fallback section. > > It does check -- by definition, if it receives a 4xx or 5xx, it's assumed > that the server is offline (broken). > > > > While online, I would expect my 4xx and 5xx page to be rendered > > normally. > > Offline Application Cache doesn't have a "while online" mode, it just > always works as if you were offline and tries to get the data from the > server while the server is able to respond. > > This is an important facet of how appcache works: it doesn't "work online" > or "work offline". It always acts in "offline" mode (or rather, always > works in "internet connection is flaky" mode). > > > > Finally, the fallback section in my example is very typical of most > > examples I find in various docs, including the whatwg spec. I don't > > think I'm doing anything abnormal here. > > What's abnormal is having the user visit pages that return 4xx or 5xx > error codes when there's no problem. :-) > > > > Should I design this differently or is there something missing from the > > spec? > > It's hard to know exactly without understanding more about your use case. > Can you elaborate on what you're trying to do? > > > We could just exclude 4xx (and maybe 5xx? Though that seems less > reasonable) error codes from being considered "offline" for fallback- > supported resources, if people are commonly linking people to missing > pages intentionally (and don't want the problem hidden from users by > having it fall back to locally-generated pages). But that seems like a > weird thing to do... > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- -Dave
Re: [whatwg] AppCache Error events
So are there no objections to this, should I draft a change to the spec? -Dave On Mon, Nov 26, 2012 at 12:00 PM, David Barrett-Kahn wrote: > Right now this event contains no structured information, just an error > message. It'd be helpful to us to know more about what failed, so we can > know what to report to the server and take action on. It's hard to > distinguish cache update failures due to just being offline from those > which are actually causing trouble. In the second case it's also hard to > work out which resource is proving unavailable and why. > > One way to do this would be to create an AppCacheError subclass, with an > errorCode parameter, and also nullable url and httpResponseCode properties. > Potential error codes: > * couldn't fetch manifest (includes url and httpResponseCode) > * pre and post update manifest fetches mismatched (includes url) > * fetching a resource failed (includes url and httpResponseCode) > > Related bug: > https://code.google.com/p/chromium/issues/detail?id=161753 > > Thoughts? > > -Dave > > -- -Dave
[whatwg] AppCache Error events
Right now this event contains no structured information, just an error message. It'd be helpful to us to know more about what failed, so we can know what to report to the server and take action on. It's hard to distinguish cache update failures due to just being offline from those which are actually causing trouble. In the second case it's also hard to work out which resource is proving unavailable and why. One way to do this would be to create an AppCacheError subclass, with an errorCode parameter, and also nullable url and httpResponseCode properties. Potential error codes: * couldn't fetch manifest (includes url and httpResponseCode) * pre and post update manifest fetches mismatched (includes url) * fetching a resource failed (includes url and httpResponseCode) Related bug: https://code.google.com/p/chromium/issues/detail?id=161753 Thoughts? -Dave
Re: [whatwg] Proposal for a debugging information API
I'm not sensing a lot of enthusiasm about this proposal, and am guessing it would be an uphill slog with all the privacy/security issues involved. I'm therefore thinking I won't take it any further. If you feel something important is being lost here and that you could help me move this forward do let me know though. Thanks, -Dave On Fri, Nov 16, 2012 at 6:04 PM, Ian Hickson wrote: > On Fri, 16 Nov 2012, David Barrett-Kahn wrote: > > > > Thanks Ian. So here's what confuses me, why is the bar so much higher > > for traditional webapps than it is for browser extensions, chrome apps, > > native apps, mobile apps or nearly anything else? > > Browser extensions, chrome apps, native apps, and mobile apps aren't > anywhere near as secure as Web apps. > > The bar shouldn't be any lower for them than for the Web, but that it is > is one of the Web's biggest strengths. You can, by and large, follow any > random link, and be assured that you're not going to get scammed (modulo > security bugs). If you just install any random native program you come > across, your machine is going to become a nest of malware. > > > > Extensions, chrome apps, and mobile apps have a consent experience, but > > it's hard to argue that users are making an informed decision there and > > that the consent experience really protects them. Native apps have no > > consent experience at all. > > Right. Compare the average amount of malware on a Windows machine to that > on a Chrome OS machine. :-) > > > > I guess I'm hoping you can point me to some guidelines you've developed > > or which you agree with on where the limits of the web sandbox should > > be. I'd rather not force you to re-have a discussion I'm sure you've > > had far too many times :-) > > I don't think there's anything formally written down. > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- -Dave
Re: [whatwg] Proposal for a debugging information API
Thanks Ian. So here's what confuses me, why is the bar so much higher for traditional webapps than it is for browser extensions, chrome apps, native apps, mobile apps or nearly anything else? Extensions, chrome apps, and mobile apps have a consent experience, but it's hard to argue that users are making an informed decision there and that the consent experience really protects them. Native apps have no consent experience at all. I guess I'm hoping you can point me to some guidelines you've developed or which you agree with on where the limits of the web sandbox should be. I'd rather not force you to re-have a discussion I'm sure you've had far too many times :-) Regards, -Dave On Fri, Nov 16, 2012 at 10:06 AM, Ian Hickson wrote: > On Thu, 15 Nov 2012, David Barrett-Kahn wrote: > > > > Ian, I'd be interested in what you had in mind when you said 'a lot of > > user opt-in'. > > I don't know, exactly. It has to be something where we're confident that > the user understands that he is about to send sensitive information to a > stranger. > > The concern isn't when this is used by a company like Apple or Facebook; > the worst such companies are going to do with sensitive data is target ads > better or make their products more streamlined. The concern is when some > attacker wants to get information about your company's intranet's > topology, or wants to know what potentially vulnerable plugins or > extensions you have installed, or wants to know what software you are > running, so that they can more precisely target you. Such an attacker can > trivially provide you with a game to play, and then have the game crash, > misleading you into thinking they're a perfectly honest game developer and > causing you to eagerly send them all the sensitive information they want. > > These are not hypothetical concerns. Over the last few years, targetted > attacks of this nature have become much more common and are a real threat. > > -- > Ian Hickson U+1047E)\._.,--,'``.fL > http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' > -- -Dave
Re: [whatwg] Proposal for a debugging information API
Thanks Tobie, that does sound related, but not quite the same use case. That proposal seems to want to make the creation of memory/network/runtime performance profiles scriptable if the user allows it. Presumably you wouldn't do that routinely, which raises the question of when you would do it. Once the app has crashed it's probably too late. I foresee this mainly being used by groups of users 'friendly' to the application author, such as employees of their firm, qa testers, etc. Their privacy issue isn't so bad, either, as there would be nothing in those profiles which the app author didn't in principal have access to before. I'm also not sure my use case falls inside the performance working group's charter. In any case, I'll reach out to them and see if they're interested, thanks. Ian, I'd be interested in what you had in mind when you said 'a lot of user opt-in'. Presumably you don't feel a permission dialog raised at the time of the API call enough, were you thinking of a browser configuration setting, off by default? That's very limiting, you'd be down to 'friendly users' again. Your other objections I think could mostly be dealt with. I've specified that user agents supporting the screenshot have to provide a blackout tool. Also, in some ways the more annoying this dialog is the better, as it's supposed to be something devs only use if they really need to. You could focus the 'no' button by default, or make it unresponsive until a timeout, stuff like that. I'll raise this with some of the browser vendors directly as Ian suggested. Thanks, -Dave On Thu, Nov 15, 2012 at 1:46 AM, Tobie Langel wrote: > On Thu, Nov 15, 2012 at 6:07 AM, David Barrett-Kahn > wrote: > > Hi whatwg. I have a proposal for a new web standard, and would value > your > > feedback. This is based on my experiences working on Google Docs, which > > has a well developed ability to send crash reports back to the server for > > analysis. We often find these crash reports to be lacking in crucial > > information though, because that information is not available on the JS > > APIs. > > > > My proposal is to have a class of information which can be made available > > to an app only after the display of a generic 'this application has > > crashed' dialog, which could be drilled into to show what is being > > disclosed, and which of course can be denied. > > > > Good examples of the information in question are the system's precise > > hardware and network configuration, what Chrome extensions it has > > installed, and perhaps a screenshot of the failed application. > > There is directly related work[1] being included in the WebPerf > WG[2]'s upcoming charter. Given the privacy and fingerprinting > constraints are the same, you should probably bring your suggestions > there. > > --tobie > --- > [1]: > https://docs.google.com/document/d/1Yw_qNMCnGsWQRsdcrifzh_kzFey-ThQ3yp-DmxuJxvg/edit > [2]: http://www.w3.org/2010/webperf/ > -- -Dave
Re: [whatwg] Proposal for a debugging information API
Yes, thanks, these are just the sorts of systems which would be used to collect this information were it available. I believe that as it becomes easier for less well resourced development teams to have crash reporting of this kind its use will become more widespread, and that it will eventually become part of the standard toolkit. -Dave On Wed, Nov 14, 2012 at 9:12 PM, Gordon P. Hemsley wrote: > Recent blog posts that coincidentally may be useful in this discussion: > > http://vocamus.net/dave/?p=1532 > http://www.twobraids.com/2012/11/socorro-as-service.html > > > On Thu, Nov 15, 2012 at 12:07 AM, David Barrett-Kahn wrote: > >> Hi whatwg. I have a proposal for a new web standard, and would value your >> feedback. This is based on my experiences working on Google Docs, which >> has a well developed ability to send crash reports back to the server for >> analysis. We often find these crash reports to be lacking in crucial >> information though, because that information is not available on the JS >> APIs. >> >> My proposal is to have a class of information which can be made available >> to an app only after the display of a generic 'this application has >> crashed' dialog, which could be drilled into to show what is being >> disclosed, and which of course can be denied. >> >> Good examples of the information in question are the system's precise >> hardware and network configuration, what Chrome extensions it has >> installed, and perhaps a screenshot of the failed application. >> >> I've fleshed this out in the following document, and would value opinions >> on the value of a feature of this kind, and the merits of this particular >> approach. >> >> >> https://docs.google.com/document/pub?id=1pw2Bzvy6OEn8YY3fAcZiReJPmgB79swkx-NJAdcemPk >> >> Thanks! >> >> -Dave >> > > > > -- > Gordon P. Hemsley > m...@gphemsley.org > http://gphemsley.org/ • http://gphemsley.org/blog/ > -- -Dave
[whatwg] Proposal for a debugging information API
Hi whatwg. I have a proposal for a new web standard, and would value your feedback. This is based on my experiences working on Google Docs, which has a well developed ability to send crash reports back to the server for analysis. We often find these crash reports to be lacking in crucial information though, because that information is not available on the JS APIs. My proposal is to have a class of information which can be made available to an app only after the display of a generic 'this application has crashed' dialog, which could be drilled into to show what is being disclosed, and which of course can be denied. Good examples of the information in question are the system's precise hardware and network configuration, what Chrome extensions it has installed, and perhaps a screenshot of the failed application. I've fleshed this out in the following document, and would value opinions on the value of a feature of this kind, and the merits of this particular approach. https://docs.google.com/document/pub?id=1pw2Bzvy6OEn8YY3fAcZiReJPmgB79swkx-NJAdcemPk Thanks! -Dave
Re: [whatwg] CACHE MANIFEST
If you're referring to a debugging tool, Chrome has chrome:appcache-internals for this purpose. At least in dev channel it shows the full contents of the cache, not sure whether that change has made it to stable yet. -Dave On Sun, Oct 16, 2011 at 1:54 PM, Francis Boumphrey wrote: > This is a great new addition. > However none of the current versions of Browsers provide an easy way to > view > cached files when the user is off line. Earlier IE's would give you an > option, but this seems to have been done away with i later versions. > Should not The spec require that compliant browsers provide an easy way to > view cached files when the user is off line? > Frank > -- -Dave
