Re: [whatwg] Zip archives as first-class citizens
On Wed, Aug 28, 2013 at 10:21 AM, Glenn Maynard wrote: > On Wed, Aug 28, 2013 at 12:07 PM, Eric Uhrhane wrote: >> >> We've covered this several times. The directory records in a zip can >> be superseded by further directories later in the archive, so you >> can't trust that you've got the right directory until you're done >> downloading. > > Both the local headers and the central record can be wrong. (As mentioned > on IRC the other day, apparently EPUB files often have broken central > records, so eBook readers probably prefer the local records.) If they're > out of sync, then they'll always be broken in some clients. > > We just have to make sure that the record that takes priority in any > particular case is well-defined, so we have interop. If some malformed > archives won't work in some cases as a result, using a different format > isn't an improvement: that just means *zero* existing archives would work. Broken files don't work, and I'm OK with that. I'm saying that legal zips can have multiple directories, where the definitive one is last in the file, so it's not a good format for streaming. If you're saying that you want to change the format to make an earlier directory definitive, that's going to break compat for the existing archives everywhere, and would be confusing enough that we should just go with a different archive format that doesn't require changes. Or at least don't call it zip when you're done messing with the spec. > This applies to various other aspects of the format: the maximum supported > length of comments and handling of duplicate filenames, for example. This > would all need to be specified; the ZIP "AppNote" doesn't specify a parser > or error handling in the way the web needs, it just describes the format. > > -- > Glenn Maynard >
Re: [whatwg] Zip archives as first-class citizens
On Wed, Aug 28, 2013 at 9:43 AM, Glenn Maynard wrote: > On Wed, Aug 28, 2013 at 4:54 PM, Eric Uhrhane wrote: >> >> > Without commenting on the other parts of the proposal, let me just >> > mention that every time .zip support comes up, we notice that it's not >> > a great web archive format because it's not streamable. That is, you >> > can't actually use any of the contents until you've downloaded the >> > whole file. > > > ZIPs support both streaming and random access. You can access files in a > ZIP as the ZIP is downloaded, using the local file headers. In this mode, > they work like tars (except that you don't have to decompress unneeded data, > like you do with a tar.gz). Anne's quote snipped off an important piece of my message [which apparently didn't get out due to the too-many-recipients problem]: > [Before you respond that it's streamable, please look in the archives > for the rebuttal.] We've covered this several times. The directory records in a zip can be superseded by further directories later in the archive, so you can't trust that you've got the right directory until you're done downloading. > This feature wouldn't want that, since you need to read the whole file up to > the file you want. Instead, it wants random access, which ZIPs also > support. You download the central directory record first, to find out where > the file you want lies in the archive, then download just the slice of data > you need. You don't need to download the whole file. > > -- > Glenn Maynard >
Re: [whatwg] Zip archives as first-class citizens
Again from the right address... On Wed, Aug 28, 2013 at 8:47 AM, Eric U wrote: > Without commenting on the other parts of the proposal, let me just > mention that every time .zip support comes up, we notice that it's not > a great web archive format because it's not streamable. That is, you > can't actually use any of the contents until you've downloaded the > whole file. > > Perhaps some other archive format would be a better fit for the web? > > [Before you respond that it's streamable, please look in the archives > for the rebuttal.] > > Eric > > > On Wed, Aug 28, 2013 at 6:32 AM, Anne van Kesteren wrote: >> A couple of us have been toying around with the idea of making zip >> archives first-class citizens on the web. What we want to support: >> >> * Group a bunch of JavaScript files together in a single resource and >> refer to them individually for upcoming JavaScript modules. >> * Package a bunch of related resources together for a game or >> applications (e.g. icons). >> * Support self-contained packages, like Flash-ads or Flash-based games. >> >> Using zip archives for this makes sense as it has broad tooling >> support. To lower adoption cost no special configuration should be >> needed. Existing zip archives should be able to fit right in. >> >> >> The above means we need URLs for zip archives. That is: >> >> >> >> should work. As well as >> >> >> >> and test.html should be able to contain URLs that reference other >> resources inside the zip archive. >> >> >> We have thought of three approaches for zip URL design thus far: >> >> * Using a sub-scheme (zip) with a zip-path (after !): >> zip:http://www.example.org/zip!image.gif >> * Introducing a zip-path (after %!): http://www.example.org/zip%!image.gif >> * Using media fragments: http://www.example.org/zip#path=image.gif >> >> High-level drawbacks: >> >> * Sub-scheme: requires changing the URL syntax with both sub-scheme >> and zip-path. >> * Zip-path: requires changing the URL syntax. >> * Fragments: fail to work well for URLs relative to a zip archive. >> >> Fragments are conceptually the cleanest as the only part of a URL >> that's supposed to depend on the Content-Type is the fragment. >> However, if you want to link to an ID inside an HTML resource you'd >> have to do #path=test.html&id=test which would require adding >> knowledge to the HTML resource that it is contained in a zip archive >> and have special processing based on that. And not just HTML, same >> goes for CSS or JavaScript. >> >> I'm not sure we need to consider sub-scheme if zip-path can work as >> it's more complex and not very well thought out. E.g. imagine >> view-source:zip:http://www.example.org/zip!test.html. (I hope we never >> need to standardize view-source and that it can be restricted to the >> address bar in browsers.) >> >> zip-path makes zip archive packaging by far the easiest. If we use %! >> as separator that would cause a network error in some existing >> browsers (due to an illegal %), which means it's extensible there, >> though not backwards compatible. >> >> We'd adjust the URL parser to build a zip-path once %! is encountered. >> And relative URLs would first look if there's a zip-path and work >> against that, and use path otherwise. >> >> Fetching would always use the path. If there's a zip-path and the >> returned resource is not a zip archive it would cause a network error. >> >> >> As for nested zip archives. Andrea suggested we should support this, >> but that would require zip-path to be a sequence of paths. I think we >> never went to allow relative URLs to escape the top-most zip archive. >> But I suppose we could support in a way that >> >> %!test.zip!test.html >> >> goes one level deeper. And "../image.gif" in test.html looks in the >> enclosing zip. And "../../image.gif" in test.html looks in the >> enclosing zip as well because it cannot ever be relative to the path, >> only the zip-path. >> >> >> -- >> http://annevankesteren.nl/
Re: [whatwg] getAsEntry(File) was, Re: Using requestFileSystem to setup mounts
On Tue, Dec 13, 2011 at 2:32 PM, Charles Pritchard wrote: > On 11/22/2011 8:58 AM, Glenn Maynard wrote: >> >> >> > Each Entry would have a dummy FileSystem object attached to it, >> in order to >> > fill out the Entry.filesystem API, but all it would contain is >> the file >> > itself. >> >> Again I think this could be left to the UA's implementation decision. >> >> >> The main point is just that a FileSystem object will always be available, >> even if the UA is only exposing one file in a directory which contains other >> (inaccessible) files. Most of the time it wouldn't be used, it just avoids >> exceptional cases in the API. (In other words, Entry.filesystem would not >> become nullable.) > > > I'd like to see a means of getting an "anonymous" FileEntry. > http://www.w3.org/TR/file-system-api/ > > The purpose being to convert a File object into a read-only FileEntry object > (with an anonymous FileSystem object). > > Currently, a FileEntry can be converted into a File object, but to turn a > File object into a FileEntry requires a writable FileSystem as well as a few > calls to file writer methods. > It may be easier to use copyTo instead of FileWriter in some cases, and it > may be easier to treat dataTransfer items as FileEntry objects depending on > the application and code paths. True; this could be a nice convenience feature, as long as it could be made read-only and all path information could be scrubbed. > This is mostly about ease of use for authors working with the file system > api. > > Glenn proposed something like getAsEntry as a fix for webkitdirectory>, earlier in this thread, but that's not the use case I'm > focused on. > I suspect that it will come in handy, to be able to work with anonymous file > systems in the future. > > In the meantime, it'd make things a bit easier to use copyTo instead of File > Writer when a file or blob is available. > > -Charles > >
Re: [whatwg] "Content-Disposition" property for tags
On Sun, Apr 10, 2011 at 11:49 AM, Glenn Maynard wrote: > On Sun, Apr 10, 2011 at 1:59 PM, Bjartur Thorlacius > wrote: > >> Right. As an end-user I ask: Does a web developer publishing links to >> resources have a say as to whether I render aforementioned resource >> immediately, write it to disk or both? >> > > As far as Content-Disposition already allows us to do this, yes. > > Note that this doesn't allow bypassing the "open/save" dialog you see in > most browsers. Content-Disposition: attachment asks the browser to show > that dialog, when otherwise it may have displayed the content directly, > without asking. (Browsers generally don't have a "show this file in the > browser, even though it's C-D: attachment" option on that dialog--they > should, but that's a separate issue.) > > Better yet, File API could have an API for writing blobs to files. >> > > FileWriter exists (don't think anyone's implemented it yet). It's an > important API, but covers a different set of use cases. allows > creating a download link to any URL (not just blobs) that behave like a > normal link, including things like the browser's standard context menu > items. FileWriter doesn't do this. Folks did propose making FileSaver do this at TPAC, but we haven't gotten around to hashing out the details yet. The idea was that FileSaver would take a URL instead of a Blob, and thus could also be used for downloading arbitrary links. > -- > Glenn Maynard >
Re: [whatwg] Intent of the FileSystem API
On Mon, Feb 28, 2011 at 2:54 PM, Charles Pritchard wrote: > I'd like some clarification on the intent of the FileSystem API: > requestFileSystem permanent, getDirectory and getFile. The FileSystem API has several goals. Some of them are targeted by the current spec, and some have been discussed, but put off until later. We didn't want to take on too much in a single pass [hence the three layers of file-related specs so far]. > Are they intended to directly pass through to the host operating system, or > are they just programming constructs? The intent for the local sandbox described in the current FileSystem spec was that that would be up to the implementer. If a UA implements it as a passthrough, the files could then be accessible to client-side apps as well as the web. That's reason for the restrictions in the "uniformity of interface" section--if you're going to expose the true local filesystem, you run into different restrictions on names and paths on each platform, and we want code that uses this API to run everywhere. However, we've been running into some issues in this area with our implementation--more on that below. > They're not particularly easy to use, compared to the IndexedDB data store, I find files to be easier to use than databases, but I'm clearly biased ;'>. However, that's not really the point. Files and databases serve different needs, and various use cases are better served by each than the other. If you want transactions or indexing, you want IDB. If you want fast, mutable binary blobs with persistent URLs, you want FileSystem. > but if they are OS level commands, > then they do help with usability of a web app with the rest of the OS: with > managing files directly from the OS file manager. > > Is the FileSystem API intended to expose a folder on the host operating > system, or is it just an abstraction > which can be bolted onto any data system (such as, using SQLite as a > backend, as appCache and IndexedDB do) ? While the current API could in theory be implemented either way, there have been many requests for expansions to the API that would allow for access to directories outside the sandbox, e.g. giving Flickr access to "My Photos". While that's not yet been specced, that would clearly require real pass-through access and real file names. The rest of the API could of course be identical, and I hope that eventually it will serve both use cases. > Are there any plans of reviewing/visiting efficient File/Blob support in > indexeddb? I can't speak for the indexedDB developers, but the last I heard on-list, they were at least hoping to support immutable Blobs, but not soon. More on those portability issues: We've been implementing the current FileSystem API spec in Chrome, and had planned that our implementation of the sandbox would be just a passthrough to a directory under the user's profile. We've been testing that out, currently only allowing access to extensions and apps, but we've gotten feedback that long profile paths are causing a problem on Windows. Our current implementation on Windows uses the standard API calls that limit paths to 256 characters long. If your profile directory is deeply nested [e.g. because you have a really long username], code that works for your friend might not work for you. We thought we'd fix that by using the long-path APIs that allow creation of paths up to ~32k chars long. However, it seems that, even though Windows has these APIs, most programs don't use them. In particular, Windows Explorer doesn't, so it chokes on them and can't delete files in directories with long names. We think it would be really awkward if Chrome were creating directories under its profile directory that couldn't easily be deleted, so we're going to start virtualizing our filesystem implementation. We'll still have real native files for speed of access and ease of modification, but we'll be storing the paths in an internal database. This then brings up the question of whether one can specify a uniform, useful interface for the API that *doesn't* require virtualization of the filesystem, but I'll be bringing that up in another thread. Eric
Re: [whatwg] Inline Web Worker
How about using a Blob URL? See the discussion here: https://groups.google.com/a/chromium.org/group/chromium-html5/tree/browse_frm/thread/4288931009182422/12703ab802469702. On Fri, Oct 15, 2010 at 3:17 PM, Samuel Ytterbrink wrote: > > Hi I have found something really frustrating with the specs. to show that I > at least read the blog about proposing features here is the questions and > answers: > > What is the problem you are trying to solve? > To create sophisticated single file webpages. > What is the feature you are suggesting to help solve it? > Some sort of inline Web Worker. Using Data URL is what i have in mind or by > creating a class. > What is the processing model for that feature, including error handling? > This should be very clear, including things such as event timing if the > feature involves events, how to create graphs representing the data in the > case of semantic proposals, etc. > Well the same as for other URLs, except that it inherit its location > information from its creator. > Why do you think browsers would implement this feature? > To make standalone local webpages easier to be used by users. And in some > cases faster dl of large pages. > Why do you think authors would use this feature? > Webpages are more then just information, its programs. Programs in one file > is easier to have. And also for testing quick things, inline is a Bliss. > What evidence is there that this feature is desparately needed? > I only have my own, trying to build a more optimal standalone DAISY player > (would be nice if i could rewrite it with web workers). And that google > gears seems to support it. > > So is this a totally bad idea? > //Samuel Ytterbrink > p.s. hope i posted it in the correct Mailing list. and that my spelling > isn't that bad. >
Re: [whatwg] Web Storage, Editor's Draft 20 August 2010 - Request for enhancement
On Tue, Sep 14, 2010 at 4:30 PM, Jim Williams wrote: > I see localStorage and sessionStorage as a chance to fix things that weren't > so good with cookies. So I'd be interested to know what factors actively > promote the failure to come up with a common browser-independent interface > for localStorage. Do browser builders actually have something to gain by > resisting interoperability here? I think you're coming at it from a quite different point of view than browser builders usually have. When we implement e.g. our localStorage database, having it use the same file format as Opera is the furthest thing from our mind. Even if we wanted to share data with them, how would we make sure that we didn't both write the file at the same time? How would we know when to update our in-memory state from disk? What if you had multiple Firefox profiles that each used a different set of cookies--which profile should sync with Opera? These are huge problems and lots of work, and for very little payoff. > I'd also be interested to see some actual data on how often people switch > browsers. Much of my own browser-switching experiences have to do, not with > web development, but with online courseware that was designed to run on a > particular browser - and then I follow links on whatever browser I'm on at > the moment, so that the same sites often turn up on both browsers. I also > know nontechnical people who just like downloading and playing with stuff, > including browsers. > > Also, yes, one could use the file system API in place of cookies or other > local storage, but that tends to interrupt the user's flow of thought, so > I'd prefer to avoid such heavy-handedness without having a good reason. > > Tab Atkins Jr. wrote: > > On Tue, Sep 14, 2010 at 4:52 AM, Jim Williams > wrote: > > > I tried out local storage, used it to save the contents of a > content-editable passage. It worked great in Firefox, Chrome, Safari, and > MSIE. Only one problem: Every time I switched browsers, I had to start > over with the original unedited passage. So I have two requests. > > 1. I would like the browser vendors to all use the same implementation of > localStorage, as this will greatly facilitate browser-independent viewing > experiences. As it stands, I have no idea how to maintain continuity if a > user viewing my page in one browser switches to another browser. None. > > > Like cookies, all browser data will be dependent on the browser. > There's very little chance of this ever changing. > > Users rarely switch browsers, in any case. We web developers are a > rare exception. > > > > 2. Kindly extend the specification so that other applications can make > constructive use of localStorage. Specifically, (a) establish a convention > for associating keys with particular files (e.g., by prepending the file's > path name to the key), and (b) allowing other applications to treat the file > and its associated local storage as a single entity. Doing this would allow > a user to e-mail the current state of a file to a friend, so that both will > have the same view of the file. This ability to share "current" views of a > file is useful for maintaining HTML's role as a communications vehicle. > > > The FileSystem API is designed for this use-case, so you can build a > file in javascript and ask the user to save it to their harddrive. > > ~TJ > > >
Re: [whatwg] Web Storage, Editor's Draft 20 August 2010 - Request for enhancement
On Tue, Sep 14, 2010 at 4:52 AM, Jim Williams wrote: > I tried out local storage, used it to save the contents of a > content-editable passage. It worked great in Firefox, Chrome, Safari, and > MSIE. Only one problem: Every time I switched browsers, I had to start > over with the original unedited passage. So I have two requests. > > 1. I would like the browser vendors to all use the same implementation of > localStorage, as this will greatly facilitate browser-independent viewing > experiences. As it stands, I have no idea how to maintain continuity if a > user viewing my page in one browser switches to another browser. None. If you need persistent cross-browser state, on a page that you control, why not just store it server-side? Then it also works from multiple computers, which even your proposed modifications to localStorage won't get you. > 2. Kindly extend the specification so that other applications can make > constructive use of localStorage. Specifically, (a) establish a convention > for associating keys with particular files (e.g., by prepending the file's > path name to the key), and (b) allowing other applications to treat the file > and its associated local storage as a single entity. Doing this would allow > a user to e-mail the current state of a file to a friend, so that both will > have the same view of the file. This ability to share "current" views of a > file is useful for maintaining HTML's role as a communications vehicle. > > Jim Williams
Re: [whatwg] ArrayBuffer and ByteArray questions
On Tue, Sep 7, 2010 at 4:09 PM, Jian Li wrote: > Hi, > Several specs, like File API and WebGL, use ArrayBuffer, while other spec, > like XMLHttpRequest Level 2, use ByteArray. Should we change to use the same > name all across our specs? Since we define ArrayBuffer in the Typed Arrays > spec > (https://cvs.khronos.org/svn/repos/registry/trunk/public/webgl/doc/spec/TypedArray-spec.html), > should we favor ArrayBuffer? > In addition, can we consider adding ArrayBuffer support to BlobBuilder, > FormData, and XMLHttpRequest.send()? It seems like an obvious addition for BlobBuilder or XHR.send, but do we need it in both, or is one sufficient? > Thanks, > Jian >
Re: [whatwg] Canvas API: What should happen if non-finite floats are used
On Wed, Sep 8, 2010 at 9:45 AM, Oliver Hunt wrote:
> The problem with throwing an exception is that it's fairly common for code to
> end up accidentally producing a NaN or Infinite value, and throwing an
> exception would prevent all subsequent drawing from occurring.
I believe that was the point: you throw an exception, the bug becomes
obvious, and you fix it. Without the exception, you draw the wrong
thing, and it's much harder to find the problem.
> I suggested this behaviour a long time ago after running into yet another
> piece of code that hit this case in webkit (back when the spec said to throw
> an exception) yet firefox and opera did not throw. In some cases firefox
> does throw, and in others it doesn't (or maybe didn't? has ffx behaviour
> changed?) and we came to the conclusion that as much as possible the canvas
> should silently ignore NaN/Infinite values.
>
> --Oliver
>
> On Sep 7, 2010, at 10:36 PM, Jonas Sicking wrote:
>
>> This seems like a strange choice of behavior. Given that this is very
>> likely a bug in the program, wouldn't it make more sense to throw an
>> exception as to make it easier to debug? Similar to for example
>> Node.appendChild when called with a null argument.
>>
>> / Jonas
>>
>> On Tue, Sep 7, 2010 at 10:32 PM, Sam Weinig wrote:
>>> In 4.8.11.1 the spec does state:
>>>
>>> "Except where otherwise specified, for the 2D context interface, any method
>>> call with a numeric argument whose value is infinite or a NaN value must be
>>> ignored."
>>>
>>> -Sam
>>>
>>> On Sep 7, 2010, at 9:41 PM, Boris Zbarsky wrote:
>>>
Consider this testcase:
try {
var c = document.getElementById("c"),
t = c.getContext("2d");
t.moveTo(100, 100);
t.lineTo(NaN, NaN);
t.lineTo(50, 25);
t.stroke();
} catch (e) {alert(e); }
Behavior in the spec seems to be undefined (in particular, no mention is
made as to what the canvas API functions are supposed to do if non-finite
values are passed in). Behavior in browsers is:
Presto: Throws NOT_SUPPORTED_ERR on that lineTo(NaN, NaN) call.
Gecko: Throws DOM_SYNTAX_ERR on that lineTo(NaN, NaN) call.
Webkit: Silently ignores the lineTo(NaN, NaN) call, and then
draws a line from (100,100) to (50, 25).
Seems like the spec needs to define this.
-Boris
P.S. This isn't a hypothetical issue; this came up in a page that was
trying to graph things using canvas and ending up with divide-by-0 all
over the place. It "worked" in webkit (though not drawing the right
thing, so much). It failed to draw anything in Presto or Gecko.
>>>
>>>
>
>
Re: [whatwg] New File attributes creationDate, modificationDate and size
On Fri, May 14, 2010 at 5:05 PM, Arun Ranganathan wrote: > On 5/12/10 4:25 AM, Ashley Sheridan wrote: >> >> On Wed, 2010-05-12 at 00:05 -0400, Biju wrote: >> >> >>> >>> It would be good if we can also get the same at server side when user >>> upload a file using form with file controls >>> ie, like the suggestion at >>> https://bugzilla.mozilla.org/show_bug.cgi?id=549253 >>> (it works even with javascript disabled) >>> >>> Also remember modificationDate can be a time before creationDate on >>> windows. >>> This is because modificationDate get copied when you copy a file, >>> hence it almost shows modificationDate of the actual content. >>> >>> creationDate on other hand is file creation time on the >>> folder/directory and when you copy a file to a new directory, it will >>> be showing the coping time. >>> >>> PS, for JS option there is mozilla bug 390776 >>> >> >> > > I intend to update the File API so that the File object exposes creationDate > and modificationDate. You might want to consider making an async getMetadata function; see discussion ending at [1]. Async because the modification time can change often, and as a generic all-metadata function because it's easy to expand and experiment with. And if you put that right in the File API, then I can inherit it from the FileSystem API instead of having to spec it myself ;'>. Eric [1] http://lists.w3.org/Archives/Public/public-device-apis/2010Apr/0054.html
Re: [whatwg] Multiple file download
On Wed, Mar 10, 2010 at 12:28 AM, timeless wrote: > On Fri, Feb 26, 2010 at 3:31 AM, Jose Fandos wrote: >> Er... sure. It is not as convenient for certain web apps when compared to >> desktop apps. With this supported, the gap get's reduced. > > Adding support for tar (and all of its variations) involves adding > extra code, testing, etc. to browsers. This is sometimes called bloat, > and can be painful for browsers that work on mobile devices. Things > aren't "free", especially not duplicative features. > > I'm quite happy to demand that web sites include code for generating Zip > files. > > http://www.pkware.com/documents/casestudies/APPNOTE.TXT V. General > Format of a .ZIP file > > the zip format is fairly streaming friendly, the directory is at the > end of the file. And if you're actually generating a file which has so > many records that you can't remember all of them, you're probably > trying to attack my user agent, so I'm quite happy that you'd fail. Isn't a format that has its directory at the end about as streaming-UNfriendly as you can get? You need to pull the whole thing down before you can take it apart. With a .tar.gz, you can unpack files as they arrive. Eric
Re: [whatwg] api for fullscreen()
2009/12/16 Jonas Sicking : > 2009/12/16 Ian Fette (イアンフェッティ) : >> I think what I've heard from application developers over and over again is >> that, while the UA may provide some way to go into full screen from in the >> browser chrome, it is much more discoverable when that capability exists >> from within the content area (e.g. people are used to clicking on the full >> screen button in YouTube, and when you take that away users can no longer >> figure out how to go full screen). >> Obviously there are security considerations re: UI spoofing, but I'm >> beginning to wonder how much we should beat ourselves over this. If there >> are simple things that we can do to improve upon the model Flash uses (e.g. >> don't have a translucent overlay but instead use an opaque overlay, or use >> an overlay that doesn't go away until the user dismisses it, etc) without >> totally killing current use cases and discoverability, then let's consider >> that. Overall though, it feels like we are burying our head in the sand a >> bit by saying "Well, as long as HTML doesn't provide a way to go full >> screen, the users are safe and it's not *our* fault if anything bad >> happens," when the reality is that Flash is installed on 98-99% of all >> machines out there and anyone who is really trying to phish people using >> this method could easily use flash instead of whatever we provide. (And yes >> I'm aware people can turn off flash, but those users sophisticated enough to >> use noflash can probably figure out if they are in full-screen mode or not.) >> -Ian > > In addition to UI spoofing there is also the "annoying websites" > factor. There is today API for pages to resize the browser window, > which I know that some pages abuse to resize the browser window to be > as big as possible. This API is one of very few that Firefox has > specific API to turn off, because its one of the APIs that annoy users > the most. > > As for flash going full screen. I heard something regarding that while > in full screen mode flash disables certain capabilities, in order to > reduce the risk of spoofing. Such as the ability to receive keyboard > events. Haven't investigated this at all though. I looked into this when implementing fullscreen for O3D. Yes, they disable keyboard input entirely. That's acceptable for some applications, but quite limited for games, accessibility, etc. What we ended up doing was allowing the developer to designate a rectangular region of the window to be a clickable region that would trigger the fullscreen transition. When the user clicked it, we'd go fullscreen, then put up a banner for a few seconds that told them how to get out of it [hit Esc]. The Esc key was always the way out, intentionally matching Flash. The app developer was responsible for informing the user where to click, so that we didn't force a UI on them. Eric
