With hindsight this technique is so similar to some other more advanced patterns I couldn't believe that I couldn't find it documented anywhere. I'd expect this is due to my using a different internal glossary to other people, nevertheless before finding this solution it looked hard, and afterward it seemed beautifully simple.
Intent
Send cross domain messages such as deep link requests to a named browser window. Do not interrupt existing playback of video etc. on the page.
Motivation
External search results and intranet pages will link to a single video player. As the player may have existing content queued to play, a deep link request that overrides the existing play list or causes the page to unload would be unwelcome. Prevention of cross domain scripting means that this cannot be directly accomplished by script.
Applicability
Allows one way messages to a web page from an external source with no need for javascript etc. at the sending location. If you need two way messaging and can use javascript then there are more appropriate patterns.
Implementation
Calling page may use javascript or a simple hyperlink to both create the instance and to send a message.
<a href="http://server.com/Player.aspx#MessageText" target="SingletonContext"> Link Content
</a>
The target (SingletonContext here) forms a context for the application to run in, and the page location, http://server.com/Player.aspx acts as a constructor call. MessageText can be any message you need to send.
MessageText needs to be appropriately encoded as part of your defence from XSS attacks, and must be limited in length. IE only supports around 4K total length for the entire URL after encoding.
In Silverlight 2 I can retrieve the bookmark text from C# easily.
public string GetCurrentBookmark()
{
string pageBookmark = HtmlPage.Document.DocumentUri.Fragment;
if (!string.IsNullOrEmpty(pageBookmark) && pageBookmark.StartsWith("#"))
{
return pageBookmark.Substring(1);
}
else {
return null;
}
}
and process this text in any way I want in order to extract the message. To refresh the bookmark we are using a Timer with a short interval.
Similar implementation is possible in javascript and any other platform with access to the page URL.
Limitations
The context for the singleton is a single user, and web browser. This won't stop anyone else browsing to the page. The same page may be opened in multiple browsers.
Messages sent within a single timer loop will overwrite previous messages causing message loss. To mitigate this, when browser support for the HTML 5 onhashchange event starts to appear in released browsers you should check the event is present and only start the timer if it is unavailable.
Messages with identical text will be lost. You can mitigate this by resetting the bookmark by navigating from the page, or by setting a message sequence in the message.
Risks
This pattern extends a message channel that previously was safe. Verify the contents of the message and don't allow messages that would perform undesirable actions within your code.
Related Patterns
There are several similar patterns based on Iframe URL manipulation.