Re: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite
2009/1/5 Boris Zbarsky bzbar...@mit.edu Giovanni Campagna wrote: Probably treating the onbeforeunload as a real cancelable event But the key is that the page must not be able to prevent navigation away from itself without explicit OK by the user. In other words, while the UA needs to be able to cancel the unload, the page has no need to. That ability already exists with onbeforeunload. What if we follow completely Andrew's proposal? That is, we allow cancellation of beforeunload events, but we add an UI control that may be used to froze JS (in HTML5 terms), preventing a further beforeunload to be handled and canceled. This control would be useful also in case of infinite loops or 10'000 alert windows: user presses STOP and JS is disabled temporary One may attach a onbeforeunload to a frame, and would like to know if only its javascript context is going to disappear, instead of the whole tab being destroyed, so it can send messages to parent window and have them read and handled There's no difference from navigating the subframe or removing the subframe from the parent DOM in terms of the script context going away, yet they'd be treated differently in Andrew's proposal. Seems to me like the subframe should just send the messages in this situation. What for? If the whole tab is closed, there will be no more message handler, so there is no reason to send a message
Re: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite
On Mon, Jan 5, 2009 at 9:06 AM, Bil Corry b...@corry.biz wrote: My demo that is listed (http://www.corry.biz/neverleave.lasso) will require you forcibly terminate your browser, so open it with a browser you want to forcibly terminate. Chrome lets me leave that page without terminating the browser (or the tab). I suspect Opera would let me leave as well, but the site seemed to go down before I could test it in Opera. Adam
Re: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite
Giovanni Campagna wrote: Probably treating the onbeforeunload as a real cancelable event But the key is that the page must not be able to prevent navigation away from itself without explicit OK by the user. In other words, while the UA needs to be able to cancel the unload, the page has no need to. That ability already exists with onbeforeunload. One may attach a onbeforeunload to a frame, and would like to know if only its javascript context is going to disappear, instead of the whole tab being destroyed, so it can send messages to parent window and have them read and handled There's no difference from navigating the subframe or removing the subframe from the parent DOM in terms of the script context going away, yet they'd be treated differently in Andrew's proposal. Seems to me like the subframe should just send the messages in this situation. -Boris
RE: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite
Thanks everyone for addressing this issue. The wiki page does help underscore the need for something like onbeforeunload in the standard. Whether onbeforeunload is fixed or whether to change unonload seems not too important since the functionality offered by either approach is identical. Having a separate onbeforeunload seemed to me to unnecessarily complicate matters. I am working a dialog problem now and I have discovered another problem with Onbeforeunload: It is called even for javascript URLs which clearly aren't exiting the page. Ie. It gets called when user clicks on a href=javascript:doSomeFunction()Link/a This is very annoying, as I must change this to span style=cursor:pointer;text-decoration:underline onclick=doSomeFunction();Link/span To avoid this. Andrew -Original Message- From: Mike Wilson [mailto:mike...@hotmail.com] Sent: Monday, January 05, 2009 11:53 AM To: 'Boris Zbarsky'; Shropshire, Andrew A Cc: public-webapps@w3.org Subject: RE: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite Boris Zbarsky wrote: Shropshire, Andrew A wrote: 1. Allow the unload event to be cancellable from script. This will allow web designers to recreate the modal flavor of desktop apps like MS Excel that prompt with Yes/No Cancel when there are unsaved changes. Doesn't the onbeforeunload event do this? Or is your issue wanting to change the text and/or provide that one extra option (instead of the two dialogs one would need right now to give all three of Yes/No/Cancel as options)? If so, would it make sense to extend onbeforeunload to do what you want instead of changing unload? Yes, that's the way I would go. I've also wanted to be able to customize the onbeforeunload dialog in some projects. There's some write-up here: http://www.openajax.org/runtime/wiki/Enhanced_support_for_dialogs Care must be taken though to ensure there is always a way to continue even if a custom dialog in an evil page removes the Continue option. Best regards Mike Wilson
RE: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite
Thank you for your comments. I agree with your objection concerning
loss of browsing history. One other objection I had was that it still
would not be possible to recreate the typical desktop application
behavior of asking the user if they wish to save changes/cancel when
closing the application (providing a YES/NO/CANCEL dialog whereby YES
saves the changes and exits, NO does not save the changes and exits, and
CANCEL cancels the exit).
I would like to submit a revised proposal that addresses these 2
objections, and a few additional objections that are best illustrated
with 4 brief web page examples.
EXAMPLE #1
In this example, tested with Internet Explorer 7, the page has the name
'test.htm'. One may test it by saving it to disk and opening it in a
browser. This page will block all navigation by redirecting the browser
to itself in the unload event handler. IE 7 however, allows the user to
close the page. Effectively, the user has lost their browsing history.
html
head
script
function exitPageCheck()
{
window.location = 'test.htm';
}
/script
/head
body onunload='exitPageCheck()'
Test
/body
/html
EXAMPLE #2
In this second example, I added an alert() before the redirect. The
alert displays when the user closes the page. This shows that the
unload event handler is fired when the user closes the page, but in
spite of the redirect, the browser closes the page.
html
head
script
function exitPageCheck()
{
alert('blocking');
window.location = 'test.htm';
}
/script
/head
body onunload='exitPageCheck()'
Test
/body
/html
EXAMPLE #3
In this example, the code displays a confirm dialog prior to the
redirect rather than an alert. When the user closes the page, the tab
is given an orange color, focus switches to a different tab, but
tab/page does not close yet. If the user clicks on the orange tab, they
will see the confirm dialog, however, hitting cancel does not stop the
page from finally closing (at which point the tab will disappear).
html
head
script
function exitPageCheck()
{
var answer = confirm('There are unsaved changes, are you sure you wish
to leave?');
if (answer)
return;
window.location = 'test.htm';
}
/script
/head
body onunload='exitPageCheck()'
Test
/body
/html
EXAMPLE #4
In this last example, the code display 10,000 confirm dialogs in the
unload event handler. When the user closes the page, IE changes the tab
color to orange and gives focus to
a different tab, however, if the user clicks on the orange tab
(returning focus to the malicious page), IE becomes modal and the user
cannot do anything with IE (such as giving focus to another tab) until
going through 1 confirm dialogs (effectively the browser is
crashed).
html
head
script
function exitPageCheck()
{
for (var i = 0; i 1; ++i)
var answer = confirm('There are unsaved changes, are you sure you
wish to leave?');
if (answer)
return;
window.location = 'test.htm';
}
/script
/head
body onunload='exitPageCheck()'
Hello
/body
/html
Revised proposal follows that addresses all these issues. This
obsoletes replaces the previous proposal.
1. Allow the unload event to be cancellable from script. This will
allow web designers to recreate the modal flavor of desktop apps like MS
Excel that prompt with Yes/No Cancel when there are unsaved changes.
As to how the cancel is accomplished, this could be a method of the
event object such as .cancel(), with another method such as
.isCanceled() to address situations where that are multiple event
listeners registered, and a previous one has already canceled the unload
event. For example, suppose there are 2 unload event listeners. The
2nd event listener to be called would not want to display another
confirm dialog to the user, if the first event handler had already done
so and canceled the unload.
2. In the unload event, distinguish between closes and navigating away,
by adding a property to the event object such as getUnloadType() which
returns an enumerated type with one of these values:
WINDOW_IS_CLOSING = 1
WINDOW_IS_NAVIGATING_TO_NEW_PAGE = 2
(Since javascript doesn't have an enumerated type that I am aware of,
this could be an integer, or even two separate methods like
.isClosing()and .isNavigatingAway() which return booleans).
It may be helpful to know for WINDOW_IS_NAVIGATING_TO_NEW_PAGE events
what the new URL is, however, this may violate security, and I can't
think of a benefit to knowing that information at the moment, so it may
be best to not provide that information.
3. Warn user with information style bar (similar to what IE already uses
when it blocks a file download) if page cancels unload event (it will
disappears after a few seconds without user interaction to avoid
annoying the user with having to close it). The text in the bar might
be (for page closures):
This page has blocked closure. Click here to override.
Or
This page is blocked navigation to the new
Proposal #2 clarifying details
Just want to add some clarifying details to the OVERRIDE CONTROL
outlined in my previous email:
1) The override control will allow the user to forcefully close the
window (maybe implemented as a Force Close button in the special
override control window). Since this control is expected to work even
if the web page is stuck in a script loop (as in EXAMPLE #4), this
control will operate in an independent thread from that executing the
script. If a Force Close is done, the thread running the script will
be effectively aborted by the other thread. Likewise, if navigation is
forced using the OVERRIDE CONTROL, the web page thread is effectively
aborted and a new one started. For this reason, when an override is
done, the web page which is the target of the override will receive no
events (since javascript is a single-threaded language). The OVERRIDE
CONTROL may have additional usefulness for those benevolently designed
web pages that freeze the browser because they are waiting on some
synchronous function call like retrieval of the web page contents, etc.
Andrew
-Original Message-
From: Shropshire, Andrew A
Sent: Monday, January 05, 2009 7:30 AM
To: 'Boris Zbarsky'
Cc: public-webapps@w3.org
Subject: RE: Proposal: Detecting when the user leaves a page due to
hitting the back button or typing in a URL or going to a favorite
Thank you for your comments. I agree with your objection concerning
loss of browsing history. One other objection I had was that it still
would not be possible to recreate the typical desktop application
behavior of asking the user if they wish to save changes/cancel when
closing the application (providing a YES/NO/CANCEL dialog whereby YES
saves the changes and exits, NO does not save the changes and exits, and
CANCEL cancels the exit).
I would like to submit a revised proposal that addresses these 2
objections, and a few additional objections that are best illustrated
with 4 brief web page examples.
EXAMPLE #1
In this example, tested with Internet Explorer 7, the page has the name
'test.htm'. One may test it by saving it to disk and opening it in a
browser. This page will block all navigation by redirecting the browser
to itself in the unload event handler. IE 7 however, allows the user to
close the page. Effectively, the user has lost their browsing history.
html
head
script
function exitPageCheck()
{
window.location = 'test.htm';
}
/script
/head
body onunload='exitPageCheck()'
Test
/body
/html
EXAMPLE #2
In this second example, I added an alert() before the redirect. The
alert displays when the user closes the page. This shows that the
unload event handler is fired when the user closes the page, but in
spite of the redirect, the browser closes the page.
html
head
script
function exitPageCheck()
{
alert('blocking');
window.location = 'test.htm';
}
/script
/head
body onunload='exitPageCheck()'
Test
/body
/html
EXAMPLE #3
In this example, the code displays a confirm dialog prior to the
redirect rather than an alert. When the user closes the page, the tab
is given an orange color, focus switches to a different tab, but
tab/page does not close yet. If the user clicks on the orange tab, they
will see the confirm dialog, however, hitting cancel does not stop the
page from finally closing (at which point the tab will disappear).
html
head
script
function exitPageCheck()
{
var answer = confirm('There are unsaved changes, are you sure you wish
to leave?');
if (answer)
return;
window.location = 'test.htm';
}
/script
/head
body onunload='exitPageCheck()'
Test
/body
/html
EXAMPLE #4
In this last example, the code display 10,000 confirm dialogs in the
unload event handler. When the user closes the page, IE changes the tab
color to orange and gives focus to
a different tab, however, if the user clicks on the orange tab
(returning focus to the malicious page), IE becomes modal and the user
cannot do anything with IE (such as giving focus to another tab) until
going through 1 confirm dialogs (effectively the browser is
crashed).
html
head
script
function exitPageCheck()
{
for (var i = 0; i 1; ++i)
var answer = confirm('There are unsaved changes, are you sure you
wish to leave?');
if (answer)
return;
window.location = 'test.htm';
}
/script
/head
body onunload='exitPageCheck()'
Hello
/body
/html
Revised proposal follows that addresses all these issues. This
obsoletes replaces the previous proposal.
1. Allow the unload event to be cancellable from script. This will
allow web designers to recreate the modal flavor of desktop apps like MS
Excel that prompt with Yes/No Cancel when there are unsaved changes.
As to how the cancel is accomplished, this could be a method of the
event object such as .cancel(), with another method such as
.isCanceled() to address situations where that are multiple event
listeners registered, and a previous one has already canceled the
Re: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite
Giovanni Campagna wrote: What if we follow completely Andrew's proposal? That is, we allow cancellation of beforeunload events, but we add an UI control that may be used to froze JS (in HTML5 terms), preventing a further beforeunload to be handled and canceled. That places UI requirements on UAs, which restricts innovation in the UI (which is where UAs should be innovating). It also adds what I see as unnecessary complexity to accomplish something that onbeforeunload already accomplishes. This control would be useful also in case of infinite loops or 10'000 alert windows: user presses STOP and JS is disabled temporary Again, this is where UAs should be competing. Some already provide precisely such protection in infinite loop cases. Seems to me like the subframe should just send the messages in this situation. What for? If the whole tab is closed, there will be no more message handler, so there is no reason to send a message The event is firing _before_ the closing has happened, so there is in fact a message handler, which may wish to save state or whatnot. Also, closing doesn't mean the whole app is gone (e.g. the closure of a window opened via window.open may well wish to communicate something to the opener). -Boris
Update to Widgets Signatures Editors Draft
I have updated the Widgets 1.0: Digital Signatures Editors Draft [1] as follows: + fix SHA-256 URI + add RSA-SHA256 URI + update example to use SHA-256 and RSA-SHA256 and remove possibly misleading hash/signature values + add signing step for signature properties + change headings from Timestamps and WidgetSignatureProfile to Signature Propertes + fix various typos and editorial cleanup of text Added issue - I suggest we consider referencing XML Signature 1.1, which will include SHA-256 and other additional algorithms as part of the specification, but which does not change the XML Signature namespace. regards, Frederick Frederick Hirsch Nokia [1] http://dev.w3.org/2006/waf/widgets-digsig/
Re: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite
Shropshire, Andrew A wrote: I am working a dialog problem now and I have discovered another problem with Onbeforeunload: It is called even for javascript URLs which clearly aren't exiting the page. I believe this is only the case in some browsers. For example, IE/Windows does this, but Gecko-based browsers do not, last I checked. -Boris
Re: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite
2009/1/5 Boris Zbarsky bzbar...@mit.edu Shropshire, Andrew A wrote: 1. Allow the unload event to be cancellable from script. This will allow web designers to recreate the modal flavor of desktop apps like MS Excel that prompt with Yes/No Cancel when there are unsaved changes. Doesn't the onbeforeunload event do this? Or is your issue wanting to change the text and/or provide that one extra option (instead of the two dialogs one would need right now to give all three of Yes/No/Cancel as options)? If so, would it make sense to extend onbeforeunload to do what you want instead of changing unload? Probably treating the onbeforeunload as a real cancelable event (like domactivate or rightclick) instead of callback that should provide some text may be what he meant (the rest is matter of naming, ie. onunload vs onbeforeunload) 2. In the unload event, distinguish between closes and navigating away, by adding a property to the event object such as getUnloadType() which returns an enumerated type with one of these values: I'm not sure the script needs this information, to be honest. What are the use cases? One may attach a onbeforeunload to a frame, and would like to know if only its javascript context is going to disappear, instead of the whole tab being destroyed, so it can send messages to parent window and have them read and handled Giovanni
RE: Proposal: Detecting when the user leaves a page due to hitting the back button or typing in a URL or going to a favorite
Boris Zbarsky wrote: Shropshire, Andrew A wrote: 1. Allow the unload event to be cancellable from script. This will allow web designers to recreate the modal flavor of desktop apps like MS Excel that prompt with Yes/No Cancel when there are unsaved changes. Doesn't the onbeforeunload event do this? Or is your issue wanting to change the text and/or provide that one extra option (instead of the two dialogs one would need right now to give all three of Yes/No/Cancel as options)? If so, would it make sense to extend onbeforeunload to do what you want instead of changing unload? Yes, that's the way I would go. I've also wanted to be able to customize the onbeforeunload dialog in some projects. There's some write-up here: http://www.openajax.org/runtime/wiki/Enhanced_support_for_dialogs Care must be taken though to ensure there is always a way to continue even if a custom dialog in an evil page removes the Continue option. Best regards Mike Wilson
Comments on Widgets 1.0 Security requirements
I have some comments on requirements section 4.6, Security and DIgital Signatures, editors draft [1], and some concrete suggestions for changes: (1) R44 http://dev.w3.org/2006/waf/widgets-reqs/#r44.- This requirement is unclear. Is the intent to say that a signature associated with a widget package might be extracted and served to a client independently of the package, allowing the package to be delivered without the signature inside of it? Or is it saying that the certificate chain and/or revocation information should be able to be accessed independently of the package? In general it might not make sense to validate a signature without access the widget content, since that is not meaningful unless it is possible to validate the content hashes used to generate and validate the signature. (2) R45 http://dev.w3.org/2006/waf/widgets-reqs/#r45.- It would be useful to add a sentence as to why SHA-1 is still required, e.g. Continued SHA-1 support is recommended to enable backward compatibility and interoperability. On the other hand if the widget specification has not yet been adopted, is there a reason not to require SHA-256 (and make SHA-1 optional), given the known potential weaknesses with SHA-1? Suggestion: replace MUST strongly recommend the use of SHA-256 to MUST recommend SHA-256 for new signature generation and must recommend SHA-1 and SHA-256 for signature verification (or explicitly note that SHA-1 is optional) strongly recommend is not a normative phrase according to RFC 2119. (3) R46 http://dev.w3.org/2006/waf/widgets-reqs/#r46.- Change and to or in the first sentence and or to and in the second to obtain the intended meaning. (4) R49 http://dev.w3.org/2006/waf/widgets-reqs/#r49.- The phrase To provide up-to-date is misleading, since cached information may be less up to date than the result of an online query, especially with OCSP. Suggest changing rationale paragraph to To enable a widget to obtain revocation information without having to query an online CRL or OSCP server from each device. This is a lot more efficient and eases the load on CRL or OCSP servers. Note, however, that the revocation information may not be as up to date as an online query. However, if this information is updated at the server in a timely manner before widget installations, then an online query would not be necessary at the client. (5) Missing requirement: A signature should indicate the role of the signer. Suggested text A signature may be signed by a widget author as well as a widget distributor. The role of the signer should be indicated to enable the verifier to understand the role of the signer and associated implications. (6) Missing requirement: A signature should indicate a policy associated with it, independent of information associated with key or certificate information For example, a signature should have a usage (or policy) property indicating that it is associated with the W3C Widget Signature specification and processing rules. The use of a URL is recommended to allow different policies and to enable updated versions. (7) Missing requirement: Widget packages only require signature validation and certificate and revocation verification upon first installation on a device Proposed text: A widget package signature is validated and associated certificates and revocation information verified, only when the widget is first installed on the device. Signatures and certificate and revocation information may be updated over time at the server for subsequent installation on other devices, effectively creating a new widget package. (8) Missing requirement - Widget signatures must include counter- measures against use of out of date widget packages Since a signature is validated upon widget installation, and this signature (and associated certificate and revocation information) can be updated before subsequent widget installations, it is important that an old signature cannot be re-used (replayed), since that would cause updated certificate and revocation information to be ignored. Thus a signature should have material to avoid later inappropriate reuse - such as a short-lived expiration of the signature. Note that a nonce and timestamp, as used for replay attack mitigation, may not be suitable since the client may never have installed the widget previously and not have access to earlier nonce information. That is all for now, though I may have missed something. regards, Frederick Frederick Hirsch Nokia [1] http://dev.w3.org/2006/waf/widgets-reqs/
