Bug 889194 - IE9 - Check boxes in discovery queue are being un-checked back after checking it
IE9 - Check boxes in discovery queue are being un-checked back after checking it
Status: CLOSED CURRENTRELEASE
Product: JBoss Operations Network
Classification: JBoss
Component: UI (Show other bugs)
JON 3.1.2
i386 Windows
high Severity high
: ER04
: JON 3.2.0
Assigned To: Simeon Pinder
Mike Foley
:
Depends On:
Blocks: 889375 1012435
  Show dependency treegraph
 
Reported: 2012-12-20 08:35 EST by Armine Hovsepyan
Modified: 2015-09-02 20:01 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 889375 (view as bug list)
Environment:
Last Closed: 2014-01-02 15:35:10 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
SmartGWT 3.0 patch (9.96 MB, application/java-archive)
2013-09-30 22:55 EDT, Mike Thompson
no flags Details
i18n compile fail with patch applied (45.80 KB, text/plain)
2013-10-23 08:03 EDT, Simeon Pinder
no flags Details
SmartGWT 3.0.2 patch (10/12/2013) (9.96 MB, application/java-archive)
2013-10-23 17:15 EDT, Mike Thompson
no flags Details
checkbox (114.42 KB, image/png)
2013-10-25 09:08 EDT, Armine Hovsepyan
no flags Details

  None (edit)
Description Armine Hovsepyan 2012-12-20 08:35:58 EST
Description of problem:
IE9 - Check boxes in discovery queue are being un-checked back after checking it

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

JON 3.1.2
W7_x86 IE9

How reproducible:
always

Steps to Reproduce:
1. Login to jon server
2. Go to Discovery queue
3. check a check-box for any resource
  
Actual results:
For most of the times Check-box gets unchecked 

Expected results:
Check-box is marked as checked from the fist time and never gets unchecked automatically

Additional info:
Comment 2 Charles Crouch 2012-12-21 09:50:10 EST
For triage
Comment 5 Charles Crouch 2013-01-02 11:50:17 EST
(9:02:45 AM) mfoley: ok ... i want this one in JON 3.1.2 (if possible)
(10:15:27 AM) ccrouch: mfoley: if you are confident QE can detect any IE8 regressions, then I think i'm comfortable too re: including  https://bugzilla.redhat.com/show_bug.cgi?id=889194
(10:15:42 AM) ccrouch: loleary|holiday: when you are back, can you take a look at  https://bugzilla.redhat.com/show_bug.cgi?id=889194
(10:15:58 AM) mfoley: well we are going to retest 
(10:16:09 AM) mfoley: this seems like the right thing to do ... to include that in JON 3.1.2
(10:36:44 AM) ccrouch: (10:15:58 AM) mfoley: well we are going to retest 
(10:36:44 AM) ccrouch: retest both IE8 and 9 ?
(10:40:23 AM) mfoley: right ...yes
(10:40:35 AM) mfoley: that is what is needed 
(10:40:39 AM) ccrouch: right
(10:41:52 AM) ccrouch: and then *some* testing on FF too, since you can never guarantee something completely unrelated hasn't broken :-(
(10:42:16 AM) mfoley: yes ...our automation runs on FF ...and we will additionally do manual testing on FF
(10:42:45 AM) ccrouch: i'm not sure whn loleary|holiday is back, so I think it makes sense to put this into the release branch now, its already in master
(10:42:55 AM) ccrouch: that way we can get it into CR1
(10:42:57 AM) mfoley: i am fine with that 
(10:43:02 AM) mfoley: that is the right thing to do
(10:43:09 AM) mfoley: i dont want to speak for larry
(10:43:09 AM) mfoley: but
(10:43:14 AM) mfoley: he wants IE9
(10:43:17 AM) ccrouch: if something goes horribly wrong, we can back it out and all our existing testing is still valid
(10:43:24 AM) mfoley: and this is the worst of the IE9 BZs
(10:43:28 AM) ccrouch: right
(10:43:33 AM) mfoley: and i think he wants this in JON 3.1.2
(10:43:49 AM) mfoley: i am comfortable with the risk level
(10:43:57 AM) mfoley: and our ability to mitigate risk by retesting 
(10:44:32 AM) ccrouch: mtho11: just to double check, you are comfortable with  https://bugzilla.redhat.com/show_bug.cgi?id=889194 in 312 too ?
(10:44:58 AM) mtho11: yes, with retesting on IE8, IE9, FF
Comment 6 Charles Crouch 2013-01-02 11:51:32 EST
Assigning to mtho11 for backporting to the release branch.
Targeting at 312.CR1
Comment 7 Mike Thompson 2013-01-02 12:34:58 EST
Branch: release/jon3.1.x
commit: d57267a

Cherry Picked BZ 889375 from master to release 312. This changes the doc type to support IE9 better

By changing:
    <meta http-equiv="X-UA-Compatible" content="IE=8" />
to 
    <meta http-equiv="X-UA-Compatible" content="IE=9" />

See https://bugzilla.redhat.com/show_bug.cgi?id=889375 for more info.
Comment 8 Simeon Pinder 2013-01-03 21:37:05 EST
Moving this to ON_QA as available for test in CR1.
Comment 9 Mike Thompson 2013-01-07 13:09:42 EST
NOTE: smartGWT has fixed this checkbox behavior in IE9 with their latest patches (I used the 1/04/2013 patch) and this behavior works fine now. It does however introduce other worse behavior with grids not rendering in portlets throwing the following errors in multiple places:


Failed to draw Table [HLayout{ID: "isc_ResourceOperationsPortlet_0", width: 670, height: 193, members: Array[2], position: "absolute", className: "normal", top: -9999, vertical: false, children: Array[2], locatorParent: [Window ID:isc_PortletWindow_14], parentElement: [Layout ID:isc_PortletWindow_14_body], topElement: [VLayout ID:isc_CoreGUI_RootCanvas_0], tabIndex: 4653, cacheOffsetCoords: true, zIndex: 210782, memberSizes: Array[1], }].

com.google.gwt.core.client.JavaScriptException:(TypeError) : Cannot call method 'find' of undefined
--- STACK TRACE FOLLOWS ---
(TypeError) : Cannot call method 'find' of undefined
   at Unknown.isc_ListGrid_setSort(http://192.168.1.7:7080/coregui/org.rhq.enterprise.gui.coregui.CoreGUI/sc/modules/ISC_Grids.js@176)
   at Unknown.isc_ListGrid_setData(http://192.168.1.7:7080/coregui/org.rhq.enterprise.gui.coregui.CoreGUI/sc/modules/ISC_Grids.js@34)
   at Unknown.isc_ListGrid_initWidget(http://192.168.1.7:7080/coregui/org.rhq.enterprise.gui.coregui.CoreGUI/sc/modules/ISC_Grids.js@118)
   at Unknown.isc_Canvas_init(http://192.168.1.7:7080/coregui/org.rhq.enterprise.gui.coregui.CoreGUI/sc/modules/ISC_Core.js@6)
   at Unknown.isc_Class_completeCreation(http://192.168.1.7:7080/coregui/org.rhq.enterprise.gui.coregui.CoreGUI/sc/modules/ISC_Core.js@6)
   at Unknown.isc_c_Class_create(http://192.168.1.7:7080/coregui/org.rhq.enterprise.gui.coregui.CoreGUI/sc/modules/ISC_Core.js@1688)
   at Unknown.create_36(http://192.168.1.7:7080/coregui/org.rhq.enterprise.gui.coregui.CoreGUI/E632F794EF93AF8B63254D7B81F5B4DF.cache.html@38)
   at Unknown.$getOrCreateJsObj_0(http://192.168.1.7:7080/coregui/org.rhq.enterprise.gui.coregui.CoreGUI/E632F794EF93AF8B63254D7B81F5B4DF.cache.html@25)
   at Unknown.addMember(http://192.168.1.7:7080/coregui/org.rhq.enterprise.gui.coregui.CoreGUI/E632F794EF93AF8B63254D7B81F5B4DF.cache.html@17)
   at Unknown.$doOnDraw(http://192.168.1.7:7080/coregui/org.rhq.enterprise.gui.coregui.CoreGUI/E632F794EF93AF8B63254D7B81F5B4DF.cache.html@28)
   at Unknown.$onDraw_0(http://192.168.1.7:7080/coregui/org.rhq.enterprise.gui.coregui.CoreGUI/E632F794EF93AF8B63254D7B81F5B4DF.cache.html@33)

So this patch is definitely not an option as these errors are rendered in all browsers.
Comment 10 Mike Thompson 2013-01-07 13:18:16 EST
Additionally, the <meta http-equiv> change that worked in master causes other issues for IE9 (IE9 only) in JON3.1.2.CR1 with login dialog box being rendered as line (see https://bugzilla.redhat.com/show_bug.cgi?id=891876).
Comment 11 Mike Thompson 2013-01-07 13:55:40 EST
IE is tricky as each version changes quite a bit compatibility-wise (probably because of the long time periods involved). Also, the ability of users to switch compatibility modes on the browser (quirks mode) makes this even more difficult to get a solution that works in both quirks and standards mode; and each standards mode is specific to each browser (for instance 'IE8 Standards' mode is different than 'IE9 Standards' mode which is different than 'Compatibility' mode). These settings are determined by the doc type(html5,xhtml1-transitional,etc..), meta http-equiv tag or overridden by the user with IE Compatibility mode settings.

Since smartGWT widgets are developed under specific mode settings we just take what they tell us to set as they have tested with those settings and nothing else is guaranteed. When we find weird issues like this it is up to the smartGWT guys to fix (which is usually a SmartClient javascript fix as smartGWT is just a wrapper around the javascript libraries).
Comment 13 Mike Thompson 2013-01-08 09:29:35 EST
This change has been reverted from the jon3.1.x with commit: 864efb2
Comment 14 Larry O'Leary 2013-01-14 15:53:04 EST
Mike, can you confirm what milestone this is in? Update status/milestone accordingly and assign to yourself.
Comment 15 Mike Thompson 2013-01-14 16:24:04 EST
This commit: 864efb2 in jon3.1.x was in 3.1.2 CR2 milestone.
Comment 16 Larry O'Leary 2013-01-14 18:03:32 EST
We will need to re-look at this for 3.2. At the moment, there is still no official plan to support IE9 in 3.2 either so the priority is very dependent on IE9 support from a product perspective. 

When we re-look at this, be sure the we understand why we had to revert this change from the ON 3.1.2 release. Specifically that it introduced bug 892019 which demonstrates that many of the portlets on the dashboard become broken when using IE9.
Comment 17 Charles Crouch 2013-03-11 10:22:15 EDT
IE9 is a supported target for JON32
Comment 20 Mike Thompson 2013-04-25 12:16:52 EDT
To follow along the isomorphic support thread: 

http://forums.smartclient.com/showthread.php?p=103657&posted=1#post103657
Comment 21 Mike Thompson 2013-04-25 13:10:32 EDT
Isomorphic support just replied: "We've fixed this and the changes will hit nightly builds from April 26"

So I will test again on April 27th.
Comment 22 Mike Thompson 2013-04-29 12:22:35 EDT
I have validated the 4/26/2013 smartgwt-3.0.jar patch and isomorphic has now fixed the sortSpecifier issue.

So if we can figure out how to do automated builds with the patch version instead of the current version then this issue is good to go.
Comment 23 Mike Thompson 2013-05-01 12:46:16 EDT
Since we need a non-patch version so that we can pick up the changes in a new maven version, I'm assuming that we will wait for a change in release from smartgwt?

Finished from development standpoint of doing anything more with this issue.
Comment 28 Simeon Pinder 2013-09-27 07:29:44 EDT
@Heiko, I think he means the former in product build.

@Mike, How big is this jar? This is probably doable in the product build, much like we needed to patch the JBoss Modules jar for EAP 6.1.0.Final.GA.  We'd probably need to create and publish the binaries somewhere or pull into git(prefer not to if file size is pretty big), the overlay.
Comment 29 Mike Thompson 2013-09-29 16:35:21 EDT
@Heiko, only talking about patching. Definitely, not upgrade (I can only imagine the issues on such a major change).

@Spinder, the size we are talking here for smartgwt.jar is 10M (not sure if this considered large or not).

We should discuss some more via phone.
Comment 30 Mike Thompson 2013-09-30 22:55:04 EDT
Created attachment 805677 [details]
SmartGWT 3.0 patch

Attached is the smartgwt.jar from May 2013 that has the minimal changes to make this fix work (and hopefully the least risk patch).
Comment 32 Simeon Pinder 2013-10-02 06:01:20 EDT
Moving back to ASSIGNED. MODIFIED status for when the fix is in the release branch but awaiting new brew binary.
Comment 33 Simeon Pinder 2013-10-08 03:52:59 EDT
Moving into ER04 as not completed in ER03.
Comment 34 Simeon Pinder 2013-10-18 15:21:30 EDT
This is fixed with commit ed8e7b508127ba9c4 to jon-rpmspec git repository.  The fix was to add the attached smartgwt as a patched library(3.0.1) in brew maven repositories. See commit and 3.0.1.pom.xml for more details. 

Moving this to MODIFIED for testing in the next brew build.

@Mike Thompson, if you want to test this out in master you'd just need to add the nightly repo(http://download.devel.redhat.com/brewroot/repos/jboss-on-3-nightly-build/latest/maven) and move the smartgwt version to 3.0.1.

@Mike Foley, this moves the smartgwt version as described above, so you'll want to have QE look out for gui differences if any. MikeT can better describe.
Comment 35 Simeon Pinder 2013-10-23 08:03:57 EDT
Created attachment 815370 [details]
i18n compile fail with patch applied

Typically the only time we/devs do a full i18n build is at productization time. This may prevent using the IE fix.
Comment 36 Simeon Pinder 2013-10-23 10:50:01 EDT
Moving back to ASSIGNED and back out of ER4 build for now. See previous comment.  At least pushing this to ER5 until Mike has had a chance to weigh in.
Comment 37 Mike Thompson 2013-10-23 12:34:00 EDT
I can confirm that there are errors with the ja and pt bundles from the smargwt3.0.1 patch. 

So it looks like our options are either to take a more current patch and hope that doesn't cause anything unexpected. Or ???

Since they only place the patch jars out for download: http://www.smartclient.com/builds/SmartGWT/3.0p/LGPL
There is no repository that we could just build the patch source ourselves (backporting a possible fix to ja bundles to the version that fixes ie9 checkboxes). Thereby eliminating our risk in taking newer fixes and patching the bundles ourselves. So I'm still looking at options.
Comment 38 Mike Thompson 2013-10-23 12:44:59 EDT
Ok. Even though there is no repository for patches they do provide the zip file of the source. So it is possible to backport the fixes to that version if we can figure out how to build it (there is no build scripts or pom files).

I'm going to diff the source trees to see how much source code is affected here.
Comment 39 Mike Thompson 2013-10-23 13:35:00 EDT
The amount of change between the 05/04/2013 patch and the 10/12/2013 patch is actually minimal. The only things I see that have changed is the calendar, tree and RichTextEditor. With the tree being the highest risk to us. But, the number of lines of code that changed between these versions is quite minimal and makes me feel more comfortable with the latest patch.

Testing more on those three widgets with the latest patch.
Comment 40 Mike Thompson 2013-10-23 17:12:26 EDT
I have tested and attached the latest patch (10/12/2013) and everything in the UI looks good to me. The Japanese bundle issue is resolved in the new patch. The RichTextEditor and calendar widgets we don't even use and that just leaves the tree control which did have some changes but after playing around with the application everything still works fine.
Comment 41 Mike Thompson 2013-10-23 17:15:50 EDT
Created attachment 815567 [details]
SmartGWT 3.0.2 patch (10/12/2013)

New patch that fixes compile issue with i18n bundles.
Comment 42 Simeon Pinder 2013-10-23 23:43:16 EDT
The latest patch is applied with commit a91b0cfc4ee376 to jon-rpmspec. Moving this to MODIFIED for testing in next brew build and back into ER4.
Comment 43 Simeon Pinder 2013-10-24 00:10:39 EDT
Moving to ON_QA for testing in the next build.
Comment 44 Armine Hovsepyan 2013-10-25 09:08:56 EDT
Created attachment 816142 [details]
checkbox
Comment 45 Armine Hovsepyan 2013-10-25 09:12:35 EDT
verified 
thank you
Comment 46 Jay Shaughnessy 2013-11-06 15:35:43 EST
This may be clear already, but from what i can see, this is still an issue in RHQ 4.9.

We'd need to move forward with the SmartGWT version to get this resolved.  As it stands I see this in the discovery queue view with IE10.

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