Just to update those who use Windows IE11 or have gone to Windows 10 and Edge, there is one single feature on the new page that is not working.
If you try to download your call details to a CSV file (for use in a spreadsheet, although you can read it in a text file or word processor too, but is intended for spreadsheets, you will run into an error message about not being able to open in a frame or a new page.
You will then get an Appache Tomcat error being pushed back from the server related to a lack of security token.
I had a discussion with a tech support person about it and was advised that it is an Internet explorer 11 issues and related to not fully implemented hotfixes. If this is the case, then their team will have to be in deep discussion with Microsoft technical support to find a solution. I do not recommend you follow through on the request to uninstall 11 and reinstall it. I have done it, and an uninstall will actually take you back to 9, then you go back to 10, then back to 11 and you are at high risk of creating more problems and as far as I know, edge cannot be uninstalled at this point. It is highly integrated into Windows 10.
It will take time to fix if it does lie in hotfixes and the basic programming of 11 and edge, but if you do want to download the spreadsheet of the details, then go to another browser.
Good luck. Everything else about the online billing seems to have been dealt with, except for one strange glitch. I saw my bill online two days ago, the CSR I was on the phone with, originally couldn't see it, and then was able to, and the email informing me that it was available arrived two days later. Would have thought I would get the email at the same time I could see it, not two days later - go figure!
Tick one more headache off my list. I don't care about the Windows broswer issue - I don't use it anyway - I was just trying to be helpful for those who do use it and keeping it in the forefront. What am I going to talk about if everything gets fixed. Guess I can post how happy I am my services, but we still have a ways to go before I can fully say that. Here's to getting the rest of the issues cleaned up and having happy customers.
Interesting.. just took alook.
While i havent been fully paying attention to the URL for the myrogers.. looks like there may be some changes that were done which may have caused it?
I dont recall the URL used to be
When you try to go to the download usage link on IE11.. the URL is only
Vs on Chrome, etc.. the URL on the link is a much longer string, with an account number, etc in it.
My guess is something in IE is malforming the code that is supplying the URL for the link.
Good catch on the question of the unformed complete url in Windows browsers on the download details event versus the Chrome event which returns the complete url. But remember something, Explorer just follows the code that is pushed to it from the server end. Explorer on its own is dumb - you have to tell it to do something, so you have to look to the coding. I am going to guess that since everything else was dealt with, and this is still the same error from back when this all started that is still unsolvable.
url returned by both IE11 and Edge from Windows 10 is https://www.rogers.com/web/totes/#/viewbill and same in Chrome
When I hover over the download details link in Windows I get https://www.rogers.com/web/totes/ - you are right, the rest of the detail is not there. I won't put in the detail I saw in Chrome, because it includes my account number and other personal details.
But I inspected the HTML code for the whole page, and the code to bring back the CSV is in both pages - Chrome and Windows browsers, but something is failing in the code. My eyes aren't good enough to debug this line by line. Wish I could, but although I still know the basics of HTML, I just can't work this line by line. If I still had debugging tools, and the ability to isolate the events, I could probably find it. but the following message may guide the programmers. It is from the server side. I leave it to the programmers who have the tools to run debug routines, and to do side by side comparisons of the code and specific events in the code to figure out why the whole url is not being formed. Good call on that, the issue is why it is not being formed and I no longer have testing tools available to me to do that level of debugging anymore. I love debugging, but this one is going to take Appache server staff, HTML staff, Browser staff, and possible tech support from Microsoft and related software and database developers on your side. Hope it is an easy one and just got missed in all the other work.
Apache Tomcat/7.0.53 - Error report
HTTP Status 500 - EncryptedToken header not found in request.
type Exception report
message EncryptedToken header not found in request.
description The server encountered an internal error that prevented it from fulfilling this request.
org.springframework.security.web.authentication.preauth.PreAuthenticatedCredentialsNotFoundException: EncryptedToken header not found in request. com.britebill.rogers.rest.ext.security.RogersRequestHeaderAuthenticationFilter.getPreAuthenticatedPrincipal(RogersRequestHeaderAuthenticationFilter.java:41) org.springframework.security.web.authentication.preauth.AbstractPreAuthenticatedProcessingFilter.doAuthenticate(AbstractPreAuthenticatedProcessingFilter.java:116) org.springframework.security.web.authentication.preauth.AbstractPreAuthenticatedProcessingFilter.doFilter(AbstractPreAuthenticatedProcessingFilter.java:104) org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:110) org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:50) org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107) org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:87) org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:342) org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:192) org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:160) org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:344) org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:261) org.apache.catalina.filters.CorsFilter.handleNonCORS(CorsFilter.java:439) org.apache.catalina.filters.CorsFilter.doFilter(CorsFilter.java:178)
note The full stack trace of the root cause is available in the Apache Tomcat/7.0.53 logs.
For some reason, the details of the account number and where to get the data is not being populated. All searches I did on this set of errors, suggest that it is typically on the server side.
Occam's razor, "the simplest explanation is usually the correct one" is often correct, so look there first, but sometimes unfortunately it is not.
Good luck to programmers and testers.
My only point was to let the users of IE11, and Edge and IE11 in Windows 10 know about this issue. For now you have to go to Chrome, but let's remember that is merely a work around.