As explained on the main page, the testcases were checked on 5 browsers - and 3 of them caused problems. None of these are directly related to what I was investigating but mainly "got in the way" of completing the main task.
MS Edge Design Problem
<!-- saved from url=(0042)https://tools.ceit.uq.edu.au/temperature/# -->
This is pretty weird since this line has been present in all versions of my application for the last 2 years without any problems (that I know of). However, I only tested the application in MS Edge via the web (or a local web server) and never directly from a local disk drive. (Yes, it always works correctly when opened that way.) When tested locally, it had the same problem!!!
Besides removing the line (ok for the test file, but not in the application), the following "fixed" the problem.
This was especially difficult to trouble shoot because
MS IE11 Design Problem
After that, I would modify the html file's encoding (via notepad) and press F5 to reload the page. When the new encoding was ANSI, the first 2 canvases - Local HTML and ANSI js - and the text field displayed black diamonds - failure.
Repeated F5 and ctrl-F5 had no effect - the failure was still there.
When I closed IE, reopened it, and entered the url, it displayed all 3 Degree Symbols. Once the Degree Symbols were displayed, pressing refresh produced no change.
Once there was a failure, simply adding a space to the end of the url (in the address bar) and pressing enter (or clicking the arrow) caused the page to display correctly.
Inconsistent results like this are never acceptable! - Another Microsoft design problem - flaky software.
Based on the data, I think IE has a cache problem - it doesn't check the encoding type when refreshing the page. However, this only matters to people debugging a specific type of problem and is unlikely to be an issue for regular users.
To recreate this
Chrome 63 Design Problem
Text files encoded as UTF-8 are marked by placing 3 special characters at the beginning of the file. As a part of the process of developing the test page, and documenting what I learned, I place them in one of the gray comment boxes - similar to the one below. (The characters were copied from examdiff which makes them visible.) At that time, the testcases were also located in this file - they are now in separate files - and I tested various scenarios by modifying the encoding of this file - sometimes ANSI, other times UTF-8. As expected, since these 3 characters were no where near the beginning of the file, they were ignored by all the test browsers .. except Chrome 63! I have provided a separate test page so that you can see the problem yourself.
ï »¿/* At beginning of the file - this has an extra space
|Image of the table on the test page showing the failure in Chrome 63 when accessed locally
Browser consistency is wonderful - too bad it doesn't exist!
I want to make it clear that this is a very specific problem that is not likely to show up in any web page except one trying to determine the cause of a problem (like this one). It is included here mainly for completeness and because it took a long time to figure out what was going on.
Just to confuse everyone (including me), after I uploaded these files to the web and tried them from there, there is no error - everything works as it should. Apparently, the problem only exists when displaying files from a local file store, not from the web.