And this is why some people hate Javascript

Working on our VLF application, I ran into a problem for our Microsoft Edge users: If the command handler window was expanded (the draggable bar pulled upwards) beyond a certain point, only the filter window contracted. Not the instance list and thereby effectively nor the command handler window.

The problem comes from resizing of the table cells, the function VF_SY001_PRIVATE_SizeInstanceList_Height in VF_XXNNN.js.

So I chose to overwrite the function in an additional javascript file, if the user is in Edge:

window.setTimeout(function() {
if (window.navigator.userAgent.indexOf("Edge") > -1) {
var func = VF_SY001_PRIVATE_SizeInstanceList_Height;
VF_SY001_PRIVATE_SizeInstanceList_Height = function(sHeight) {
func(sHeight);
let nHeight = parseInt(sHeight);
nHeight = nHeight + 24;
nHeight = "" + nHeight + "px";
document.getElementById("VF_UM011_Container").style.height = nHeight;
};
}
}, 1000);

I set the func variable to the original function, overwrite the function to call the original plus some extra code. Now I just need it tested by others.

Advertisements

Old application and new(-ish) browser

Back in a web application built using Visual Lansa v. 12.5 and using the technology service PPC_XHTML, I got the task of getting it to work on a new unit. It was – unsurprisingly – a PDA application and the new “PDA” would be a modern, fast and capable android unit.

The application was built for an Internet Explorer for the handheld units and on an Android it is logical to look at Chrome.

To my surprise very little had to be done to get it to look nice. CSS media queries and a tiny bit at that and I was practically done.

However, one of the WAMs had an auto-submit when the user made a change to the selection in a radio and in Chrome 54 for Android, that resulted in a request with the old value being sent. The radio button was updated but as the request contained the old value, the response was “wrong”. The problem was that the request body was being constructed, on the click event, before the radio button change had taken effect.

The fix was rather simple – I inserted a bit of javascript using jQuery:

$("input#RADIOBUTTON1").mousedown(function() {
   $("input[name=RADIOGROUP]").val($(this).val());
});
$("input#RADIOBUTTON2").mousedown(function() {
   $("input[name=RADIOGROUP]").val($(this).val());
});

This way, as the mousedown event fires before the click event (remember, a click event is combination of a mousedown and a mouseup on the same element), the radio button was updated before the request body was constructed.

Unfortunately the final unit turns out to run a browser built on Chromium 52. And there is a bit difference for the web application.

I have not solved it yet – we might be able to get the units with a newer browser – but I needed to test it on my own machine. And getting an old Chrome/Chromium does take some steps.

First of all, you can’t really get an old Chrome. But Chromium should be good enough.

I found the guide on the Chromium website but I will repeat it here, just it case:

And then I could confirm that the issue exists in Chromium 52. Now I could just find the cause in the change logs.

Update: I think I managed to “fix” my problem. The browser was built using the system component WebView on Android. WebView, which uses Chromium and will be using Chrome on Android 7, can be updated using the Google Play Store and after doing that, it now runs on Chromium 55 and our web application works as intended.