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 wid
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 Geck
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
On Mon, Jan 5, 2009 at 10:44 AM, Adam Barth wrote:
> On Mon, Jan 5, 2009 at 9:06 AM, Bil Corry 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 le
On Mon, Jan 5, 2009 at 9:06 AM, Bil Corry 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 th
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
Giovanni Campagna wrote on 1/5/2009 10:48 AM:
> This control would be useful also in case of infinite loops or 10'000 alert
> windows: user presses STOP and JS is disabled temporary
This problem was recently discussed on WHATWG:
http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-
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
Shropshire, Andrew A wrote on 1/2/2009 8:36 AM:
> I'd like to propose an onNavigateToNewPage event for the window object.
> This would be distinguished from the onUnload event in that the event is
> only fired when the user navigates to a new page whereas onUnload is
> fired additionally for when
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
2009/1/5 Boris Zbarsky
> 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
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
2009/1/5 Boris Zbarsky
>
> 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
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
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
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
16 matches
Mail list logo
