I have developed a chrome extension and I want to have the inline installation on my website.
I have the following code but it does not seem to work:
<head>
<link rel="chrome-webstore-item" href="https://chrome.google.com/webstore/detail/-extension_ID-">
<script>
function ExtInstall() {
if (chrome.app.isInstalled)
alert("already installed!");
else
chrome.webstore.install();
}
</script>
</head>
<body>
<button onclick="ExtInstall()" id="install-button">Add to Chrome</button>
</body>
I have also linked the website with the extension, but it does still not working. The chrome.app.isInstalled returns always false even if I have the extension installed and chrome.webstore.install(); does nothing.
Any ideas?
After discussing with the poster, it turns out to be a Chrome bug, where verified sites that have port numbers are not handled correctly (i.e. if the verified site is example.com:1337, inline installation requests from http://example.com:1337/install.html will fail with "Installs can only be initiated by the Chrome Web Store item's verified site".
I have filed Chromium bug 110917 to track this.
Related
I have a simple, local HTML file:
<html>
<head>
<link href="stylesheet.css" rel="stylesheet" type="text/css"/>
</head>
<body>
<div class="myclass">Hello World</div>
</body>
</html>
and a simple stylesheet:
.myclass {
color: #456123;
background-color: red;
}
I am deploying my stylesheet to an outside cloud hosting service (AWS S3). However, when I swap the URL out, the styles don't work anymore:
<link href="https://example.s3.us-east-2.amazonaws.com/stylesheet.css" rel="stylesheet" type="text/css"/>
What do I mean by they don't work? The page doesn't display correctly, none of my styles get applied. The page renders as if there was no stylesheet at all.
I've tested all the obvious things, and then some:
The remote stylesheet is accessible, I downloaded it separately by URL and WGet
The remote stylesheet is the exact same as local, byte-for-byte (no diff)
I have disabled cache in my browser
I have hard refreshed
Per my browser tools > network tab, the browser loads the stylesheet promptly (~200ms)
Per my browser tools > sources tab, I can confirm that the entire stylesheet is there, present as a source and readable
I even wrote a script that I loaded into the body that fetched the CSS stylesheet externally, and using a callback after that, created the myclass div. The styles still didn't apply, even when controlling for latency/race conditions like that.
What could be going on here?
Fixed it! I found a similar problem here, which led me to the answer: when CSS files get uploaded to AWS, they get uploaded as Content-Type: Binary/Octet-Stream for some godforsaken reason. (Madness!)
My browser tools didn't raise that as an issue -- I guess browsers are pretty flexible these days -- but it must've still been an issue for HTML rendering.
So the solution is simple: go into AWS S3, click on the file, and change its metadata to hold:Content-Type: text/css. Or you can also set that metadata programmatically if you're uploading these files via an AWS CLI or SDK.
As an aside, you should do the same for JS files, which also get uploaded as binary/octet-stream. For whatever reason, the browser is still able to execute those fine.
There is an html page that works correctly on any Windows and Android (shows content of iframe). Hosting by Github Pages. It works on iOS version 12.5.1, but no on 14.6 (blank page on Chrome, Safari, Opera). Why?
Tried src with wikipedia - ok everything. The problem narrows down to a combination of iframe and src of apps script (that opens separately correctly)
Assume that the problem was mixed http/https according to post. Just http was in style http://www.w3.org/2000/svg, I changed to https (even removed all styles). No effect.
No log errors, just blank page. Seems like trying to load, but break and stop. I haven't ios device to debug. Feedback user.
If you have iOS 14, can try open this site. What you see blank page or access error?
Error like the next is right. It tell about you haven't access.
Refused to display 'accounts.google.com/…' in a frame because it set 'X-Frame-Options' to 'DENY
If you sign in Google Account and try again, will be error from Google Drive. I have all this on any platform in incognito mode. Don't pay attention to them.
Only interested in the case of a blank screen/stop loading like screenshot below
iOS 14.6
Windows
<!DOCTYPE html>
<html lang="ru">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>Goofy</title>
<style>
html, body, iframe { width: 100%; height: 100%; margin: 0; border: 0; }
</style>
</head>
<body>
<iframe src="https://script.google.com/macros/s/AKfycbzmAfVL_ozEP69vpYvMo3t1Qlc4orPfk7eV5rWT/exec"></iframe>
</body>
</html>
Apps Script render page with XFrameOptionsMode.ALLOWALL
function doGet() {
return HtmlService.createHtmlOutputFromFile('launch.html')
.addMetaTag('viewport', 'width=device-width, initial-scale=1')
.setXFrameOptionsMode(HtmlService.XFrameOptionsMode.ALLOWALL);
}
Cookies for cross-site resources are now blocked by default (iOS 13+). Source. Other platform (iOS 12, Windows, Android) while aren't do this. Such cookies need to verify user on github.io with iframe and google src. That's why I see the blank page on iOS 14.
Solve is go to browser's setting and allow 3rd party cookies.
Thanks Shivam's answer
It’s browser side problem. Due to 3rd party cookies, Safari will block the content. Unless user set on their own, the preference to allow all cookies. Until now, I only know Safari that will do this action. Other browser, i think all okay with content in iframe that come from 3rd party.
You can't frame certain websites, because the server won't allow you for security reasons (Imagine that a random page iframes your gmail and steals all your data). So you will have to modify the macro on google scripts and maybe ask other question for what you are trying to do. X-Frame-Options
i have create an iframe look like this :
<iframe src="https://mychatbot.com/chat?token= adadasdasd>
it doesn't work/load in IOS device
But when i change that iframe to
<iframe src="//mychatbot.com/chat?token=adadasdasd>
And bammm, it work !!! i think we just need get rid of http/https out of our "src"
It's just a simple page for now however the background colour and image do not appear properly on the uploaded site, but are fine in the local files. Moreover, the website appears different when using with and without the www prefix.
[EDIT - I see either a white blank page, or one with a squashed logo in the middle of the page. I've tried with chrome, edge, on mobile and desktop, and with/without incognito mode.]
http://swedge.design/
http://www.swedge.design/
https://imgur.com/fk8UufL [ what it looks like through swed...]
https://imgur.com/aqTTwPP [ what it looks like through www.swed...]
and what it looks like locally
I've checked it using the W3 markup validation service and corrected those errors. I can't see any errors on the console either, and have had other people check, and checked on my phone as well, so it can't be a cache problem.
<!DOCTYPE html>
<html lang="en">
<head>
<title> swedge.</title>
<link rel="stylesheet" href="style.css">
<link rel="shortcut icon" href="/favicon.ico">
<meta charset="UTF-8">
</head>
<body>
<div><img src ="swedge.png" alt = "">
</div>
</body>
</html>
CSS
body
{
background-color: #333333;
}
div {
top:0;
left:0;
}
div img {
position:fixed;
top:0;
left:0;
height: 200 px;
width: 200px;
}
I've had a search around but everything seems to point to either errors in the code, or a cache needing cleared.
As now two other persons mentioned here: For us the online version looks just like your screenshot. This is good news for you, but why did it not work for you but for us?
This is a very usual problem encountered in web development and caused by caching. You most likely opened the webpage before you deployed the final version. Your browser or a CDN server cached the old files and when you reloaded the page after the final deployment those old files broke the web page as the page is now half new and half old.
The easiest way to check for caching issues is to open the web page in an incognito window/tab. The incognito mode does not share the caches, thus it is like you would open the webpage for the first time. After closing and opening a new incognito window, caches are reset again.
In Chrome you can also left click on the reload icon while the developer tools are open and select "hard reload" to manually invalidate all caches and reload everything.
Please not that both methods will not work when the caching issue is caused by a CDN server, as your browser will receive the outdated files again from the CDN. In this case you need to wait until the CDN drops your files from the cache.
You can control this behaviour with the cache control headers (browser and CDN). Shorter or no cache times will reduce this issue but will increase the load on your servers.
Edit:
You mentioned in an other comment that, you already tried incognito mode. This means that the issue is most likely caused by a CDN. You can check the HTTP response headers for caching directives.
I have been trying to get my HTML5 offline cache manifest to work nicely in Safari when accessing the site with HTTPS.
I have the following setup:
index.html:
<!doctype html>
<html lang="en" dir="ltr" manifest="app.appcache">
<head>
<base href="https://www.example.com">
<link rel="stylesheet" href="//some.cdn.com/styles.css" charset="utf-8">
<script src="//some.cdn.com/app.js"></script>
</head>
<body>
</body>
</html>
app.appcache
CACHE MANIFEST
//some.cdn.com/styles.css
//some.cdn.com/app.js
NETWORK:
*
Accessing my site over HTTP works fine! Assets get loaded correctly and cached; I can use my app offline
Accessing my site over HTTPS in Chrome works fine as well
Accessing my site over HTTPS in Safari breaks :-( Assets get loaded normally, but won't cache. Debugging didn't got me any further. No useful information in the logs
According to the specs, referring to another domain in the cache manifest is allowed.
I have also tried using http:// or https:// explicitly in my HTML and manifest instead of the //-notation. Of no avail.
In my search online I've found some comments about cross-domain requests and that it isn't allowed in the cache manifest, but according to the W3C specs this is allowed (and proved by the fact that the browsers I tested it cache all the assets correctly, except for the combination https & safari.
So apparently I missed an important restriction of the appcache.
As mentioned in https://www.w3.org/TR/2011/WD-html5-20110525/offline.html:
If the manifest's is https: or another scheme intended for encrypted data transfer, then all URLs in explicit sections must have the same origin as the manifest itself.
TL;DR
I've read through many questions on Stack Overflow on this issue and I've tried to follow the given advice. Still, my CSS stylesheet will not work in Chrome/Safari but it can work in Internet Explorer.
The only odd thing that I can see about my scenario is my server is returning all files as of type application/octet-stream. I cannot change this aspect of the server. Is there something I can do to interpret my CSS file as a stylesheet in Chrome/Safari and IE?
I have an embedded web server project that I am working on. I have very limited control of the server software and the ability to make page-level settings. All I can do is create static HTML, CSS, and image files that are compiled into the server application.
As such, all files that are returned from the embedded server are declared as application/octet-stream in the HTTP header. This produces warnings in Chrome but no errors.
Initially, I had a problem loading this style sheet in Chrome/Safari but it would work in IE. After reading through a couple questions on Stack Overflow, I found that I needed to change my stylesheet declaration from:
<link rel="stylesheet" href="/styles/index.css">
to:
<link rel="stylesheet" type="text/css" href="/styles/index.css">
When I made this change Chrome & Safari still failed to process the CSS file but IE also started to ignore the stylesheet.
Oddly, if I do not declare a DOCTYPE on my HTML document I can get linked stylesheets to work in all of my browsers. This is, however, not a desirable solution.
My guess is this issue has something to do with the HTTP header declaration and that it doesn't match the type declared in the link element.
What can I do to get this stylesheet to work in Chrome, Safari, and IE while following good web development codes-of-practice (i.e. using doctypes on my HTML files and not embedding the style code in the HTML headers?)
For clarity sake, the relevant CSS/HTML code is shown below.
index.css
html {height:100%}
body {margin:0;min-height:100%;position:relative}
iframe {width:100%;height:100%;border:none}
.hdr {min-width:765px;overflow:auto}
.logo1 {float:left;margin:4px}
.logo2 {float:right;margin:4px}
.menu {position:absolute;top:70px;left:0px;bottom:0px;width:175px}
.content {position:absolute;top:70px;left:175px;bottom:0px;right:0px;}
index.htm
<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=windows-1252">
<link rel="stylesheet" href="/styles/index.css"> <!-- Removed the type declaration so that this would at least work in IE9 //-->
</head>
<body lang="en-us">
<div class="hdr"><img class="logo1" src="/images/logo1.png" alt="Logo #1"><img class="logo2" src="/images/logo2.png" alt="Logo #2"></div>
<div class="menu"><iframe name="menu" src="/menu.shtm"></iframe></div>
<div class="content"><iframe name="main" src="/home.htm"></iframe></div>
</body>
FYI, this is a new project that is being developed from an existing one. The original project did not declare a DOCTYPE on the HTML files. Therefore, all page data was loaded and executed in the browser in quirks mode. Furthermore, the index.htm originally consisted of multiple frames within a frameset.
I am trying to update this application, using correct, and up to date methods for developing web pages. I can make this application work, but I feel that this would be at a sacrifice of future-browser compatibility if I have to rely on browser quirks mode and framesets.
I have tried to close the link tag but that doesn't help. Technically, this shouldn't be an issue since this document is declared as an HTML5 document, rather than XHTML.
It's certainly due to the application/octet-stream content type. I can re-create the issue on my end. Soon as the content type is set to text/css your HTML/CSS load fine.
As a workaround you can use <style> tags for you CSS if you can't get the server to send the correct content type.
I hate to have to answer my own question this way but the problem was most certainly with the fact that the server was returning a content type of application/octet-stream within the HTTP header.
After discussing the issue with management we had to update the code associated with the HTTP processor. This is code that is part of a third-party RTOS and we have been extremely hesitant to making any changes to this code.
However, in this case the need has out-weighed that desire. I've integrated the necessary changes to fix the HTTP header to return a content type of "text/css" for cascading style sheets. All is now right with the world.
I think I'll just chime in here. Not to answer the question, but to confirm the issue and perhaps help people with similar problems.
I had the same problem: an external css file was loaded alright, but it was not applied in Chrome. (Safari and FF were ok about it). So, same problem, slightly different cause.
It turned out that because of a bug in the webserver code the HTTP response contained two Content Types, 'text/html' and 'text/css'.
The solution was to remove the faulty 'text/html' line. It seems Chrome is pickier than other browsers about response headers. Which I suppose is legitimate, but a warning would have been nice.
btw, you can see all the http information for a loaded resource in Chrome, when you open Developer Tools, and select Network. Then click on the file that you want to investigate. (it took me a while to find that)
We had a problems with an iframe wich it's contents was updated by an external javascript routine, the CSS were loaded but were not applied. But updating the body HTML from a routine present in the iframe head worked as suposed to.
This same behaviour was not present in gecko and explorer, but happened the same at Safari browser (webkit)
Hope this could give some light in this curious case.
I would like to add one bit of information that may save some of you some time. It appeared that chrome was not recognizing my CSS either. After reading the above post I reviewed the files in the Developer Tools->Network. Turns out that Chrome was using a locally cached version of my CSS. As soon as I refreshed as opposed to accessing the URL again, it worked!
I'm no expert, but i've made this mistake before, it's rather simple.
You've written:
<link rel="stylesheet" href="/styles/index.css">
If this is a folder in the same directory as your index.html file, then you need to remove the first /. like so:
<link rel="stylesheet" href="styles/index.css">
EDIT: I think someone else mentioned this already, but it may have been overlooked.