How can I use navigator.clipboard.readText() in a Chrome extension? - google-chrome

I wrote a Firefox extension that reads the clipboard and if it has some PEM certificate, it will print it's details in a new tab. I'm trying to port to Chrome. It does not work. What am I doing wrong?
I asked for the clipboardRead in manifest.json and I run this in background script and it works fine in Firefox.
navigator.clipboard.readText().then(function (textFromClipboard) {
//do stuff with textFromClipboard
});
This fails in Chrome with "Failed to execute 'readText' on 'Clipboard': Illegal invocation". What am I doing wrong? How can I make this work in Chrome also? Most answers involve creating an input, getting focus, executing paste. That is really complicated, I hope I don't have to do this. It works really well in Firefox, why is it complicated in Chrome?

You can use #bumble/clipboard. It is an npm library for Chrome extensions that emulates the Clipboard API.
It doesn't require user interaction, and works in a background script. It only requires clipboardRead or clipboardWrite permissions.
import { clipboard } from '#bumble/clipboard'
// Read text from the clipboard, or "paste"
clipboard.readText()
.then((text) => {
console.log('clipboard contents', text)
})
// Write text to the clipboard, or "copy"
clipboard.writeText('write this to the clipboard')
.then((text) => {
console.log(text, 'was written to the clipboard')
})
Disclosure: I wrote this library for myself to solve the same problems that #ddreian mentioned. It is a non-blocking Promise based solution that uses document.execCommand under the hood.

Related

Can you enable chrome / chromium edge extensions on the extension pages? [duplicate]

Is Chrome blocking access to the webstore url?
I would like to make an extension that displays a like button beside the +1 button, but it looks like that content scripts are not working on https://chrome.google.com/webstore/*
Is that true?
TL;DR The webstore cannot be scripted by extensions, and the flag that previously allowed you to do that (--allow-scripting-gallery) has been removed in Chrome 35.
Chrome extensions cannot execute Content scripts / insert CSS the Chrome Web Store. This is explicitly defined in the source code, at function IsScriptableURL (click on the previous link to see the full logic).
// The gallery is special-cased as a restricted URL for scripting to prevent
// access to special JS bindings we expose to the gallery (and avoid things
// like extensions removing the "report abuse" link).
// TODO(erikkay): This seems like the wrong test. Shouldn't we we testing
// against the store app extent?
GURL store_url(extension_urls::GetWebstoreLaunchURL());
if (url.host() == store_url.host()) {
if (error)
*error = manifest_errors::kCannotScriptGallery;
return false;
}
manifest_errors::kCannotScriptGallery is defined here:
const char kCannotScriptGallery[] =
"The extensions gallery cannot be scripted.";
The error can be viewed in the background page's console when you use chrome.tabs.executeScript to inject a script in a Web Store tab. For instance, open https://chrome.google.com/webstore/, then execute the following script in the background page of an extension (via the console, for live debugging):
chrome.tabs.query({url:'https://chrome.google.com/webstore/*'}, function(result) {
if (result.length) chrome.tabs.executeScript(result[0].id, {code:'alert(0)'});
});

Chrome Update broke generated pdf download in php webapp - service worker seems at fault, but why?

So we have a little php web app that, among other things, allows the colleagues to export all the info into a pdf and download it.
This was done with wkhtmltopdf and the PDF was previously immediately forced to download, as in the "Save As" dialog would pop up instead of trying to open it in the browser, etc.
Headers included:
header('Content-Type: application/force-download');
header('Content-Type: application/octet-stream', false);
header('Content-Type: application/download', false);
header('Content-Type: application/pdf', false);
header('Content-Disposition: attachment; filename="' . basename($file) . '";');
header('Content-Transfer-Encoding: binary');
Now with the latest Chrome Update (71.0.3578.98) the PDF does not SEEM to be generated at all. It is not "force downloaded" or even shown in the browser, however via file->save as or the keyboard shortcut (ctrl+s) you can save it, so it is still generated, just not displayed in any way..
I noticed if I unregister the service worker on our page, it behaves as it had before the chrome update.
Ive tested this on a few colleagues computers, some with that newest version of Chrome, others before the update, and am 99.9% sure that is the culprit. What exactly made this change in behavior occur though, I am not sure.
Any idea how to get around this and have it "force" download again? Can I blacklist pdfs from the service worker somehow?
EDIT: Can also confirm this behavior from the following Chrome version: 72.0.3626.7 (Developer Build)
Alright so this was kinda quick, and I'd generally just delete this, but I have a sneaking suspicion this might come up more often for others as soon as this Chrome update starts being applied in more places.
So this might not be a legitimate "fix" for this, but by adding a few lines to my serviceworkers fetch block I was able to exclude the URLs which generate PDFs and therefore the download was again offered up as normal.
i.e.
self.addEventListener('fetch', function(event) {
// Here you can use indexOf or a regex if you'd like
if ( event.request.url.indexOf( '/format/pdf/' ) !== -1 ) {
return false;
} else {
event.respondWith(
caches.match(event.request).then(function(response) {
return response || fetch(event.request);
})
);
}
});

Is it possible to use Watir-Webdriver to interact with Polymer?

I just updated my Chrome browser (Version 50.0.2661.75) and have found that the chrome://downloads page has changed such that my automated tests can no longer interact with it. Previously, I had been using Watir-Webdriver to clear the downloads page, delete files from my machine, etc, without too much difficulty.
It looks like Google is using Polymer on this page, and
there are new (to me) elements like paper-button that Watir-Webdriver doesn't recognize
even browser.img(:id, 'file-icon').present? returns false when I
can clearly see that the image is on the page.
Is automating a page made with Polymer (specifically the chrome://downloads page) a lost cause until changes are made to Watir-Webdriver, or is there a solution to this problem?
Given that the download items are accessible in Javascript and that Watir allows Javascript execution (as #titusfortner pointed out), it's possible to automate the new Downloads page with Watir.
Note the shadow root elements (aka "local DOM" in Polymer) can be queried with $$.
Here's an example Javascript that logs the icon presence and filename of each download item and removes the items from the list. Copy and paste the snippet into Chrome's console to test (verified in Chrome 49.0.2623.112 on OS X El Capitan).
(function() {
var items = document
.querySelector('downloads-manager')
.$$('iron-list')
.querySelectorAll('downloads-item');
Array.from(items).forEach(item => {
let hasIcon = typeof item.$$('#file-icon') !== 'undefined';
console.log('hasIcon', hasIcon);
let filename = item.$$('#file-link').textContent;
console.log('filename', filename);
item.$.remove.click();
});
})();
UPDATE: I verified the Javascript with Watir-Webdriver in OS X (with ChromeDriver 2.21). It works the same as in the console for me (i.e., I see the console logs, and the download items are removed). Here are the steps to reproduce:
Run the following commands in a new irb shell (copy+paste):
require 'watir-webdriver'
b = Watir::Browser.new :chrome
In the newly opened Chrome window, download several files to create some download items, and then open the Downloads tab.
Run the following commands in the irb shell (copy+paste):
script = "(function() {
var items = document
.querySelector('downloads-manager')
.$$('iron-list')
.querySelectorAll('downloads-item');
Array.from(items).forEach(item => {
let hasIcon = typeof item.$$('#file-icon') !== 'undefined';
console.log('hasIcon', hasIcon);
let filename = item.$$('#file-link').textContent;
console.log('filename', filename);
item.$.remove.click();
});
})();"
b.execute_script(script)
Observe the Downloads tab no longer contains download items.
Open the Chrome console from the Downloads tab.
Observe the console shows several lines of hasIcon true and the filenames of the downloaded items.
Looks like Google put the elements inside the Shadow-Dom, which isn't supported by Selenium/Watir/WebDriver spec (yet). There might a way to obtain the element via javascript (browser.execute_script(<...>)), but it is experimental at best still.
Attempting to automated a Polymer page, I found I was able to access the web elements by asking Polymer to use the shady dom by adding ?dom=shady in the URL. Like in the example on this page https://www.polymer-project.org/1.0/docs/devguide/settings:
http://example.com/test-app/index.html?dom=shady
Adding the dom parameter to request Polymer to use the shady dom may be worth a try.

chrome-extension:// links open about:blank

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.
});
}

Chrome Extension Content Script on https://chrome.google.com/webstore/

Is Chrome blocking access to the webstore url?
I would like to make an extension that displays a like button beside the +1 button, but it looks like that content scripts are not working on https://chrome.google.com/webstore/*
Is that true?
TL;DR The webstore cannot be scripted by extensions, and the flag that previously allowed you to do that (--allow-scripting-gallery) has been removed in Chrome 35.
Chrome extensions cannot execute Content scripts / insert CSS the Chrome Web Store. This is explicitly defined in the source code, at function IsScriptableURL (click on the previous link to see the full logic).
// The gallery is special-cased as a restricted URL for scripting to prevent
// access to special JS bindings we expose to the gallery (and avoid things
// like extensions removing the "report abuse" link).
// TODO(erikkay): This seems like the wrong test. Shouldn't we we testing
// against the store app extent?
GURL store_url(extension_urls::GetWebstoreLaunchURL());
if (url.host() == store_url.host()) {
if (error)
*error = manifest_errors::kCannotScriptGallery;
return false;
}
manifest_errors::kCannotScriptGallery is defined here:
const char kCannotScriptGallery[] =
"The extensions gallery cannot be scripted.";
The error can be viewed in the background page's console when you use chrome.tabs.executeScript to inject a script in a Web Store tab. For instance, open https://chrome.google.com/webstore/, then execute the following script in the background page of an extension (via the console, for live debugging):
chrome.tabs.query({url:'https://chrome.google.com/webstore/*'}, function(result) {
if (result.length) chrome.tabs.executeScript(result[0].id, {code:'alert(0)'});
});