Favorites and bookmarklets in Microsoft Edge

I use Microsoft Edge as my primary browser since Windows 10 was released, and I am really satisfied with it. I don’t miss the plugins, but saving a bookmarklet was trickier than I thought.

Let’s take the Pinterest bookmarklet, the Pin It Button as an example. In every other browser you can navigate to the webpage of the bookmarklet, and drag the button which contains the JavaScript code to your favorites. For security reasons this does not work in Edge, but you can fix it.

The case was much simpler before the major update in November 2015, because the favorites were stored in the file system, in this folder:

C:\Users\{FELHASZNÁLÓNÉV}\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC\MicrosoftEdge\User\Default\Favorites

According to the sources all over the Internet, now they sit in the spartan.edb ESE database here:

C:\Users\{FELHASZNÁLÓNÉV}\AppData\Local\Packages\Microsoft.MicrosoftEdge_8wekyb3d8bbwe\AC\MicrosoftEdge\User\Default\DataStore\Data\nouser1\120712-0049\DBStore

Because this is a database, you need special tools and special care to edit it, but luckily it seems that the browser also uses registry. I managed to find my favorites in this location in the registry:

HKEY_CLASSES_ROOT\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Storage\microsoft.microsoftedge_8wekyb3d8bbwe\MicrosoftEdge\FavOrder\FavBarCache

Based on this, I could add the Pinterest bookmarklet to my browser with these steps:

1. I navigated to the page of the Pinterest bookmarklet, right clicked the “Pin It” button, and then selected the Copy Link item from the menu to copy the JavaScript code of the bookmarklet to the clipboard.
2. After this I added this page to my favorites just to have the Pinterest icon for my bookmarklet.
3. I started Regedit, and navigated to the path above.
4. The folder with the largest number contains the data for the favorite item I created on Step 2. I pasted the JavaScript code from the clipboard to the url key.
5. I restarted the browser.

This is totally unofficial, not supported and not a perfect solution, but works on my machine.

 

Technorati-címkék: Microsoft Edge,bookmarklet,registry,browser

Mixed content warning

It is so sad, when a webpage falls apart in the browser, like this one in Chrome:

Why is that? Oh, isn’t it obvious? The explanation is there, let me help you:

It is called the mixed content warning, and although it is a warning, it is very easy to miss. Let’s see the same page in Firefox:

Do you get it? Here it is:

Internet Explorer is not so gentle, it immediately calls the user’s attention:

Although you don’t have to search for a shield icon (which is one of the most overused symbol in the IT history) here, because you immediately receive a textual message, the situation is not really better. Average users don’t understand this message and the real cause behind it. What’s more, not only users don’t get it, but also web developers don’t understand the security consequences, otherwise there won’t be any page with this warning at all.

It is so easy to get rid of the mixed content warning: just ensure that if you load the page via https:// protocol, then you must load all referenced content (yes, all of them) via https as well. If you have a single http:// URL in your page, then the browser will trigger the mixed content warning. If you load content from a third party domain and you cannot use relative URLs, then start your reference URLs with “//”, which tells the browser to use the same protocol which was used to load the page itself. It is called the “protocol relative”, “scheme relative” or “scheme-less relative” URL, and you can find its description already in the RFC 3986 (dated January 2005) which specifies the URI syntax. Thankfully all browsers understand it as well.

It is time to fix these pages, and let the browsers sooner or later completely block these poorly implemented pages.

 

Technorati-címkék: security,browser,SSL

Firefox vs UTF-8

I had an unusual issue while I was updating the MSDNAA site of our university: the pages rendered correctly when I opened them from my own computer, but not from the server. Almost all browsers displayed them perfectly, except Firefox that showed ugly characters instead of the special Hungarian accented chars.

I checked the files, all of them were saved correctly in UTF-8 with the byte-order-mark in the beginning – which was not hard to recognize thanks to Firefox that rendered them on the page: 

Because the site now consists of brand new HTML5 pages, all page contains the <meta charset="utf-8" /> line, but I also added the classic Content-Type line for sure – in vain.

After the quick checks, back to Rule #1: When in doubt, start Fiddler! Fiddler showed me the following header in the response:

Content-Type: text/html; charset=iso-8859-1

This was the moment when I understood why the old files were all saved in ISO-8859-1: because this header is forced by the webserver! And the setting in the header overwrites the setting in the page – at least in Firefox now.

Because the site runs on Apache in a shared hosting environment without ASP.NET, PHP or admin access, server side code was not an option to overwrite the header. None the less the final solution became quite simple. I just added this single line to the .htaccess file in the root of the site:

AddDefaultCharset UTF-8

The settings in the root are applied to the subfolders as well.

 

Technorati-címkék: Apache,encoding,Firefox