Unable to call server side function within HTML entities

[Segi]

I am having a very strange problem.

I attached a client callable script to my forms' CCF section.

The function is a simple one that only returns a string like this:

function test() {
return "TEST";
}

When I load the page and before I click on anything, if I open the dev console and run $eb.executeFunction("test"), "TEST" is returned.

My form has a table and one of the columns is a hyperlink with an HTML entities that looks like this:

Code: Select all

// Ignore click events if this cell does not contain any text
if ($(this).parent().html().indexOf("Hyperlink") == -1) {
     return false;	
}

debugger;

return false;

If I click on the link while the dev console is open, execution stops on the debugger line as expected. If I run the exact same command $eb.executeFunction("test") while in HTML entities, undefined is returned.

There is no error on the server to indicate that anything went wrong.

This is happening on 2 different instances of Ebase, one on 5.5 and another on 5.4

Edit: I also tested this out in a slightly different way by creating a new project with a new form with a new field that was set up as a hyperlink with debugger in HTML entities. The form was tied to a brand new script that I created with the test function above and this issue is still happening.

Sample project is available for you guys at Verj to try out here: https://ufile.io/5n7c5

[Jon]

I'm not too sure what I'm supposed to be looking at here. I imported your form and ran it and it stops at the debugger line and opens my Chrome debugger (I had to add jquery first). Is this what's supposed to happen?

[Segi]

Jon,

Yes thats correct.

When I call $eb.executeFunction("test") while stopped at that debugger break point, the result is ALWAYS undefined. When you load the form but before you click on the link, if you open the dev console and run $eb.executeFunction("test") you get the expected response. I think it has something to do with the context of $eb while debugging

[Jon]

Ah I see. Yes I get the same result.
The $eb.executeFunction() does indeed attempt to pick up the local context. It looks like something is missing when it goes into "debugger" mode. I confess I didn't know that you could even do that!

[Segi]

Jon,

Yea its very helpful when you want to test out your server side function in real time; when it works.

[Segi]

Jon,

Has this issue been raised so it can be fixed in the next version of Verj ?

I tested this out on Chrome 73.0.3683.103, Firefox 66.0.3 and Edge 42.17134.1.0 and this issue only happens in Google Chrome.

My production server is currently on 5.5.0 and my Dev server is on 5.5.1 and both seem to have this problem.

I found a similar situation where if you call $eb.getField("FIELDNAME") while stopped at a debugger breakpoint, it also returns undefined. Calling $eb.getField("FIELDNAME") when not stopped at a debugging breakpoint correctly returns an object.

This bug is causing us a lot of issues because most of my applications open up in a popup window which displays a form where you can edit an individual record. When you save the record and close the popup window, I have this jQuery script that runs in the popup window to trap the window unload event:

Code: Select all

// This script will execute when a popup window is closed and will call the appropriate function in REFRESH_FUNCTIONS to refresh the table in a parent window
$(document).ready(function () {
	  $(window).on("beforeunload", function(e) {  	   
	  	   // If the parent window doesn't have a refreshTables function, it means REFRESH_FUNCTIONS client script is not attached to it so do not continue
	  	   if ( typeof(window.opener.refreshTables) != "function" ) {
	  	        return;	
	  	   }
        
              // This line is failing because of the issue with $eb.getFieldValue's context when debugging
	       var refreshNeeded=$eb.getField("REFRESHNEEDED").getValue();
	       
	  	   if (refreshNeeded == 1) {
	  	        window.opener.refreshTables($eb.getField("REFRESHTABLE").getValue());
	  	   }
	  });
});

The parent window that opened the popup has this script attached:

Code: Select all

function refreshTables(refreshTable) {
	   if ( refreshTable == "HR_CALENDAR" ) {
	   	    var param=[parseInt($('#MonthSelect').val())-1,parseInt($('#YearSelect').val())];
	   	    
	        $eb.executeFunction("refreshCalendar",param,true);
	   } else {
	        $eb.executeFunction("refreshEbaseTables",refreshTable,true,false);
	   }	   
}

which in turn calls the server side function refreshEbaseTables() which calls fetchTable for the table name passed as a parameter.

This way, when you save a record in the popup window, the parent window is automatically refreshed with the latest data. This bug is causing this logic to fail in the popup window for the line that I highlighted above.

[Jon]

Segi,

We have a similar requirement in the Server Admin App. It pops up a new window to allow you to edit individual items e.g. database connections, then updates the original display if necessary. It does this using the following mechanism (you may be able to adapt this to your own requirement):

Each popup form has a page defined called RETURN_PAGE which contains no content but the following Javascript is added as HTML++ (this is an example from the database connection popup):

Code: Select all

<script type="text/javascript" language="javascript"><!-- 
var refresh = window.parent.$("#refreshDbcon");
if (refresh)
{
  refresh.trigger("click");
}
--></script>

When the user clicks Save on the popup this invokes a server side script to save the data and then issues form.gotoPage(pages.RETURNPAGE);

The parent form has a refresh icon which is an Image Control with id of refreshDbcon assigned in HTML Element properties, so the effect of doing this is to simulate a click of this icon which then refreshes the original display with the new or changed data from the popup.

Hope this makes sense to you and might prove useful. If you want to see more detail of how the Server Admin App popups work, switch your studio workspace to point to the shipped internal workspace directory. The page displaying a table of database connections is form ebaseAdmin, page DATABASE_CONNECTIONS. The popup edit page for a database connection is form ebaseDatabaseConnectionEdit.

Regarding your original problem, at the moment I have no idea whether this is a bug with our code or just the result of how the browsers work. If it is a bug, it won't be easy to fix. The easiest route is probably to find another way to achieve the same result.

Regards
Jon

[Segi]

Jon,

This is clearly a bug. $eb is broken on Chrome and only Chrome.

This is a very serious bug for anyone who relies on $eb in the client side and uses Chrome.

There is no other way to achieve the same result without being able to use $eb.

FYI: I compared the $eb object between a breakpoint and non breakpoint and they seem to be identical.