We are switching from IE to Edge Chromium or Chrome (to be d...

[Ian Dalton]

We are switching from IE to Edge Chromium or Chrome (to be decided) soon but having done some basic tests we find that Portals have changed the font for all out menu options down the left-hand side and dont align properly at all. Has anyone else had this We believe we may have to upgrade from 8.1.05M to 8.2.07 to resolve this but that is a major project in itself. For the moment I was wondering if there is a workaround

[Ian Dalton]

Here is a doc with the different fontsPortal Using Chrome.docx (331.7 KB)

[Warren Hinchliffe]

Have you checked Developer tools to see if Chrome is not loading some files like CSS or Fonts

[Toby Mills]

Hi Ian

I opened a case with IBI about geting 8105m to play nicer with Chrome. Unfortunately I didnt have any luck. In general, the answer is that the current version of Chrome wasnt even around back when 8105m was last updated, so IBI wont support it.

Switch to a newer version to get it to work.

I did dig in and find some clues that I couldnt really put to use, but Ill pass this on here.

I bet your BIP loads up for you if you do the following: Start the Chrome debugger (f12) and then on the little gear (Settings), look for Network. Check the box for Disable Cache.

 

image.png988608 116 KB

 

Obviously this is not a good solution for your users, but maybe for the right programmer person, itll give a clue as to how to make the compatibility better.

What we did, we converted the V3 BIPs to V4 (collaborative) BIPs using the utility for this purpose under the utilities folder. And were running 8207 now. The 8207 environment is not prod yet and I still get plenty of complaints from Chrome users.

If you have a web programmer who can figure out how to make caching not happen, we can bury the updated code into existing 8105m code and the problem would be fixed. I cant do that though - not smart enough:).

Also IBI had a slightly newer version of 8105m than what we have installed. Maybe yours will work better or different

Let me know if forcing the nocache makes it work for you. Just curious. We see the same problems here - sometimes the stylesheet loads right and sometimes not.

[Ian Dalton]

Thanks Waz and Toby for your suggestions - I am not in until Wed. but will try them out then. Assume there is an equivalent Disable Cache for Edge too

[Ian Dalton]

I decided I couldnt wait until Wed. so logged on and discovered that first time in was ok and then subsequent times font was corrupted. This ties in with your cache theory Toby. I then disabled cache and it worked fine but this is only when when in Developer Mode (F12). Obviously we need a Chrome setting in out HTML code to do this all the time as you have suggested. I will keep you posted. The utility you mentioned seems to be a good start - how do you invoke it

[Toby Mills]

Hi Ian

Im afraid the collaborative portal conversion isnt available in 8105m.

All I see down there is a bipv3util.bat that was for converting BIPs made in 8.0x I think.

The utilities are under drive:ibiWebFOCUS81utilities.

The only way I can think of right now to solve this would be to trace all the activity between 8105m and 8207 (for me anyway) and for me to look at whats different. I thought I had to convert everything to collaborative (v4) portals, but really, I did a test a while back and would swear chrome was working okay for me even though I hadnt done the conversion.

So maybe just comparing Fiddler traces from both 8105m and 8207 using the same V3 portal would show what is being done differently. If we could find that, we could try to patch things inside the 8105m webapp.

Feel free to open a case and ask about it - maybe youll have better luck than I did. My TSR has only been messing with WebFOCUS for a year or so, so hes not going to know all the insides of the product. If Lloyds is premium support, you might get a better answer.

[Alban Hertroys]

If you look at the network tab in Chromes developer tools, do you see any HTTP 404 or 3xx errors there It looks to me like some style sheets failed to load, either because they couldnt be located or because they couldnt be accessed.

Another possibility is some syntax errors in some of the style sheets. Those probably get listed in the Console (also Dev tools), but not by default I think - perhaps Verbose level will show those

I strongly doubt that caching plays a role here, unless the BI portal modifies the CSS dynamically from one load to the next I cant imagine how that would be useful (or work in IE, which has far worse caching behaviour).

[Ian Dalton]

Hi Alban, thanks for you suggestions - I will take a look in the developer tools to see whether it is down to stylesheets failing to load. The reason I believe it is a cache issue is that it does load correctly first time in, but then after that it is is corrupted. If I then clear cache and retry all ok first time again but then corruptions after that. I will explore both what you, Toby and Waz have suggested re stylesheets etc.

[Toby Mills]

Great ideas from Alban. Ian - keep us all posted if you find something that might fix things. Ive tried to figure it out but Im just not educated enough to help in this area.

I hope to have all our people off 8105m by the end of March (on to 8207).

Toby

[Alban Hertroys]

The only way that I can see caching playing a role here is if the cached files get immediately corrupted somehow. That could be due to a full local file-system, but I would expect youd then have lots of other problems too.

Usually, caching problems prevent changes from propagating to the client apart from the first time, they wouldnt behave differently after that.

What could be going on is that there is a timing issue in Javascript code, that does not happen when loading resources takes longer (the uncached situation), but does when some of the resources can be loaded from cache.

Ive seen things like that happen when Javascript code is executed from an externally loaded script file, but execution doesnt wait for the (HTML) document to be loaded. If that code references HTML elements within the document, those may not exist yet at execution time. You would probably see Javascript errors on the Console about that.

To solve that, you have to postpone execution of such code until the appropriate event has happened. This could be an onload handler on the document, or it could be executed from the WebFOCUS specific onInitialUpdate function that gets called when WebFOCUS has finished with the basics (which, AFAIK, gets called from the document onload handler, so this is a later stage). If that happens in core ibi code though I suppose you could edit those files in ibi_html, but its probably saver to open a PR in that case.

[Toby Mills]

Thats an interesting idea Alban.

I see this warning in the chrome debugger - I didnt think much about it, but since you brought up timing, and this warning is about something synchronous (which reminds me of timing), I thought Id put a picture up for you.

 

image.png1251713 44.4 KB

 

This was right after logging in to 8105m using Chrome.

Looks like it refers to an event similar to the ones you mentioned - in this case its onreadystatechange

Http.onreadystatechange=this.__onreadystatechange;

I also think its a javascript thing, but I dont have the background youve got.

[Alban Hertroys]

With the onInitialUpdate function I was referring to the stub-function that gets created on the Javascript tab in App/Dev Studios HTML Composer.

Im a bit surprised I cant seem to find it documented in the WF manuals, Im sure it is. Related documentation can be found here.

The log message you quote is actually a different issue; Javascript can perform HTTP requests. It can either do that asynchronously (the default), sending a bunch of requests at once and then dealing with the responses as they come in - or synchronously, sending one at a time, waiting for the response, sending the next, etc.

Obviously, with a lot of requests like that going on, sending them sync vs. async will take more time, which I think is what they mean with detrimental effects to the end users experience.

Ibi probably chose to perform their requests synchronously due to some issues (corner-cases I suspect), but you really rather dont, hence the warning.

[Ian Dalton]

I think all these suggestions are excellent but I may need some assistance with how to interpret these correctly. I will look into further next week and ley you both know.