There are a lot of very clever developers out there that just love accessing and modifying the DOM through client scripts. Typical reasons include: it's just easy so why not; they need to build an enhanced client interaction that may not be possible using published client APIs; they want to build a custom look and feel that no one else has. The challenge in Fuji is that direct access to the ServiceNow DOM is now forbidden when executed in an application scope. They still work in the global scope which is where all of the ServiceNow apps live. So you'll still see examples of DOM scripts but you won't be able to copy the logic to your apps. This is a topic that will generate plenty of grumpy coders. We might need DOM Coders Anonymous support group at Knowledge15 to get through it together.
So what's the real impact? It depends on how much you're doing with the DOM. I've always been on the conservative side. I'd rather talk customers into slightly modified use-cases so that we can make use of supported APIs over building a solution that is ultimately a higher cost of ownership, and could possible break in a future release. Even this conservative approach has me banging my head on the keyboard when I run into limitations.
Say you're using a client UI Action and want to redirect to a new page. The case I ran into was a UI Action that runs a client script for a progress viewer (more on this soon) then redirect to a list of records on callback from the progress worker. This redirect would usually be accomplished by setting the window.location using a few different options.
window.location.href = "x_cavu_table_list.do"; window.location = "x_cavu_table_list.do"; window.location.replace("x_cavu_table_list.do");
The problem is standard DOM objects such as "window" and "document" are not available in client side scripts for scoped applications. Your action will just fail to work but you won't know why unless you check your browser console and notice this:
Luckily, there is still one place you can show off your DOM muscles in your scoped applications, that's in UI Pages. Since APIs like GlideForm don't exist in your own pages, it's kind of required that DOM objects be available so it's a good thing they allow it.
So with a little help from my friends still inside the mothership I was able to get the functionality I needed from a UI Action. I feel a little dirty but at least it works until there's a better solution.
Instead of using a client side UI Action, I made it a server side action. On the server you can redirect using action.setRedirectURL(). I redirected to a new UI Page that only has a client script. This client script handles the progress worker execution, progress display, and final redirect to the list of record generated by the worker. It works perfect. Since it's my own UI Page I was able to use:
I anticipate future ServiceNow releases will expand client APIs to support the common use cases like window redirect without having to access the DOM directly. Until then, you might have to get a little creative while sticking with the published APIs that are available.
Disclaimer: this is written based on patch2 hf1. Things have been moving a lot between patches and hotfixes so your mileage may vary.