We Keep Coding

Compress large JSON/JS object from content script to background.js - chrome extension

I want to send a large JSON/JS object from content.js to background.js
I have tried the library lz-string to compress the object.
content.js
var compressedJSON = LZString.compress(JSON.stringify(largeObject));
chrome.runtime.sendMessage({type: "type1", result: compressedJSON}, function(response){
// handle response
});
background.js
var uncompressedJSON = JSON.parse(LZString.decompress(request.result));
Doing so, I get null for uncompressedJSON in background.js
However, if I decompress the same string compressedJSON in content.js using LZString.decompress(), it works!
I wonder if UTF encoding has something to do with this. This library seems to work really well as I am able to compress my object by about 78%.
Suggestions for other libraries are welcome too!

Use LZString.compressToUTF16 and LZString.decompressFromUTF16:
compressToUTF16 produces "valid" UTF-16 strings in the sense that all browsers can store them safely. So they can be stored in localStorage on all browsers tested (IE9-10, Firefox, Android, Chrome, Safari). Can be decompressed with decompressFromUTF16. This works by using only 15bits of storage per character. The strings produced are therefore 6.66% bigger than those produced by compress
However, it'd be still much much faster to send an uncompressed JSON.stringify result in 32MB string chunks (along with chunk number), then combine them in the background script.

GetJSObject fails when run on Microsoft Surface (Excel-VBA)

I have written a small utility in Excel-VBA that also interacts with Acrobat Javascript in a handful of separate .pdf files.
The code has been tested extensively and runs exactly as intended on my desktop PC. However, I ultimately need to implement this code on a Microsoft Surface platform. When I try to run the same code from an Excel file on a Microsoft Surface, the code balks at any lines utilizing "GetJSObject."
Eg. The following works fine on my PC, but causes an "object or method not supported" error on my Surface.
Set gAPP = CreateObject("AcroExch.App")
Set gPDDOC = CreateObject("AcroExch.PDDoc")
If gPDDoc.Open(pdfFileName) Then Set jso = gPDDOC.GetJSObject
So far, I've been able to find some hints online that GetJSObject doesnt work well in a 64 bit environment and my Surface runs 64 bit Windows 10 and 32 bit Excel.
However, I don't think that this alone can account for the difference in behavior across both machines; my desktop is running 64-bit Windows 7 with 32 bit Excel, and everything works as intended.
Where should I be looking to help discover the source (and solution) of the problem?
EDIT/UPDATE: The getJSObject statement actually works as intended, IF I take the additional step of manually opening a copy of one of the relevant .pdf files in Acrobat prior to running my VBA code. I assume this means that it is somehow the object definitions (e.g. Set gAPP = CreateObject("AcroExch.App")) that are working differently on the Surface relative to my PC--and not the getJSObject command specifically, as originally thought?
So far, it hasnt made much sense to me how/why this could be true (let alone how I could go about resolving the issue).

Not sure if this had been answered yet, however there are two courses of action i'd take for research:
1.
See if you can launch it without the constructor by using:
Set AcroApp = New AcroApp
Rather than
Set AcroApp = CreateObject("AcroExch.App")
2.
Ensure you are using the same version of acrobat, from my research this error occurs from the very first result in Google for the search query:
createobject acroexch.app error 429
You cannot do this with Adobe Reader, you need Adobe Acrobat.
This OLE interface is available with Adobe Acrobat, not Adobe Reader.

Maximum call stack size exceded

I am trying to download encrypted pictures and decrypt them using RNcryptor within a Javascript web application and place them within the html of my app. Everything works perfectly except for when pictures are larger in size and cause the call stack to be exceeded.
This error does not occur when to and from devices such as the Iphone, but when I try to send them to the web app, I get this error from the Iphone 6+ but no other device
This is my function used to convert a byte array to base64 string:
function encode(data)
{
var str = String.fromCharCode.apply(null,data);
return btoa(str).replace(/.{76}(?=.)/g,'$&\n');
}
Is there a more call stack efficient way to convert the data? I am willing to sacrifice speed if necessary.

The reason this is happening on only the Iphone 6 (and I assume it is mainly with pitcures made using its camera) is because the file you are sending is to large. This error probably would not occur with an older model Iphone such as the 5 or the 4 because of the picture quality.
The way that I would fix this is in your app where the picture is originally being encoded and placed on the database, I would resize it before doing so.

Different behaviour of encodeURIComponent() in Firefox only

I encode a filename and send it as a part of URL like /rest/get?name=Filename.txt. In JS link construction is as simple as
url = '/rest/get?name=' + window.encodeURIComponent(file.name);
It works good for simple cases but for hardcore testing I use a file named
你好abcABCæøåÆØÅäöüïëêîâéíáóúýñ½§!#¤%&()=`#£$€{[]}+´¨^~'-_,;.txt
After URI encoding I expect to get a link
/rest/get?name=%E4%BD%A0%E5%A5%BDabcABC%C3%A6%C3%B8%C3%A5%C3%86%C3%98%C3%85%C3%A4%C3%B6%C3%BC%C3%AF%C3%AB%C3%AA%C3%AE%C3%A2%C3%A9%C3%AD%C3%A1%C3%B3%C3%BA%C3%BD%C3%B1%C2%BD%C2%A7%3F%3FabcABC%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD!%23%C2%A4%25%26()%3D%60%40%C2%A3%24%E2%82%AC%7B%5B%5D%7D%2B%C2%B4%C2%A8%5E~%27-_%2C%3B.txt
And I get it. The constructed link works ok in the latest versions of IE and Chrome but fails in Firefox. After some investigation I've found that in Firefox encodeURIcomponent works differently. Here's actual result in Firefox:
/rest/get?name=%3F%3FabcABC%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD%EF%BF%BD!%23%EF%BF%BD%25%26%28%29%3D%60%40%EF%BF%BD%24%3F{[]}%2B%EF%BF%BD%EF%BF%BD^~%27-_%2C%3B.txt
Visual comparison (Chrome link is on the left and Firefox link is on the right):
I've also tried to copy and paste the valid link (constructed in Chrome) to Firefox and it works ok.
Why do I get different results?
I̶s̶ ̶i̶t̶ ̶a̶ ̶b̶u̶g̶ ̶w̶i̶t̶h̶ ̶̶e̶n̶c̶o̶d̶e̶U̶R̶I̶c̶o̶m̶p̶o̶n̶e̶n̶t̶(̶)̶̶ ̶i̶n̶ ̶F̶i̶r̶e̶f̶o̶x̶?̶
Does Firefox use a different encoding in encodeURIComponent()?
UPD. I've found similar questions (encodeURIComponent behaves differently in browsers for China as location [搜索] and
encodeURIComponent difference with browsers and ä-ö-å characters [äöå]), both without an answer.
UPD.2 Further investigation has shown that the following characters are encoded differently and causing 'File not found' exception on server:
你好
æøåÆØÅäöüïëêîâéíáóúýñ
½§¤
£€

I suppose your problem is not the encodeURIComponent() method. It's the encoding of whatever constructs file.name. Extend your question. How is file.name initialized? Where do the chars come from?

encodeURIComponent() is a native function so Firefox is obviously using some different implementation under the covers.
If you are stuck, then just deliver your own javascript implementation of encodeURIComponent(), then you'll get the same results across browsers. Here's a link how to get an open source copy of that:
encodeURIComponent algorithm source code

What's causing the limit of 512 bytes - openkeyval or something else

Hei!
I've found the superb service at http://openkeyval.org for storing simple key value from any webapps. From the docs it seems like it allows 64kBytes of data, put from what I see it's only possible to store 512 bytes.
See the example below (press load to load data from my key, and save to store back into key)
http://jsfiddle.net/larsi/h8Mbg/
Any ideas what might be causing the limit?
Regards Lars Erik

the problem is that you are doing GET request instead of POST, to send a big portions of data you have to use POST. This code worked on my Chrome, but it could be only implementation of Chrome, so other browsers could not support such data transfer via GET
update
there is an issue regarding your problem and here is the link of existing issue on openkeyval's github:
https://github.com/shinyplasticbag/openkeyval/issues/14