CDR Tickets

DLL on DEV has been modified to use the default browser instead of always using Internet Explorer. Please test.

Works for me and I was very surprised about it because I expected an error message in IE. :-)

We'd like to back out this change. It won't be in the Darwin release.

Hi Bob, just a reminder that we decided to back out this change from Darwin.

Change backed out on DEV as requested.

We decided to re-open this ticket for future consideration.

Microsoft recently announced that Internet Explorer will be retired a little over a year from now.

I can think of four courses of action available to us.

1. Continue to use IE, in the hope that Microsoft won't really disable it completely and it won't be a security risk without security updates.

2. Switch to Microsoft Edge.

3. Pick another browser, require that it be installed on all users' machines, and use that browser.

4. Use the browser which the user has configured as the machine's default browser.

I don't recommend  the first option (too risky) and the users rejected the last option when we tried it, on the grounds that it introduced too much variability. That would leave options #2 (which has the advantage that since the CDR client machines are all running Windows 10 — the only operating system on which XMetaL runs — they are therefore guaranteed to have Microsoft Edge installed) and #3 (which has the advantage that at least one of those browsers — Google Chrome — is more popular, and in the views of at least some of the users, produces the best printed output).

I'm poking around looking at a few reports using Edge and I found one that looks different compared to the version in IE. I wanted to switch to viewing this in IE mode within Edge but it appears that the availability of the IE mode is handled via group policy and our installation of Edge (currently) does not allow IE mode to be used.

Here is the documentation I found regarding IE group policy:  https://docs.microsoft.com/en-us/deployedge/edge-ie-mode-policies

I am working with Bill Cockayne at CBIIT to figure out why our installations of Edge doesn't provide the ability for a page to "Reload in IE mode".

In the meantime, I've created two sample documents, one run in IE and copied to Word and one run in Edge and copied to Word.  It appears to me that the Edge version presents three major problems:

• The table width is not limited to the page width

• The font size is inconsistent - 12pt inside paragraphs, 13.5pt inside lists

• The font type is inconsistent - Arial and Times New Roman for table headings and content

Bill and I are continuing to find out more about this IE mode in Edge.  There are many posts on the internet commenting on this mode being available.  However, there are just as many comments indicating that the option suddenly disappeared or is only available when  Edge is run with a specific command line option.  Neither I nor Bill have been able to actually see this option.  I suggested to just ask Microsoft assuming they should know but Bill informed me that they don't have a service contract with Microsoft.

I'm getting the feeling that this issue is not worth pursuing any further.  I'm trying to identify "if" it's possible to use the IE mode.  If it's just as difficult to setup each user's computer it's going to be a long battle with CBIIT.

Having said that, I did make some progress.  The tables copied to Word with the table width too wide for the table is a result of a table property that is set to use a table width of 9.24 inches.  If we turn off this property, maybe via a Word macro, the table displays nicely.  I'm hoping it's possible to change or disable this table width property globally.

For testing the various reports in different browsers, it will be good to have a spreadsheet of all CDR reports as a guide to make sure we have looked at all the major reports. I am sure we have one of these spreadsheets somewhere but a current copy will be much better.

You are probably the best person to compile such a list (in collaboration with Robin and Victoria). You're in the best position to know what you consider "major" and it's quite possible that you'll want to list multiple flavors of individual reports separately, when the options on the form for requesting the report can result in completely different layouts, depending on which options are chosen for a specific request.

What I am looking for is a query for a list of all the CDR Reports we have. We will use this list to identify all the reports we need to test instead of doing that manually. I am sure we can come up with a list manually but having a complete list of all the CDR reports will be a good start, unless that is not possible.

What I can create would be a list of what's on the CDR admin menus, but

1. that would include things which aren't reports

2. it wouldn't include reports generated by other means (scheduler, EBMS, one-off reports generated by the developers, etc.)

3. it wouldn't identify menu items which create completely different layouts depending on which options are selected

Thanks! That is exactly what we will need. We can remove all the menu items that are not reports and manually include other reports/utilities or tools that are not on the menu or that were not included in the spreadsheet.

https://cdr.cancer.gov/cgi-bin/cdr/CdrMenus.py

Takes a couple of minutes.

Looks good. Thanks!

I have attached the spreadsheet we will use to identify the major reports for testing the browsers. We have a meeting scheduled for 7/19/21 to talk about this. 

Browser Testing for CDR Reports.xlsx

Testing is still ongoing but I wanted to share the results of a poll we took to see which browser had the most fans 🙂.

Circling back to the Internet Explorer mode in Edge:

The latest version of Edge does now include the option we were looking for earlier to use the IE compatibility mode within Edge.  I tested this out and it is working as expected.  Tables, for instance, that were cut off after pasting the HTML into MS-Word are now displaying as before.

Unfortunately, in order to display a page in IE compatibility mode one must enter the URL into a "Pages list".  All pages from this list will be displayed in IE mode.  Everything else is displayed in Edge.  According to the Microsoft documentation, it is not possible to enter pages using wildcards, so every time a page must be displayed in IE mode it must first be added to that list.  This can only be used as a work-around in the most desperate case but cannot be used as a workable solution because the URL changes with each document/QC report.

Adding the link to the Microsoft documentation

https://docs.microsoft.com/en-us/deployedge/edge-ie-mode-site-list-manager

As discussed with ~bkline, my understanding of having to enter the full URL into the IE mode list to trigger the IE compatibility mode assumed we had to enter all parameters submitted but that is not true.  Entering the URL https://cdr-dev.cancer.gov/cgi-bin/cdr/QCforWord.py is sufficient to display all QC reports in IE compatibility mode.  Obviously, this will cause all QC reports to be displayed in IE mode and the user might only want to add the URL when it is necessary to do so.

There is only one little drawback with this approach:  The URLs entered into the IE mode list are automatically removed after 30 days.

Our testing for the default CDR browser is almost done with no clear winner but a slight urge for Chrome. Most users do not have a strong preference for any one of the major browsers as there are very minor noticeable differences between them as far as the HTML display goes. The only noticeable difference most users reported had to do with font size display in Chrome, which appears bigger and more appealing to users than in Edge or Firefox.

As expected, the major issue we faced for all three major browsers is copying from the HTML page into Word. For example, copying content from a QC report (HTML) that includes a table into Word has different undesirable results for the different browsers we tested. At least for tables, IE displayed it much better than any of the other 3 major browsers displayed them.

This is how Chrome and Edge display a table from the STS summary. Part of the table remains hidden and may take

some time to troubleshoot before you can get the full table to display.

Firefox fails to include table borders by default.

Copying content from HTML to Word (using any of the three major browsers) has varying results. I researched what other users on the web have been handling copying html into Word since Microsoft removed the Edit in Word tool from IE, and it looks like the most popular workaround, which appears to work consistently for all the major browsers is to (for Chrome)

1. While in the HTML report page, right-click to Open/View the Source Page

2. Right-Click again to Save the Source Page AS HTML or Webpage

3. Launch MS Word and open a blank Word document

4. Go to File > Open in MS Word and navigate to the saved HTML page in step 2

5. Open the file in Word

This approach appears to work well with Word displaying the pages with little to no differences. If we adopt this approach of “converting” to Word, it will help to know if it is possible to have button or icon the CDR (toolbar for example) that could convert to Word (or Excel) instead of users going through the steps above each time we want to see the document in Word.

Links within content that has been copied to Word generally work don’t but for the most part that is to be expected.

~oseipokuw Could you check a sampling of the CIAT user machines and find out the location of chrome.exe on those machines? Basically,

1. Find the shortcut

2. Right-click on the shortcut

3. Select Properties

4. Get the full path for the executable file from the Target box

Thanks.

This is from 5 different laptops and they appear to be in the same location. 

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"
"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"

Do you want me to modify the DLL on DEV so that it launches Chrome on that tier, so we can test that the mechanism works properly and reliably (the method is completely different from launching Internet Explorer, which — as the antitrust courts determined — was in bed with the operating system in ways that none of the other browsers had access to)?

The DLL on CDR DEV has been modified as we decided in Thursday's meeting to bring up pages in Chrome. This works fine if Chrome is already running on the user's machine, but if the DLL has to start Chrome XMetaL becomes unresponsive until Chrome is closed. I'm doing some research and experimentation to find out if there's a way to avoid this behavior. If there isn't we'll have to decide between

1. trying another browser (Edge?)

2. telling users to make sure Chrome is already running

3. using the user's registered preferred browser

4. telling the users they have to close Chrome before they can use XMetaL again if Chrome hadn't already been running when it was launched

Not the most appealing set of options, I admit. 😛 If anyone thinks of a better option, I'm all ears.

I found a way to suppress the hanging of XMetaL, so we don't have to make that Hobbesian choice. 😃

We have started experiencing problems with IE on PROD and the other tiers. The modal links for the glossary terms and reference links no longer work in IE (click on the links and nothing happens). However, the links work in Chrome and Edge. Looks like it is time to make a decision on the next default browser and get rid of IE before we run into other problems.

Implemented switch to Chrome browser and installed on DEV for OHM release.

A user was getting the following error message when running QC reports on DEV 

I checked her (x86) folder and didn't find the Google Chrome folder.  It turned out that the Chrome folders was in the Programs folder instead of the Programs (x86) folder. 

C:\Program Files\Google\Chrome\Application\chrome.exe

So, somehow, CBIIT is not consistently installing Chrome in the same location for all users. 

We got the helpdesk to copy the Chrome folder into the x86 folder and that fixed the problem but I am wondering if it is possible to configure CDR to look for the files both places? That is, if it is not found in the expected location.

The logic is already implemented to look in both of those locations plus two others. The next time this happens, please defer taking any actions until we have had a chance to figure out what is causing the problem. In the meantime, please report what the output is for the following commands (run in a command console window) on this user's machine. This won't be as reliable a set of information as it would have been before CBIIT touched the machine after the incident, but it's still possible it might reveal some clues.

echo %ProgramFiles%
echo %ProgramFiles(x86)%
echo %APPDATA%
echo %LOCALAPPDATA%

Here is the output from the echo commands

C:\Program Files  

C:\Program Files (x86)  

C:\Users\yun3\AppData\Roaming

C:\Users\yun3\AppData\Local

I found a couple more places where IE is being launched. Will replace them with Chrome.

I have removed/replaced all remaining code which launched IE. Now the only browser used is Chrome. I'm leaving this ticket in the "To Do" column where William moved it. I'll let him decide if/when enough time has passed without any failures launching Chrome to move it to a later column.

Moving this to DEV verified since there have not been any recent failures on DEV. Thanks!

Verified on QA. Thanks!

Is the program looking for the Chrome is this folder too?

"C:\Program Files\Google\Chrome\Application\chrome.exe"

CBIIT is not consistent with where Chrome files are installed so at least two of us are getting the unable to find Chrome Browser error. I assume the only option available is to file a ticket to install it in 

"C:\Program Files (x86)\Google\Chrome\Application\chrome.exe"

I'll check. Did this work on all the other tiers?

Don't have CBIIT do anything until we can investigate to find out exactly why it's failing.

Here's what the software does. For each of the following environment variables:

ProgramFiles(x86)
ProgramFiles
APPDATA
LOCALAPPDATA

the software retrieves the value of the environment variable and appends

\Google\Chrome\Application\chrome.exe

to that location and checks to see whether a file with that constructed path exists. If it can't find chrome.exe at any of those four locations, it reports the error.

So our first troubleshooting step will be to examine the contents of those four environment variables on the user's machine, as follows:

echo %ProgramFiles(x86)%
echo %ProgramFiles%
echo %APPDATA%
echo %LOCALAPPDATA%

Let's set up screen shares where we can do that together on each of the machines which is failing.

Not for the currently affected computers. One is a recent replacement and the other is a loaner.

Let's start with a screen share session for the replacement computer. Do you need to start that?

We were able to track down the problem to the fact that on some of the machines the %ProgramFiles% environment variable is set to the wrong value (the same value as the %ProgramFiles(x86)% environment variable). ~oseipokuw will file a ticket in Pauling to have a fifth environment variable tried (%ProgramW6432%). In the meantime, he will ask CBIIT to install Chrome in the \Program Files (x86) directory for those machines where the environment variables are pointing to the wrong directories.