DynamicForm layout bug

Technical Q&A
1

There appears to be a bug with the DynamicForm layout.

When a DynamicForm is placed within a TabSet and the tab with the form inside is NOT selected (ie: a different tab is selected) and the position of the form is moved within the browser (because it’s embedded within a Window), then the layout will be wrong when switching back to the tab that contains the DynamicForm.

I have attached some example code that illustrates the problem, and some screenshots showing the rendered output.

Steps to reproduce.

  1. Load the page.
  2. Notice the form on tab “one” looks fine (submit button on the bottom).
  3. Select tab “two”
  4. Drag the Window to new position in the browser’s view
  5. Switch back to tab “one”
  6. Notice the messed up rendering
  7. Drag the Window again with tab “one” selected. Notice that the rendering becomes corrected as long as tab “one” is selected when dragging.

I have had large RichTextEditors completely hide some of the fields (although that isn’t shown in this example.

This is using SmartClient_81_Evaluation.

Any help in figuring out how to fix the rendering problem would be greatly appreciated.

Thanks,
Chris

example.html (2.56 KB)

Before.png
Before.png387×247 11 KB

After.png
After.png385×249 10.8 KB

2

Not reproducible - if you’re using unpatched 8.1, go to smartclient.com/builds and download the latest 8.1.x nightly to get all the post 8.1 patches.

3

I just downloaded the latest nightly and have the exact same problem.
http://www.smartclient.com/builds/SmartClient/8.1/Eval/2011-12-05/SmartClient_SC_SNAPSHOT-2011-12-05_Evaluation.zip

Since you said that you couldn’t reproduce it I got thinking that it may be browser specific. The code seems to work fine in Google Chrome and Safari, but fails in Firefox on the Mac. I’m using FireFox 8.0.1 on a Mac, which is where it is failing. Unfortunately I don’t have access to a Windows box right now to verify the functionality there.

Thanks,
Chris

4

Ug, you’re right, we see this in Mac Firefox only. Must be a Firefox bug. We’ll take a look, but this won’t receive as high a priority as other bugs given that it’s Mac only and Firefox may well just fix it. Also, a workaround is to use an isc.Button instead of ButtonItem, and combine it with the form in the VLayout.