I have a webpage (php form using yii framework) secured by ssl that shows an SSL padlock with a yellow alert in Google Chrome. I have not been able to identify the problem and am stumped. It seems to be related to my page and is specific to Google Chrome (other browsers work fine).
Troubleshooting so far:
Eliminated Cache as the Cause
Completely cleared my Google Chrome cache to ensure that previously loaded components were not causing the problem.
Tested the page on a separate machine to confirm that the alert is visible on a different system not related to my machine. Alert on page was generated on separate system.
Scoped the Problem to an Element on My Page
Setup a simple page under the same domain, successfully generated the padlock.
Tested failing page at https://www.whynopadlock.com/check.php and the script indicates that all components are called securely. No alerts generated.
Scoped the Problem To Google Chrome
Tested in Internet Explorer - No alerts
Tested in Safari - No Alerts
Tested in Firefox - No Alerts
Does anybody know of a page element that will cause an alert (broken padlock) in Google Chrome, but not in Internet Explorer, Safari, or Firefox?
Related
General Problem
We've had a long-standing problem with our two ExtJS 5.1.0 apps that div scrollbars don't show in Chrome, using only our QA testers' AWS Workspace Chrome browsers. They don't see this in other websites using that Chrome, only our two applications. We've been able to ignore this since the problem was isolated, but now a user is having the same problem.
We've been able to confirm that the difference is that wherever there's a div that should be overflow: auto is being generated as overflow: hidden. So scrollbars for grids, dropdowns, etc don't render but the div can still be scrolled via other means (tabbing, page down).
I've been looking for general ideas about what could cause this--is it ExtJS? Windows setting? Chrome setting? Again, the problem is isolated to AWS Workspace's Chrome and a user's Chrome.
Versions
Chrome:
AWS Workspace has exact same Chrome version as me, 79.0.3945.88.
User has Chrome 80.0.3987.149 (up-to-date).
Windows:
AWS Workspace is Windows Server 2016 Datacenter.
User has Windows 10.
What We've Tried
These are all troubleshooting steps we've tried in the AWS Workspace Chrome:
Disabled all extensions. Also ran in incognito mode which should do this also. The extensions are nothing that I don't also have, and I don't see the problem.
Inspected Chrome's flags--they're all default, and again not different than what I have.
Disabled Chrome's “Use hardware acceleration when available” setting and restarted Chrome.
Previously opened a ticket up with AWS and they were unable to help.
Researched any connection of this to Chrome, ExtJS, or Windows Server 2016 Datacenter without luck. Only found general information about "what to do if you have scrolling problems in Chrome".
Other Problems Our Apps Have in AWS Workspace Chrome
Listing these in case it helps trigger any ideas about the underlying problem, but focusing on the scrolling for now. Again these are isolated to Chrome in AWS Workspace (unclear if the user is seeing these also):
Drag and drop doesn't work.
Tabs that aren't the selected tab when the tab bar is loaded don't load at all.
It turns out that the problem was related to touchscreens. Our user has a touchscreen laptop (and didn't realize it for a while, we asked about this early on). And the Amazon Workspaces are touchscreen-compatible, as they have a "HID compliant touch screen" device listed in Device Manager > Human Interface Devices. So something about touchscreens + Chrome/Edge is telling ExtJS 5.1.0 that the device is mobile and scrollbars shouldn't be rendered.
Solutions:
For our user, she was happy to disable her touchscreen device and this worked for her.
For Amazon Workspaces, disabling the touchscreen device did not work. For Chrome we were able to resolve by adding --touch-events=enabled to the Chrome shortcut. There are various touch-related Chrome flags mentioned online as a solution, but none of those are available in the current version. Anything touch-related we did find in Chrome's list of flags didn't help.
I haven't looked for a solution for Edge if someone uses Edge and wants to keep their touchscreen. This is fine for us right now. (Because we realized Edge has the problem also, presumably due to Chromium. Did not see it with Firefox.)
And I did confirm using ExtJs' Kitchen Sink examples that I can replicate the problem in 5.1.0 with both a touchscreen laptop and an Amazon Workspace. Also that I can't replicate the problem in the current version, so we should be good once we upgrade.
Our application uses a popup window to show a report. This works in every browser except Chrome.
In Chrome the URL in the Network tab of the inspector has a blank response. I also see Chrome loading an inject.preload.js script from disk cache?
This exact same page works in Firefox and Safari as well. I haven't been able to check IE yet (i'm on a mac today).
What is this inject.preload.js script and why would Chrome not load a URL in a popup?
The exact same code running staging servers works, the popup loads just fine. In production it works everywhere except Chrome. Both staging and production use SSL, have the same config, etc.
I unfortunately can't link as its a secured site.
Inject.preload.js is generally some sort of adblocker. It could be the case that its acting up and blocking your popup. If it is the case, it would show as an icon to the right of the address bar.
It was reported to me this morning that one our marketo landing pages was not displaying properly in IE. When I checked the page none of the css or js was loading, so it's pretty much an empty page with a few images.
Link to landing page
Using dev tools in IE I noticed the error:
SEC7112: Script from http://pages.vistex.com/js/forms2/polyfills/placeholder/placeholder.css was blocked due to mime type mismatch
I'm using IE9 the browser seems to go into IE 9 Compatibility View with IE7 Standards. We do have a group policy forcing compatibility view on our domain on our network.
Could this just be an internal network error? Or is this error firing for all users. I was able to check the page in IE11 off our network and it looks fine.
I am experiencing an issue with opening a Microsoft Office Document, using IT Hit WebDAV AJAX library, in latest Chrome 39.0. running on Windows OS. It is a sporadic issue that occurs only in Chrome, and it happens when one opens a document multiple times. Word instance won't start, the page freezes and browser becomes unresponsive, and Chrome suggests killing the page. The only solution is restarting the browser, which solves the issue.
I have tried opening a document in Chrome on Mac OS X, and it is working fine. So are Mozilla and Safari on all operating systems. It seems to be a Chrome + Windows issue only.
Has anyone experienced this issue and is there a fix?
The Microsoft Office plug-in that opens the document displays a warning popup "Some files can harm your computer.", which is a modeless dialog:
If you quickly click on a link that opens the document more than one time the dialog will hide behind the main web browser window. As a result the web browser window is blocked.
You need to switch to that dialog and confirm or reject document opening, otherwise after some time Chrome will ask you if to kill the page or wait.
Note that there is no way to avoid that dialog, this is a built-in MS Office functionality as far as I know.
Chrome will only work good with ITHitWebDAV if the user has got Office 2013 or superior.
Google is blocking all Java applets and NPAPIs now, so good luck with that. I just detect the browser of the user that wants to edit a document, and if it's chrome, I warn him to change to another browser like Firefox with a modal, and that's all.
Very poor support between Chrome and ITHitWebDAV, and no much you can do about it.
I am looking for a way to launch a file located on our local file network for use via our local intranet using Firefox or Chrome.
The link works well in IE:
View Report
but in Firefox it shows:
View Report
is there a way to get the link to render properly?...Just a simple click from a href tag.
For Chrome, a new extension was just posted today! It's called LocalLinks and it replicates the functionality of the locallink add-on for Firefox! You'll find it on the Google Extensions page, or you can get to it directly here:
https://chrome.google.com/extensions/detail/jllpkdkcdjndhggodimiphkghogcpida
Enjoy!
This is not enabled in firefox for security reasons (remember that most computers have files and applications of a sensitive nature located in similar locations, like C:\System\Windows)
you can try adding this to the user.js file for any user that needs to be able to access these links:
user_pref("capability.policy.policynames", "localfilelinks");
user_pref("capability.policy.localfilelinks.sites", "file:///[[PUT SERVER NAME HERE]]";);
user_pref("capability.policy.localfilelinks.checkloaduri.enabled", "allAccess");
Just remember that this is a security risk.
Firefox seems to want file://///Start/Of/My/Network/file.xlsx
Chrome and IE handles that too.
file://Start/Of/My/Network/file.xlsx appears to work in Chrome as well, sometimes firefox hics up on it..
There is the LocalLink add-on for firefox. It uses a context menu though...
Use IE tab (available for Chrome and Firefox) and set that to handle all links of the form file:/// by adding an autourls entry like this:
r/file:///.*
Technically this isn't opening the file in the original browser, but it gives you all the windows explorer integration you'd expect from whatever IE version you've got installed when dealing with local file links. I would advise against doing this except in cases when the browser isn't being used to access the web - e.g. for viewing internal wiki or intranet pages, due to the obvious security risk.