In the recent released update, the update doesn’t work.[see screenshot - console output]
I have tested it on portable as well as desktop versions, same difference.
I have attached a debugger and I am getting the following errors thrown which “COULD” explain what’s going on but not sure short of rebuilding from source and finding out, I don’t have the time for that right this minute.
Resource interpreted as Script but transferred with MIME type text/plain: "chrome://resources/js/cr.js". chrome/:79
Resource interpreted as Script but transferred with MIME type text/plain: "chrome://resources/js/cr/ui/focus_manager.js". chrome/:80
Resource interpreted as Script but transferred with MIME type text/plain: "chrome://resources/js/load_time_data.js". chrome/:81
Resource interpreted as Script but transferred with MIME type text/plain: "chrome://resources/js/util.js". chrome/:82
Resource interpreted as Script but transferred with MIME type text/plain: "chrome://resources/js/i18n_template2.js". chrome/:106
Resource interpreted as Script but transferred with MIME type text/plain: "chrome://resources/js/cr.js". uber-frame/:70
Resource interpreted as Script but transferred with MIME type text/plain: "chrome://resources/js/cr/ui/focus_manager.js". uber-frame/:71
Resource interpreted as Script but transferred with MIME type text/plain: "chrome://resources/js/load_time_data.js". uber-frame/:72
Resource interpreted as Script but transferred with MIME type text/plain: "chrome://resources/js/i18n_template2.js". uber-frame/:99
Resource interpreted as Script but transferred with MIME type text/plain: "chrome://resources/js/util.js". help-frame/:345
Resource interpreted as Script but transferred with MIME type text/plain: "chrome://resources/js/cr/ui.js". help-frame/:346
Another issue, Extensions don’t update in developer mode or automatically either. [no screenshot - see console error]
Digging a little deeper reveals this:
Uncaught TypeError: Object function BrowserOptions() {
OptionsPage.call(this, 'settings', loadTimeData.getString('settingsTitle'),
'settings');
} has no method 'removeMessageCenterOption'
(anonymous function)
Uncaught TypeError: Cannot read property 'parentNode' of null options_bundle.js:7096
ContentSettings.setOTRExceptions options_bundle.js:7096
(anonymous function)
That’s all I have right now, if there is anything further needed, I would be happy to provide.
NOTE: This issue DID NOT occur prior to this new version.
We will need more details in order to investigate the update issue. Please add a complete bug report as described in this thread.
Also, please add the “dragon_updater.exe.log” file from %windir%\Temp\ComodoLogsFolder.
The extension update issue is not related to the browser updates. We will provide a fix with the next release.
I will get that to you, as you can see in the screenshot, it just won’t check for updates. I wasn’t sure if it was related to the extension issue or not but since they happened at the same time, it was a natural assumptions until I can find out more. I know how to submit a bug report, don’t need the link and have already read it. If I have something, you have it, so if I didn’t include it, then it doesn’t exist. Case in point, no such thing as a ComodoLogsFolder and NO dragon_updater.exe.log either, so any other ideas? I don’t want this to end up like the search for Hoffa, wouldn’t help
The extension update issue is not related to the browser updates. We will provide a fix with the next release.Thank you.
Good to know, but what’s the problem there? I mean unless you are planning a next release NOW, in the meantime extensions are not updating and that’s an issue for me and I assume others given that I am a developer and tester, so I can’t work without it at least updating by force when I click the button. Manually updating by going to the extension and reinstalling it, is just annoying. So what is the problem that is causing it, that is being fixed in the next release, more disclosure and transparency would be nice. Thanks.
To further the investigation I’ll share what I was able to make out from the information you provided so far. It is true that the logs you provided show there is an issue, but we cannot address it unless we find it’s cause.
The logs suggest that there is an issue with the server communication. Either the server is not running (which isn’t the case), the response from the server is not received in the format expected by Dragon (or is not interpreted correctly by Dragon) or the browser cannot access the server for another reason.
This behavior didn’t reproduce on any OS during our tests and this leads me to believe that there is an environment variable causing the issue on your system. At this moment I can list a few possible causes:
The connection is redirected to another server, which doesn’t provide the expected response. This could be a local server or an external server if you’re using a proxy.
The message interpretation is altered by an extension or application running on your system/in the browser.
The browser’s access to network resources is blocked.
The screenshot shows you are using a non-portable version of Dragon which installs an update service. The log I requested is created by that update service (regardless of the update method set in the browser’s settings - automatic/manual). This log could tell us if the update service encountered an issue while checking for updates. “ComodoLogsFolder” is created during installation and contains the setup logs and update logs. Under normal conditions these two are present on disk.
Here are some troubleshooting steps:
1.
1.1 Check the Windows hosts file and if you have made any changes try using using the default configuration.
1.2 Try updating Dragon with no proxy settings enabled (system and Dragon defaults).
1.3 Check your DNS settings and try reproducing the issue with DNS disabled.
2. Try running Dragon with the following command line parameters: --disable-extensions, --disable-plugins.
3. Check your security software and make sure Dragon is not prevented from connecting to the network. Also check if you have any custom filters and try disabling them.
We need a complete bug report because it contains information that helps us replicate your work environment and reproduce the issue. Running the tests on our systems also allows us to more freely change system variables.
If you have any more information relevant to identifying the issue please let us know.
I am using and have tested BOTH desktop and portable versions. I just needed to submit only one screenshot since they both do the same thing, I mentioned that in my post.
I will try to figure out if its something on my end that’s causing the issue but there are no logs being created, I have checked the usual documented places as well as a wildcard search on both the local and removable drives looking for logs, nothing. NO matter what the issue is, shouldn’t the updater create a log?
1.1 - Nothing remotely Comodo related on the HOST file
1.2 - System has no proxy configured and neither does the browser - strictly direct connection
1.3 - DNS settings are handled strictly by the router, which gets its primary DNS from the ISP and the secondary from Comodo and tertiary from OpenDNS
2 - Done with no difference in result
3 - Security checked software and hardware firewalls have not been changed and they are not blocking anything Comodo related - Software FW being Comodo itself
I understand the point of bug reports but nothing can create what’s not there, I gave you all I have and that’s what a bug report is, providing all you got and whatever follow-up is asked, not manufacturing things from thin air that don’t exist. Again, not my first rodeo, I have been developing for 25+ years and in mission critical environments, trust me, I know how to submit a bug report.
I am going to run some more tests on my side and see if I can figure something out, in the meantime what I know I have provided and you know.
Still no log generated but I did seem to resolve the issue temporarily by running a trap and trace on the application and found that its trying to communicate with 127.0.0.1:0 and then trying again on 127.0.0.1:9005 and then again on 127.0.0.1:1111 which is bizarre to say the least.
Being a network guy, I decided to take a chance and do a big no-no and bridge straight to my external IP using an ultimate address 0.0.0.0 route config and it worked fine. Now I need to figure out WHY its doing this LOCALHOST port hopping when its configured for direct connection to the internet.
UPDATE
I was able to narrow down the odd behavior to the machines located on a specific VLAN subnet of the network which was being worked on during the configuration of the new Cisco Router and 2 Switches causing some funky behavior. I was able to verify on other subnets that it works fine and also on my own personal machines at home, so that was our network bad, my apologies. Its been “cured” if you will. HOWEVER, still NO DRAGON UPDATER LOGS, that HAS NOT changed. Just so you know. Not sure why, but we can’t get updater to generate a log if lives depended on it. But the connection is working and glitch was confirmed on our end. I worked pretty hard to make sure that the blame was not unduly put on you guys that’s why I am updating you to set you at ease on that one.
However, the extensions still not updating, you said you were aware of it and will update in the next release but failed to acknowledge and respond to my request for technical information on what is causing that so I can try to see if I can patch it on my end or not, or at least observe and better understand what’s going on. Please share that information so I can keep digging on my end, if for nothing more than to understand and who knows I might be able to help in some way.
Thank you for the update on the issue and thank you for the work you’ve put into finding the cause.
The short explanation for why extension update doesn’t work at this time would be this:
The communication with the Google servers was performed through a generic function which has been blocked in the current release. Unfortunately that function also managed the extension updates among other things. The issue has been fixed on our side so the next release will have working extension updates.
The dragon_updater issue looks like another kind of beast…
As long as the update service is running, it should write to the log file. It logs all update checks, service start and service stop.
Could you run Process Monitor and restart the update service? It will attempt to create the log file during this operation and it might also tell us why it fails.
My pleasure, accurate information is the foundation of progress. Thank you for bearing with me while I nailed it down. I am glad that at least I wasn’t completely wrong ;D
The short explanation for why extension update doesn't work at this time would be this:
The communication with the Google servers was performed through a generic function which has been blocked in the current release. Unfortunately that function also managed the extension updates among other things. The issue has been fixed on our side so the next release will have working extension updates.
Aha! Thanks for that because I had a sneaking suspicion when I compared the behavior of official Chrome release (Google’s) with our last release (Comodo’s) side by side and noticed some traffic that wasn’t shared but I thought that was just Chrome being overly homesick :-X but that explains its. Interesting that they would tie the phone home chatter with the extension update requests into one function 88) so I guess to fix that, we need to just sift and separate what’s core and what’s just noise :-La
The dragon_updater issue looks like another kind of beast...As long as the update service is running, it should write to the log file. It logs all update checks, service start and service stop.
Yeap, figured as much. When not dealing with “sky falling” issues - I AM playing around with that trying to figure out more. I will keep you posted on that front, promise - you know I am good for my word.
Could you run Process Monitor and restart the update service? It will attempt to create the log file during this operation and it might also tell us why it fails.
I will certainly do that, its part of what I have been trying already but need to dedicate more of a solid block to it. Will put a trap and trace on the process, related I/O read/writes, DA/MA and see what I can figure out, will let you know for sure when I have something.
