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:
For triage
(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
Assigning to mtho11 for backporting to the release branch. Targeting at 312.CR1
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.
Moving this to ON_QA as available for test in CR1.
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.
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).
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).
This change has been reverted from the jon3.1.x with commit: 864efb2
Mike, can you confirm what milestone this is in? Update status/milestone accordingly and assign to yourself.
This commit: 864efb2 in jon3.1.x was in 3.1.2 CR2 milestone.
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.
IE9 is a supported target for JON32
To follow along the isomorphic support thread: http://forums.smartclient.com/showthread.php?p=103657&posted=1#post103657
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.
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.
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.
@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.
@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.
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).
Moving back to ASSIGNED. MODIFIED status for when the fix is in the release branch but awaiting new brew binary.
Moving into ER04 as not completed in ER03.
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.
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.
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.
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.
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.
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.
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.
Created attachment 815567 [details] SmartGWT 3.0.2 patch (10/12/2013) New patch that fixes compile issue with i18n bundles.
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.
Moving to ON_QA for testing in the next build.
Created attachment 816142 [details] checkbox
verified thank you
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.