** Changed in: xorg-server (Ubuntu)
Status: Fix Committed => Won't Fix
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1625846
Title:
Xmir -rootless: Firefox menus pop up then close right away
Syncing task from Mir.
** Changed in: mir (Ubuntu)
Importance: Undecided => High
** Changed in: mir (Ubuntu)
Status: New => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1625846
Enabled the workaround by default:
https://git.launchpad.net/~xmir-team/xorg-
server/+git/xmir/commit/?id=a70468ccd3afbf51e9116a60fea5a94b354f8196
** Changed in: xorg-server (Ubuntu)
Status: Triaged => Fix Committed
** Changed in: canonical-devices-system-image
Status: Confirmed
Prototyped another workaround:
https://git.launchpad.net/~xmir-team/xorg-
server/+git/xmir/commit/?id=0e421f3165501e87349bcd5832c07f172517c3ef
I'm considering turning it on by default, which would allow this bug to
be closed on the Xmir task at least, until Mir gets a proper fix (LP:
#1671771)
Ah, OK. We've been arguing with different assumptions.
Symptom: Firefox's menus don't work
Bug: XMir's focus behaviour differs from a spec-compliant X11 window manager.
One solution here, which is what I've been suggesting, is to implement
spec-compliant focus behaviour in XMir.
But you're
I know they don't need to be the same - that's how the workaround 'Xmir
-flatten' works. However if they are not the same then the OSK will not
function correctly, which is unacceptable. Only acceptable as a
temporary workaround...
And we don't need to make the choice to implement X11 window
So, specifically, in this paragraph:
“
In both cases the shell must not implicitly change the focus while the user is
interacting with Firefox, but Mir/Unity8 is doing just that. And the unfocus
event on the Firefox main window is tricking Firefox into closing the popup
(and menus) immediately.
I'm clearly communicating poorly, so I'll try again:
The X11 focus, and the Mir focus, do *not* need to be the same.
In fact, a stronger claim holds: X11 focus and Mir focus *cannot* be the
same unless we want to implement pieces of X11 window management in Mir.
This does not mean simply
The official link:
https://www.x.org/releases/X11R7.6/doc/xorg-docs/specs/ICCCM/icccm.html#pop_up_windows
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1625846
Title:
Xmir -rootless: Firefox menus
I am aware of the above ICCCM spec and that Xmir doesn't follow it
fully, but that's also possibly not the issue here. The issue with
supporting the Locally Active focus model is that apps want the ability
to either focus their popups explicitly or not at all:
Hm, that's correct. XMir *could* defer acting on focus lost until a
timeout or focus-gained event, but that would be a heuristic.
The “Locally Active focus model” is a fairly X11-specific thing. It's
from a time when applications were built in a one-X11-window-per-widget
fashion, and so a textbox
Chris, although I agree with a lot of what you say, I'm not sure Xmir
has all the information it needs at the right time.
As mentioned in comment #11 Mir is unfocussing the one window before
focussing the other. When Xmir receives the focus loss it cannot know
whether the focus is moving to a
I think bug 1671771 is fundamentally the wrong solution (to this
problem; it does need to be fixed).
The problem here is that XMir is not behaving like a spec-compliant X11
window manager. Unless we want to require Mir servers to implement X11
window management, this is not something that we can
(The reason why bug 1671771 is not going to fix this is that Firefox¹
*may* set input focus to one of its subwindows, and will behave weirdly
if that doesn't work. You can't just set “no focus” on the Mir surface
corresponding to Firefox's subwindow and then delegate to Mir's input
focus.)
¹:
Blocked on bug 1671771 now.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1625846
Title:
Xmir -rootless: Firefox menus pop up then close right away
To manage notifications about this bug go to:
Added a nicer workaround:
https://git.launchpad.net/~xmir-team/xorg-server/+git/xmir/commit/?id=c1a41c3e2fca342bb77ccf204d54051303d15e73
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1625846
Title:
OK, I think that "Freestyle" is the appropriate solution here. And that
X11 overrideRedirect windows should equate to Freestyle surfaces which
never receive input focus.
Mir 0.27/1.0 appears to have a new function for creating freestyle
surfaces but I can't find any way to flag that they should
Or I can just try this...
mpt: (sorry, I haven't seen or found design docs in a long time)
is there any surface type that never gets keyboard focus?
duflu, yes, the “gloss” and “tip” types are unfocusable, and an
app/toolkit should be able to specify whether a particular “freestyle”
window is
Hmm, I could do a semi-permanent workaround in Xmir along the lines of:
Xmir -flattenOverrideRedirects
That might be adequate to fix this for Firefox and others. Although I
dread having to make Xmir lookup a blacklist of broken apps and apply
workarounds on the fly. It would be better in the
** Changed in: canonical-devices-system-image
Importance: Undecided => High
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1625846
Title:
Xmir -rootless: Firefox menus pop up then close right
If MirAL can't be fixed right now, that suggests we need to modify
libmirserver first, to separate input focus from the stacking order.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1625846
Title:
** Changed in: canonical-devices-system-image
Assignee: (unassigned) => Stephen M. Webb (bregma)
** Changed in: canonical-devices-system-image
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
** Also affects: canonical-devices-system-image
Importance: Undecided
Status: New
** Tags added: unity8-desktop
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1625846
Title:
Xmir
** Description changed:
To reproduce:
1) Open firefox on a rootless Xmir
2) Right click or attempt to open the menu on the top right
Expected:
Menu to open
Result:
Menu pops up then closes right away.
+ I think this is an expected bug, but dont remember the bug# soo figure
Incomplete for miral, we can't fix this in miral directly. The way focus
works in Mir does seem odd and I'm surprised that the workarounds
(ignoring focus loss) in the Qt and Gtk toolkits are "good enough". When
we have a plan, then will reassess how miral is affected.
** Changed in: miral
Incomplete for Xmir. We can't fix this in Xmir directly, but are waiting
on a fix and/or new client-API from Mir itself to limit automatic focus
assignment.
** Changed in: xorg-server (Ubuntu)
Status: Triaged => Incomplete
--
You received this bug notification because you are a member of
** Tags added: rootless
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1625846
Title:
Xmir -rootless: Firefox menus pop up then close right away
To manage notifications about this bug go to:
It seems that Daniel's analysis is correct.
With Mir a newly opened menu surface gets focus. This takes place in
msh::AbstractShell::set_focus_to_locked() and the sequence is:
/1/ reconfigure the existing focus window to mir_window_focus_state_unfocused
/2/ reconfigure the new window to
Similar behavior can be seen in Xterm.
1) Open Xterm with rootless Xmir
2) Ctrl+Right-Click very briefly opens menu and then immediately closes menu
Expected behavior: Menu stays open
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I briefly wondered if this were related to lp:1660691 - but empirically
not:
$ miral-xrun firefox
creates (and immediately destroys a menu)...
[2017-02-14 09:21:08.828425] miral::Window Management: place_new_window
app_info={application=XMIR, windows={Merge into trunk : miral-toolkit-dev :
Workaround:
Xmir -rootless -flatten ...
This will stop the Mir shell from creating separate windows for the
menus (or for anything), which in turn prevents the Mir shell from
sending unwanted focus events.
** Tags added: clientapi
--
You received this bug notification because you are a
Basically it's the old problem of "the focused window is not always the
top-most window". Other windowing systems don't assume they're the same
and if existing apps are to work with Mir then Mir needs to understand
that on-top and focused are not always the same thing. Utility windows
like menus
Interesting. It appears this might be a shell/Mir/MirAL bug.
The problem is that Mir shells are sending focus events to surfaces that
never receive focus events on normal X desktops. Sending a focus event
to a menu that has specified never to receive focus (or is override
redirect) is not
** Also affects: mir
Importance: Undecided
Status: New
** Also affects: miral (Ubuntu)
Importance: Undecided
Status: New
** Also affects: miral
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Ubuntu
Bugs, which
Yeah, this is going to become more of an issue since we are enabling
rootless by default for Libertine apps.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1625846
Title:
Xmir -rootless: Firefox
Previously reported in bug 1590553
** Changed in: xorg-server (Ubuntu)
Importance: Medium => High
** Changed in: xorg-server (Ubuntu)
Status: Confirmed => Triaged
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
36 matches
Mail list logo
