Sub-file Widget issue on Chrome in a HATS Modernization Project built via Default Rendering


In a recent assignment we encountered a strange issue. The HATS application built using Default Rendering was working absolutely fine on Internet Explorer and Mozilla Firefox and presumably on other browsers, but not on Chrome. In Chrome the sub-file widget was not loading at all and the content that should be appearing at the bottom was being displayed within the table making readability very difficult. Considering it was default rendering, we had only one file to play with and were needed to come up with a general global fix.


We were short on time for delivery and had little time to perform R&D to get this fixed. However, with the brilliant team members, we were sure that we will make it like always.

So we identified a pattern on the screens and came across following scenarios

  1. Screen Sizes: There were multiple screen sizes on the Green Screen.
  2. Text identification (Markers): There were multiple text patterns on green screen to identify a sub-file widget (table).

Considering both the scenarios, we created a solution in which all the variations of Screen Sizes and possible positions of Text Markers (multiple row numbers) were focused in the eventual solution. We defined a global variable in which we kept Browser identifier as soon as user session gets started. The variable was global so its scope was across the application and it could be used anywhere. Now, based on the screen sized and possible positions of the Marker text, we programmed specifically to display the table and move the data at appropriate places and displaying sub-file widgets wherever it was required.

Now, the application is working fine across the board in all the browsers and most importantly in Chrome. The solution was developed very quickly and I am proud of my team to coming up with this innovative, out of box solution with little time to analyze and perform R&D.

Leave a Reply