Linux native notifications: Add hack for xfce4-notifyd spec version

Linux native notifications: Add hack for xfce4-notifyd spec version

This CL worksaround xfce4-notifyd returning a spec version of 0.9 when
it really has a spec version of 1.2.

Xfce bug (opened by me) for this:
https://bugzilla.xfce.org/show_bug.cgi?id=13578

BUG=676220
R=peter@chromium.org,thestig@chromium.org

[Lei Zhang, 2017-05-15 22:32:06]

How do we know there isn't an old version of xfce4-notifyd that really only
implements the 0.9 version of the spec?

https://codereview.chromium.org/2883983004/diff/1/chrome/browser/notification...
File chrome/browser/notifications/notification_platform_bridge_linux.cc (right):

https://codereview.chromium.org/2883983004/diff/1/chrome/browser/notification...
chrome/browser/notifications/notification_platform_bridge_linux.cc:470: // Hack
for xfce4-notifyd.  It says it only supports spec
Can you reference https://bugzilla.xfce.org/show_bug.cgi?id=13578 ?

[Peter Beverloo, 2017-05-15 22:38:58]

I dislike doing this, sorry.

As I said previously, my strong preference is to set a quality bar for ourselves
and asking notification centers to match this. Our goal is to provide a good and
predictable experience to users and developers, so we get a say in this.

Making this sort of exceptions sets a bad precedence. Do we fully understand why
xfce4-notifyd doesn't advertise 1.2 support? Even if they support the new hints,
have they caught up with any other requirements introduced between versions 0.9
and 1.2?

M60 won't become stable until the week of August 1st, and even beta is still a
month or so away. If they truly already are compatible with 1.2 of the
freedesktop notifications protocol, bumping up the number should be trivial for
them.

I'm happy to be convinced otherwise by the way, I'd just like to get a better
understanding of the justification. We try to avoid hacks like this in the code
wherever possible.

[Tom (Use chromium acct), 2017-05-16 19:06:34]

On 2017/05/15 22:32:06, Lei Zhang wrote:
> How do we know there isn't an old version of xfce4-notifyd that really only
> implements the 0.9 version of the spec?
> 

We don't :(

On 2017/05/15 22:38:58, Peter Beverloo wrote:
> I dislike doing this, sorry.
> 
> As I said previously, my strong preference is to set a quality bar for
ourselves
> and asking notification centers to match this. Our goal is to provide a good
and
> predictable experience to users and developers, so we get a say in this.
> 
> Making this sort of exceptions sets a bad precedence. Do we fully understand
why
> xfce4-notifyd doesn't advertise 1.2 support? 

Probably they only supported 0.9 at some point, and then added support for
1.0-1.2 features and forgot to update the spec version string.

Then again, this doc includes the revision history:
https://people.gnome.org/~mccann/docs/notification-spec/notification-spec-1.1...
And GetServerInformation only started returning the spec_version in 1.0, so I
don't see how they could be at 0.9 :S

> Even if they support the new hints,
> have they caught up with any other requirements introduced between versions
0.9
> and 1.2?

The only differences since version 0.9 are:
* GetServerInformation now returns spec_version
* File images were added in 1.1
* Image hints were renamed in 1.2
AFAIK xfce4-notifyd has all the 1.2 features.

> M60 won't become stable until the week of August 1st, and even beta is still a
> month or so away. If they truly already are compatible with 1.2 of the
> freedesktop notifications protocol, bumping up the number should be trivial
for
> them.

Unfortunately it's not that simple in the Linux ecosystem.  Most distros (like
Ubuntu) have their package versions pinned and they won't change until the next
release of the distro.  Security fixes will be backported, but it would be
difficult to get all distros to backport this change.

> I'm happy to be convinced otherwise by the way, I'd just like to get a better
> understanding of the justification. We try to avoid hacks like this in the
code
> wherever possible.

Check the 7 day aggregation for Notifications.Linux.BridgeInitializationStatus
and see how many users are affected by this (and I'm not even sure if all of
those are coming from Xfce)

Maybe we can just avoid the hack altogether.  Spec version 1.1 was introduced on
Aug 25, 2007.  This is more than enough time for all the servers and distros to
catch up.
I think that we should remove the spec version check and always pass BOTH an
"image_path" AND an "image-path" hint.  wdyt?

[Peter Beverloo, 2017-05-17 13:42:35]

On 2017/05/16 19:06:34, Tom Anderson (DO NOT USE) wrote:
> On 2017/05/15 22:32:06, Lei Zhang wrote:
> > How do we know there isn't an old version of xfce4-notifyd that really only
> > implements the 0.9 version of the spec?
> > 
> 
> We don't :(
> 
> On 2017/05/15 22:38:58, Peter Beverloo wrote:
> > I dislike doing this, sorry.
> > 
> > As I said previously, my strong preference is to set a quality bar for
> ourselves
> > and asking notification centers to match this. Our goal is to provide a good
> and
> > predictable experience to users and developers, so we get a say in this.
> > 
> > Making this sort of exceptions sets a bad precedence. Do we fully understand
> why
> > xfce4-notifyd doesn't advertise 1.2 support? 
> 
> Probably they only supported 0.9 at some point, and then added support for
> 1.0-1.2 features and forgot to update the spec version string.
> 
> Then again, this doc includes the revision history:
>
https://people.gnome.org/~mccann/docs/notification-spec/notification-spec-1.1...
> And GetServerInformation only started returning the spec_version in 1.0, so I
> don't see how they could be at 0.9 :S
> 
> > Even if they support the new hints,
> > have they caught up with any other requirements introduced between versions
> 0.9
> > and 1.2?
> 
> The only differences since version 0.9 are:
> * GetServerInformation now returns spec_version
> * File images were added in 1.1
> * Image hints were renamed in 1.2
> AFAIK xfce4-notifyd has all the 1.2 features.
> 
> > M60 won't become stable until the week of August 1st, and even beta is still
a
> > month or so away. If they truly already are compatible with 1.2 of the
> > freedesktop notifications protocol, bumping up the number should be trivial
> for
> > them.
> 
> Unfortunately it's not that simple in the Linux ecosystem.  Most distros (like
> Ubuntu) have their package versions pinned and they won't change until the
next
> release of the distro.  Security fixes will be backported, but it would be
> difficult to get all distros to backport this change.
> 
> > I'm happy to be convinced otherwise by the way, I'd just like to get a
better
> > understanding of the justification. We try to avoid hacks like this in the
> code
> > wherever possible.
> 
> Check the 7 day aggregation for Notifications.Linux.BridgeInitializationStatus
> and see how many users are affected by this (and I'm not even sure if all of
> those are coming from Xfce)
> 
> Maybe we can just avoid the hack altogether.  Spec version 1.1 was introduced
on
> Aug 25, 2007.  This is more than enough time for all the servers and distros
to
> catch up.
> I think that we should remove the spec version check and always pass BOTH an
> "image_path" AND an "image-path" hint.  wdyt?

Thank you for the thorough explanation!

We already switch the hint name for file paths based on the version, and since
the value should be in the tens of bytes I don't have big concerns there.
However, since file images were added in 1.1, how do we know that either of them
will be supported if the notification server advertises 0.9? Can we rely on
"icon-static" for this?

[Tom Anderson, 2017-05-17 22:02:00]

On 2017/05/17 13:42:35, Peter Beverloo wrote:
> On 2017/05/16 19:06:34, Tom Anderson (DO NOT USE) wrote:
> > On 2017/05/15 22:32:06, Lei Zhang wrote:
> > > How do we know there isn't an old version of xfce4-notifyd that really
only
> > > implements the 0.9 version of the spec?
> > > 
> > 
> > We don't :(
> > 
> > On 2017/05/15 22:38:58, Peter Beverloo wrote:
> > > I dislike doing this, sorry.
> > > 
> > > As I said previously, my strong preference is to set a quality bar for
> > ourselves
> > > and asking notification centers to match this. Our goal is to provide a
good
> > and
> > > predictable experience to users and developers, so we get a say in this.
> > > 
> > > Making this sort of exceptions sets a bad precedence. Do we fully
understand
> > why
> > > xfce4-notifyd doesn't advertise 1.2 support? 
> > 
> > Probably they only supported 0.9 at some point, and then added support for
> > 1.0-1.2 features and forgot to update the spec version string.
> > 
> > Then again, this doc includes the revision history:
> >
>
https://people.gnome.org/~mccann/docs/notification-spec/notification-spec-1.1...
> > And GetServerInformation only started returning the spec_version in 1.0, so
I
> > don't see how they could be at 0.9 :S
> > 
> > > Even if they support the new hints,
> > > have they caught up with any other requirements introduced between
versions
> > 0.9
> > > and 1.2?
> > 
> > The only differences since version 0.9 are:
> > * GetServerInformation now returns spec_version
> > * File images were added in 1.1
> > * Image hints were renamed in 1.2
> > AFAIK xfce4-notifyd has all the 1.2 features.
> > 
> > > M60 won't become stable until the week of August 1st, and even beta is
still
> a
> > > month or so away. If they truly already are compatible with 1.2 of the
> > > freedesktop notifications protocol, bumping up the number should be
trivial
> > for
> > > them.
> > 
> > Unfortunately it's not that simple in the Linux ecosystem.  Most distros
(like
> > Ubuntu) have their package versions pinned and they won't change until the
> next
> > release of the distro.  Security fixes will be backported, but it would be
> > difficult to get all distros to backport this change.
> > 
> > > I'm happy to be convinced otherwise by the way, I'd just like to get a
> better
> > > understanding of the justification. We try to avoid hacks like this in the
> > code
> > > wherever possible.
> > 
> > Check the 7 day aggregation for
Notifications.Linux.BridgeInitializationStatus
> > and see how many users are affected by this (and I'm not even sure if all of
> > those are coming from Xfce)
> > 
> > Maybe we can just avoid the hack altogether.  Spec version 1.1 was
introduced
> on
> > Aug 25, 2007.  This is more than enough time for all the servers and distros
> to
> > catch up.
> > I think that we should remove the spec version check and always pass BOTH an
> > "image_path" AND an "image-path" hint.  wdyt?
> 
> Thank you for the thorough explanation!
> 
> We already switch the hint name for file paths based on the version, and since
> the value should be in the tens of bytes I don't have big concerns there.
> However, since file images were added in 1.1, how do we know that either of
them
> will be supported if the notification server advertises 0.9? Can we rely on
> "icon-static" for this?

I'm actually not entirely sure what 'icon-static' does.  It might just be fore
the app_icon.

Enlightenment, for example, doesn't list 'icon-static', but does support icons
(then again, I think every server that I've tested seem to support icons). 

It's possible the servers that don't list 'icon-static' are just buggy, and
should list it ¯\_(ツ)_/¯

[Tom Anderson, 2017-05-18 01:07:44]

Description was changed from

==========
Linux native notifications: Add hack for xfce4-notifyd spec version

This CL worksaround xfce4-notifyd returning a spec version of 0.9 when
it really has a spec version of 1.2.

Xfce bug (opened by me) for this:
https://bugzilla.xfce.org/show_bug.cgi?id=13578

BUG=676220
R=peter@chromium.org,thestig@chromium.org
==========

to

==========
Linux native notifications: Add hack for xfce4-notifyd spec version

This CL worksaround xfce4-notifyd returning a spec version of 0.9 when
it really has a spec version of 1.2.

Xfce bug (opened by me) for this:
https://bugzilla.xfce.org/show_bug.cgi?id=13578

BUG=676220
R=peter@chromium.org,thestig@chromium.org
==========