Are there any known issues on deployed applications whereby a radio button becomes unresponsive? As if it is not selectable. Same with icons. It seems to happen after a dialog is closed - not always reproduceable though and it only happens on IE. It looks like it might be window masking problems but the funny thing is that there are other controls on the page which is responsive.
-
-
an update on this issue - it seems it's only the mouse that becomes unresponsive over the canvas items. When we tab through the canvas items on the screen, the radio button/select item/date item becomes responsive again. Note that it only starts breaking IF we have just shown a dropdown or a date picker. -
we are using SmartClient_v82p_2012-06-06_PowerEdition in deploymentComment
-
It also seems to happen after a tooltip for a field is shownComment
-
Any thoughts on this??Comment
-
We haven't seen this effect.
It sounds like it is indeed a case where the UI is being masked by some floating element in the DOM.
We have a number of cases where we write a transparent div and float it over components in order to explicitly block mouse interactions, etc -- for example for the clickmask. It is possible that this kind of thing is responsible, but we just can't give you a definite answer without more information.
Ideally - as always - a test case we can run will allow us to get to the bottom of it.
Other than that:
- if you pop open the developer console and click on the unresponsive item, you should see the mouse down target reported in the developer console. Try this while in the good (working) state first and you should see the ID of the form the item is embedded in. Then try in the broken state and see if something else is reported. This may indicate if another component is rendering above the item and blocking it.
- Secondly you could inspect the DOM while in the bad state and actually look at whether there is an element floating over the top of the item blocking mouse interactions. If you can give us details about this element (ID etc) it may clarify where it's coming from.
There are other things we could suggest (forcing redraw, experimenting with z-index, etc) but these are going to be random guesses without more information.
A repro-case would undoubtedly allow us to get to the bottom of this, so we'd recommend channeling your efforts that way.Comment
-
We could not reproduce it outside of production and only in our client's computers. We had them redeploy it with debugging information so that we could get further clarification but now they are unable to reproduce it.Comment
-
Is it possible that may GWT obfuscated code would conflict with how SC functions?Comment
-
This is always possible, if the GWT code goes and interferes with SmartClient's DOM and/or event handlers (obfuscated GWT code is JavaScript, so can do whatever JavaScript can do).Comment
-
Ok - there goes that theory - the issue is still reproduceable even with unobfuscated gwt code. This is quite difficult to debug since if we put the debugger into the deployment, it is no longer reproduceable. By debugger I mean we add the following directories and redeploy:
isomorphic\system\development
isomorphic\system\helpersComment
-
That's an interesting observation, but of course if those files are merely sitting there on disk they cannot possibly affect your app. So you must be making some other change at the same time that is part of the problem - try to figure out what that is.Comment
-
Just to confirm, would https vs http deployment make a difference?Comment
-
It should have no effect. But we're talking about IE, so that's never something you can say for sure.Comment
-
Here's a bit more information to speculate on (since we cannot do much else)
"Few things noticed when we are not able to click on some components, I used mouse to scroll browser and it started to work and stops again."Comment
-
There's a very huge possibility that this issue has to do with not deploying with the helper directory as mentioned here:
http://forums.smartclient.com/showthread.php?p=94589#post94589
Could this be? If so, why is this issue only reproduceable in client's production and specific machines?Comment
Comment