#55 Bogus urgency hint with Opera

closed-fixed
nobody
None
5
2012-12-18
2012-10-26
Anonymous
No

I use the Opera browser without tabs; i.e. browser windows open separately, and Notion does the tabbing. In the latest Notion, opening a new opera window works, but also sets the urgency hint to another opera window that is currently open in another workspace. To be clear, the other window shouldn't be involved at all. Everything is correct, except the bogus urgency hint; nothing should be urgent in this situation. In ion3, this all worked just fine.

I ran a bisect, and the issue first appeared in commit 35951ebac0f78fa8cad16bb23f0c4f49ae486453

Immediately before that commit the bogus urgency hint isn't there, but for some reason Notion switches to the workspace containing the other Opera window first, before creating a new one. This is wrong as well, but different.

Discussion

1 2 > >> (Page 1 of 2)
  • Etan Reisner
    Etan Reisner
    2012-10-26

    That commit changed the behaviour of notion's response to that even in exactly the way you see. It used to switch to and focus the client asking for a stacking change and now it merely sets activity. The new behaviour is better (and was changed at my request as I recall).

    The problem here appears to be that opera is unnecessarily requesting a stacking change on some other window (perhaps the first window that was created?) when it attempts to open a new window. I'm guessing this is tabbing related code gone wrong (i.e. this would make sense when spawning a new tab in an existing window).

    An X event log of this happening would confirm my suspicions but I don't have an easy way for you to get one at the moment.

     
  • dima
    dima
    2012-10-26

    Does it make sense that this worked as expected with ion3, everything else being equal? I just moved over to Notion, so I KNOW nothing else changed.

     
  • Etan Reisner
    Etan Reisner
    2012-10-26

    Yes. Support for responding to stacking requests is new in notion.

     
  • dima
    dima
    2012-11-01

    I just hit a very similiar-looking bug with gnuplot, not opera. The symptom is an incorrectly-set urgency hint. I can reproduce this with the latest notion. To reproduce:

    1. split desktop into two panes
    2. in one pane, open a shell, and do "gnuplot -persist -e 'plot x with lines'"
    3. This should open a plot in one pane.
    4. Switch to other pane, and tell notion to unsplit the tiling (to make the desktop one big pane). I use emacs bindings, so it's "META-x 0" for me. It calls WTiling.unsplit_at(_, _sub)
    5. After the unsplit, the gnuplot window is highlighted with urgency. This is wrong

    I ran xtrace to see what X events gnuplot is sending/receiving. The log is attached to this bug. The logging command was

    xtrace --relative-timestamps -o /tmp/gnuplot.xtlog gnuplot -persist -e 'plot x with lines'

    The first column of the log is a relative timestamp. The unsplit event started at t=10.955.

     
  • dima
    dima
    2012-11-01

    Apparently sourceforge doesn't let me attach the log. It appears here instead: https://gist.github.com/3996929

     
  • Etan Reisner
    Etan Reisner
    2012-11-04

    As expected the configure event has above-sibling set. This is what notion is reacting to. The original change was made, I believe, to have windows that request to re be raised given the focus. That was determined to be too intrusive (and against the general ion/notion philosophy of user controlled windowing) though and so the current mechanism was put in place.

    I don't know what, specifically, motivated the first change or whether there is any good reason to keep it (though it certainly seems reasonable to have this feature to me). It is certainly going to be the case that this is going to trigger unwanted activity notifications though because I'm certain lots of applications will have been abusing raise events for ages. (There's a reason the major DEs all added some form of focus stealing prevention code in "recent" years.)

     
  • dima
    dima
    2012-11-04

    Would we consider making this behavior optional (urgency ONLY with a WM_HINT, not with raises)? At least for my everyday use the current behavior is never what I want.

     
  • dima
    dima
    2012-11-16

    I'm attaching a patch to make responding to window-stacking optional. This patch sets the default to what notion does currently, although I'd argue that the old ion3 behavior is the less-surprising one and IT should be the default.

    This bug describes two programs that behave in unexpected ways with the new notion behavior: opera, gnuplot. Any specific examples for applications that work BETTER with the new behavior? If not, the default value of this option should be flipped at the very least.

     
1 2 > >> (Page 1 of 2)