Skip navigation

I’ve been talking about JSF 2.2 new features out on the conference trail for quite a while now. I usually talk about the big three: Flows, Resource Library Contracts, and HTML5 Friendly Markup. This blog entry talks about another, mostly behind-the-scenes, feature: ClientWindow. I introduce the concept of ClientWindow and give a simple example illustrating one solution to a common web browser problem: the browser’s "open in new tab” or "open in new window” feature.

First, some background on the ClientWindow feature. In the name of clean design, this feature is disabled by default. Because the Faces Flows feature entirely depends onClientWindow, the usage of Faces Flows will automatically enable ClientWindow if it is not enabled already. To explicitly enable ClientWindow, you can set a <context-param> with a<param-name> ofjavax.faces.CLIENT_WINDOW_MODE and a<param-value> of url in yourweb.xml. For example


The JSF specification allows other values for this parameter, but other values would be implementation specific.

If ClientWindow is enabled, it will add an extra name=value pair onto every navigation component rendered by JSF. This extra name=value pair is the rendered representation of an instance of the javax.faces.lifecycle.ClientWindowclass. The JavaDoc for that class states:

This class represents a client window, which may be a browser tab, browser window, browser pop-up, portlet, or anything else that can display a UIComponent hierarchy rooted at a UIViewRoot.

The specification provides for additional logic that will cause an instance of ClientWindow to be automatically created if one is not already present for the currently rendered view. Now that we’ve defined the feature, let’s explain how to trip it up, and how to fix it.

“Open in new tab” or “Open in new window”

If a JSF 2.2 app has the ClientWindow feature enabled, every view that can be reached from the landing page for that app will have the extra name=value pair appended. In Oracle Mojarra, this parameter looks like this:jfwid=518a78c52da3c025ab7a31cf4d50:6. Components that render as hyperlinks offer the user a browser context menu that usually includes two options: “Open in new tab” and “Open in new window”. Selecting either of these two options would effectively cause two tabs to share the sameClientWindow. This is a violation of the concept and any data that is client window specific (such as flow scoped data) would now be shared across the two tabs (or windows). The easiest way to work around this is to simply prevent the context menu on any link components. This can simply be accomplished using an HTML5 Friendly Markup feature in JSF 2.2: passthrough attributes.

Declare a an XML namespace on your facelet page with the following namespace URI: Once declared, any attribute from that namespace will automatically be rendered straight to the markup without any server side interpretation. This can be used with the handy oncontextmenu javascript attribute to disable the context menu. For example:

<html xmlns=""
<h:form prependId="false">
   <p><h:link value="callB via GET" outcome="callB"
               my:oncontextmenu="return false;"/></p>

Granted, this is a pretty brute force approach, but it can be targeted at individual components. I’ve opened JAVASERVERFACES_SPEC_PUBLIC-1227to create a more nuanced approach. Please vote for it if you’re interested and maybe we’ll get to it for JSF 2.3.

My JavaOne 2013: Wrapup

This blog entry summarizes my session participation at JavaOne 2013. I plan to update this entry with links to the content on as it becomes available.

Sessions I Attended

In general, speaking more than listening is a very bad way to live. I find this holds true at conferences as well. Here are the sessions I attended. I attended eight and presented six, so I guess I'm safe. Twitter links to session speakers provided for convenient following.



  • Building CDI Extensions - CON2667

    Jason Porter - Tuesday, Sep 24, 1:00 PM - 2:00 PM - Parc 55 - Mission

    Having built CDI extensions to enable JSF 2.2 FlowScoped and ViewScoped, I was keen to see what I had done wrong. Turns out the code Pete Muir and J.J. Snyder gave me, and which I hacked on until it worked, is exactly what Mr. Porter ordered. I was glad to share one hard-learned nugget in writing CDI 1.1 extensions: Don't forget to publish the @Initializved and@Destroyed CDI events at the appropriate times.


  • Introduce Java Programming to Kids - CON3431

    Arun Gupta and Jim Weaver - Wednesday, Sep 25, 10:00 AM - 11:00 AM - Hilton - Continental Ballroom 6

    My ten year old is just getting in to programming, and it's inspiring what Arun's ten year old has done in the field of educating about Minecraft modding. Personally, I'm still a little uneasy with the legality of it because it just doesn't feel right to have to bytecode decompile something to hack on it, but Arun assures me someone named "Notch" is ok with it. I guess that will have to do.

  • How to Get More Kids to Code - CON3023

    Saskia Vermeer-Ooms,Regina ten Bruggencate- Wednesday, Sep 25, 11:30 AM - 12:30 PM - Hilton - Continental Ballroom 6

    Even though there was subject matter overlap between this and the previous sessions, this session offered different perspectives, most importantly the female perspective. I think the Devoxx4Kids idea is great. I hope someone in our cash-strapped, time-starved educational community here in the U.S. picks it up. I don't have the time!

  • The Adventurous Developer's Guide to JVM Languages - CON4191

    Simon Maple - Wednesday, Sep 25, 1:00 PM - 2:00 PM - Hilton - Yosemite B/C

    In the fashion of such breezy talks, Mr. Maple gave an excellent tour of some of the more popular JVM languages. I like such talks for their value in reducing first order ignorance.


Sessions I Presented


  • JavaServer Faces from a New Perspective: JSF 2.2, HTML5, Bean Validation 1.1, EL 3.0, JPA 2.1 - JUN10155

    9/22/13 (Sunday) 9:00 AM - Golden Gate University, 536 Mission Street - Room 5215

    Slides ready: 100%

    Demos ready: 100%




Filter Blog

By date: