Many of our users are reporting that they are getting a blank page when using IE11 to access our website. Sometimes they don't even get a blank page, the browser just stays on the last page visited. These users can access other domains (such as google.com) without a problem.
For the browsers that are failing, if those users disable Protected Mode in IE, then they can again access our site, but this isn't a good solution because we have thousands of users and we can't go telling each of them to reconfigure their browsers, not to mention that we're completely losing the business of those potential customers who just surf by, see a blank page, and then keep on going without filing an error report.
Firefox and Chrome work fine. Also, even when using IE11 in protected mode, some users have zero problem, their computers just seem to work.
We are running the site off of IIS7. Other sites on the same server run fine, it's just the one particular site that is having the problem, and it's intermittent, affecting some computers and not others.
There must be something I can do on my side in the server or network settings to keep this problem from happening, but I'm baffled as to what it might be. When I look at the network traffic on a browser that's failing, the GET request is just being aborted with no explanation. When looking at the traffic with Wireshark, I see no errors, and no errors are showing up in the IIS logs. Of the browsers that fail, they are not even opening a connection to our web server to make a GET request, the request is just aborting immediately.
Any advice appreciated!
(followup): Another test we did: We can reproduce the problem on our development server, with the same pattern of which computers "work" and which don't. We tried turning off the webserver, and the problem stayed consistent, we'd still get a blank page error. So it's obviously not to do with anything that's in our page content? I've run tests on 9 computers on our office network: 5 worked, 4 failed. We're all baffled. :/
(January 24 followup): We figured out what's causing the problem, but not how to fix yet. Deep in the Windows registry, a key is being set in a Zonemap folder, adding a "play.net" domain with a key value of 2. IE sees that key when someone types play.net, and quivers and dies without an error message (Firefox and Chrome handle it fine).
So next question, what is setting that key in the first place? Probably an ActiveX control somewhere, but we haven't had any luck finding it in this 15 year old site, as many of the coders who may have created ActiveX controls in the past are long gone.
Does anyone know of a way to scan an entire domain and list anything that might be twiddling a registry key?
Followup mail threads from Elonka indicated that some users had the play.net domain mapped to a specific / non-default Internet Explorer security zone, and those users were the ones having problems.
Try add
<meta http-equiv="X-UA-Compatible" content="IE=10" />
into the header. It fixed IE11 for my website. It just forces it into IE10 mode (A complete joke though)
I accessed your domain in Internet Explorer 11, with Protected Mode enabled. I was unable to get a fully broken experience, but I did see something perhaps related to what your customers are experiencing. Some directories on your domain would hang for me, resulting in a white screen if they've not yet been loaded, or staying on the present page while the forthcoming page is loaded.
When I navigated to /dr, I found that my browser hung for over 7 seconds while your files loaded. Note, there were roughly 60 items, totaling about .78mb. This isn't much, but I'm presently on a relatively slow connection, and this resulted in a hang for me.
I would inquire what connection speeds your clients are on when experiencing this issue - it could very well be nothing more than some directories being served up more slowly than others. Regardless, you could optimize the experience considerably by compressing and concatenating your CSS files, as well as all of your JavaScript files. This results in fewer parallel requests, and quicker downloads.
If you have a reproducible example, please feel free to share and I'm sure myself and many others here will be more than happy to assist you.
For me box-shadow on an element caused this behavior. I removed the box-shadow(but left -webkit-box-shadow and -moz-box-shadow) and the problem disappeared. The interesting thing is that I still have box-shadow on another element...
If you are using 'offline.js' in your project, and you have version less than 0.7.19, then IE11 latest security update will see this code as potential security threat and block pages which are using 'offline.js' code.
Solution: Update to latest 'offline.js' version.
Related
I'm trying to help a client with their slow-ish website https://www.dp-tools.de. If I use Google page speed for mobile I can see that it takes 7 seconds to be interactive but nothing in the found problems really tells me why it is actually that slow. I also tried chrome lighthouse and couldn't really see all that much.
Is there another way of checking or maybe anyone here sees why it is so slow?
Open up the client's Shopify Admin, and examine the theme. Does it have any strange slow code in it? Examine the Apps installed that directly affect theme. Are any of them crap, old, broken junk?
The best way to debug a slow theme is to just start hacking out any junk the client may have added to their theme. A lot of themes are so bad, for example, they load jQuery 3 times. Likely you have one bad apple in there, a call that is blocking and takes way to long to timeout or respond. Developer tools can point these out to in your console. Mobile versions have to come with a developer console you can inspect too right?
I can't login to iTunes.connect anymore. It delivers an empty white page since the whole day now. There is no 401 and no 404, just plain html that renders an empty page:
https://www.youtube.com/watch?v=UhIy6OeaBZY&feature=youtu.be
My friends can log into itunes connect and see the real page, but not me.
I tried different browsers, cleared cache and everything else.
What to do now? Apple isn't interested in this issue because it works for lot of people apparently....
I don't think there is anything you can do about it on your end, but I wouldn't panic. I believe it may be traffic and/or account related. We have it happen every now and then and usually after a couple of hours things are back to normal. Should the issue persist, I absolutely would contact Apple regarding it though.
As #Ramsay also commented, some more people had this issue yesterday...
How i ended up with this: i switched the network to 3G UMTS where everything worked fine.
Then I disconnected the router for a while to achieve an IP-address-change from my provider for my office. But iTunes.Connect then worked only in incognito mode, so i had to clear browser cache with cookies again. Now it works.
Apparently iTunes.Connect had some serious issues in general. The processing-state for a new release in the internal-testing-phase of Testflight took more than 5 hours yesterday. Usually 10 minutes where enough to process.
Is there any way to consistently detect PhantomJS/CasperJS? I've been dealing with a spat of malicious spambots built with it and have been able to mostly block them based on certain behaviours, but I'm curious if there's a rock-solid way to know if CasperJS is in use, as dealing with constant adaptations gets slightly annoying.
I don't believe in using Captchas. They are a negative user experience and ReCaptcha has never worked to block spam on my MediaWiki installations. As our site has no user registrations (anonymous discussion board), we'd need to have a Captcha entry for every post. We get several thousand legitimate posts a day and a Captcha would see that number divebomb.
I very much share your take on CAPTCHA. I'll list what I have been able to detect so far, for my own detection script, with similar goals. It's only partial, as they are many more headless browsers.
Fairly safe to use exposed window properties to detect/assume those particular headless browser:
window._phantom (or window.callPhantom) //phantomjs
window.__phantomas //PhantomJS-based web perf metrics + monitoring tool
window.Buffer //nodejs
window.emit //couchjs
window.spawn //rhino
The above is gathered from jslint doc and testing with phantom js.
Browser automation drivers (used by BrowserStack or other web capture services for snapshot):
window.webdriver //selenium
window.domAutomation (or window.domAutomationController) //chromium based automation driver
The properties are not always exposed and I am looking into other more robust ways to detect such bots, which I'll probably release as full blown script when done. But that mainly answers your question.
Here is another fairly sound method to detect JS capable headless browsers more broadly:
if (window.outerWidth === 0 && window.outerHeight === 0){ //headless browser }
This should work well because the properties are 0 by default even if a virtual viewport size is set by headless browsers, and by default it can't report a size of a browser window that doesn't exist. In particular, Phantom JS doesn't support outerWith or outerHeight.
ADDENDUM: There is however a Chrome/Blink bug with outer/innerDimensions. Chromium does not report those dimensions when a page loads in a hidden tab, such as when restored from previous session. Safari doesn't seem to have that issue..
Update: Turns out iOS Safari 8+ has a bug with outerWidth & outerHeight at 0, and a Sailfish webview can too. So while it's a signal, it can't be used alone without being mindful of these bugs. Hence, warning: Please don't use this raw snippet unless you really know what you are doing.
PS: If you know of other headless browser properties not listed here, please share in comments.
There is no rock-solid way: PhantomJS, and Selenium, are just software being used to control browser software, instead of a user controlling it.
With PhantomJS 1.x, in particular, I believe there is some JavaScript you can use to crash the browser that exploits a bug in the version of WebKit being used (it is equivalent to Chrome 13, so very few genuine users should be affected). (I remember this being mentioned on the Phantom mailing list a few months back, but I don't know if the exact JS to use was described.) More generally you could use a combination of user-agent matching up with feature detection. E.g. if a browser claims to be "Chrome 23" but does not have a feature that Chrome 23 has (and that Chrome 13 did not have), then get suspicious.
As a user, I hate CAPTCHAs too. But they are quite effective in that they increase the cost for the spammer: he has to write more software or hire humans to read them. (That is why I think easy CAPTCHAs are good enough: the ones that annoy users are those where you have no idea what it says and have to keep pressing reload to get something you recognize.)
One approach (which I believe Google uses) is to show the CAPTCHA conditionally. E.g. users who are logged-in never get shown it. Users who have already done one post this session are not shown it again. Users from IP addresses in a whitelist (which could be built from previous legitimate posts) are not shown them. Or conversely just show them to users from a blacklist of IP ranges.
I know none of those approaches are perfect, sorry.
You could detect phantom on the client-side by checking window.callPhantom property. The minimal script is on the client side is:
var isPhantom = !!window.callPhantom;
Here is a gist with proof of concept that this works.
A spammer could try to delete this property with page.evaluate and then it depends on who is faster. After you tried the detection you do a reload with the post form and a CAPTCHA or not depending on your detection result.
The problem is that you incur a redirect that might annoy your users. This will be necessary with every detection technique on the client. Which can be subverted and changed with onResourceRequested.
Generally, I don't think that this is possible, because you can only detect on the client and send the result to the server. Adding the CAPTCHA combined with the detection step with only one page load does not really add anything as it could be removed just as easily with phantomjs/casperjs. Defense based on user agent also doesn't make sense since it can be easily changed in phantomjs/casperjs.
we are developing an extension, hosted in the Google chrome web store.recently - we've got complaints from our users that sometime they get a notification window saying "the extension crashed, click here to reload".
after a short research we found out that this is happening only when we upload a new version to the Chrome Web Store.
we started to look it up online and found no documentation what so ever for this, so we started to check for it ourselves.
we tried to see what exactly can cause this problem and if we can identify a distinctive cause.
our tries included updating only the manifest.json file, a css file, a js file or not changing nothing at all but the version number, and on each change we've uploaded a new version and update it in about 10 different machines.
the results were the same, when on each update we made, it caused the extension to crash on just a few of the machines, while updating perfectly fine on the others. each time different machines acted differently.
then, we thought it might be related to the fact we have a timer working in the background page, and it might be happening just at the time it is working.
so we tried to raise the timer's frequency (from 5 seconds to 100 millisecond), and it still acted the same, crashing on only 3 out of the 10 machines.
we ran out of ideas now, and it really causing a problem in terms of user experience to our extension's users.
did someone had this problem, or came across any extension crashes on version update?
is it a known bug in chrome's extension engine or are we doing something wrong?
I am having the same problem and I think I found the cause. Do you by chance, override the new tab page?
I am able to reproduce the problem 100% of the time and when I remove the new tab override from the manifest, the problem goes away.
I opened an issue: Issue 104401
Is there a trick to logging in to Apple Developer Connection? For the past two weeks, out of about 100 tries, I've been able to log in three times. Every other time, after a successful entry of my username and password, it takes me back to the login screen.
This happens to me on both my Macs, on Safari and Firefox, so I'm not hopeful of a solution. But I have a hard time believing that the situation is really this bad...
I am having the same problem, I have narrowed down to a problem with my ISP. Of course they will not acknowledge it, but the problem only arises when I attempt a login from home. I think they are probably using a caching proxy and something in the scheme used by apple to login->access the content makes the proxy believe it's only visiting content that is still valid. I am going slightly mad because of this.
This question and the related discussion clued me in to how to fix my problem with the same symptoms on developer.apple.com. In my case, I have multiple "teams," so after entering in my Apple ID, it takes me to a team selection page. After selecting a team, I'd just be redirected back to the login/Apple ID page.
Turns out, the login is done over HTTPS, while the team selection (and probably the bulk of other activities on developer.apple.com) are over HTTP. Our firewall load balances over a couple of Internet connections, and the HTTPS traffic was passing over a different interface than the HTTP. Evidently, this was confusing Apple's authentication mechanism. It also explains why I was occasionally able to get through -- sometimes all traffic would end up on the same interface.
Ultimately, my solution was to add a rule to the firewall to send all 17.0.0.0/8 traffic (Apple's legacy class A network) over the same interface.
Hopefully this helps someone else with a frustratingly endless login loop.