Using chrome.runtime.sendMessage without the extensionID - google-chrome

I'm working on a project that needs to use an extension that a customer must download and install, however my web page needs to communicate with the extension, so i use the documented way:
https://developer.chrome.com/extensions/runtime#method-sendMessage
chrome.runtime.sendMessage(string extensionId, any message, object options, function responseCallback)
{
...
}
This means i have to include the "extensionId" of an extension that only generates this code once its installed.
Doesn't this sound a little "cart before the horse"?
I have to explain this to our clients, how to go and get their extension ID, and some how apply it to this page in order for it to work? Its seems terribly clumsy, especially since i have have to set the permissions explicitly.
"externally_connectable": {
"matches": ["*://mywebsite.com/*"]
},
If I omit extensionId, it doesn't work.
"Uncaught Error: Invalid arguments to connect"

According to the link you posted, it says extensionId is optional and that it is "[t]he ID of the extension/app to send the message to. If omitted, the message will be sent to your own extension/app." So it seems that it should still work even without the extension ID.
Having said that I noticed the same error on an extension I'm trying to debug, but it seems to be all working despite it. And when I add the extensionId the errors disappear. Might need to find a way to access the extensionId from within the extension.
Update: I successfully substituted in '##extension_id'. See this.

Related

WebAssembly crash info in window.onerror()

I am trying to collect crash logs for my WebAssembly application. It's built with emscripten, everything is served from the same domain, testing in Chrome. In the developer console I see a proper error with stack trace when a crash occurs, I'd like to capture this and send it to a server.
Instead I am only getting "Script error." passed to window.onerror() and the fifth parameter is null. This is supposed to happen when violating the same-origin policy (linked question is only about javascript, does not talk about this WebAssembly-specific problem.) Errors occurring in the .js file don't have this problem, only webassembly runtime errors.
I added the crossorigin attribute to the .js file generated by emscripten. The site is running in secure context, the Response object passed to WebAssembly.instantiateStreaming() (in the emscripten-generated .js file) has "basic" as its .type, so as I understand it has no restrictions on what can be done with it. "Access-Control-Allow-Origin" header is set to "*".
For some weird reason I managed to get the full error with stack trace exactly once, so it is apparently possible, but seemingly doing everything the same way I can't get it to work again.
How can this be solved?
instantiateStreaming is promised based so maybe try window.addEventListener('unhandledrejection')?

DriveApp.setSharing is now throwing an Exception, is there something wrong with the legacy runtime?

The following code was working previously (and still works with the V8 runtime):
function myFunction() {
var file = DriveApp.createFile("Test", "Test");
file.setSharing(DriveApp.Access.DOMAIN_WITH_LINK, DriveApp.Permission.VIEW);
Logger.log(file.getUrl());
}
Now it is throwing the following error:
Invalid argument
I have isolated the issue down to the DOMAIN or DOMAIN_WITH_LINK Access parameter. PRIVATE works fine. ANYONE and ANYONE_WITH_LINK throws a permissions error (which is expected as this user does not have access to share outside the domain).
Unfortunately I cannot update the script to use the V8 runtime due to my use case.
One other thing to note: I get this exact same error with this exact same code when running it in a free Google account. (Could it be an issue with Google's engine recognizing the domain?)
As mentioned by #Cooper there are many issues regarding sharing.
The most recent issue is currently being worked on: https://issuetracker.google.com/issues/161201634
You just have to go there and click on the star next to the title so you get updates on the issue and you give the issue more visibility.

Chrome Web Store In-App Payments: Errors getting SKUs

I'm trying to get the SKUs available for a freemium Chrome Extension I'm developing.
I'm following all of the documentation here:
https://developer.chrome.com/webstore/payments-iap
...and I'm using the provided buy.js file, but it doesn't seem to work and the returned error messages are useless: "INVALID_RESPONSE_ERROR"
My code:
google.payments.inapp.getSkuDetails({
parameters: {env: 'prod'},
success: (r) => {
console.log(r);
},
failure: (err) => {
console.log(err);
},
});
Thoughts:
- Am I missing some permission in my manifest? I don't see any mention that it needs any additional ones.
Other StackOverflow questions have mentioned needing to proxy due to region issues. I'm in the states, shouldn't be an issue.
I've tried the above from both an options page and a popup - does it need to happen in a background page?
I'm pretty baffled. Any help is appreciated!
Thanks.
Updates:
The above works when released (in prod), but not locally
In prod you cannot buy your own thing (heads-up). It'll give you some stupid, meaningless error, but won't tell you that.
Still can't get this to work locally which means I have to test in prod.
If you need this to work locally, you must set the 'key' in your manifest.json file. When you reload it, it will show the same ID as the loaded extension from production.
Here are instructions on how to get the relevant key
If you debugging your extension in unpacked mode, you may need to set production "key" in your manifest.

Chrome Console: VM

When executing a script directly in the console in Chrome, I saw this:
Does anyone know what's the meaning of VM117:2
What does VM stand for ?
It is abbreviation of the phrase Virtual Machine.
In the Chrome JavaScript engine (called V8) each script has its own script ID.
Sometimes V8 has no information about the file name of a script, for example in the case of an eval. So devtools uses the text "VM" concatenated with the script ID as a title for these scripts.
Some sites may fetch many pieces of JavaScript code via XHR and eval it. If a developer wants to see the actual script name for these scripts she can use sourceURL. DevTools parses and uses it for titles, mapping etc.
Thanks to #MRB,
I revisited this problem, and found the solution today,
thanks to https://stackoverflow.com/a/63221101/1818089
queueMicrotask (console.log.bind (console, "Look! No source file info..."));
It will group similar elements, so make sure you add a unique identifier to each log line to be able to see all data.
Demonstrated in the following example.
Instead of
data = ["Apple","Mango","Grapes"];
for(i=0;i<10;i++){
queueMicrotask (console.log.bind (console, " info..."+i));
}
use
data = ["Apple","Mango","Grapes"];
for(i=0;i<data.length;i++){
queueMicrotask (console.log.bind (console, " info..."+i));
}
A better way would be to make a console.print function that does so and call it instead of console.log as pointed out in https://stackoverflow.com/a/64444083/1818089
// console.print: console.log without filename/line number
console.print = function (...args) {
queueMicrotask (console.log.bind (console, ...args));
}
Beware of the grouping problem mentioned above.

Problems with MediaWiki's AccessControl extension

I've installed the AccessControl MediaWiki extension however it seems like it causes an access denied error if you search for anything even contained within the page that is access controlled.
Anyone using this extension?
All I want to do is hide one page in the wiki from everyone except for 5 people.
MediaWiki version 1.18.0
AccessControl version 2.1
I solved it by adding another namespace to put the pages I need to secure in. I then removed the namespace from being searchable by implementing the searchablenamespaces hook.
By doing this, there will never be an access denied page displayed just by searching for text that happens to be in an access controlled page.
Here is the code for $IP/extensions/NoSearchNameSpace/NoSearchNameSpace.php
<?php
// This is a quick hack to remove certain listed namespaces from being searchable
// Just set a list of namespace IDs in the wgNoSearchNamespaces array in LocalSettings
// ie $wgNoSearchNamespaces = array(500,501) would remove 500 and 501 from being searched
$wgHooks['SearchableNamespaces'][] = 'noSearchNameSpace';
function noSearchNameSpace($arr){
global $wgNoSearchNamespaces;
foreach($wgNoSearchNamespaces as $ns){
unset($arr[$ns]);
}
return $arr;
}
Example LocalSettings.php entry:
// Add two custom namespaces. One for ACL pages.
// one for pages that will be ACL'd that should not be searched.
$wgExtraNamespaces[500] = "ACL";
$wgExtraNamespaces[501] = "NoSearch";
// Include the NoSearchNamespace extension
require_once("extensions/NoSearchNamespace/NoSearchNameSpace.php");
$wgNoSearchNamespaces = array('500','501');
I tried it with 1.20.2, and had the problem when a page I was searching for contained text being searched, putting it in the list of search results, which provoked an error because the "hookUserCan" function in AccessControl.php didn't return a value. To try to fix this, I modified line 341 of AccessControl.php ("return doRedirect( 'accesscontrol-info-anonymous' );" to "return false;". This forces the search results to return just the title of the page, and then gets a permission error if an unauthorized user tries to open it. This is not a perfect fix, but it is sufficient for my purposes.
Editted, this is a better answer:
I made some modifications to the AccessControl.php program, and now it appears to work ok with MediaWiki user groups. A remaining problem is that the TITLES of protected pages show in the search results. This is fixable in the main MediaWiki source code (SpecialSearch.php, around line 562), but according to comments in that code, it would screw up the paging.
Here is my git directory, which can be unzipped to $IP/extensions/AccessControl:
https://ejc.s3.amazonaws.com/AccessControlGit.zip
Here is just the AccessControl.php file: http://pastebin.com/WnyB6gBw
Note that this has only been tested (briefly) with MediaWiki 1.20.2. I'm hoping that the author of the extension will review what I did and fix whatever problems remain.
I fixed this error by adding
return false;
after ALL LINES that say
doRedirect( 'accesscontrol-info-anonymous' );