Issue Details (XML | Word | Printable)

Key: JAVASERVERFACES_SPEC_PUBLIC-1227
Type: New Feature New Feature
Status: Open Open
Priority: Major Major
Assignee: Unassigned
Reporter: Ed Burns
Votes: 3
Watchers: 2
Operations

If you were logged in you would be able to see more operations.
javaserverfaces-spec-public

Add <f:protectClientWindowOpenInNewTab> JavaScript behavior tag

Created: 07/Oct/13 10:38 PM   Updated: 20/Dec/13 02:13 PM
Component/s: Ajax/JavaScript
Affects Version/s: 2.2
Fix Version/s: None

Time Tracking:
Original Estimate: 4 days
Original Estimate - 4 days
Remaining Estimate: 4 days
Remaining Estimate - 4 days
Time Spent: Not Specified
Time Spent - Not Specified

Tags:
Participants: Ed Burns, tandraschko and Thomas Asel


 Description  « Hide

With the introduction of ClientWindow in JSF 2.2, it's possible to protect against multiple tabs being open on the same view. However, components that render links allow the user to do "open in new tab" or "open in new window". This can cause a situation where there are multiple tabs that still have the same ClientWindow, which is incorrect.

This feature proposal asks for the creation of a ClientBehavior tag that, when nested inside of a component that renders as a link, will make it so a new client window is created when the link is clicked.



Ed Burns added a comment - 07/Oct/13 11:49 PM

Here's a sketch for how this could work.

Here's how you'd use it.

<h:link outcome="callB" value="Call B via GET">
<f:protectClientWindowOpenInNewTab />
</h:link>

This would cause the link to be rendered with some javascript that listens for an onclick on the link. In the handler, check if the right mouse button was pressed and take appropriate action.


Thomas Asel added a comment - 08/Oct/13 06:28 AM

I am afraid that this feature would force unintuitive behavior and also advocates a rather patronizing development style.

How about creating a client behavior that creates a window id on demand?
So instead of blocking the contextmenu we could use the oncontextmenu handler to create a new id and append it as a parameter to the link.


Ed Burns added a comment - 08/Oct/13 12:40 PM

Thanks for the feedback, Thomas. We can certainly change the name to be less patronizing.

Please note that the ClientWindow will be created on demand when the request comes in without having one already. This is why it is sufficient for the context menu handler to simply strip it off.

The client behavior for this tag does two things.

1. If the link is clicked without the context menu, no action is taken. The already-existing ClientWindow is allowed to remain on the link, causing the correct ClientWindow to be carried forward.

2. If the link is clicked with the context menu (new tab or new window), the ClientWindow is removed before the browser issues the GET. This will cause a new ClientWindow to be created for the new tab (or window), this is the correct action in this case.


tandraschko added a comment - 20/Dec/13 02:13 PM

@Ed
is it really possible to listen on "onclick" when the link will be openend in new tab via context menu?
I'm sure onclick won't be called.

Maybe we should never render the windowId to a link und just add via onclick.
We could store the windowId globally in a JS varable in in the listener, we could add it to the href.