I'm having a very strange problem with a site in Google Chrome:
When I click on a link (from a list view to a detail page), the page hangs and I Chrome throws up a dialogue asking me to kill the page. The page is never displayed.
But if I navigate directly to the page, it loads in Chrome without any problems. Both actions (clicking on a link or navigating to the page) work fine in Safari and Firefox.
Disabling "Predict network actions to improve page load performance" in Chrome's settings seems to fix the problem, but this is not a viable solution as I don't have any control of my user's browser settings.
Some more detail about the situation:
The link is just a regular <href>. I'm not doing any javascript
click() handling or anything else. I'm not using any 'prefetch' or 'prerender' <link> elements.
The pages all validate using the W3
html5 validator.
The page I'm navigating to loads a lot of JS, uses Knockout.js for rendering and loads a video file over HTTP.
On the occasions that the page does load (after a very long wait),
Chrome appears to have rendered the entire page in the background and
loaded all external resources. If I navigate directly to the page it
doesn't preload anything though (I'm using knockout to show a 'please
wait' message while the external resources load).
When I log the network requests using Charles, it appears that
Chrome loads the HTML for the page instantly, but the requests for
the external resources seem to take forever.
If I look at the CPU usage in Activity Monitor, 'Google Chrome Renderer' uses 100% CPU when loading from the href, but only 30% when loading directly from the page.
I'm using the latest version of Chrome (22.0.1229.94)
So - my question
Is there a way to programatically disable "Predict network actions to improve page load performance"?
Or is there some other solution to this problem?
Just going through high voted unanswered questions I came across this one, and I once got into a similar situation for entirely different reasons (chrome was preloading a huge file I couldn't afford to load for every user). The fairly simple solution I applied back then was to open the link through Javascript rather than a simple href which worked wonders. Either way, your problem might already be solved, but seeing the number of views I thought I could at least share this small insight.
Related
I have been having a very odd problem in all Salesforce orgs, but only when using Chrome.
If I go to Setup, and click on a "classic" setup link, like "users", instead of opening it in the iframe within lightning, it attempts to open it in a new browser tab. The page renders, but none of the links or javascript do anything.
I have seen advice that says to avoid a plugin called "Ghostery" but I am not using that, and have turned off other browser extensions but nothing works. This is not happening for anyone else I know using chrome and salesforce, which leads me to believe it is some Chrome configuration setting, but I don't know what to look for.
Click Me
This used to work as a valid href attribute but it seems in the past few months it now shows an error in the console (I'm using Chrome):
Not allowed to load local resource: view-source: http://stackoverflow.com
I found some links from 2013 where this was once a bug in Chrome but said it was fixed.
Could someone point me to an authoritative source that can explain why this no longer works? I assume that this is security by the browser and not an angular issue (since view-source is whitelisted and used to work)
Looks like Chrome and Firefox (at least) disabled this within the past year or so
I found this thread, and these release notes explaining why and provides a timeline as to when the change took place.
Related StackOverflow question: File URL "Not allowed to load local resource" in the Internet Browser
Chrome responds with the "Not allowed to load local resource:" as a security protocol. I'm not sure why this used to work, but not now, though there is no real way around this unless web-security is disabled. There may be a different outcome on other browsers, but ultimately you are correct in thinking that it's Chrome's security.
The reason is that Chrome tries to preload URLs in background, to speed up your browsing experience.
If you open the DevTools after loading the page, the content of the items listed on the Resources tab may not be populated. This is also true of network requests on the Network tab. To see the fully populated resources on the Resources tab, first open the DevTools, then refresh the page, or navigate to the desired page with the DevTools open. Now select the html resource and it should be populated.
In previous version of chrome, on a webpage with the following:
<script>
document.write('<plaintext>');
</script>
<img src="http://example.com/image.jpg">
the image would not be downloaded. At some point a chrome update changed this behavior. Now when I look at the network tab, I see the image is downloaded. (fiddle here: https://jsfiddle.net/doojunqx/)
I have a script that is on a page, I would like to use this script to stop the browser from downloading (using up network bandwidth) for images and other assets that are unwanted and below my script tag.
Mobify does something similar here:
http://cdn.mobify.com/mobifyjs/examples/capturing-grumpycat/index.html
As they say on the page "Open your web inspector and note the original imgs did not load." However, when I open chrome developer tools and look at the network tab, I see the original images ARE now loading. I'm not sure what version of chrome changed this, but I think it is recent, within the last month or two.
Is there any way to force chrome back to the old behavior? Or any other way to stop these unwanted assets from loading?
Thanks,
Great question, and you're correct that it is a recent change in Chromium that affected the plaintext tag behaviour. In versions up to and including version 42.*, the HTML document parser would not spawn an asynchronous parsing thread until an external resource was found in the original HTML document. Once such a resource was found, an asynchronous thread would be spawned that would aggressively download all resources references within the HTML.
The recent change simplified the parsing behaviour by moving all document parsing to the asynchronous thread which now kicks off automatically. Whereas before, using the plaintext tag would ensure that no resources would be loaded if it was inserted before the first external resource, the plaintext tag is now racy as resources will download up to the moment the plaintext tag is executed in the main HTML document. As there is a time delay for the script to execute, an unknown number of resources will be retrieved.
There is as of yet no solution to this new behaviour, nor is there a way to disable the preload scanner as you would like. You will need to rely on workarounds such as polyfills to control your resource downloads. This new behaviour is only present in all versions of Chrome >= 43.* and has not been implemented in Safari, Firefox, or other browsers.
WebGL does not work in the following three scenarios:
(for the 'test webgl' site used get.webgl.org)
1 Start chrome, Google search for the 'test webgl' site, click on the link in the search result.
2 Go to the 'test webgl' site from a link in an email.
3 Start Chrome from a short cut or command prompt, "C:\Program Files\Google\Chrome\Application\chrome.exe" http://get.webgl.org/
This only happens when Chrome is not already running. In other words WebGL does not work when chrome starts up. However it does work if chrome is already running.
The best demonstration is scenario number 3, above. This starts chrome and goes to http://get.webgl.org/ and Webgl does not work. Then do exactly the same again but this time with chrome already open and Webgl works.
Would very much appreciate feedback or a solution, thanks.
Have also created various test sites in html, javascript and webgl, in order to find a work-around. For example if webgl is not available then allow the user to click on a link to open the page in a new tab, this does not work. However if the user opens a new tab then loads the page, webgl is detected and works.
In short, if a customer opens chrome and searches for your website (that has webgl content). Then clicks on the link, webgl will not work. It does not seem reasonable to then instruct the customer to open a new tab and then go to the same website a second time. So far have not been able to find a solution so that it just works without the customer having to fiddle around.
I realize that this may be a chrome issue as it does not occur in firefox, however am trying to find a javascript solution rather than waiting for chrome developers to fix it.
Thanks for any suggestions.
(Windows XP Pro, Chrome V36)
Hi Mack,
Thanks for your reply. The majority of visitors to my web site have XP and Chrome. I should imagine that this is true for quite a lot of peoples, websites.
Problem 1 The first fallback I had on my website was to detect if webgl is supported. If yes then continue as normal. If no then display a help page. This was simple and worked, however, google crawlers do not handle the javascript very well, therefore always index the webgl help page, rather than the home page.
Solution 1 Managed to fix this by having a popup box appear when webgl is not supported, giving the user a choice of whether to continue or go to the help page. The conditional code that processes the user response is arranged so that if the user is a google crawler then it simply 'falls through' and displays the html content of the home page, and not the help page.
There are lots of web sites that seem to have this same problem, including get.webgl.org, in other words, if you do a google search for a website, and that site contains webgl detection and fallback code, the search result always shows the fallback content, rather than the authors intended main content.
Problem 2 Now that I finally have the home page listed correctly by google, found that am still losing many customers, as they are starting chrome, searching google for my site 'suit yourself shirts', clicking the link in the result and being told incorrectly that webgl is not supported.
Am very interested in your solution but do not quite understand how it works. Have tried detection then page refresh or load the page in a new tab or display a link for the user to load the page, but none of these methods seem to work. Seems like quite a fundamental problem that would effect many webgl websites. Would be very greatfull if you could explain your suggestion a little further. Thanks for your help, kind regards - Gary
I read in a source that chrome, when it goes to a domain, it prefetches most of the pages that might be used for that domain. As a result of this, I'm facing a problem. I have a greasemonkey script which is to be injected in every page. But what seems to happen is that the browser injects the script for the first page in a domain and that remains when i go to another page, instead of being re-injected (which is what i would want). Any ideas on how i could achieve this behavior ??
Google Chrome will precache DNS entries on the page but it doesn't pro-actively go and fetch pages, Firefox however, does prefetch pages.
Actually, there is a case where Chrome will proactively pre-cache any page that is mentioned in the cache manifest. This is designed for offline scenarios. However, each page when downloaded will not be executed against any injected script, nor will it run any JS on those pages.