...

That's a very simple approach which has some disadvantages. It just adds the Window-ID to all URLs. That works if users don't open e.g. a link in a new tab (it would clone a window - that isn't nice but not worse than the HTTP session itself). Furthermore, a "drop" script detects the "open in new tab" use-case and drops the current window-id and requests the page again with a new window-id.
There must be a per-use way to disable the inclusion of the URL in a link.

custom-Mode

This mode allows that a JSF implementation or RenderKit provides a proprietary mode which is even more optimized - e.g. using an intermediate page which can be stored in the local-storage of HTML5.
Values: custom:name of the mode e.g.: <param-value>custom:intermediate-page</param-value>

...

Optional onunload hook (in some browsers it just works with a sync. request - and not with async. requests)

Summary of the Discussion in the EG

1 Suggestions based on the status in CODI:
------------------------------------------------

1.1 General Definitions regarding Window-ID
------------------------------------------------------------
a) a window-id always refers to the tab to allow a proper isolation (it should/can be stored in the browsers window.name)

b) a window-id always is unique in the session of the user. A session contains exactly 1 window-id per browser tab.

c) rendering multiple window-ids per browser tab is not allowed hence also not in portlet mode.(because the window-id is stored in the browsers window.name)

1.2 Modes and special cases
---------------------------------------
1) no mode: no window-id is generated - legacy mode

2) url-Mode: the window-id is stored in the browser url
hidden fields are shadowed into the forms also to keep the window-id support for post requests.
windowId parameters are added to http get links.
Server side the windowId needs to be processed over the sent windowId parameters.

This is even the same for Portlet cases since the window-id has
a referential pattern of 1:n to the scopes
The same goes for sub scopes.

If a new tab is opened a Javascript script detects that use case and basically re-renders the page with a new window-id dedicated to the tab.
How that is done is up to the implementation. The basic implementation is to check for an empty or non-matching window.name and then redirect the page without a window-id in the url to force a new one.

3) custom-Mode:
Allows to use a custom mode provided by the JSF implementation or a custom RenderKit.

Value: custom:[name of the mode]

e.g.:
<param-value>custom:intermediate-page</param-value>

TBD

5) Bookmark case or a href … target=_new: This is handled in CODI by opening a new window-id or recycling the old one (bookmarking case with same windowid in the bookmark as the existing one)

2. Status quo of the spec discussion compared to CODI:
---------------------------------------------------------------------------

a) URL mode: checked is discussed.

b) overriding the URL not yet fully discussed: since it opens another can of worms (f)

c) synchronizing the URL with hidden fields: checked is discussed due to having hidden fields holding javay.faces.windowId

d) Open in new tab script: soon under discussion

e) hidden field only mode: Breaks e.g. the get requests and browser refresh, therefore not doable

f) jsf.getWindowId can be simplified (is now in the proposal) if (b) is omitted or postponed, otherwise it needs to be investigated, if the current implementation can hold. The entire code was programmed under the assumption that we have a window-id per Portlet use case, which cannot hold for (d) see also (g)

g) Ajax protocol ViewRoot either redundant, or in case of (b), cannot work on ViewRoot level
because single forms can if override is enabled be updated with different ViewRoots.
(my mistake i was under the wrong assumption between window-id and scope and because of (g) )

h) window-id per Portlet, is there a use case for that one? Especially since it breaks the new
tab detection jsf.getWindowId can hold for (g)

i) server side part of the window-id handling, where to be rendered, under discussion

h) open point: what to do with the a hrefs and pages where you don´t want to have a window id. Should a link to a different window-id be possible, how can you turn it off/on.