I'm trying to replicate this example https://www.primefaces.org/showcase-ext/views/codeScanner.jsf but a white screen appears, somebody can help me?
It turns out that some users experience issues with this component in the showcase when the browser decides the that the site is not secure:
This is a browser dependent issue possibly in combination with the type of SSL, or certificate PrimeFaces is using on their server. Note that this may change over time.
If this happens to you, first try upgrading your browser. If that did not help, try the component on localhost or a https server with no security issues for the browser you are using.
See also:
https://www.chromium.org/Home/chromium-security/deprecating-powerful-features-on-insecure-origins
Related
I have a site hosted on AWS S3, with CDN managed by Cloudflare. For most purposes the site works fine, but when I try to share it through the social media app WeChat, I get a warning (pictured below) and then the site doesn't render properly. This doesn't happen consistently, but when the warning appears, then the site fails to load properly.
My first line of thought was that the problems might be that the different settings of S3 compared to a more standard Apache server were triggering some security issue in WeChat, and that Cloudflare might fix the problem, but it doesn't seem to have made any difference.
Removing Google Analytics and all CDN-ified resources also doesn't seem to have made any difference.
Any thoughts or input on either weirdness in the WeChat browser's rendering rules or why S3 might be triggering a warning would be greatly appreciated. Running into a bit of a wall here.
tl;dr WeChat shows a warning for certain top-level domains. My site was on a .me tld, which triggered a warning. The page rendering incorrectly is based on the warning (not sure about why these two things are connected)
After messing around with https (security issues) and removing all CDN-ified assets (thought they might be blocking down rendering), and hosting the site in China vs outside of China, I finally stumbled upon this. Nothing else matters. Its just the tld that triggers the warning and causes the rendering problem.
For one my projects, we need to extract the distilled content of a crawled webpage. We want to be able to this as an internal service on the server side without the browser. I have been working on using the headless mode of chromium with the distill functionality to be able to do this. Has anyone tried doing this in this forum? Even if you have not done, could someone share some insights on how to potentially do this ?
Thanks,
Praveen.
Chrome is forcing https (as well as adding https to every internal link) to everything on my site, even though I have https support disabled/don't want to use it.
This occurred after I went to my site's cpanel (which requires you go through https). I changed no settings, and after that Chrome forces it. Only occurring on Chrome (firefox is working fine), and only on one computer.
Of course, I tried restarting, clearing cache/cookies as well as going to chrome://net-internals and deleting the domain from HSTS. Nothing works.
Any ideas? Thank you
I had the same issue and to all odds it had something to do with my website itself. In my case I'm running WordPress & WooCommerce on my site and it seems like by deactivating WooCommerce my issue was solved. Still not sure how to properly fix this since as soon as I activate WooCommerce again the same issue re-appears. However, at least I know now where the issue is coming from and can dig around further.
I noticed the same issue with WooCommerce 2.3. Earlier versions don't have the same issue. My workaround was to load my site using Internet Explorer {the horror}.
This is the weirdest bug.
For some reason, the ctrl-click context menu has stopped appearing only on Chrome - localhost. I can view localhost in Safari and get a context menu and I can even view the exact same site I am developing on it's url in Chrome and get a context menu. Any other site I view in Chrome will also generate a context menu.
The context menu stopped appearing recently, it had been working fine up until this point.
I haven't been able to find any information on why this is happening.
I found this help in chrome
I hope it helps you
Re-enable the possibility to use the context menu on sites that overrides it.
This extension re-enables the context menu.
Indeed, many sites prohibit the right-click on images, pretending to protect their content. I think it is illegitimate.
(This extension is AD supported. If you don't wish to support me you may disable it in the settings.)
Unfortunately, Google Chrome does not have advanced options for what javascript is allowed to do (on the contrary of Konqueror, Opera or firefox). If you think it should, please star (don't add a "me too" comment)
In the meantime, this extension provides a workaround, by resetting the oncontextmenu to its default behaviour on many elements of the page. Oh, as a bonus, it works for Flickr and Youtube html5 videos too!
If a site is not supported, please report it in the bug tracker, not in the comments.
If a site is broken by the extension, please report it in the bug tracker, not in the comments.
However, a nice comment is always welcome :-)
I think chrome introduced this in 57 or 58 .. A perhaps simpler workaround is to add an entry to your system's hosts file and access your server using that.
i.e.:
127.0.0.1 server.local
then, instead of http://localhost/ , use http://server.local/ (and/or https, and/or port number, etc. as the case may be)
Bam! Chrome gives you your context menu back!
I can modify the Document mode that IE renders the page in, by passing in a X-UA-Compatible in the response header. I can achieve this by modifying a setting in IIS.
Similarly is there a way to modify the Browser mode to Compatibility view by modifying any setting in the IIS?
Shown below is what I currently see in the F12 tool in ie.
To configure IIS 7 on a Windows Server 2008-based computer to include a custom HTTP response header:
Click Start, click Administrative Tools, and then click Internet
Information Services (IIS) Manager.
In the connections pane, expand the node for the server, and then
expand .
Click the Web site where you want to add the custom header.
In the Web site pane, double-click in the section IIS on HTTP Response Headers.
Under Actions, click Add.
In the Name box, type X-UA-Compatible.
In the Value box, type IE=EmulateIE9.
Click OK.
Hope this helps!
I was also looking into this issue and found my answer here:
http://www.nczonline.net/blog/2010/01/19/internet-explorer-8-document-and-browser-modes/
From that site:
There doesn’t appear to be any other way that and end user can trigger Internet Explorer 7 mode. As such, it appears that this is just a convenience tool for developers that frees us from needing to and so it appears to be a tool used primary for developers
The same thought can be applied to IE10 I guess. It's rather frustrating, but I hope it helps.