After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 345155 - Does not unhide properly on xinerama screens with different resolutions
Does not unhide properly on xinerama screens with different resolutions
Product: gnome-panel
Classification: Other
Component: panel
Other Linux
: Normal normal
: ---
Assigned To: Panel Maintainers
Panel Maintainers
Depends on:
Blocks: randr-tracker
Reported: 2006-06-17 02:01 UTC by Sven Arvidsson
Modified: 2009-02-26 19:14 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14

Description Sven Arvidsson 2006-06-17 02:01:11 UTC
This bug was reported to the Debian BTS.

Define a panel at the bottom of the smaller screen of a xinerama system. Set
auto-hide to true. Then the mouse has to hit exactly the remaining strip of
the hidden panel for some time to unhide the panel. If the mouse moves below 
the bottom of the screen the panel keeps its hidden state. Thus, it is difficult
to unhide the panel if the remaining size is set to a low value.
Comment 1 Vincent Untz 2007-06-29 14:04:42 UTC
Hrm, you mean the mouse can go below the screen because the other screen is bigger?
Comment 2 Josselin Mouette 2007-07-02 19:48:11 UTC
I don't have an asymmetric dual-head setup to check, but this is apparently what is happening to the reporter.
Comment 3 Eric Piel 2008-05-07 09:53:01 UTC
I can confirm this bug. If the mouse goes to an area not displayed, the panel will not popup. It has to be just over the hidden panel :-(

Now I wonder if that is not a xorg bug, which should forbid moving the mouse to areas not displayed on any screen (this is hard to handle though, because screens are allowed to have black areas between them).

Another possibility would be the panel to detect black areas corresponding to where it is hiding and detect when the mouse reach one of those areas.
Comment 4 Federico Mena Quintero 2009-02-26 19:14:24 UTC
The real bug here is that X allows the mouse to move into the area outside the monitors, but still inside the frame buffer.  See