Re: [IDB] Lifetime of IDB objects
On Sun, Oct 21, 2012 at 5:01 PM, João Eiras jo...@opera.com wrote: Hi ! The specification does not specify in detail what happens to several of the object types once they have reached their purpose. For instance, IDBTransaction's abort and objectStore methods dispatch InvalidStateError. However, IDBRequest and IDBCursor have properties which return other objects like IDBRequest.source, IDBRequest.result, IDBRequest.transaction, IDBCursor.source, The intent was for these properties to return the same value as they always did. Suggestions for how to make this more clear would be welcome. IDBCursor.key, IDBCursor.primaryKey which behavior, after the request has completed, is undefined or defined as returning the same value (for source only it seems). These too don't change their value when a transaction is committed. The spec is hopefully pretty clear that these values are set to 'undefined' once the cursor has been iterated to the end though? Having these objects keeping references to other objects after they have completed, can represent extra memory overhead, while not very useful, specially if the application is data heavy, like an offline main client with lots of requests, or long blobs are used, and it prevents the garbage collector from cleaning up more than it could, specially while a transaction is active. I suggest that after an IDBRequest, IDBTransaction or IDBCursor complete, all their properties are cleared (at least the non-trivial ones) so the garbage collector can do it work. However, since that would cause the properties to return later undefined/null, it is better if they just all throw InvalidStateError when accessed after the object has reached it's purpose. I definitely don't think we should be throwing more exceptions here. I don't see that someone is doing something inherently wrong when trying to access these properties after a transaction has been committed or aborted, so throwing an exception seems like it can just introduce breakage for authors. Likewise, returning null/undefined for these objects can cause code like myrequest.source.name to throw if accessed too late. I don't think that the retaining memory problem is a particularly big one. Note that we'd only be retaining a small number of extra objects at the most. Only if a page holds on to a request do we end up keeping the store and transaction objects alive. Holding a transaction alive never ends up holding all the requests alive. Btw, an error in http://www.w3.org/TR/IndexedDB/#widl-IDBCursor-source This function never returns null or throws an exception. Should be This property. Would be great if you could file a bug on this since I'm likely to forget otherwise. / Jonas
[selectors-api] Updated Testsuite
Hi, I worked on redesigning the testsuite to resolve a number of issues with the design of the old tests, including removing significant amount of redundancy and fixing broken tests. In the process, I have discovered a number of new bugs in various browsers that need to be addressed. *Summary of Changes* 1. The Level 1 baseline tests are no longer a subset of the additional tests. The baseline and additional test files now test a completely separate set of tests. 2. The :target tests were moved from baseline to additional because :target was added in Selectors 3. 3. All selectors from CSS 1, 2 and Selectors 3 are being tested. 4. level1-lib.js now contains the common functions shared among the 3 testsuites: baseline, additional and xhtml. 5. The files level1-content.html and level1-content.xht contain the all of the (X)HTML that is queried by the API, included within the iframe of each testsuite. Every element in the file is assigned an ID that is used for verification. 6. selectors.js contains all selectors for both valid and invalid selector tests. This includes annotations about the expected result from each selector, with a list of expected element IDs. These IDs are compared with the results from the queries. This change in architecture resolves some major issues with the old testsuite, which had previously resolved in false positives being reported. Notably, the namespace tests. See below. Some additional tests were added for :link and :visited, which now reveal failures in both Gecko and WebKit. Notes: * The Selectors API Level 2 tests have not yet been updated. * Some tests are still needed for :not() and ~ sibling combinator. * Some test descriptions have not been finished in selectors.js. *Failures* Opera: Baseline: 1157 PASS, 10 FAIL * (no parameter) tests (throwing WRONG_ARGUMENTS_ERR instead of TypeError) * #head :link, #head :visited (new bug in 12.10 beta, passes in 12.02) Additional: 512 PASS, 0 FAIL Chrome/Safari: Baseline: 1140 PASS, 27 FAIL * hasFeature() returns false * namespace tests Additional: 508 PASS, 4 FAIL * :target tests Mozilla Gecko: Baseline: 1154 PASS, 13 FAIL * hasFeature() returns false * (no parameter) tests (throwing NS_ERROR_XPC_NOT_ENOUGH_ARGS instead of TypeError) * :link and :visited for fragment and detached element tests failing to match A and AREA elements. Additional: 512 PASS, 0 FAIL * No failures (I haven't got access to IE at this time, so I have not tested it.) The testsuite can be found here. http://dev.w3.org/2006/webapi/selectors-api-testsuite/ All files for these tests are located in the hg repo. http://w3c-test.org/webapps/SelectorsAPI/tests/submissions/Opera/ -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [widgets] Does anyone still care about Widget Updates?
On 20 Oct 2012, at 13:12, Arthur Barstow wrote: For various reasons, a Candidate Recommendation of Widget Updates was never published, although the CfC to do so passed and the ED is prepared as such [widget-updates]. Since no one has raised this as an issue, I would like feedback on what we should do with this spec. The main options are: 1) to stop work (and publish a WG Note); 2) to move forward with the CR. I don'tthink it makes much sense to move the spec to CR if we do not have commitments for at least two independent implementations of the CR. Therefore, Implementors should please speak up if they willcommit to implementing this CR. Its implemented in Apache Wookie from version 0.13. -Thanks, AB [widget-updates] http://dev.w3.org/2006/waf/widgets-updates/ Original Message Subject: CfC: publish Candidate Recommendation of Widget Updates; deadline May 2 Resent-Date: Thu, 26 Apr 2012 16:42:00 + Resent-From: public-native-web-a...@w3.org Date: Thu, 26 Apr 2012 12:41:34 -0400 From: ext Arthur Barstow art.bars...@nokia.com To: public-webapps public-webapps@w3.org CC: public-native-web-a...@w3.org The comment deadline for the Widget Updates LCWD ended April 19. No comments were submitted for that document so this is a Call for Consensus to publish a Candidate Recommendation of the spec using the LC as the basis http://www.w3.org/TR/2012/WD-widgets-updates-20120322/. The Exit Criteria for the CR will be the same as that used for the other widget specs, namely that two or more implementations must pass each test case. This CfC satisfies: a) the group's requirement to record the group's decision to request advancement to CR; and b) General Requirements for Advancement on the Recommendation Track as defined in the Process Document: http://www.w3.org/2005/10/Process-20051014/tr.html#transition-reqs Positive response is preferred and encouraged and silence will be considered as agreeing with the proposal. The deadline for comments is May 2 and all comments should be sent to public-webapps at w3.org. -Thanks, AB
Re: [selectors-api] Updated Testsuite
On 10/22/12 6:10 AM, Lachlan Hunt wrote: * hasFeature() returns false Just as a note, this is a pretty pointless test, and the language about it should be removed from this spec, assuming http://dom.spec.whatwg.org/#dom-domimplementation-hasfeature stays the way it is. * :link and :visited for fragment and detached element tests failing to match A and AREA elements. Presumably https://bugzilla.mozilla.org/show_bug.cgi?id=787134 -Boris
Re: [selectors-api] Updated Testsuite
On Mon, Oct 22, 2012 at 4:29 PM, Boris Zbarsky bzbar...@mit.edu wrote: On 10/22/12 6:10 AM, Lachlan Hunt wrote: * hasFeature() returns false Just as a note, this is a pretty pointless test, and the language about it should be removed from this spec, assuming http://dom.spec.whatwg.org/#dom-domimplementation-hasfeature stays the way it is. Indeed, please remove http://www.w3.org/TR/selectors-api/#dom-feature-string -- http://annevankesteren.nl/
Re: [selectors-api] Updated Testsuite
On 2012-10-22 16:29, Boris Zbarsky wrote: On 10/22/12 6:10 AM, Lachlan Hunt wrote: * hasFeature() returns false Just as a note, this is a pretty pointless test, and the language about it should be removed from this spec, assuming http://dom.spec.whatwg.org/#dom-domimplementation-hasfeature stays the way it is. I dropped the feature string from both selectors api specs. I'll update the tests shortly. -- Lachlan Hunt - Opera Software http://lachy.id.au/ http://www.opera.com/
Re: [IDB] Lifetime of IDB objects
On Mon, Oct 22, 2012 at 2:00 AM, Jonas Sicking jo...@sicking.cc wrote: On Sun, Oct 21, 2012 at 5:01 PM, João Eiras jo...@opera.com wrote: Hi ! The specification does not specify in detail what happens to several of the object types once they have reached their purpose. For instance, IDBTransaction's abort and objectStore methods dispatch InvalidStateError. However, IDBRequest and IDBCursor have properties which return other objects like IDBRequest.source, IDBRequest.result, IDBRequest.transaction, IDBCursor.source, The intent was for these properties to return the same value as they always did. Suggestions for how to make this more clear would be welcome. IDBCursor.key, IDBCursor.primaryKey which behavior, after the request has completed, is undefined or defined as returning the same value (for source only it seems). These too don't change their value when a transaction is committed. The spec is hopefully pretty clear that these values are set to 'undefined' once the cursor has been iterated to the end though? Having these objects keeping references to other objects after they have completed, can represent extra memory overhead, while not very useful, specially if the application is data heavy, like an offline main client with lots of requests, or long blobs are used, and it prevents the garbage collector from cleaning up more than it could, specially while a transaction is active. I suggest that after an IDBRequest, IDBTransaction or IDBCursor complete, all their properties are cleared (at least the non-trivial ones) so the garbage collector can do it work. However, since that would cause the properties to return later undefined/null, it is better if they just all throw InvalidStateError when accessed after the object has reached it's purpose. I definitely don't think we should be throwing more exceptions here. I don't see that someone is doing something inherently wrong when trying to access these properties after a transaction has been committed or aborted, so throwing an exception seems like it can just introduce breakage for authors. Likewise, returning null/undefined for these objects can cause code like myrequest.source.name to throw if accessed too late. I don't think that the retaining memory problem is a particularly big one. Note that we'd only be retaining a small number of extra objects at the most. Only if a page holds on to a request do we end up keeping the store and transaction objects alive. Holding a transaction alive never ends up holding all the requests alive. Agreed. If I'm recalling correctly, at this point the spec implicitly requires that upward references are retained (e.g. request-transaction, index-store, request-index/store, etc). Downward references are only retained temporarily: transaction-request for unfinished requests, and transaction-store / store-index for unfinished transactions, etc. As long as script is not holding on to the leaf objects like requests/cursors the memory usage as required by the spec shouldn't be large. If you can find a spec counter-example to this assertion, we should address it in the spec - IIRC we added behavior to IDBTransaction.objectStore() and IDBObjectStore.index() to throw after the transaction was finished for this reason. Btw, an error in http://www.w3.org/TR/IndexedDB/#widl-IDBCursor-sourceThis function never returns null or throws an exception. Should be This property. Would be great if you could file a bug on this since I'm likely to forget otherwise. / Jonas
Re: [widgets] Does anyone still care about Widget Updates?
On Mon, 22 Oct 2012 15:37:51 +0200, Scott Wilson scott.bradley.wil...@gmail.com wrote: On 20 Oct 2012, at 13:12, Arthur Barstow wrote: For various reasons, a Candidate Recommendation of Widget Updates was never published, although the CfC to do so passed and the ED is prepared as such [widget-updates]. Since no one has raised this as an issue, I would like feedback on what we should do with this spec. The main options are: 1) to stop work (and publish a WG Note); 2) to move forward with the CR. I don'tthink it makes much sense to move the spec to CR if we do not have commitments for at least two independent implementations of the CR. Therefore, Implementors should please speak up if they willcommit to implementing this CR. Its implemented in Apache Wookie from version 0.13. It's implemented in Opera extensions, and in their extension server set up, although I don't have a lot more details to hand. I'll ask Opera if they can provide more info. cheers Chaals -- Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex cha...@yandex-team.ru Find more at http://yandex.com
Re: CfC: publish WD - NOT LCWD of File API; deadline October 22
All - today, Arun reported hewould like to do make some additional changes to the File API spec before it is ready for a LC to be published. I understand reflecting https://www.w3.org/Bugs/Public/show_bug.cgi?id=19554 is one issue, and Arun may expand on this or other issues. Anyhow, please consider this CfC as hereby amended to publish a new WD - and NOT a LCWD. -Thanks, AB On 10/16/12 9:29 PM, ext Arthur Barstow wrote: All - this is a Call for Consensus to publish a Last Call Working Draft of the File API spec http://dev.w3.org/2006/webapi/FileAPI/. Note bug 17125 ([1] below) is open and Arun proposes it be postponed for v.next. Additionally, Arun notes below bug 19554 ([2] below) is a related feature request for HTML and he proposes the LC comment period be used to gather input on that bug. This CfC satisfies the group's requirement to record the group's decision to request advancement for this LCWD. Note the Process Document states the following regarding the significance/meaning of a LCWD: [[ http://www.w3.org/2005/10/Process-20051014/tr.html#last-call Purpose: A Working Group's Last Call announcement is a signal that: * the Working Group believes that it has satisfied its relevant technical requirements (e.g., of the charter or requirements document) in the Working Draft; * the Working Group believes that it has satisfied significant dependencies with other groups; * other groups SHOULD review the document to confirm that these dependencies have been satisfied. In general, a Last Call announcement is also a signal that the Working Group is planning to advance the technical report to later maturity levels. ]] The proposed LC review period is 4 weeks. If you have any comments or concerns about this CfC, please send them to public-webapps@w3.org by October 22 at the latest. Positive response is preferred and encouraged and silence will be considered as agreement with the proposal. -Thanks, AB Original Message Subject: Re: [admin] Publishing specs before TPAC: CfC start deadline is Oct 15 Date: Tue, 16 Oct 2012 17:29:17 -0700 From: ext Arun Ranganathan aranganat...@mozilla.com To: Arthur Barstow art.bars...@nokia.com CC: public-weba...@w3c.org - Original Message - On 10/9/12 4:13 PM, ext Arun Ranganathan wrote: On Sep 26, 2012, at 10:27 AM, Arthur Barstow wrote: * File API - Arun can you get this spec ready for LC by October 15? Yes. ATM, File API has 8 open bugs [1]. I've rationalized these down to 2 bugs. 1. Bug 17125[1] is a feature that we should mark v.next; it calls for the ability to retroactively unselect an erroneous selection that is present in FileList. I don't think this is a pressing feature. 2. Bug 19554[2] is a spec. request feature in WHATWG/HTML5, especially useful for autoRevoke semantics for Blob URLs. I'm not sure whether autoRevoke is at risk because of this bug, since implementations have shown that stable state (what the spec. uses now) is problematic for autoRevoke. But I'll let this be discussed in LC commentary or in upcoming TPAC discussions. P.S. Dom's WebIDL checker reports a bug in the Blob constructor Thanks for catching that :) I think that particular bug is fixed. And I'm sorry this is a day late (e.g. not ready by Oct. 15). I've gotten it PubReady, using a push out date of Oct. 18. Hope that works: http://dev.w3.org/2006/webapi/FileAPI/ -- A* [1] https://www.w3.org/Bugs/Public/show_bug.cgi?id=17125 [2] https://www.w3.org/Bugs/Public/show_bug.cgi?id=19554
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
On 16/10/12 18:48, Maciej Stachowiak wrote:
Many games could work with only non-alphanumeric keys or in some cases
only the mouse. As could slideshows. You only need space/enter/arrows
for a full screen slide presentation.
FWIW I agree. Pretty much the only uses cases that I can envisage that
would really need alpha-numeric keyboard access are games, or 3D
modellers, like CAD software.
On 19/10/12 14:31, Feross Aboukhadijeh wrote:
I wrote the attack demo that prompted this discussion. Here are my
thoughts on how to improve the spec and/or the implementations in
browsers:
requestFullscreen() should trigger fullscreen mode with limited
keyboard input allowed (only space, arrow keys, and perhaps some
modifier keys like CTRL, ALT, etc.). The browser should display a
notification that the user is in fullscreen mode, although it can fade
away after some time since the risk of phishing is significantly
reduced when keyboard input is limited (note that Safari currently
sees fit to show NO notification at all about fullscreen mode because
keyboard is limited).
This level of functionality will support 90% of current fullscreen use
cases like video players, slideshow viewers, and games with simple
input requirements.
However, the spec should also support an optional ALLOW_KEYBOARD_INPUT
parameter to requestFullscreen() which, when passed, triggers
fullscreen mode with full keyboard support (except for ESC to exit
fullscreen). When this parameter is passed, the browser should show a
prominent modal dialog on top of the page content, requesting
permission to use fullscreen mode. No keyboard or mouse input should
be allowed until the user clicks Allow.
This looks remarkably like Mozilla's original proposal:
https://wiki.mozilla.org/Gecko:FullScreenAPI
We chose not to implement this as it offers little protection against
phishing or spoofing attacks that don't rely on keyboard access. In
those cases making the user aware that they've entered fullscreen is
pretty much the best defence the user has. Other than not having a
fullscreen API at all.
Our fullscreen approval UI in Firefox is based around the assumption
that for most users the set of sites that use the fullscreen API that
the user encounters on a daily basis is small, and users would tend to
opt to remember the fullscreen approval for those domains. I'd imagine
the set would be YouTube, Facebook, and possibly ${FavouriteGame}.com
for most users. Thus users would see a notification and not an approval
prompt /most of the time/ when they entered fullscreen. But when some
other site goes fullscreen they do get a prompt, which is out of the
ordinary and more likely to be read.
Chris Pearce
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
FYI Flickr slideshows and Google street view are now fullscreen users.
On Tue, Oct 23, 2012 at 12:04 AM, Chris Pearce cpea...@mozilla.com wrote:
On 16/10/12 18:48, Maciej Stachowiak wrote:
Many games could work with only non-alphanumeric keys or in some cases
only the mouse. As could slideshows. You only need space/enter/arrows for a
full screen slide presentation.
FWIW I agree. Pretty much the only uses cases that I can envisage that
would really need alpha-numeric keyboard access are games, or 3D modellers,
like CAD software.
On 19/10/12 14:31, Feross Aboukhadijeh wrote:
I wrote the attack demo that prompted this discussion. Here are my
thoughts on how to improve the spec and/or the implementations in browsers:
requestFullscreen() should trigger fullscreen mode with limited keyboard
input allowed (only space, arrow keys, and perhaps some modifier keys like
CTRL, ALT, etc.). The browser should display a notification that the user
is in fullscreen mode, although it can fade away after some time since the
risk of phishing is significantly reduced when keyboard input is limited
(note that Safari currently sees fit to show NO notification at all about
fullscreen mode because keyboard is limited).
This level of functionality will support 90% of current fullscreen use
cases like video players, slideshow viewers, and games with simple input
requirements.
However, the spec should also support an optional ALLOW_KEYBOARD_INPUT
parameter to requestFullscreen() which, when passed, triggers fullscreen
mode with full keyboard support (except for ESC to exit fullscreen). When
this parameter is passed, the browser should show a prominent modal dialog
on top of the page content, requesting permission to use fullscreen mode.
No keyboard or mouse input should be allowed until the user clicks Allow.
This looks remarkably like Mozilla's original proposal:
https://wiki.mozilla.org/Gecko:FullScreenAPI
We chose not to implement this as it offers little protection against
phishing or spoofing attacks that don't rely on keyboard access. In those
cases making the user aware that they've entered fullscreen is pretty much
the best defence the user has. Other than not having a fullscreen API at
all.
Our fullscreen approval UI in Firefox is based around the assumption that
for most users the set of sites that use the fullscreen API that the user
encounters on a daily basis is small, and users would tend to opt to
remember the fullscreen approval for those domains. I'd imagine the set
would be YouTube, Facebook, and possibly ${FavouriteGame}.com for most
users. Thus users would see a notification and not an approval prompt *most
of the time* when they entered fullscreen. But when some other site goes
fullscreen they do get a prompt, which is out of the ordinary and more
likely to be read.
Chris Pearce
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
On Oct 22, 2012, at 3:04 PM, Chris Pearce cpea...@mozilla.com wrote:
This looks remarkably like Mozilla's original proposal:
https://wiki.mozilla.org/Gecko:FullScreenAPI
We chose not to implement this as it offers little protection against
phishing or spoofing attacks that don't rely on keyboard access. In those
cases making the user aware that they've entered fullscreen is pretty much
the best defence the user has. Other than not having a fullscreen API at all.
There may be phishing scenarios that work without keyboard access, but I expect
they are *far* less common and harder to pull off. To argue from anecdote, I
visit many sites where I identify myself with a typed password, and none where
I exclusively have a mouse-based credential that does not involve typing
(though I've seen sites that use it as an additional factor). I think it's not
justified to conclude that the phishing risk with and without alphanumeric
keyboard access is identical. They are not.
Our fullscreen approval UI in Firefox is based around the assumption that for
most users the set of sites that use the fullscreen API that the user
encounters on a daily basis is small, and users would tend to opt to
remember the fullscreen approval for those domains. I'd imagine the set
would be YouTube, Facebook, and possibly ${FavouriteGame}.com for most users.
Thus users would see a notification and not an approval prompt most of the
time when they entered fullscreen. But when some other site goes fullscreen
they do get a prompt, which is out of the ordinary and more likely to be read.
I think the chance of the user paying attention to a prompt that, every time
they have seen it before, has been completely harmless, is pretty low. The odds
of the user making an informed security decision based on what the prompt says
is even lower.
Based on all this, I continue to think that requesting keyboard access should
involve separate API, so that it can be feature-detected and given different
security treatment by vendors as desired. This is what Flash does, and they
have the most experience dealing with the security implications of fullscreen
on the Web.
Regards,
Maciej
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
On Tue, Oct 23, 2012 at 12:50 AM, Maciej Stachowiak m...@apple.com wrote: Based on all this, I continue to think that requesting keyboard access should involve separate API, so that it can be feature-detected and given different security treatment by vendors as desired. This is what Flash does, and they have the most experience dealing with the security implications of fullscreen on the Web. I support the notion that if not all vendors can agree on the exact behavior/restrictions that an API is required to make this transparent to the application developer both before attempting to request fullscreen (capability discovery) and as a parameter to request fullscreen (which will only succeed if that capability is offered).
Re: Defenses against phishing via the fullscreen api (was Re: full screen api)
On Monday, October 22, 2012 at 6:04 PM, Chris Pearce wrote:
On 16/10/12 18:48, Maciej Stachowiak wrote:
Many games could work with only non-alphanumeric keys or in some cases only
the mouse. As could slideshows. You only need space/enter/arrows for a full
screen slide presentation.
FWIW I agree. Pretty much the only uses cases that I can envisage that would
really need alpha-numeric keyboard access are games, or 3D modellers, like
CAD software.
What if applications, such as iA Writer wanted to offer a web version? Too bad,
no keyboard for distraction-free mode?
(http://www.iawriter.com/)
Rick
On 19/10/12 14:31, Feross Aboukhadijeh wrote:
I wrote the attack demo that prompted this discussion. Here are my thoughts
on how to improve the spec and/or the implementations in browsers:
requestFullscreen() should trigger fullscreen mode with limited keyboard
input allowed (only space, arrow keys, and perhaps some modifier keys like
CTRL, ALT, etc.). The browser should display a notification that the user
is in fullscreen mode, although it can fade away after some time since the
risk of phishing is significantly reduced when keyboard input is limited
(note that Safari currently sees fit to show NO notification at all about
fullscreen mode because keyboard is limited).
This level of functionality will support 90% of current fullscreen use
cases like video players, slideshow viewers, and games with simple input
requirements.
However, the spec should also support an optional ALLOW_KEYBOARD_INPUT
parameter to requestFullscreen() which, when passed, triggers fullscreen
mode with full keyboard support (except for ESC to exit fullscreen). When
this parameter is passed, the browser should show a prominent modal dialog
on top of the page content, requesting permission to use fullscreen mode.
No keyboard or mouse input should be allowed until the user clicks Allow.
This looks remarkably like Mozilla's original proposal:
https://wiki.mozilla.org/Gecko:FullScreenAPI
We chose not to implement this as it offers little protection against
phishing or spoofing attacks that don't rely on keyboard access. In those
cases making the user aware that they've entered fullscreen is pretty much
the best defence the user has. Other than not having a fullscreen API at all.
Our fullscreen approval UI in Firefox is based around the assumption that for
most users the set of sites that use the fullscreen API that the user
encounters on a daily basis is small, and users would tend to opt to
remember the fullscreen approval for those domains. I'd imagine the set
would be YouTube, Facebook, and possibly ${FavouriteGame}.com for most users.
Thus users would see a notification and not an approval prompt most of the
time when they entered fullscreen. But when some other site goes fullscreen
they do get a prompt, which is out of the ordinary and more likely to be read.
Chris Pearce
