site  contact  subhomenews

Killing that persistent SM popup

January 09, 2015 — BarryK
Back in late 2013 and early 2014, when I was last working intensely on Quirky, testers reported the "persistent popup" problem with SeaMonkey.

When Quirky is installed to a USB stick, the first time that SeaMonkey is started, it is slow, as it has to create a heap of cache files in /root/.mozilla/seamonkey, and doing this via the serial USB interface causes a significant startup delay.

To let users know that SM is loading and the window will soon appear, I created a first-time-only popup window, that just has the information that SM is loading for the first time and is a bit slow because it is creating cache files.

Fine, except that it is only supposed to run once, never again, but some testers reported that it persisted, popping up everytime they started SM.

I was just about pulling my hair out, because what they were reporting defied all logic. It only popped up once for me, and for many other testers.

Anyway, forward to now, and long-time Puppy enthusiast 'pakt' has suggested that the cause is because some testers are clicking the box to run SM as user 'spot' (in QuickSetup).

The penny dropped. Yep, that's it. That thought never occurred to me, as I never run SM as spot. Now, I think that I have implemented a fix.

Some technical details:
The two files that I have modified are in woofQ, support/setup-spot and rootfs-complete/usr/bin/seamonkeyQNEW, that become /usr/bin/setup-spot and /usr/bin/seamonkey in a built puplet.

When a user chooses to run SM as spot, setup-spot renames /usr/bin/seamonkey as seamonkey.bin, and creates a new script named seamonkey.
The script seamonkey does some housekeeping for running as spot, then as user spot calls seamonkey.bin. The latter creates the popup.

When running as 'root', /usr/bin/seamonkey (or seamonkey.bin for spot) launches a small script as a separate process, that puts up the popup, then waits for SM to load, then changes /usr/bin/seamonkey to a symlink to /usr/lib/seamonkey/seamonkey.

Whoever, when launched as user 'spot', that separate process is unable to perform the symlink operation. In fact, it must not.
What it must do is change /usr/bin/seamonkey.bin to a symlink to /usr/lib/seamonkey/seamonkey.
Which I am now doing in script /usr/bin/seamonkey (while still running as root).

When SM is run as spot, the script /usr/bin/seamonkey will remain in place. if the user ever decides to change SM to run as root, /usr/bin/seamonkey is deleted, and /usr/bin/seamonkey.bin is renamed to /usr/bin/seamonkey.

That may all seem a bit convoluted, but the steps are all quite logical. I had to think through it carefully though, as haven't worked on this since early 2014.

I also fixed another problem. When run SM as spot, the popup stays up for 40 seconds, beyond when SM has loaded. Now it goes away as soon as SM window appears.

Tags: linux