This is basically the same as bug #870297, but for LXDM.
Systems using LXDM have no entries in the utmp record for logins, so tools like ’w’ and ’who’ do not show LXDM sessions.
Testcase:
1. Start Lubuntu system
2. Log into session
3. Open gnome-terminal
4. Run ’who’ command
Expected result:
You should see TWO entries (the first is from LXDM, the second is from gnome-terminal):
tty7 YYYY-MM-DD HH:MM
pts/0 YYYY-MM-DD HH:MM (:0)
Observed result:
You see only one entry:
pts/0 YYYY-MM-DD HH:MM (:0)
Additional info:
Used gnome-terminal just for consistency with the LightDM report; lxterminal also doesn’t seem to update login records so if you use it instead, observed result is actually ”no entries at all” (and issue for another report). Also, bug #1027805 about wtmp records is similarly applicable to LXDM, but that remains to be fixed even in LightDM…
Also reproducible with chromium-browser 28.0.1500.52-0ubuntu1.12.04.2 (in 12.04).
As the original reporter, I’m confirming that 5.20.0-0ubuntu2 from -proposed does contain the fix for this bug, i.e. the issue I reported above is no longer reproducible. I’m only hesitant about tagging this ’verification-done’ because PerformingSRUVerification is pretty adamant about having a solid test case and I’m not sure my sloppy initial report qualifies.
jani@saegusa:~$ LC_ALL=C apt-cache policy unity
unity:
Installed: 5.20.0-0ubuntu2
Candidate: 5.20.0-0ubuntu2
Version table:
*** 5.20.0-0ubuntu2 0
500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 Packages
100 /var/lib/dpkg/status
5.18.0-0ubuntu2 0
500 http://archive.ubuntu.com/ubuntu/ precise-updates/main amd64 Packages
5.10.0-0ubuntu6 0
500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
Christopher, your test packages do indeed fix this, excellent! As I mentioned in the report, this was 100% reproducible with the packages from -proposed, and now with the packages from your PPA I could no longer reproduce it at all, during the multiple test logins I did.
Definitely not a showstopper for me Christopher, just a minor annoyance, so it’s a go-ahead from me. Thanks for asking!
Yep, that’s exactly the issue as it occurs here too. Thanks for looking into this Christopher! If you do get this narrowed down and need testing for potentially fixed builds, I’ll be happy to try them out.
Hi Christopher, sure. For the test user, I just go to the top right cog menu, select ”Startup Applications…” and ”Add” Firefox (/usr/bin/firefox). Firefox remembers the window size, so I start it once (manually), maximize the window and then close it. On the next login, it should start maximized.
Verifying that for both test cases the issue is no longer reproducible with the proposed packages. In other words, results with packages from -proposed are as described in ”Expected:” for each test case. (For both cases the issue was reproducible here with 1:0.9.7.0~bzr19-0ubuntu10.)
jani@saegusa:~$ LC_ALL=C apt-cache policy compiz-plugins-main compiz-plugins-main-default
compiz-plugins-main:
Installed: 1:0.9.7.0~bzr19-0ubuntu10.1
Candidate: 1:0.9.7.0~bzr19-0ubuntu10.1
Version table:
*** 1:0.9.7.0~bzr19-0ubuntu10.1 0
500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 Packages
100 /var/lib/dpkg/status
1:0.9.7.0~bzr19-0ubuntu10 0
500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
compiz-plugins-main-default:
Installed: 1:0.9.7.0~bzr19-0ubuntu10.1
Candidate: 1:0.9.7.0~bzr19-0ubuntu10.1
Version table:
*** 1:0.9.7.0~bzr19-0ubuntu10.1 0
500 http://archive.ubuntu.com/ubuntu/ precise-proposed/main amd64 Packages
100 /var/lib/dpkg/status
1:0.9.7.0~bzr19-0ubuntu10 0
500 http://archive.ubuntu.com/ubuntu/ precise/main amd64 Packages
I tested 5.20 from Shuduo’s PPA and for me it reproduces the issue just the same as -proposed. To be sure, I then went back down to release versions in all the other packages (so that the only change wrt. released is again just Unity being 5.20, just now from the PPA), and the issue remained. Downgrade Unity to 5.18 and it again goes away.
But this looks like a speed issue, so Unity may not be directly at fault: any apps started once the desktop is fully loaded open as truly maximized, so a workaround is setting autostarted apps to start after a delay. Perhaps Unity going from 5.18 to 5.20 here causes just enough delay for those apps to start before whatever the component is that should fuse the menus with appindicator. The autostarting facility should wait for that component, or the component should be also able to fuse menus for existing windows once it gets up and running.
Incidentally, any appindicator-related packages’ versions also don’t seem to matter for this once Unity is 5.20. I think I’ll try upgrading just those to their -proposed versions next (so that Unity remains at 5.18) just to cover all angles.
With Unity 5.20.0-0ubuntu1 from -proposed, maximized windows opened during login by autostarting apps have their top bar visible underneath the desktop top bar (indicator-appmenu) as if unmaximized, but with the window ’maximize’ button indicating a maximized window – i.e. first click on it results in the window getting smaller. The second click on it then actually maximizes the window so that the top bar merges into the desktop top bar (indicator-appmenu).
This problem appears consistently on every login, after I’ve enabled -proposed and installed Unity 5.20 from there. It never appears when I have 5.18 from -updates. Annoyingly, I am unable to reproduce it in a VM (for a nice demonstration video), but I am able to reproduce it with a newly created user account on the host (i.e. without the configuration from my main user account).
I could’ve taken a screenshot of how it looks right after login. I’ll do that in a minute.
Edit: autostarting apps.