[Desktop-packages] [Bug 1600622] Re: Screen doesn't lock or go to sleep when certain Chrome tabs are open

2019-01-13 Thread Jeremy Walker 
>If you have this bug, what is the result of opening a terminal, and running
>systemctl suspend and waiting for a minute?

Nothing happened for a few seconds, then my network turned off, then
both screens turned off.  I thought I was screwed, because my computer
has never come back to life from a "suspend" before, but when I pressed
some keys it (slowly) came back to normal.

So, it would seem that the command you provided (and I guess system
suspension in general) is working just fine ... despite my system being
in a state where my screens wouldn't turn off for power saving after
five minutes, as they normally would.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-session in Ubuntu.
https://bugs.launchpad.net/bugs/1600622

Title:
  Screen doesn't lock or go to sleep when certain Chrome tabs are open

Status in gnome-session package in Ubuntu:
  Confirmed

Bug description:
  $ lsb_release -rd
  Description:  Ubuntu 16.04 LTS
  Release:  16.04

  $ apt-cache policy gnome-session-bin
  gnome-session-bin:
    Installed: 3.18.1.2-1ubuntu1.16.04.1
    Candidate: 3.18.1.2-1ubuntu1.16.04.1
    Version table:
   *** 3.18.1.2-1ubuntu1.16.04.1 500
  500 http://es.archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   3.18.1.2-1ubuntu1 500
  500 http://es.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  I'm using gnome-session-flashback

  What happens:
  The screen doesn't lock when having certain pages in Chrome tabs

  Expected:
  The screen should lock after the configured timeout in settings.

  I've been having this issue sice before 14.04, which I recently
  upgraded (fresh install) to 16.04.

  After fresh install, the screen would turn down and lock the computer
  after 10 minutes (or whatever time I setup). At one point it stopped
  working. The screen never shuts down unless I manually lock the
  session with CTRL-ALT-L.

  I've followed the steps in
  https://wiki.ubuntu.com/DebuggingScreenLocking#Debugging_procedure

  The culprit seems to be that Chrome issues some suspend inhibitions
  through dbus when doing certain operations. Many people find this
  problem when using Yahoo Mail. I can reproduce it with Odoo. I'm
  pretty sure that Chrome is doing something else of what i've found
  out.

  1) Gnome screen saver works correctly. I can trigger it manually with:
  $ gnome-screensaver-command -a

  2) Gnome screen saver never receives the "session idle" status
  callback.

  3) When Chrome is not running, I can manually inhibit the idle status:
  $ gnome-session-inhibit --app-id test --reason "manual idle inhibit" 
--inhibit-only --inhibit idle:suspend
  Inhibiting until Ctrl+C is pressed...

  4) I can query the inhibitors:
  $ dbus-send --print-reply --dest=org.gnome.SessionManager 
/org/gnome/SessionManager org.gnome.SessionManager.GetInhibitorsmethod return 
time=1468170482.066533 sender=:1.19 -> destination=:1.1315311 serial=1329103 
reply_serial=2
     array [
    object path "/org/gnome/SessionManager/Inhibitor1686"
     ]
  $ gdbus call --session --dest org.gnome.SessionManager --object-path 
/org/gnome/SessionManager/Inhibitor1686 --method 
org.gnome.SessionManager.Inhibitor.GetAppId
  ('test',)
  $ gdbus call --session --dest org.gnome.SessionManager --object-path 
/org/gnome/SessionManager/Inhibitor1686 --method 
org.gnome.SessionManager.Inhibitor.GetReason
  ('manual idle inhibit',)
  $ gdbus call --session --dest org.gnome.SessionManager --object-path 
/org/gnome/SessionManager/Inhibitor1686 --method 
org.gnome.SessionManager.Inhibitor.GetFlags
  (uint32 12,)

  12=4(suspend) + 8(idle)

  5) When testing, I can inhibit for 70 seconds, idle timeout being 60
  (1 minute). After these 70 seconds pass, the screen locks.

  6) Regarding Chrome, this is the information I get when querying the 
inhibitor:
  GetAppId: ('/usr/bin/google-chrome-stable',)
  GetReason: ('Uploading data to 10.200.0.163',)
  GetFlags: (uint32 4,)

  The flags just inhibits suspend, not locking or entering powersaving
  mode.

  This inhibitor seems to stay for 10-15 seconds, then goes away for
  another 30-60 seconds. The screen NEVER locks when this tab is open.
  No matter the inhibitor is present or not.

  I'm not sure where to go on. If it's a Chrome bug it must be using
  other mechanisms to prevent the idle timeout. Any ideas on what to
  look for?

  Julian.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/1600622/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp

[Desktop-packages] [Bug 1600622] Re: Screen doesn't lock or go to sleep when certain Chrome tabs are open

2018-12-13 Thread Jeremy Walker 
The importance on this ticket is incorrect: it should not be marked
"low". According to https://dev.launchpad.net/BugTriage#importance)
"Low" is defined as "legitimate but that is not scheduled for Canonical
staff to fix in the next 6 months."

This is a MAJOR issue.  As W-barath-hotmail noted it can cause some
extremely serious side effects for anyone who relies on power
management.  As such, this ticket should have an importance of "High"
("we believe we will work on in the next six months").  To ignore it for
six or more months would be to deliberately cause serious user damage.

Also, this bug is difficult for users to track down. It's not like
problematic tabs flash red or something, so each user has to figure out
on their own that not only is Chrome the source of the problem, but a
specific tab within Chrome. As a result, the number of users affected by
this bug is undoubtedly much higher than what's reflected on this page,
as many affected users just aren't able to track the problem to this
page.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to gnome-session in Ubuntu.
https://bugs.launchpad.net/bugs/1600622

Title:
  Screen doesn't lock or go to sleep when certain Chrome tabs are open

Status in gnome-session package in Ubuntu:
  Confirmed

Bug description:
  $ lsb_release -rd
  Description:  Ubuntu 16.04 LTS
  Release:  16.04

  $ apt-cache policy gnome-session-bin
  gnome-session-bin:
    Installed: 3.18.1.2-1ubuntu1.16.04.1
    Candidate: 3.18.1.2-1ubuntu1.16.04.1
    Version table:
   *** 3.18.1.2-1ubuntu1.16.04.1 500
  500 http://es.archive.ubuntu.com/ubuntu xenial-updates/main amd64 
Packages
  100 /var/lib/dpkg/status
   3.18.1.2-1ubuntu1 500
  500 http://es.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

  I'm using gnome-session-flashback

  What happens:
  The screen doesn't lock when having certain pages in Chrome tabs

  Expected:
  The screen should lock after the configured timeout in settings.

  I've been having this issue sice before 14.04, which I recently
  upgraded (fresh install) to 16.04.

  After fresh install, the screen would turn down and lock the computer
  after 10 minutes (or whatever time I setup). At one point it stopped
  working. The screen never shuts down unless I manually lock the
  session with CTRL-ALT-L.

  I've followed the steps in
  https://wiki.ubuntu.com/DebuggingScreenLocking#Debugging_procedure

  The culprit seems to be that Chrome issues some suspend inhibitions
  through dbus when doing certain operations. Many people find this
  problem when using Yahoo Mail. I can reproduce it with Odoo. I'm
  pretty sure that Chrome is doing something else of what i've found
  out.

  1) Gnome screen saver works correctly. I can trigger it manually with:
  $ gnome-screensaver-command -a

  2) Gnome screen saver never receives the "session idle" status
  callback.

  3) When Chrome is not running, I can manually inhibit the idle status:
  $ gnome-session-inhibit --app-id test --reason "manual idle inhibit" 
--inhibit-only --inhibit idle:suspend
  Inhibiting until Ctrl+C is pressed...

  4) I can query the inhibitors:
  $ dbus-send --print-reply --dest=org.gnome.SessionManager 
/org/gnome/SessionManager org.gnome.SessionManager.GetInhibitorsmethod return 
time=1468170482.066533 sender=:1.19 -> destination=:1.1315311 serial=1329103 
reply_serial=2
     array [
    object path "/org/gnome/SessionManager/Inhibitor1686"
     ]
  $ gdbus call --session --dest org.gnome.SessionManager --object-path 
/org/gnome/SessionManager/Inhibitor1686 --method 
org.gnome.SessionManager.Inhibitor.GetAppId
  ('test',)
  $ gdbus call --session --dest org.gnome.SessionManager --object-path 
/org/gnome/SessionManager/Inhibitor1686 --method 
org.gnome.SessionManager.Inhibitor.GetReason
  ('manual idle inhibit',)
  $ gdbus call --session --dest org.gnome.SessionManager --object-path 
/org/gnome/SessionManager/Inhibitor1686 --method 
org.gnome.SessionManager.Inhibitor.GetFlags
  (uint32 12,)

  12=4(suspend) + 8(idle)

  5) When testing, I can inhibit for 70 seconds, idle timeout being 60
  (1 minute). After these 70 seconds pass, the screen locks.

  6) Regarding Chrome, this is the information I get when querying the 
inhibitor:
  GetAppId: ('/usr/bin/google-chrome-stable',)
  GetReason: ('Uploading data to 10.200.0.163',)
  GetFlags: (uint32 4,)

  The flags just inhibits suspend, not locking or entering powersaving
  mode.

  This inhibitor seems to stay for 10-15 seconds, then goes away for
  another 30-60 seconds. The screen NEVER locks when this tab is open.
  No matter the inhibitor is present or not.

  I'm not sure where to go on. If it's a Chrome bug it must be using
  other mechanisms to prevent the idle timeout. Any ideas on what to
  look for?

  Julian.

To manage notifications about this bug go to:

[Desktop-packages] [Bug 39328] Re: Disable scrolling on window list to flip through windows

2018-04-09 Thread Jeremy Walker 
Please don't let this ticket die.  It amounts to one new setting and one
new line (of pseudo-code):

onScroll() {
  if (someSetting) return; // new line
  doNormalScrollThing();
}

and would remove some *really* annoying behavior.

-- 
You received this bug notification because you are a member of Desktop
Packages, which is subscribed to libwnck in Ubuntu.
https://bugs.launchpad.net/bugs/39328

Title:
  Disable scrolling on window list to flip through windows

Status in GNOME Panel:
  Invalid
Status in One Hundred Papercuts:
  Invalid
Status in libwnck:
  Confirmed
Status in libwnck package in Ubuntu:
  Triaged

Bug description:
  On a laptop track pad, it's really easy to accidentally use the
  "scrolling goes through windows" feature of the new g-p. I believe
  this would warrant disabling the functionality (maybe only if a
  trackpad is detected? is this doable?) or at least offering an option
  to do so.

  As a workaround, you can install packages from the following PPA that were 
compiled with the “scrolling on task list” feature disabled.
  https://launchpad.net/~libwnck-noscroll/+archive/ppa

To manage notifications about this bug go to:
https://bugs.launchpad.net/gnome-panel/+bug/39328/+subscriptions

-- 
Mailing list: https://launchpad.net/~desktop-packages
Post to : desktop-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~desktop-packages
More help   : https://help.launchpad.net/ListHelp