Details
-
Bug
-
Status: Resolved
-
Major
-
Resolution: Fixed
-
1.7.05
-
None
-
None
-
Mac OS X 10.10.5
-
Help
-
i2b2 Web Client
-
Firefox, Safari
Description
In our production i2b2 deployment, clicking the Help link does the following:
1) A panel appears containing the Help contents
2) It almost immediately is replaced by two 404 errors, one where the table of contents is supposed to be, and another where the actual content is supposed to be. Looking at the browser logs, the URLs for the two iframes are "/webclient/help/toc.html" and "/webclient/help/content.html", which are wrong in our environment.
In our QA i2b2 deployment, Help works fine.
Looking through the web client source code, the Help iframes are loaded in three places:
1) the web client main page (default.htm), in which the URLs for the iframes are "help/toc.html" and "help/content.html"
2) twice in js-i2b2/hive/help_viewer.js. This file, when the user clicks Help, loads "help/default.htm", which separately attempts to create the frames using the (wrong) URLs I see in my browser log in production.
Furthermore, looking at the network traffic through my browser, in my QA environment, the traffic on clicking the Help link is as follows:
1) Finds help/toc.html and help/content.html in the browser cache and loads them
2) Attempts to load /webclient/help/toc.html and /webclient/help/content.html, which never return for some reason
In my production environment, the network traffic is as follows:
1) Attempts to load /webclient/help/toc.html and /webclient/help/content.html, which cannot be found
2) A canceled second attempt at loading /webclient/help/toc.html and /webclient/help/content.html
My hypothesis is that, in QA, the browser happens to find the help contents in the browser cache, so reloading the wrong URLs is never attempted. The only different between QA and prod is the domain name; otherwise, the URLs are all identical. I don't know why the cached version isn't picked up in production, but I'm seeing this behavior consistently in Safari and Firefox. Regardless, I believe that relying on browser caching to avoid going to a wrong URL is going to be error-prone.
I tried commenting out the Ajax.Updater lines in js-i2b2/hive/help_viewer.js, and Help now works correctly in both production and QA. I believe those lines can be removed.
1) A panel appears containing the Help contents
2) It almost immediately is replaced by two 404 errors, one where the table of contents is supposed to be, and another where the actual content is supposed to be. Looking at the browser logs, the URLs for the two iframes are "/webclient/help/toc.html" and "/webclient/help/content.html", which are wrong in our environment.
In our QA i2b2 deployment, Help works fine.
Looking through the web client source code, the Help iframes are loaded in three places:
1) the web client main page (default.htm), in which the URLs for the iframes are "help/toc.html" and "help/content.html"
2) twice in js-i2b2/hive/help_viewer.js. This file, when the user clicks Help, loads "help/default.htm", which separately attempts to create the frames using the (wrong) URLs I see in my browser log in production.
Furthermore, looking at the network traffic through my browser, in my QA environment, the traffic on clicking the Help link is as follows:
1) Finds help/toc.html and help/content.html in the browser cache and loads them
2) Attempts to load /webclient/help/toc.html and /webclient/help/content.html, which never return for some reason
In my production environment, the network traffic is as follows:
1) Attempts to load /webclient/help/toc.html and /webclient/help/content.html, which cannot be found
2) A canceled second attempt at loading /webclient/help/toc.html and /webclient/help/content.html
My hypothesis is that, in QA, the browser happens to find the help contents in the browser cache, so reloading the wrong URLs is never attempted. The only different between QA and prod is the domain name; otherwise, the URLs are all identical. I don't know why the cached version isn't picked up in production, but I'm seeing this behavior consistently in Safari and Firefox. Regardless, I believe that relying on browser caching to avoid going to a wrong URL is going to be error-prone.
I tried commenting out the Ajax.Updater lines in js-i2b2/hive/help_viewer.js, and Help now works correctly in both production and QA. I believe those lines can be removed.