elektroelch.net – blog

Chrome extensions, Manifest v3 and local storage views

The other day I started coding a Chrome extension that makes heavy use of Chrome’s IndexedDB. Until this time then I had no problem inpecting any local storage using the DevTool’s “Application” tab. Those were extensions that used Manifest v2 but as of June 2023 Google will only acept Manifest v3 extensions.
One of the main changes is that background pages are replaced with service workers. So I changed my code accordingly from:

"background": {
    "page": "background/background.html"
  },

to

"background": {
	"service_worker": "background.js",
  }

and coded happily on. When I reached the local storage part and wanted to check the local storage by clicking on the new “service worker” link:

Surprisingly the IndexedDB pane in the “Application” tab was empty though I definitely knew that there was data stored:

So what was happening? After a long search on the Internets I came across an answer on StackOverflow that saved my day.

If your extension contains a popup you can right click and select “Inspect” to open the correct DevTools window:

And there you go:

But what do you do if your extension does not containa popup? There is a solution though it’s a bit more complicated.
Open the extension page and look for the extension’s ID:

Copy that ID and enter the following URL into the address bar, replacing “ID” with the actual ID:

chrome-extension://ID/manifest.json

Right click on the window and select “Inspect”:

One last problem: In contrast to the standard DevTools popup this one disappears if you reload the extension. Fortunately you can bookmark the tab:

Update: You don’t actullay need to insert the ID manually but you can click on any script in your default Devtools window (opened with “Inspect views service worker” link), right click on any script in the “Sources” pane, select “Open in new tab” and, just like above, right click the tab and select “Inspect”:

The only question that remains is: Why, Google, why has this be so complicated?

How-to split a number into equal chunks

The other day I had to iterate over a large number of items but to avoid a timeout I could only compute a certain amount at a time. So I had to split the number into equal chunks and a remainder. Here’s an easy way to determine the chunk size:

$totalNumber = 50321;
$chunkSize = 1023;

$remainder =  $totalNumber % $chunkSize;
$chunks = ($totalNumber - $remainder) / $chunkSize;

The code return the following values:
$remainder => 194
$chunks => 49
Verification: (49 * 1023) + 194 = 50321

How does it work?
In line 4 $totalNumber is divided by a modulo operator (“%” is the PHP token for modulo). The operator returns the remainder of the division (194 in this case). By subtracting this value from $totalNumber it becomes a whole number multiple of $chunks and the division with $chunkSize equals the desired number of $chunks (line 6).
Now you have the number of necessary iterations and the remaining part.

Firefox Addon: Add options menu to addon icon

Especially during development it’s annoying to reach the option page of a Firefox addon:

  1. Hamburger
  2. Addons and Themes
  3. …
  4. Options

There should be a faster way. At least for your own Add-ons you can quite easily add an “Options” menu item to the browser action:

browser.contextMenus.create({
    title: 'Options',
    contexts: ['browser_action'],
    onclick: () => {
      browser.runtime.openOptionsPage();
    },
  });

Additionally to have to add a new permission to the manifest.json file:

 "permissions": ["contextMenus"],

That was easy!

Set selections in a multiple select element with ES6

If you’re looking on the web for a solution to programmatically set the selections of a multiple select element in JavaScript you most likely find answers using jQuery, an indexed loop and an if condition, or some other complicated stuff. Modern browsers and ES6 gives you a simple solution in (almost) a single line of code:

<select id="selectElement" size="3" multiple>
    <option value="oranges">Oranges</option>
    <option value="apples">Apples</option>
    <option value="cherries">Cherries</option>
</select>

let selectElement = document.getElementById('selectElement');
let a = ['oranges', 'cherries'];
for (option of selectElement.options) option.selected = 
    a.includes(option.value);

There you go!

(Photo by Anthony Martino on Unsplash)

Big Tech 0wns web development

Web development is based on free software by developers like you and me, isn’t it? At first glance, this seems to be the case. Let’s take a look at the main tools modern web is mainly developed with nowadays:

  1. Visual Studio Code
  2. TypeScript
  3. React
  4. npm
  5. GitHub
  6. Chrome

Most of the tools are Open Source projects (VS Code only in parts, npm is proprietary). So where are the big companies? Well, all six tools and sites are owned by Big Tech:

  1. Microsoft
  2. Microsoft
  3. Facebook
  4. Microsoft
  5. Microsoft
  6. Google

The tools we use all day rise and fall with the benevolence of companies typically seen as enemies of Free Software by the majority of Open Source developers.

Especially GitHub and npm are irreplaceable because of their large data collection. If Microsoft decides to pull the plug from one moment to the next, the access to the vast collection of free code will be gone at least for some time and the build processes of millions of programs will break.

Of course, these services can and would be replaced by others, but it would take some time until dominant services will emerge and web developers would need to find an interim way of accessing their externalized source code.

(Photo by Max Bender on Unsplash)

Supperfood – Not so tasty after all

This month’s surprise box from Degustabox contained two bottles of “Superfood” by the Austrian company Friya. With basil seeds. OK, nowadays basil seems to be a superfood, too.
The stuff isn’t too tasty after all. The basil seeds are covered with a slimy substance. The whole thing looks like frog spawn.

 

The drink is quite alright but the frog spawn (the basil seeds) is quite disgusting. I really don’t need to have it a second time. I have another bottle containing Chia seeds but I’m not sure about it…

WordPress: add_filter or add_action? It actually doesn’t matter!

It’s a doctrine of WordPress plugin development:

Use actions to expand the functionality and filters to change information.

We’ve all heard it, we always follow that demand. Always? Well…

… if I want to add some functionality and nowhere near or far there is an action hook in the core but only a filter hook, I use that hook without considering the doctrine.

Surprisingly it works. But why? If we all insist that you have to use the right hook type, there has to be a difference between them. Let’s take a look behind the scenes (/wp-includes/plugin.php):

function add_action($tag, $function_to_add, $priority = 10, $accepted_args = 1) {
   return add_filter($tag, $function_to_add, $priority, $accepted_args);
}

What? add_action does nothing but call add_filter and nothing else? There is no difference in functionality, it’s only a different name. So there is no reason why you shouldn’t use add_filter instead of add_action if you have no other solution.

I don’t say that you should interchange filter and action hooks at will. Using the correct hook type makes your code more readable and maintainable, for yourself and for others. Nevertheless, if there’s not other way to accomplish your goal but to use a filter hook instead of an action, don’t hesitate, it virtually makes no difference.