notifications do not display content if not supported markup tags are used (aka <a href=... links)

[Alexander Sack]

1. notify-send "Test" 'before <a href="http://www.nothing.tld">link</a> after'

Result:
 Notification pops up only showing the title "Test"; the other content is not rendered at all.

Expected Result:
 Notification appears with title "Test", and body text "before link after".

Specification: <https://wiki.ubuntu.com/NotifyOSD#Sanitizing%20body%20text>

[Alexander Sack (asac)]

moving alsdorf bugs to new source package: notify-osd

[Mirco Müller (macslow)]

That is by design. A link implies being able to click on it, but the new jaunty notification spec does not allow notifications to be clickable. So the app doing that needs to be patched. A more indepth explanation of the rationale behind this ui-design decision is in spec. I'll post the link as soon as I have it handy.

[Dominic Evans (oldmanuk)]

not sure I agree with the reason for this bug being marked as invalid

it might be 'by design' to now not display clickable links, but surely it is not correct function to display a blank box if the message contained an <a href... link? you are then asking every single app that previously passed this markup to the notification daemon to add additional code to strip off the markup

surely the correct design would be for notify-osd to strip off the HTML markup and just display all plain text

[Alexander Sack (asac)]

i obviously agree that this is a bug. removing actions is one thing, but also saying that apps are wrong if they include an optional <a href markup is overly strict and notification daemon can do better.

[Alexander Sack (asac)]

general rule: be as strict as necessary, but be as polite as possible

[Mat Tomaszewski (mat.t.)]

Alexander, I strongly disagree - once we make one exception to "You cannot interact with notification bubbles" rule it will cause a whole bunch of other exceptions to follow, and the whole concept of non-intrusive notifications will be completely dissolved.
It is a tough compromise, but I feel it's the right way to go. Time and life will tell :)

[Dominic Evans (oldmanuk)]

Nobody is asking for an exception though.

But notify-osd should 'do the right thing' by displaying notifications exactly how they displayed before, but instead of processing and applying markup that allows interactions, they should simply throw that markup away.

What we should not have is 'if text.contains(markup): return', as an empty notification is worse than no notification at all.

[Mat Tomaszewski (mat.t.)]

Dominic, Alexander, yes of course it should display plain text instead of an empty box.

[Alexander Sack (asac)]

bumping importance. This is really loss of displayed content without any fallback available.

[Alexander Sack (asac)]

Suggesting to get this fixed till beta.

[Alex Rybicki (alex-rybicki)]

Dominic's temporary fix works for me.
http://bazaar.launchpad.net/~gwibber-committers/gwibber/trunk/revision/247

displays plain text instead of a blank box.

[David Barth (dbarth)]

Assigned to the upstream project. This is really not a packaging bug.

I don't think we should remove the text of the link. We should render it as plain text.

[Alexander Sack (asac)]

On Wed, Feb 25, 2009 at 12:37:49PM -0000, David Barth wrote:
> Assigned to the upstream project. This is really not a packaging bug.
>
> I don't think we should remove the text of the link. We should render it
> as plain text.

my suggestion was to render it as plain text with _underscore_ attribute.

Not sure if that was understood when i said: "before _link_ after"

 - Alexander

[Alexander Sack (asac)]

On Thu, Feb 19, 2009 at 06:30:33PM -0000, Mat Tomaszewski wrote:
> Alexander, I strongly disagree - once we make one exception to "You cannot interact with notification bubbles" rule it will cause a whole bunch of other exceptions to follow, and the whole concept of non-intrusive notifications will be completely dissolved.
> It is a tough compromise, but I feel it's the right way to go. Time and life will tell :)
>

you replied here on my line "general rule: be as strict as necessary,
but be as polite as possible"

Which i posted because mirco set this bug to invalid.

Anyway, now you stated that you agree that displaying plain text
(read: being polite) is the right thing here, I now wonder why you
strongly disagreed :).

Anyway, good that we agree ...

 - Alexander

[Matthew Paul Thomas (mpt)]

I think underlining links would suggest that they are clickable when they are not.

[Mat Tomaszewski (mat.t.)]

I don't think displaying the hyperlink with the underscore is a good idea. It will suggest that it's clickable, and that's misleading.

[Mat Tomaszewski (mat.t.)]

MPT, you got there first, *again*.
:)

[Mat Tomaszewski (mat.t.)]

Alexander, it seems like I was very sleepy/partly unconscious and clearly misread your comment. You're 100% right, what I wrote there doesn't actually make much sense :)

[Mirco Müller (macslow)]

I've commited a fix, that will pass any text as is, if the markup-filter fails.

[Mirco Müller (macslow)]

I commited a fix that will pass such text as-is, thus the bubble will not be empty.

[Launchpad Janitor (janitor)]

This bug was fixed in the package notify-osd - 0.9ubuntu2

---------------
notify-osd (0.9ubuntu2) jaunty; urgency=low

  * Merge bug fixes from trunk (r219):
    - Added max. limit of 10 lines for message-body text.
    - 3-line wrapping for summary text.
    - capability "truncation" now advertised to clients (LP: #337389)
    - non-composite mouse-hover effect now fully blanks (LP: #336108)
    - disable markup-filter if parsing fails (LP: #331019)

 -- Martin Pitt <email address hidden> Wed, 04 Mar 2009 19:47:24 +0100