Inclusion of dojo compressed CLDR to address #95 and #101 #102
Conversation
The optimized build is missing the necessary CLDR nls files to support many locales. Adding these to fix locale support.
Adding the standard Esri favicon to prevent the 403 (Forbidden) error for https://ago-assistant.esri.com/favicon.ico that some users are seeing, such as in Esri#101.
|
Looks good. Did you test to verify this resolves the issue with en-au (and other) language settings? How did you know to grab those files specifically and where did you grab them? |
|
Both en-au and en-gb worked great in Firefox 42 and IE 11 (for IE 11 I needed to change my entire system location, keyboard language, etc. before IE would pick up and send a different locale). Chrome appears to not allow changing locales. I even changed my system location, keyboard language, etc. and Chrome still identified as the original locale. It looks like to test someone with a version of Chrome installed in a different locale would need to do the testing. For where I got the files: If you go into that and navigate to the "dojo" folder that is where the cldr folder is located. I just added the whole cldr folder, since it has a bunch of locales that wouldn't have worked either. The errors in #95 and #101 had paths ending in /dojo/cldr/nls/en-gb/gregorian.js and /dojo/cldr/nls/en-gb/gregorian.js which is referencing that missing cldr folder in the "dojo" folder of the app. By adding the cldr folder those missing files and all the files for the other locales are now there and when dojo reaches out at runtime to load the appropriate locale resources it can now find the correct file(s). The only difference in the cldr file that I committed from the one downloaded was that I went through and deleted all the ".uncompressed.js" versions of the files and left the ".js" versions. The uncompressed versions aren't necessary for a production app and they take up extra space. Let me know if you have any questions/changes. If anyone you know can test in Chrome or if you know of an approach to change locales in Chrome let me know. |
|
Great job. |
|
Thanks @lucksimo for checking. You were testing against my pull request? That strangely didn't work to actually change the locale in my Chrome. Can you please do something to confirm it changed the locale? Just hit control+shift+j or F12 to open the debugger in chrome. After opening it, can you go to the console and type: navigator.language Then can you let me know what it says? When I changed the language and input settings where you referenced, the language still unfortunately was reading en-us for me. Can you confirm if it reads au? If it does, can you then go to the network tab and refresh the page? Do you see a request in the list for a something with "gregorian" in the path and does that path also include "en" and "au"? Thanks! |
|
@nheminger |
|
@lucksimo |
|
I don't see this file in the NetWork traffic. I am not sure whether or not this will help: My work computer behaves differently. when I change the language from English (United Kingdom) to English (United States) the value of navigator.language will change from "en-GB" to "en-US" and vice versa. as I said before, the value doesn't change on my home computer regardless the language choice. Sorry for the contradictory information. I am puzzled as well... I believe this is something beyond my knowledge. |
|
@lucksimo Okay, thanks for checking that! So it sounds like your work computer is the one that is somehow actually updating the navigator locale. If the locale is changing, then you should see the extra url with "gregorian" listed in it. When you wrote that you do not see it, was that with the work computer or home computer? Thanks for checking all that. We'll get it figured out yet! 😄 At least we know it works great in Firefox and Internet Explorer so far. Hopefully we can confirm it works in Chrome as well! |
|
@shaunnicholson can you test in Firefox and @garys-esri can you test in IE so once we get those both tested we can know that #95 is good to go? Then if @lucksimo can test in the same browser on the same machine was having the issue for #101, then that will close out that one as well. If we can get those two individual ones tested, then I believe that will resolve things. @lucksimo, if you can confirm if there is a case where the fixes aren't working still, then I can try and look at fixing that case so we can get this one confirmed as tested. |
|
It resolved it in Firefox for me. I was never able to replicate in Chrome or IE. |
|
Great! I think the only unconfirmed part is the issue @lucksimo was having in chrome for #101. Hopefully we can get confirmation it works there now? |
|
Hi @nheminger I am using https://ago-assistant.esri.com/, I assume that's the correct url? Thanks |
|
I doubt that the changes have been pushed to https://ago-assistant.esri.com/ yet. I think you have to check out this pull request and run it on your own web server to test. (Is that true, @ecaldwell?) I will try to do that in a moment here. |
|
I checked it, and I get an error in IE with this pull request:
That happens on a call to I don't get that error in Chrome. When I click the login button in Chrome, I get a popup, but there I get an "Invalid redirect_uri" 400 error in the login popup instead of a login form. I get that with the main branch too, so that's probably just my ignorance in setting up the application to run from my web server. But that IE error seems like something specific to this pull request. |
|
What version of IE are you testing with? That sounds like a problem with one of the frameworks...probably bootstrap. |
|
@garys-esri That error occurs with IE 9 for me. What version did you test with? If you tested with IE 11 and you had the web debugger open, can you please check your emulation settings and make sure the debugger didn't kick you into IE 9 mode when you opened the debugger? I have seen this a lot where opening the IE debugger results in getting kicked into IE 9 mode. I think that error is related to the site not working in IE 9. @ecaldwell Do you have documentation on what versions are supported? I saw that error in IE 9 mode and I assumed that IE 9 is a pretty old browser at this point. Also, the error isn't related to my changes - it happens on the production site as well. |
|
I'm using IE 11. In the F12 developer tools, there's a menu with these options: Edge, 10, 9, 8, 7, 5. Edge is selected by default. If I switch it to 10 or 9, I get the same error of |
|
@garys-esri, Weird, hopefully we can get this figured out. "Edge" is edge support, which would be IE 11. Can you try turning off the web debugger and seeing if you still get the error? Turning on the debugger can throw it sometimes into weird modes. Also, is the IE 11 locked down by any enterprise policies? What error are you seeing in Chrome? Same one? What locale is your Chrome reading as? Thanks! |
|
@nheminger, it doesn't work in IE whether the debugger is on or off. I click the "Log in to get started" button but nothing happens. In Chrome, I get an "Invalid redirect_uri" 400 error in the login popup instead of a login form, as I mentioned above. |
|
@garys-esri, thanks for checking that. For IE, what specific version (like the full number from "about") are you using and on what OS? Is it locked down with any policies? For Chrome, can you take a screenshot of the network tab's output? Also, do you have a web proxy being used on your system? Can you send the request/response screenshot for that one specifically from your network tab? |
|
@nheminger, it's IE 11.0.9600.18053 on Windows 8.1 64-bit. To my knowledge, there aren't any special policies.
Here's the Chrome network tab for the main page:
Here's the Chrome network tab for the login popup:
To my knowledge, I don't have a "web proxy." I'm not running Fiddler if that's what you mean. |
|
Thanks to @nheminger for stopping by to look at the issue. The Chrome issue was my fault; I didn't change the app ID and run But the IE issue remains. I am now checking out various commits of ago-assistant to see where the IE issue was introduced. So far I know that v2.0.0 works and v2.2.5 does not. I will try one release at a time to discover which commit introduced this error. |
|
v2.0.0 works, and v2.1.12 does not, in IE. I will try to narrow it down to a specific commit if I can. |
|
8cfe27c works, but 7617116 doesn't, in IE. It appears that this issue was introduced in 7617116. The issues that @nheminger means to fix with this pull request appear to be fixed, based on my experience in Chrome. Therefore, I recommend that this pull request be merged and that I create a new issue for the IE behavior introduced in 7617116. |
|
P.S. what I mean about Chrome is that I switched my Chrome language to en-gb and ArcGIS Online Assistant works. It pulls gregorian.js from en-gb as it should. |
|
I logged the IE issue as #108. I think this pull request is ready for merging. |
|
Nice work...thanks for all the testing on this one! |
The optimized build is missing the necessary CLDR nls files to support many locales. This appears to cause #95 and #101. Adding the compressed version of these from the Dojo download site. This should resolve the locale errors that prevent the site from loading/working.
Eventually it may be possible to create a more optimized build using dojo.cldr. However, inclusion of these files only increases the size of the app by a small amount (~1.28MB). Additionally the locales that were supported previously will still download the same number/size of files so load time isn't affected. The locales that broke the site before will now successfully be able to download the few extra files needed to allow the page to load/work.