Dashboards & Visualizations

FlashChart not redrawing in Chrome after browsing away and back to it with LinkSwitcher

Builder

Hi all,

I'm having some trouble with a FlashChart in Chrome 19. In an advanced XML dashboard, I have a module chain of HiddenSearch-JobProgressIndicator/LinkSwitcher-HiddenPostProcess-FlashChart. The other child of LinkSwitcher is HiddenPostProcess-SimpleResultsTable. By default the data displays in chart format and looks fine. If I click the link for the table, then click the link to go back to the chart, the chart does not re-render; I get a blank panel. If I change the FlashChart to a JSChart, it works as expected. If I remove the JobProgressIndicator module, the search is regenerated each time I click and the chart displays properly, but I don't want to do that. IE 7 and IE 8 do not have this problem. Anyone seen this before? Bug, expected behavior, or what?

1 Solution

SplunkTrust
SplunkTrust

I've encountered this class of bugs before. It's hard to recommend something that will solve it 100% of the time, but I can tell you what's going on and suggest 2 things.

Background:
What happens is that flash movies are overly clever and they like to load and unload themselves from the browser when their canvas becomes visible and invisible. The FlashChart module then has some code that tries to keep up with this, so it tries to redraw the canvas when the swf gets unexpectedly reloaded. For the most part this works great, but this is in a class of cases where it doesn't

What makes it trip up, is that there's some "float:left" CSS up on your LinkSwitcher. that float CSS causes some extra unpredictability as to whether the flash player thinks the chart is visible. In the end you end up with a FlashChart that's there, but it's forgotten to render itself one last time.

1) First, to troubleshoot, replace your LinkSwitcher with a SubmitButton module. I'll bet the problem goes away because the float css on LinkSwitcher will be gone.

2) You can try to patch the situation by introducing a little bit of "clear" CSS, below the LinkSwitcher but above the FlashChart, and this might clear the float:

If your view is called "my_view", then you would put this into application.css:

.splView_my_view .FlashChart {
    clear:both;
}

Or you can try just putting this StaticContentSample module in there, below the LinkSwitcher but above the FlashChart in the same layoutPanel. It does the same thing but all embedded in the view so you don't have to monkey with the css file.

<module name="StaticContentSample">
  <param name="text"><![CDATA[
    <br clear="all">
  ]]></param>
</module>

UPDATE----------

I investigated further intending to work in a patch from Sideview Utils to at least prevent this problem from biting Sideview Utils users. To my surprise I found that I already do patch this problem from Sideview Utils.

Short answer: If you use the Sideview Utils app and incorporate the SideviewUtils module into your view, I think you'll find the bugs like this will go away.

Longer version: For Sideview views, my patches to the core systems are applied from the required "SideviewUtils" module. It's a little strange to start using Sideview Utils app and use only the SideviewUtils module, but you could do that. Certainly this alone will add significant improvements beyond fixing this bug. That said, once you go that far you'll probably want to start converting/improving other things, like taking out intentions and replacing SearchSelectListers with Pulldown, ExtendedFieldSearch with TextField, etc.. . But if you just put the SideviewUtils module into the view and nothing else, Utils modifies and normalizes the FlashChart's code so that this bug should go away.

View solution in original post

SplunkTrust
SplunkTrust

I've encountered this class of bugs before. It's hard to recommend something that will solve it 100% of the time, but I can tell you what's going on and suggest 2 things.

Background:
What happens is that flash movies are overly clever and they like to load and unload themselves from the browser when their canvas becomes visible and invisible. The FlashChart module then has some code that tries to keep up with this, so it tries to redraw the canvas when the swf gets unexpectedly reloaded. For the most part this works great, but this is in a class of cases where it doesn't

What makes it trip up, is that there's some "float:left" CSS up on your LinkSwitcher. that float CSS causes some extra unpredictability as to whether the flash player thinks the chart is visible. In the end you end up with a FlashChart that's there, but it's forgotten to render itself one last time.

1) First, to troubleshoot, replace your LinkSwitcher with a SubmitButton module. I'll bet the problem goes away because the float css on LinkSwitcher will be gone.

2) You can try to patch the situation by introducing a little bit of "clear" CSS, below the LinkSwitcher but above the FlashChart, and this might clear the float:

If your view is called "my_view", then you would put this into application.css:

.splView_my_view .FlashChart {
    clear:both;
}

Or you can try just putting this StaticContentSample module in there, below the LinkSwitcher but above the FlashChart in the same layoutPanel. It does the same thing but all embedded in the view so you don't have to monkey with the css file.

<module name="StaticContentSample">
  <param name="text"><![CDATA[
    <br clear="all">
  ]]></param>
</module>

UPDATE----------

I investigated further intending to work in a patch from Sideview Utils to at least prevent this problem from biting Sideview Utils users. To my surprise I found that I already do patch this problem from Sideview Utils.

Short answer: If you use the Sideview Utils app and incorporate the SideviewUtils module into your view, I think you'll find the bugs like this will go away.

Longer version: For Sideview views, my patches to the core systems are applied from the required "SideviewUtils" module. It's a little strange to start using Sideview Utils app and use only the SideviewUtils module, but you could do that. Certainly this alone will add significant improvements beyond fixing this bug. That said, once you go that far you'll probably want to start converting/improving other things, like taking out intentions and replacing SearchSelectListers with Pulldown, ExtendedFieldSearch with TextField, etc.. . But if you just put the SideviewUtils module into the view and nothing else, Utils modifies and normalizes the FlashChart's code so that this bug should go away.

View solution in original post

Builder

Thanks for looking into it, Nick.

0 Karma

SplunkTrust
SplunkTrust

To my surprise the Sideview Utils app already does patch this area of FlashChart behavior, such that this bug and others like it will go away if you start using Sideview Utils in your views. I have updated my answer with more details.

0 Karma

SplunkTrust
SplunkTrust

Aha. Interesting. OK I'll dig up the testcase I used last time I looked into this. If you can send over your xml to me please go ahead and do that nick [at] sideviewapps.com I'm wondering if I can put a patch for this FlashChart issue into Sideview Utils and have done with it.

0 Karma

Builder

Changing the LinkSwitcher to a PulldownSwitcher didn't make a difference.

0 Karma

SplunkTrust
SplunkTrust

Having the break tag enclosed in it's own SplunkModule div (the one from StaticContentSample) might not do the trick. You might be better off going into the CSS and making the FlashChart div itself clear the float.
Also, you can troubleshoot by replacing the LinkSwitcher with a PulldownSwitcher -- it'll still show/hide, but of course there's no float. That would be interesting to know.

0 Karma

Builder

If I replace the LinkSwitcher with SubmitButton, then the chart and table show up at the same time--there's no hiding the chart to begin with and thus no rerendering to do. I tried making the StaticContentSample a direct child of both the Linkswitcher and the HiddenPostProcess, but neither worked. Is it supposed to be a parent of the FlashChart or just at the same level? I think I tried both ways, but my closing module tags might have been in the wrong place.

0 Karma