Fixes #1217060 - fix viewmode controls in :gui:

Fixes #1217060 - fix viewmode controls in :gui:

- When you go to a :gui: charm details view the browser is hidden from view,
but holds control of the viewmode controls for build/browser.
- Because of this, the event for clicking on the controls is part of the
:charmbrowser: namespace and cannot clear the :gui: space. You can never
escape!

This branch then does a few things:
- Fixes an edge case where, when hidden, the clean old view helper,has no old
view to clean.
- Make sure that, even when hidden, we update the _oldState to be able to
track viewstate changes while hidden.
- Add a giant XXX'd hack to operate viewmode controls from the app so that
when the browser is hidden, the controls operate as expected doing evil things
to fire navigate events that clear all namespaces and force something for the
users to work with.

Tests are added for the things we want to keep, like updating view state in
the browser. However, the giant XXX hack is not tested and is marked with XXX
so that we can come back and clear this when the serviceInspector is the
default in the very near future.

QA:

- Deploy a charm
- Click on the charm and hit view to go into the details
- Note that the active viewmode control is selected (build)
- Click on browse and you end up in browse mode correcetly
- Click on build to get back to the canvas
- Click on the charm again and go to view to get back to details
- Note that the viewmode controls keeps in sync this whole time
- Click on browser again to verify it works successive times.

https://code.launchpad.net/~rharding/juju-gui/browser-fix-1217060/+merge/182398

(do not edit description out of merge proposal)

[rharding, 2013-08-27 15:23:58]

Please take a look.

[matthew.scott, 2013-08-27 15:34:12]

LGTM, QA okay (Chrome, FF).  Shame about the hack, but it'll go away soon.

[jeff.pihach, 2013-08-27 15:44:08]

LGTM QA OK
IE QA OK 

Thanks for doing this fix

https://codereview.appspot.com/13282043/diff/1/test/test_app.js
File test/test_app.js (right):

https://codereview.appspot.com/13282043/diff/1/test/test_app.js#newcode244
test/test_app.js:244: // XXX bug:1217383
I'd add serviceInspector string somewhere here so that when we grep for the flag
we can easily find this to remove.

[rharding, 2013-08-27 16:01:15]

*** Submitted:

Fixes #1217060 - fix viewmode controls in :gui:

- When you go to a :gui: charm details view the browser is hidden from view,
but holds control of the viewmode controls for build/browser.
- Because of this, the event for clicking on the controls is part of the
:charmbrowser: namespace and cannot clear the :gui: space. You can never
escape!

This branch then does a few things:
- Fixes an edge case where, when hidden, the clean old view helper,has no old
view to clean.
- Make sure that, even when hidden, we update the _oldState to be able to
track viewstate changes while hidden.
- Add a giant XXX'd hack to operate viewmode controls from the app so that
when the browser is hidden, the controls operate as expected doing evil things
to fire navigate events that clear all namespaces and force something for the
users to work with.

Tests are added for the things we want to keep, like updating view state in
the browser. However, the giant XXX hack is not tested and is marked with XXX
so that we can come back and clear this when the serviceInspector is the
default in the very near future.

QA:

- Deploy a charm
- Click on the charm and hit view to go into the details
- Note that the active viewmode control is selected (build)
- Click on browse and you end up in browse mode correcetly
- Click on build to get back to the canvas
- Click on the charm again and go to view to get back to details
- Note that the viewmode controls keeps in sync this whole time
- Click on browser again to verify it works successive times.

R=matthew.scott, jeff.pihach
CC=
https://codereview.appspot.com/13282043