When you type in an invalid address, Chrome displays a grey page that says "Oops! Google Chrome could not find X. Did you mean Y?"
Because this is not an HTTP page but rather one of the browser's built-in things, I can't put a content script in it and can't control it, so my extension is frozen until the user manually goes to another page.
Since the extension is supposed to be able to control the browser on its own, it's very important that anytime this page opens, it automatically goes back to a page I do have content script access to, and then displays a message instead.
Is this impossible?
You can use the chrome.webNavigation.onErrorOccurred to detect such errors, and redirect to a different page if you want. Unless you've got an extremely good reason to do so, I strongly recommend against implementing such a feature, because it might break the user's expectations of how the browser behaves.
Nevertheless, sample code:
chrome.webNavigation.onErrorOccurred(function(details) {
if (details.frameId === 0) {
// Main frame
chrome.tabs.update(details.tabId, {
url: chrome.runtime.getURL('error.html?error=' + encodeURIComponent(details.error))
});
}
});
According to the docs the only pages an extension can override are:
The bookmarks manager
The history
The new-tab
So, an extension can't change/contol/affect the behaviour of the browser regarding the "Oops!..." page.
Related
It was hard to encapsulate my question in the title.
I've rewritten a personal web page that made extensive use of javascript. I'm simplifying matters (or so I hope).
I use a home automation server that has a REST interface. I can send commands such as 'http://192.168.0.111/rest/nodes/7%2032%20CD%201/cmd/DON to turn on a light. I'm putting links on my simplified web page using an href tag. The problem is that it opens the rest interface page and displays the XML result. I'd like to avoid having that page show up. ie when you click on the link it 'goes' to the link but doesn't change the page.
This seems like it should/would not be possible but I've learned not to underestimate the community.
Any thoughts?
You can use the fetch function if your browser is modern enough:
document.querySelector(lightSelector).addEventListener('click', e => {
e.preventDefault(); // prevent the REST page from opening
fetch(lightURL).then // put promises here
})
The variables lightSelector and lightURL are expected to be defined somewhere.
The code listens for clicks on the link, and when one comes, we prevent the REST page from opening (your intention) then we send a request to your light URL with fetch. You can add some promises to deal with the response (e.g. print "light on" or "light off" for example) using then but that's another matter.
If you make the "link" a button, you can get rid of e.preventDefault(); which is the part preventing the REST page from opening.
I noticed that whenever you download a PDF in Chrome, it consistently makes two requests, and then cancels one of them. This is causing the request to be registered twice in my Web app, which don't want. Is there a way to get Chrome to only make one request for PDFs?
I've researched this topic quite a bit now, and I have not found a sufficient answer. Closely-related answers suggest that the problem is that Chrome is looking for a favicon, but the network tab shows that it is actually making the same request twice, and then canceling the second request.
Is there a way to prevent Chrome from making the second request?
Below is a link to a random PDF file that I found through Google which when clicked should demonstrates the behavior. I would've posted a picture of my network tab in devtools but this is my first post on Stack Overflow, and the site is prohibiting me from uploading a picture.
https://www.adobe.com/enterprise/accessibility/pdfs/acro6_pg_ue.pdf
It looks like a bug in Chrome: https://bugs.chromium.org/p/chromium/issues/detail?id=587709
The problem is that Chrome, when it loads an iframe that returns a PDF stream, writes an "embed" tag inside that iframe which again contains the same URL as the iframe. This triggers a request for that URL again, but Chrome immediately cancels it. (see the network tab)
But by that time, the damage is done.
We have the same issue here, and it does not occur in Firefox or IE.
We're still looking for a good solution to this problem.
I'm still trying to find a proper solution but as a partial "fix" for now you could have two options
1) set the content disposition to "attachment" in the header
setting that to "inline" cause chrome to run a second cancelled call
so for example you can do something like that (nodejs resp in example)
res.writeHead(200, {
'Content-Type' : 'application/pdf',
'Access-Control-Allow-Origin' : '*',
'Content-Disposition' : 'attachment; filename=print.pdf'
});
unfortunately this solution will force the browser to download the pdf straight away instead of rendering it inline and that's not maybe desiderable
2) adding "expires" in the headers
this solution will always fire a second cancelled call but it's ignored by the server
so for example you can do something like that (nodejs resp in example)
res.writeHead(200, {
'Content-Type' : 'application/pdf',
'Access-Control-Allow-Origin' : '*',
'Content-Disposition' : 'inline; filename=print.pdf',
'Expires' : new Date(new Date().getTime() + (60000))
});
I had the same problem in an iframe. I turned of the PDF Viewer extension and the problem disappeared. I'm thinking the extension downloads the file twice. The first time to get the size, the second time to download with a progress bar (using the size gathered in the first request)
I've tried the other solutions and none worked for me, I'm a little late, I know, but just for the record, I solved this in the following manner:
Adding the download attribute:
In my case I was using a form, so it goes like this:
<form action="/package.zip" method="POST" download>
This worked on Brave and Safari, which previously showed the same problem, I think it will work for Chrome.
With my case, problem wasn't browser related. I've noticed our scrollbar plugin's (OverlayScrollbars) DOM manipulations reloads embedded pdf data and calls controller more than once due to on plugin's construct or destroy events. After I've initialized scrollbar before DOM is ready, problem is solved.
I have a web app which uses localStorage. Now we want to embed this web app on other (third-party) sites via iframe. We want to provide an iframe embed similar to youtube so that other websites can embed our web app in an iframe. Functionally it is the same as if it wouldn't be embedded. But it does not work. Chrome prints the error message:
Uncaught SecurityError: Failed to read the 'localStorage' property from 'Window': Access is denied for this document.
I just do the following check (in the iframe):
if (typeof window.localStorage !== 'undefined') {
// SETUP SESSION, AUHT, LOCALE, SETTINGS ETC
} else {
// PROVIDE FEEDBACK TO THE USER
}
I checked my security settings in Chrome like described in another Stackoverflow Thread but it doesn't work. Is there any change to make embedding possible without the need of adjusting (default) security settings of most modern browsers?
To give more information, we use Ember-CLI for our web app and turned on CSP (more info about the Ember-CLI CSP). Could CSP cause our web app to throw security errors?
Under Chrome's Settings > Privacy > Content Settings, you have the cookie setting set to "Block sites from setting any data".
This checkbox is what is causing the exception.
According to this
This exception is thrown when the "Block third-party cookies and site data" checkbox is set in Content Settings.
To find the setting, open Chrome settings, type "third" in the search box, click the Content Settings button, and view the fourth item under Cookies.
On the following URL: chrome://settings/content/cookies uncheck "Block third-party cookies".
If you're using incognito mode, make sure you turn off "Block third-party cookies".
Open a new tab in any incognito window, and turn off the option:
localStorage is per domain, per protocol. If you are trying to access localStorage from a standalone file, i.e. with file:/// protocol, there is no domain per se. Hence browsers currently would complain that your document does not have access to localStorage. If you put your file in a web server (e.g. deploy in Tomcat) and access it from localhost, you will be able to access localStorage.
I ran into this problem in my phone, I couldn't open a certain site with chrome.
It took me some time to find the cookies on my phone, when I found it, I saw that my cookies was blocked.
go to your Settings --> Site settings --> Cookies
and allow the site to save and read cookie data, make sure that you don't block third-party cookies!
I hope this helps you.
I checked all the answers but ended up not finding anything. Then I realized what browser I'm using. If you're using Brave (Chromium Based), you will get this error if your shield is up. Try lowering your shield.
A more secure way of doing this in Chrome would be to allow only the site(s) that you trust:
Chrome
-> "Settings"
-> "Show advanced settings..."
-> "Privacy"
-> "Content settings..."
-> "Manage exceptions..."
-> (add a pattern such as [*.]microsoft.com)
-> be sure to hit enter
-> "Done"
-> "Done"
If disable block third-party cookies is not an option, you can use try...catch:
try {
// SETUP SESSION, AUHT, LOCALE, SETTINGS ETC
} catch(err) {
// PROVIDE FEEDBACK TO THE USER
}
As has been pointed out in the comments, localstorage is single origin only -- the origin of the page. Attempting to access the page's localstorage from an iframe loaded from a different origin will result in an error.
The best you can do is hack it with XDM via the postMessage API. This library purports to do the heavy lifting for you, but I haven't tried it. However, I would make sure you're aware of IE's terrible support for XDM before going down this route.
imho it has nothing to do with CSP settings on your ember cli app but to do with browser settings.
Some browsers (Chrome) block localStorage content loaded into an iframe.
We too are facing a similar situation for our Ember App,were we have an ember app and a plugin which loads on 3rd party websites, the user token loaded into the iframe gets blocked in Chrom,we are experimenting with some solutions, will keep this thread posted as to how it goes.
To get rid of this warning - under Chrome's Settings -> Privacy -> Content settings, you have to clear the "Block third-party cookies and site data" option
Secure way of doing this in Chrome top right, click on eye logo and allow the site you are on to use third-party cookies:
Check this image if you can't find the eye logo
Clear Cookie
Chrome->setting->privacy and Policy->Sites that can never use cookies In turnremove cookie for local storage.
For all others like me who search for a Javascript solution/fix:
var storageSupported = false;
try
{
storageSupported = (window.localStorage && true);
}
catch (e) {}
if (storageSupported)
{
// your code
}
Credits: https://github.com/zoomsphere/ngx-store/issues/91
I've recently been contributing to the Enhanced Steam extension and I've found that a link fetched with chrome.extension.getURL simply opens about:blank and not the link described.
I do not believe it's actually a problem with the extension, but rather a problem in chrome. The link it supplies is valid (chrome-extension://pimjhgjngccknempdnehdeaihcjbajod/options.html) and navigating directly works correctly.
I tried chrome.tabs.create, but found that I am not allowed to use it due to the script modifying pre-existing content.
Any help or work arounds would be appreciated.
I put all my required files into "web_accessible_resources", it solved my problem. See this in #4 https://bugs.chromium.org/p/chromium/issues/detail?id=310870#c4
It is Chrome's previous problem which is not secure. In build 31.0.1650.57, Chrome fixed this which is to force to put required files in "web_accessible_resources". In Chrome extension, lots of samples don't use "web_accessible_resources", those are the bugs, those samples will have this "chrome-extension:// links open about:blank" problem in build 31.0.1650.57.
Actually my chrome extension MarkView was facing this issue and I had to update its manifest.json to make it work for this Chrome update. By the way, MarkView is tool to read and write Awesome Markdown Files, it provides features including Content Outline, Sortable Tables and code block syntax highlight with line number.
Looks like a bug in Chrome to me. If you don't have too many pages like this to change then could you try using message passing to pass the page you want to open to the background page? Then use either window.open or chrome.tabs.create within the background page. Example code shown below:
//CONTENT SCRIPT
chrome.runtime.sendMessage({greeting: "OpenPage", filename:"somepage.html", querystring:"?aValue="+someVal}, function(response) {});
Then in your Background page
//BACKGROUND PAGE
chrome.runtime.onMessage.addListener(
function(request, sender, sendResponse) {
if (request.greeting == "OpenPage"){
open_page(request.filename, request.querystring)
}
});
function open_page(filename, querystring){
var pageUrl = chrome.extension.getURL(filename)+querystring;
chrome.tabs.create({'url': pageUrl }, function(tab) {
// Tab opened.
});
}
I'd like to make a very simple extensions that slightly alters how the Downloads page looks. Changing the History page might be interesting too, but that's for later.
Is there a way to do that?
I tried making a Content Script extension, with "chrome://downloads" as match in manifest.json. Chrome won't allow that and responds with an error when packaging the extension.
Is there another simple way? It has to be simple, because changes would be simple, because all chrome:// pages are built with HTML, JS and CSS.
edit
After trying with background scripts a little...
I can't get chrome.tabs.executeScript to work! I added in background.html:
chrome.browserAction.onClicked.addListener(function(tab) {
alert(this.document.body.innerHTML);
alert(chrome.tabs.executeScript(null, {
code : "document.body.style.backgroundColor = 'red';"
}));
});
And I added this in manifest.json to add a (invisible) 'browser action button':
,"browser_action": {
/* "popup": "background.html",*/
"name": "Alter page"
}
The onClicked event fires both alerts (first is background.html's body, second is undefined). But the code (a string with document.body.style.backgroundColor = 'red';) doesn't execute! And ofcourse there's no debugging for extensions like this =)
Any tips anyone? I'm trying to get a hold of the tab's window.document (not background.html's window.document!). An injected script (that's what chrome.tabs.executeScript is supposed to do) should do that.
PS
I'm stealing from make_page_red/manifest and make_page_red/background.html
The 'extension' I have so far: http://hotblocks.nl/js/downloads.rar
EDIT
I found out what I want to achieve is possible with just CSS. I don't need to inject javascript. Does that make it easier? Does that make it possible? =)
According to this documentation, chrome:// URLs are an invalid scheme so they won't be matched:
A match pattern is essentially a URL that begins with a permitted scheme (http, https, file, or ftp), and that can contain '*' characters.
I would look into using override pages instead.
As requested, here's my extension that can at least load when chrome://downloads is loaded, although as I said, I don't think you can modify the page even if you know that's the page you're viewing.
manifest.json
{
"name": "Test",
"version": "0.0.1",
"background_page": "background.html",
"permissions": [
"tabs"
]
}
background.html
<script>
chrome.tabs.onUpdated.addListener(function(tabId, changeInfo, tab)
{
if (tab.status == "complete")
{
alert(tab.url);
// should alert 'chrome://downloads' on that page. You can
// check for this url here and then do whatever you want
}
});
</script>
Update: Since Chrome 31 there is an API for extensions that allows access to Chrome's downloads: https://developer.chrome.com/extensions/downloads
There's also an API that allows access to list and manage other installed extensions: https://developer.chrome.com/extensions/management
(Previous Answer)
Unfortunately, there's not currently an API for Chrome extensions to access information about a user's downloads. It's a widely requested feature, though, and there's some discussion among Chrome developers here: http://code.google.com/p/chromium/issues/detail?id=12133
Star the issue if it's a feature that you'd like to see, and you'll receive email updates.
As this page shows, there is no API to override the downloads page... However, there is a way to make a file you have made replace the chrome://downloads/ page whenever it is loaded using javascript in your background page...
chrome.tabs.onUpdated.addListener(function(tabId, changeInfo, tab){
if(changeInfo.status === "loading"){
if(tab.url === "chrome://downloads/"){
chrome.tabs.update(tab.id, {url: "REPLACEMENT.html"});
}
}
});
Essentially what this does is - As soon as the page chrome://downloads begins loading (using the tabs.onUpdated API), the page is redirected to REPLACEMENT.html (Using tabs.update API)... There is no visible delay in the tab update
as this script is run before the chrome://downloads page begins loading... You can use a similar code in your file by pressing CTRL + U on the downloads page to view and copy its source code