Harsh Kansagara theharshin

Two way iframe communication

The main difference between the two pages is the method of sending messages. Recieving messages is the same in both.

Parent

Send messages to iframe using iframeEl.contentWindow.postMessage Recieve messages using window.addEventListener('message')

iframe

Nice answer on stackoverflow to the question of when to use one or the other content-types for POSTing data, viz. application/x-www-form-urlencoded and multipart/form-data.

“The moral of the story is, if you have binary (non-alphanumeric) data (or a significantly sized payload) to transmit, use multipart/form-data. Otherwise, use application/x-www-form-urlencoded.”

Matt Bridges' answer in full:

The MIME types you mention are the two Content-Type headers for HTTP POST requests that user-agents (browsers) must support. The purpose of both of those types of requests is to send a list of name/value pairs to the server. Depending on the type and amount of data being transmitted, one of the methods will be more efficient than the other. To understand why, you have to look at what each is doing

Upload a file with $.ajax to AWS S3 with a pre-signed url

When you read about how to create and consume a pre-signed url on this guide, everything is really easy. You get your Postman and it works like a charm in the first run.

Then you open your browser, try your usual $.ajax() and send your PUT operation, and you hit the cold iced wall of AWS error message, a simple <Code>SignatureDoesNotMatch</Code> that will steal hours from your productivity.

So here I come to save you and give you a free working example of how to upload a file directly to AWS S3 from your browser. You are wellcome :).

⚠️ This gist is no longer updated! For maintained, improved and even more extended guide click here.

How to use Discord Webhook

It's a JSON

First, learn JSON. It's not programming language, not even close. Just follow syntax rules and you will be fine.

Now that Electron has hit Chrome's 60s we can have proper module support. But of course, the standard (for very good reasons) prevents loading modules from file: and it makes sense for both Electron and NW.js to adhere to the statusquo.

So if you were really excited and this bums you, don't worry, you are in for awesome things.

The future Electron eco-system offers two options for native ES modules:

Custom Electron protocol via Chromium's module loading subsystem
Custom NodeJS loaders via Node's module loading subsystem recommended

	var myConfObj = {
	iframeMouseOver : false
	}
	window.addEventListener('blur',function(){
	if(myConfObj.iframeMouseOver){
	console.log('Wow! Iframe Click!');
	}
	});

	document.getElementById('YOUR_CONTAINER_ID').addEventListener('mouseover',function(){

	// from http://scratch99.com/web-development/javascript/convert-bytes-to-mb-kb/
	function bytesToSize(bytes) {
	var sizes = ['Bytes', 'KB', 'MB', 'GB', 'TB'];
	if (bytes == 0) return 'n/a';
	var i = parseInt(Math.floor(Math.log(bytes) / Math.log(1024)));
	if (i == 0) return bytes + ' ' + sizes[i];
	return (bytes / Math.pow(1024, i)).toFixed(1) + ' ' + sizes[i];
	};

	document.querySelector('[contenteditable]').addEventListener('paste', function (event) {
	event.preventDefault();
	document.execCommand('inserttext', false, event.clipboardData.getData('text/plain'));
	});

	const {BrowserWindow} = require('electron');

	const win = BrowserWindow.getAllWindows()[0];
	const ses = win.webContents.session;

	ses.clearCache(() => {
	alert("Cache cleared!");
	});