Firefox Tab Sync Issues

Firefox again. Whenever I have time to waste, I try to configure its features to make working with a browser more productive. Incrementally, I’m getting there — by the year 2100 I should have reached optimum productivity. :-)

When I recently installed openSuse 13.2 on my laptop (fresh installation, except that the /home directory was preserved), and then opened Firefox (33.0) for the first time, it synchronized the tabs from my work computer (a desktop computer). All those tabs were pinned tabs, since I rarely have regular tabs open in the browser. (When I do, it’s mostly for searches, or for ebay which cannot handle pinned tabs well.) Anyway, looks I’ve been lucky with that pristine Firefox from the fresh installation. Normally, there seems to be no way of keeping tabs in sync across devices. Meh.

At least there’s a semi-automatic way of syncing tabs, but it’s well hidden in Firefox. From googling, I found that there must have been an option in the History sidebar (CTRL+H) at some point (2012 or so), labeled something like “tabs from other devices”. That would be nice to have, but apparently they removed it in newer Firefox versions. These days, what you do is open a new tab, then type about:sync-tabs in the address bar. Quite intuitive, I would say. :-)

firefox-sync-tabs

The prerequisite of seeing something here is that you’ve enabled Firefox Sync on your various devices. If that’s the case, Firefox will list the tabs from your other computers, tablets, or smartphones, grouped by device. Note that it will list only the tabs that aren’t already open on your current device. Also note that Firefox has its own ideas about what “open” is — any pinned tabs on your current machine are disregarded. In other words, if a page is open in a pinned tab, Firefox will still show it in the tabs from other devices list. However, Firefox will show pinned tabs from your other devices, which is kind of inconsistent, but helpful nevertheless.

Now you can double-click on the gray boxes, and they’ll be opened in a new tab. At the same time, they’ll disappear from the list.

Right-clicking on the sync-tabs page lets you refresh the open tabs list. If you mark a gray box with a left-click, then right-click on it, you get an additional option, which is to add it as a bookmark.

So, very limited functionality, and limited use.

I tried grouping tabs, too, but that’s a feature I’d consider not working properly, or at least it has a flawed design. It doesn’t work at all with pinned tabs (they appear in every tab group, no matter what you do), so you’re forced to use regular tabs. Also, tab groups are supposed to close tabs from other groups when you open them, but they don’t behave that way in my browsers (on Linux). And if I dare to manually close those other tabs that were opened from another tab group, guess what happens? The tab group is empty then. Oh boy. That’s usability spelled backwards.

Comments are welcome, but please don’t advice to switch to Chrome. While I do use Chrome when working with add-ons in Google Docs (because add-ons only work in Chrome), I have a pretty good idea how this world would look like if everyone consolidated on Chrome. I bite my tongue not to end this article with a little rant, so let me just say that I deem a properly working Firefox an important thing to have these days. Thanks for reading, and agreeing. :-)

2014/11/21 at 13:26 Hinterlasse einen Kommentar

MediaWiki toolbar missing after DSM update

Meh. Synology updated quite a few built-in components when updating the DSM (basically the “operating system” of the Synology NAS boxes) from DSM 5.0 to DSM 5.1. Look at my previous articles to see what stuff broke, and how I fixed it, or at least how I found a suitable workaround for broken functionality. Let me make it clear that I’m not blaming Synology for the issues I’ve been facing; but having to fix stuff in the aftermath is a nuisance, anyway.

Okay, so here’s the most recent issue I found, and how I fixed it. When editing a page in the MediaWiki on one of my NAS boxes (“zeus”), I found the toolbar was missing. Not a deal-breaker, but an inconvenience.synology-mediawiki-toolbar

In one of the articles I found by googling for “mediawiki toolbar missing” someone suggested to turn on the Firefox web console (formerly: JavaScript console, if I remember correctly), and see if there were any JavaScript errors when editing a page. So I turned it on (CTRL+Shift+K), and indeed, an error showed up (marked in the screenshot below):

synology-mediawiki-debug-GetVersion

Googling for that error message, I found a short article pointing out that the “mw.loader.version” function had been removed in a recent MediaWiki update. Thanks very much for that! :-) Fortunately, the article also had a link to the respective bug, and to the fix, which is here:

https://gerrit.wikimedia.org/r/#/c/114094/1/modules/jquery.wikiEditor.js,unified

Here’s how I applied the fix:

  1. Get on the command line, as root.
  2. In the directory where the MediaWiki is installed (/volume1/web/MediaWiki by default), either grep for “mw.loader.version”, or simply believe me that the file you need to edit is under extensions/WikiEditor/modules. So change directory there.
  3. Make a copy of the file (cp jquery.wikiEditor.js jquery.wikiEditor.js.ORIG).
  4. Edit jquery.wikiEditor.js — I’m using vi for this.
  5. Locate the line that contains the wrong function (in vi, press / and type mw.loader.version, then press Return).
  6. Change mw.loader.version to mw.loader.getVersion.
  7. Save the file, and quit the editor (in vi, this is :wq).
root@zeus:/volume1/web/MediaWiki/extensions/WikiEditor/modules> ls -l jquery.wikiEditor.js*
-rw-r--r--    1 http     http         21440 Nov 19 09:04 jquery.wikiEditor.js
-rw-r--r--    1 root     root         21437 Nov 19 08:40 jquery.wikiEditor.js.ORIG

When done, edit a Wiki page in Firefox. You might have to forcibly reload the page in Edit mode, because Firefox loves to load pages from cache. Now, the JavaScript error should be gone, and the toolbar should be back.

2014/11/19 at 09:21 Hinterlasse einen Kommentar

SyncMe Wireless

I’ve been using Rsync Backup on my Wiko Cink Peax 2 smartphone for half a year. Two days ago, it stopped working. That is, it refused to connect to my Synology NAS (DS 214se), complaining about “no matching algo kex”. There’s a lot of discussion going on about that error on the developer’s website:

Automatic Nightly Backups for Your Android Device to Your Computer | Guysoft’s Weblog

The reason for the error: The latest operating system update on the NAS removed some old SSH ciphers that were insecure. Rsync Backup uses those ciphers. The fix would be to re-add them, so I tried that. The result was that the SSH daemon on the NAS would refuse to start up. Also, fiddling with insecure ciphers isn’t particularly secure. The real fix would be to use secure ciphers for Rsync Backup, but apparently the developer has no plans to do that. So, looking for a replacement.syncmewireless

On the Play Store, I found SyncMe Wireless. Wow, what a nice tool! Its usability is brilliant, kudos to the author!

On startup, it ran me through the process of finding the computer to back up to, by scanning the local network for Windows computers. My Synology NAS are Linux boxes, but they have SMB enabled (Synology calls that Windows File Service, fair enough), so their drives and (shared) folders show up just like Windows drives. SyncMe uses plaintext login (username/password), so I’d recommend to use it only in a safe environment, which is what I had been intending to do, anyway.

After storing the connection information, SyncMe asked to create a sync profile, which in my case is a simple backup profile for the photos. So I did that, selecting the destination folder (on the NAS), and the source folder (DCIM/Camera on the smartphone). I deselected the SyncMe option to overwrite any existing files in the destination folder, so it will copy over only new photos, which is exactly what I want.

After saving the profile, it’s now a matter of three taps to back up my photos: open the app, select the profile, run the profile. Very neat, very quick.

2014/11/14 at 12:44

Synology Network Backup failing with rsync error

On November 10, 2014, I updated my Synology NAS boxes (DS214se) to the latest DSM (DSM 5.1-5004). Next day, I found that the Network Backup jobs scheduled in Task Scheduler were failing (I’m backing up shared folders from one box to another on the LAN). Unfortunately, in the logs that can be viewed under Backup & Replication / Logs, it just says “Information … Backup task started”, followed by “Error … Failed to backup task”, without details what caused the failure. Before the DSM update, Network Backup jobs worked without issues.

Synology support seems to be overwhelmed by tickets; I filed one on Monday, and got a reply on Wednesday that they’ll take 3 to 5 business days to get back to me. (Normally, the turnaround is more like < 1 day.)

So, googling, and then logging on to the source box via SSH. (The source box is the one where the data come from, and where the Network Backup jobs are run from the Task Scheduler.) Inspecting the rsync error log unveils this:

zeus> tail /var/log/rsync.error
 Nov 11 02:00:23 (20726) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9]
 Nov 11 02:15:05 (20907) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9]
 Nov 11 02:30:05 (21091) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9]
 Nov 11 02:45:05 (21272) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9]
 Nov 12 02:00:23 (15542) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9]
 Nov 12 02:15:05 (15722) [ERROR]: rsync error: rsync service is no running (code 43) at io.c(687) [Receiver=3.0.9]
...

The dates look right. In the error log, there aren’t any service is no running entries before November 11 (the day after I did the DSM update). Looks like rsyncd (the rsync daemon) isn’t running.

What the error lines don’t tell, and that took quite some more googling to find out, is that this is related to rsyncd on the target machine (the NAS where the backups end up). So I looked at the settings on the target machine, and voilà — the Enable network backup service checkbox wasn’t ticked. Ticking it, and then starting the Network Backup job manually on the source machine yielded success.

synology-backup-services

I can’t tell if it worked without the checkbox being ticked before the DSM update, or if the DSM update unticked the checkbox. In any case, Network Backup works again now, and I can sleep better again. :-)

2014/11/12 at 09:21 10 Kommentare

XSane: Konnte Scanner nicht starten — ungültiges Argument

Wollte heute Morgen mein frisches Foto für den Reisepass scannen. Vorschauscan funktionierte, Scannen nicht. XSane meldete:

Konnte Scanner nicht starten — ungültiges Argument.

Googeln erbrachte überwiegend die Empfehlung, den Ordner ~/.sane zu löschen und es noch mal zu probieren. Das funktionierte ebenfalls nicht.

Der wirkliche Grund scheint ein anderer zu sein: Das Passbild ist einfach zu klein. XSane mag es anscheinend nicht, wenn man nur 3,39 x 4,27 cm scannt. Erst wenn beide Werte (Höhe und Breite) etwa 5 cm betragen, zickt XSane nicht mehr rum, sondern scannt brav wie immer schon.

Meine Konfiguration (obwohl diese wahrscheinlich keine Rolle spielt): XSane 0.998 gestartet aus dem grafischen Tool HP Linux Imaging and Printing (HPLIP) 3.13.10 unter openSuse 13.1. Der Drucker/Kopierer/Scanner ist ein HP LaserJet 200 color MFP M276nw, sehr ordentliches Gerät übrigens.

2014/11/07 at 10:40

2013 wird geprüft

Die WordPress.com-Statistik-Elfen fertigten einen Jahresbericht dieses Blogs für das Jahr 2013 an.

Hier ist ein Auszug:

Eine Cable Car in San Francisco fasst 60 Personen. Dieses Blog wurde in 2013 etwa 2.500 mal besucht. Eine Cable Car würde etwa 42 Fahrten benötigen um alle Besucher dieses Blogs zu transportieren.

Klicke hier um den vollständigen Bericht zu sehen.

2014/01/01 at 23:10

Calendar doesn’t reload? Reload Akonadi!

Reminder to self: When KOrganizer refuses to reload your remote calendars, no matter how hard you press F5 (reload calendars), and when all hope is lost because even in the KDE system settings there’s no way to reload calendars, and when you’ve banged your head against the monitor often enough after reading all the good advice that suggests you should simply recreate your calendars with the same settings, then delete the old calendars: Wait. What you need to do is simple and straightforward, and if you weren’t a moron just like me, you’d have guessed it, anyway:

Reload Akonadi.

To do that, locate the funny little arrow up in the KDE system tray, right-click on the “Akonadi module” button, select “configure”, then select the “configuration of the Akonadi server” tab, and press the “restart” button. Go back to KOrganizer, reload your calendars, and voilá — they’re updated.

This is completely intuitive and perfectly easy to understand, but I keep forgetting it.

2013/05/16 at 15:41

Ältere Beiträge


November 2014
M D M D F S S
« Jan    
 12
3456789
10111213141516
17181920212223
24252627282930

Enter your email address to follow this blog and receive notifications of new posts by email.

Schließe dich 294 Followern an


Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 294 Followern an