WHATWG Wiki - User contributions [en]

Modal prompts

2012-02-16T13:52:44Z

Jochen:

==Overview==

This document describes a proposal for gradually removing modal dialogs and prompts from the platform.

==Rationale==

In a tabbed browser, modal dialogs are potentially disrupting the work flow of the user as they can't interact with any other web site as long as the modal dialog is displayed.

Furthermore, implementing <code>showModalDialog</code> might require running a nested message loop which caused several security issues in the past.

===Issues with current implementations===
Chromium for example doesn't display a window created by <code>showModalDialog</code> in a modal way: http://crbug.com/16045

WebKit and Firefox don't suppress events while a modal dialog is running: https://bugs.webkit.org/show_bug.cgi?id=78240 and https://bugzilla.mozilla.org/show_bug.cgi?id=360872

Firefox displays modal prompts as tab-modal. However, it's possible to execute JavaScript in a tab that should be blocked by a modal prompt: https://bugzilla.mozilla.org/show_bug.cgi?id=727397 and the prompts from separate tabs can block each other: https://bugzilla.mozilla.org/show_bug.cgi?id=727801

==Proposal==

===Callbacks===

For the following modal prompts, a callback parameter is introduced

* <code>alert</code>
* <code>confirm</code>
* <code>prompt</code>

When these functions are invoked with a callback parameter, they return immediately (instead of blocking). The callback is invoked as soon as the modal dialog closes. For <code>confirm</code> and <code>prompt</code>, the callback takes one parameter which is set to the value to modal version would have returned.

====WebIDL====

Current interface

<pre>
void alert(DOMString message);
boolean confirm(DOMString message);
DOMString? prompt(DOMString message, optional DOMString default);
</pre>

Proposed interface

<pre>
void alert(DOMString message, optional VoidCallback complete);
boolean confirm(DOMString message, BooleanCallback complete);
DOMString? prompt(DOMString message, optional BooleanCallback complete);
DOMString? prompt(DOMString message, DOMString default, optional BooleanCallback complete);
</pre>

<code>prompt</code> requires overloading, as the existing interface already has an optional parameter.

===showModalDialog===

I would like to propose deprecating and eventually removing <code>window.showModalDialog</code> from the platform. Web sites can already now use e.g. <code>window.open</code> instead. However, I'm not quite sure how this could be achieved.

==Examples==

<pre>
window.confirm("Are you sure?", function(result) { if (result) doIt(); });
</pre>

==Issues==

* What would a reasonable plan to deprecate <code>showModalDialog</code> look like?
* Does it make sense to add a callback to <code>alert</code> at all?
* Should we rather invest in <code><dialog></code> and then try to deprecate all of the modal prompts and dialogs?

[[Category:Proposals]]

Modal prompts

2012-02-16T13:17:43Z

Jochen:

==Overview==

This document describes a proposal for gradually removing modal dialogs and prompts from the platform.

==Rationale==

In a tabbed browser, modal dialogs are potentially disrupting the work flow of the user as they can't interact with any other web site as long as the modal dialog is displayed.

Furthermore, implementing <code>showModalDialog</code> might require running a nested message loop which caused several security issues in the past.

===Issues with current implementations===
Chromium for example doesn't display a window created by <code>showModalDialog</code> in a modal way: http://crbug.com/16045

WebKit and Firefox don't suppress events while a modal dialog is running: https://bugs.webkit.org/show_bug.cgi?id=78240 and https://bugzilla.mozilla.org/show_bug.cgi?id=360872

Firefox displays modal prompts as tab-modal. However, it's possible to execute JavaScript in a tab that should be blocked by a modal prompt: https://bugzilla.mozilla.org/show_bug.cgi?id=727397 and the prompts from separate tabs can block each other: https://bugzilla.mozilla.org/show_bug.cgi?id=727802

==Proposal==

===Callbacks===

For the following modal prompts, a callback parameter is introduced

* <code>alert</code>
* <code>confirm</code>
* <code>prompt</code>

When these functions are invoked with a callback parameter, they return immediately (instead of blocking). The callback is invoked as soon as the modal dialog closes. For <code>confirm</code> and <code>prompt</code>, the callback takes one parameter which is set to the value to modal version would have returned.

====WebIDL====

Current interface

<pre>
void alert(DOMString message);
boolean confirm(DOMString message);
DOMString? prompt(DOMString message, optional DOMString default);
</pre>

Proposed interface

<pre>
void alert(DOMString message, optional VoidCallback complete);
boolean confirm(DOMString message, BooleanCallback complete);
DOMString? prompt(DOMString message, optional BooleanCallback complete);
DOMString? prompt(DOMString message, DOMString default, optional BooleanCallback complete);
</pre>

<code>prompt</code> requires overloading, as the existing interface already has an optional parameter.

===showModalDialog===

I would like to propose deprecating and eventually removing <code>window.showModalDialog</code> from the platform. Web sites can already now use e.g. <code>window.open</code> instead. However, I'm not quite sure how this could be achieved.

==Examples==

<pre>
window.confirm("Are you sure?", function(result) { if (result) doIt(); });
</pre>

==Issues==

* What would a reasonable plan to deprecate <code>showModalDialog</code> look like?
* Does it make sense to add a callback to <code>alert</code> at all?
* Should we rather invest in <code><dialog></code> and then try to deprecate all of the modal prompts and dialogs?

[[Category:Proposals]]

Modal prompts

2012-02-16T13:09:14Z

Jochen:

==Overview==

This document describes a proposal for gradually removing modal dialogs and prompts from the platform.

==Rationale==

In a tabbed browser, modal dialogs are potentially disrupting the work flow of the user as they can't interact with any other web site as long as the modal dialog is displayed.

Furthermore, implementing <code>showModalDialog</code> might require running a nested message loop which caused several security issues in the past.

===Issues with current implementations===
Chromium for example doesn't display a window created by <code>showModalDialog</code> in a modal way: http://crbug.com/16045

WebKit and Firefox don't suppress events while a modal dialog is running: https://bugs.webkit.org/show_bug.cgi?id=78240 and https://bugzilla.mozilla.org/show_bug.cgi?id=360872

Firefox displays modal prompts as tab-modal. However, it's possible to execute JavaScript in a tab that should be blocked by a modal prompt: https://bugzilla.mozilla.org/show_bug.cgi?id=727397 and the prompts do not terminate necessarily in the correct order: https://bugzilla.mozilla.org/show_bug.cgi?id=727399

==Proposal==

===Callbacks===

For the following modal prompts, a callback parameter is introduced

* <code>alert</code>
* <code>confirm</code>
* <code>prompt</code>

When these functions are invoked with a callback parameter, they return immediately (instead of blocking). The callback is invoked as soon as the modal dialog closes. For <code>confirm</code> and <code>prompt</code>, the callback takes one parameter which is set to the value to modal version would have returned.

====WebIDL====

Current interface

<pre>
void alert(DOMString message);
boolean confirm(DOMString message);
DOMString? prompt(DOMString message, optional DOMString default);
</pre>

Proposed interface

<pre>
void alert(DOMString message, optional VoidCallback complete);
boolean confirm(DOMString message, BooleanCallback complete);
DOMString? prompt(DOMString message, optional BooleanCallback complete);
DOMString? prompt(DOMString message, DOMString default, optional BooleanCallback complete);
</pre>

<code>prompt</code> requires overloading, as the existing interface already has an optional parameter.

===showModalDialog===

I would like to propose deprecating and eventually removing <code>window.showModalDialog</code> from the platform. Web sites can already now use e.g. <code>window.open</code> instead. However, I'm not quite sure how this could be achieved.

==Examples==

<pre>
window.confirm("Are you sure?", function(result) { if (result) doIt(); });
</pre>

==Issues==

* What would a reasonable plan to deprecate <code>showModalDialog</code> look like?
* Does it make sense to add a callback to <code>alert</code> at all?
* Should we rather invest in <code><dialog></code> and then try to deprecate all of the modal prompts and dialogs?

[[Category:Proposals]]

Modal prompts

2012-02-15T22:49:44Z

Jochen:

==Overview==

This document describes a proposal for gradually removing modal dialogs and prompts from the platform.

==Rationale==

In a tabbed browser, modal dialogs are potentially disrupting the work flow of the user as they can't interact with any other web site as long as the modal dialog is displayed.

Furthermore, implementing <code>showModalDialog</code> might require running a nested message loop which caused several security issues in the past.

===Issues with current implementations===
Chromium for example doesn't display a window created by <code>showModalDialog</code> in a modal way: http://crbug.com/16045

WebKit and Firefox don't suppress events while a modal dialog is running: https://bugs.webkit.org/show_bug.cgi?id=78240 and https://bugzilla.mozilla.org/show_bug.cgi?id=360872

Firefox displays modal prompts as tab-modal. However, it's possible to execute JavaScript in a tab that should be blocked by a modal prompt: https://bugzilla.mozilla.org/show_bug.cgi?id=727397 and the prompts do not terminate necessarily in the correct order: https://bugzilla.mozilla.org/show_bug.cgi?id=727399

==Proposal==

===Callbacks===

For the following modal prompts, a callback parameter is introduced

* <code>alert</code>
* <code>confirm</code>
* <code>prompt</code>

When these functions are invoked with a callback parameter, they return immediately (instead of blocking). The callback is invoked as soon as the modal dialog closes. For <code>confirm</code> and <code>prompt</code>, the callback takes one parameter which is set to the value to modal version would have returned.

====WebIDL====

Current interface

<pre>
void alert(DOMString message);
boolean confirm(DOMString message);
DOMString? prompt(DOMString message, optional DOMString default);
</pre>

Proposed interface

<pre>
void alert(DOMString message, optional VoidCallback complete);
boolean confirm(DOMString message, BooleanCallback complete);
DOMString? prompt(DOMString message, optional BooleanCallback complete);
DOMString? prompt(DOMString message, DOMString default, optional BooleanCallback complete);
</pre>

<code>prompt</code> requires overloading, as the existing interface already has an optional parameter.

===showModalDialog===

I would like to propose deprecating and eventually removing <code>window.showModalDialog</code> from the platform. Web sites can already now use e.g. <code>window.open</code> instead. However, I'm not quite sure how this could be achieved.

==Examples==

<pre>
window.confirm("Are you sure?", function(result) { if (result) doIt(); });
</pre>

==Issues==

* What would a reasonable plan to deprecate <code>showModalDialog</code> look like?
* Does it make sense to add a callback to <code>alert</code> at all?

[[Category:Proposals]]

Modal prompts

2012-02-15T09:57:26Z

Jochen: added "Issues with current implementations"

==Overview==

This document describes a proposal for gradually removing modal dialogs and prompts from the platform.

==Rationale==

In a tabbed browser, modal dialogs are potentially disrupting the work flow of the user as they can't interact with any other web site as long as the modal dialog is displayed.

Furthermore, implementing <code>showModalDialog</code> might require running a nested message loop which caused several security issues in the past.

===Issues with current implementations===
Chromium for example doesn't display a window created by <code>showModalDialog</code> in a modal way: http://crbug.com/16045

WebKit and Firefox don't suppress events while a modal dialog is running: https://bugs.webkit.org/show_bug.cgi?id=78240 and https://bugzilla.mozilla.org/show_bug.cgi?id=360872

Firefox displays modal prompts as tab-modal. However, it's possible to execute JavaScript in a tab that should be blocked by a modal prompt: https://bugzilla.mozilla.org/show_bug.cgi?id=727397 and the prompts do not terminate necessarily in the correct order: https://bugzilla.mozilla.org/show_bug.cgi?id=727399

==Proposal==

===Callbacks===

For the following modal prompts, a callback parameter is introduced

* <code>alert</code>
* <code>confirm</code>
* <code>prompt</code>

When these functions are invoked with a callback parameter, they return immediately (instead of blocking). The callback is invoked as soon as the modal dialog closes. For <code>confirm</code> and <code>prompt</code>, the callback takes one parameter which is set to the value to modal version would have returned.

====WebIDL====

Current interface

<pre>
void alert(DOMString message);
boolean confirm(DOMString message);
DOMString? prompt(DOMString message, optional DOMString default);
</pre>

Proposed interface

<pre>
void alert(DOMString message, optional VoidCallback complete);
boolean confirm(DOMString message, BooleanCallback complete);
DOMString? prompt(DOMString message, optional BooleanCallback complete);
DOMString? prompt(DOMString message, DOMString default, optional BooleanCallback complete);
</pre>

<code>prompt</code> requires overloading, as the existing interface already has an optional parameter.

===showModalDialog===

I would like to propose deprecating and eventually removing <code>window.showModalDialog</code> from the platform. Web sites can already now use e.g. <code>window.open</code> instead. However, I'm not quite sure how this could be achieved.

==Examples==

<pre>
window.confirm("Are you sure?", function(result) { if (result) doIt(); });
</pre>

==Issues==

What would a reasonable plan to deprecate <code>showModalDialog</code> look like?

[[Category:Proposals]]

Modal prompts

2012-02-14T19:34:54Z

Jochen: add webidl and reword showModalDialog section

==Overview==

This document describes a proposal for gradually removing modal dialogs and prompts from the platform.

==Rationale==

In a tabbed browser, modal dialogs are potentially disrupting the work flow of the user as they can't interact with any other web site as long as the modal dialog is displayed.

Furthermore, implementing <code>showModalDialog</code> might require running a nested message loop which caused several security issues in the past.

==Proposal==

===Callbacks===

For the following modal prompts, a callback parameter is introduced

* <code>alert</code>
* <code>confirm</code>
* <code>prompt</code>

When these functions are invoked with a callback parameter, they return immediately (instead of blocking). The callback is invoked as soon as the modal dialog closes. For <code>confirm</code> and <code>prompt</code>, the callback takes one parameter which is set to the value to modal version would have returned.

====WebIDL====

Current interface

<pre>
void alert(DOMString message);
boolean confirm(DOMString message);
DOMString? prompt(DOMString message, optional DOMString default);
</pre>

Proposed interface

<pre>
void alert(DOMString message, optional VoidCallback complete);
boolean confirm(DOMString message, BooleanCallback complete);
DOMString? prompt(DOMString message, optional BooleanCallback complete);
DOMString? prompt(DOMString message, DOMString default, optional BooleanCallback complete);
</pre>

<code>prompt</code> requires overloading, as the existing interface already has an optional parameter.

===showModalDialog===

I would like to propose deprecating and eventually removing <code>window.showModalDialog</code> from the platform. Web sites can already now use e.g. <code>window.open</code> instead. However, I'm not quite sure how this could be achieved.

==Examples==

<pre>
window.confirm("Are you sure?", function(result) { if (result) doIt(); });
</pre>

==Issues==

What would a reasonable plan to deprecate <code>showModalDialog</code> look like?

[[Category:Proposals]]

Modal prompts

2012-02-14T14:17:50Z

Jochen: Initial proposal for dealing with modal dialogs

Meta referrer

2011-11-19T10:33:47Z

Jochen: /* Issues */ what should happen if the origin is unique

==Overview==

This document describes a proposal the "referrer" metadata name. Using the referrer metadata attribute, a document can control the behavior if the Referer HTTP header attached to requests that originate from the document.

==Use Cases==

An author might wish to control the <code>Referer</code> header omitted by a document for a number of reasons.

===Privacy===

A social networking site has a profile page for each of its users, and users add hyperlinks from their profile page to their favorite bands. The social networking site might not wish to leak the user's profile URL to the band web sites when other users follow those hyperlinks (because the profile URLs might reveal the identity of the owner of the profile).

Some social networking sites, however, might wish to inform the band web sites that the links originated from the social networking site but not reveal which specific user's profile contained the links.

===Security===

A web application uses HTTPS and a URL-based session identifier. The web application might wish to link to HTTPS resources on other web sites without leaking the user's session identifier in the URL.

===Trackback===

A blog hosted over HTTPS might wish to link to a blog hosted over HTTP and receive [http://en.wikipedia.org/wiki/Trackback trackback] links.

===Object-Capability Discipline===

Some web applications wish to follow an object-capability discipline. The <code>Referer</code> header constitutes an ambient authority, contrary to an object-capability discipline. Having the ability to disable the <code>Referer</code> header makes it easier for these web applications to follow this discipline.

==Specification==

Keyword: <code>referrer</code>

The referrer metadata attribute can have one of four values for its content attribute:
* <code>never</code>
* <code>always</code>
* <code>origin</code>
* <code>default</code>

When a meta element is inserted into the document, if its name attribute is presents and matches the referrer metadata name, then the user agent must run the following algorithm:
# If the meta element lacks a content attribute, abort these steps.
# Let the document's ''referrer-policy'' be the value of the content attribute converted to lower case with leading and trailing <code>LWS</code> removed.
# If the document's ''referrer-policy'' is not one of the strings listed above, replace the document's ''referrer-policy'' with the string <code>default</code>.

''TODO:'' This algorithm causes the most recently added meta element to control the ''referrer-policy''. Should we support changing the policy by setting the content attribute?

Replace Step 3 of ''Fetching resources'' in the HTML standard [[http://www.whatwg.org/specs/web-apps/current-work/ HTML]] with the following text:
<blockquote>
Let the ''referrer-header-value'' be the document's ''current address of document''.

Remove any <fragment> component from the ''referrer-header-value''.

If the ''origin'' of the appropriate Document is not a scheme/host/port tuple, then replace the ''referrer-header-value'' with the empty string, regardless of its value.

* If the ''referrer-policy'' is <code>never</code>:
: Replace the ''referrer-header-value'' with the empty string, regardless of its value.

* If the ''referrer-policy'' is <code>default</code>:
: Replace the ''referrer-header-value'' with the empty string if the <scheme> component of the ''referrer-header-value'' represents a protocol that uses transport-layer security and the <scheme> component of the resource being fetched does not.

* If the ''referrer-policy'' is <code>origin</code>:
: Replace the ''referrer-header-value'' with the ''ASCII serialization'' [[http://tools.ietf.org/html/draft-ietf-websec-origin ORIGIN]] of the ''origin' of the appropriate Document.

* If the ''referrer-policy'' is <code>always</code>:
: Do not alter the ''referrer-header-value''. '''Note: This might cause https referrers to be sent over the network as part of unencrypted HTTP requests.'''
</blockquote>

In Step 5 of ''Fetching resources'' in the HTML standard [[http://www.whatwg.org/specs/web-apps/current-work/ HTML]], replace the text "For the purposes of the Referer (sic) header, [...]" with the following text:
<blockquote>
For the purposes of the Referer (sic) header, use the ''referrer-header-value'' are generated in Step 3.
</blockquote>

==Examples==

This meta element instructs the user agent to omit the <code>Referer</code> header in all HTTP requests that originate from the document containing the element:
<pre>
<meta name="referrer" content="never">
</pre>

This meta element instructs the user agent to include the document's origin in the <code>Referer</code> header rather than the full URL of the document:
<pre>
<meta name="referrer" content="origin">
</pre>
'''Note:''' The user agent will include the origin string in the <code>Referer</code> header even for links from HTTPS to HTTP resources.

==Issues==

How does this interact with rel=noreferrer? Presumably rel=noreferrer should override whatever global setting the user agent gets from the meta element.

The origin is not a canonical URL as it lacks a path. The user agent should probably just add / as path.

What should happen if the origin is unique? Presumably the referrer should be omitted in that case.

[[Category:Proposals]]

Meta referrer

2011-11-18T23:19:42Z

Jochen: /* Issues */ Added a note about the origin not being a valid URL