Bug 1344062 - Javascript issues on a client can cause issues updating the state of a dialog
Summary: Javascript issues on a client can cause issues updating the state of a dialog
Keywords:
Status: CLOSED DUPLICATE of bug 1328828
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Provisioning
Version: 5.5.0
Hardware: All
OS: All
high
high
Target Milestone: GA
: 5.7.0
Assignee: eclarizi
QA Contact: Dave Johnson
URL:
Whiteboard:
Depends On:
Blocks: 1347704 1347705
TreeView+ depends on / blocked
 
Reported: 2016-06-08 15:56 UTC by Felix Dewaleyne
Modified: 2020-01-17 15:47 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1347704 1347705 (view as bug list)
Environment:
Last Closed: 2016-07-08 17:47:27 UTC
Category: ---
Cloudforms Team: ---
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Felix Dewaleyne 2016-06-08 15:56:23 UTC
Description of problem:
provision dialog delivers to automate an older state than the current one - causing the appearance that values are truncated in the dialog.

Version-Release number of selected component (if applicable):
5.5.3

How reproducible:
regularily - disappears if the appliance is rebooted for some time

Steps to Reproduce:
1. use the dialog several time to provide vms
2.
3.

Actual results:
after several provisiohns or some time left running, provisions start to use older states of the dialog and that makes ip adresses appear to look truncat

Expected results:
provisioning with the dialog gives a consistant experience

Additional info:
logs added later

Comment 6 Felix Dewaleyne 2016-06-14 11:16:45 UTC
another aspect of this issue is that using a field to cause all the others of a dialog to refresh will make automation rttied to soime of the refreshed fields unable to read the data that was updated and caused the refresh.

consultants have been able to reproduce the issue and think it is tied with the load of the appliance and the amount of data transferred in the form.

I'll ask them for info as they may be able to provide a better description of how to reproduce the issue.

Comment 7 Felix Dewaleyne 2016-06-14 11:21:05 UTC
I had not understood the description well - the issue is caused by a client having a high performance issue. I think Kevin may still be able to give us a description of what kind of hardware/vm was used and caused that issue.

Comment 9 Loic Avenel 2016-06-16 07:18:24 UTC
Additional update base on discussion, Consultant reproduced the issue on his laptop by doing the following:
- Create a simple formulaire with Text boxes
- overload text box with a lot of text
- Click submit
Results: text is truncated...

What we observed, it takes time to upload the text to the server, if you click submit all text may be not there yet.

Customer has very slow desktop and slow network...

Comment 10 kpichard 2016-06-16 10:23:04 UTC
After some tests, this issue is related to the JS script not pushing the full data. I see the JS script pushing part of the content then update it. But some how if you have too much data/ too much fields and your client computer hasn't good performance, you could have the case that the JS start to push data then not update the whole content to cloudforms. 

It has been tested in last GA 4.0 and could be reproduce with fresh instance. 

Create dialog with like 20 text field. 

Create service based on this dialog.

Fill the field with a lot of data then submit.

You should see on production.log the JS fill send data for CF.

Then if you check the submit and variable you should have some blank/truncated values.

Comment 11 Greg McCullough 2016-06-16 18:16:17 UTC
It would be good to provide a service dialog export and maybe a screenshot showing the data entered to reproduce.  Also, it is not really clear what "Fill the field with a lot of data then submit" means, a screenshot would really help here.

Comment 12 eclarizi 2016-06-16 22:03:16 UTC
After doing a little bit of investigating, it appears that this PR that got merged to master might be able to fix the issue: https://github.com/ManageIQ/manageiq/pull/8421

Martin, does backporting that PR sound reasonable or would there be too many conflicts? Do you think this would potentially resolve the issue?

Comment 13 kpichard 2016-06-17 08:13:13 UTC
Hello,

I think this is the issue : https://bugzilla.redhat.com/show_bug.cgi?id=1328828

Seems to be ok in beta 2 after some tests.

Comment 18 eclarizi 2016-07-08 17:47:27 UTC

*** This bug has been marked as a duplicate of bug 1328828 ***


Note You need to log in before you can comment on or make changes to this bug.