Created attachment 81155 [details]
Example for the bug

Here’s an example of the two cases. There’s a Geany window on each monitor, vertically maximized. Note how the title bar of the one on the left screen is not visible, while the right one is. The same happens if you use full maximization (i.e., in both directions).

The obvious work-around is to use resize the window by hand, possibly using a shortcut for horizontal maximization.

I think this is bug #308853 (the explanation of the problem there might be wrong / unsharp)

Please post the output of 
   xprop | grep -iC1 STRUT
(the cursor turns into a cross, then just click somewhere on the problematic panel)
and
   xrandr -q

(In reply to comment #2)

Here you go:

$ xprop | grep -iC1 STRUT
_KDE_NET_WM_BLUR_BEHIND_REGION(CARDINAL) = 0, 0, 1920, 25
_NET_WM_STRUT(CARDINAL) = 0, 0, 4294966891, 0
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 4294966891, 0, 0, 0, 0, 0, 0, 1919, 0, 0
WM_STATE(WM_STATE):
--
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_CHANGE_DESKTOP
_KDE_NET_WM_FRAME_STRUT(CARDINAL) = 0, 0, 0, 0
_NET_FRAME_EXTENTS(CARDINAL) = 0, 0, 0, 0

$ xrandr -q
Screen 0: minimum 8 x 8, current 3120 x 1920, maximum 8192 x 8192
DVI-I-0 disconnected (normal left inverted right x axis y axis)
VGA-0 disconnected (normal left inverted right x axis y axis)
DVI-I-1 connected 1200x1920+1920+0 left (normal left inverted right x axis y axis) 546mm x 352mm
   1920x1200      60.0*+   59.9  
   1680x1050      60.0  
   1600x1200      60.0  
   1600x1000      60.0  
   1280x1024      75.0     60.0  
   1280x960       60.0  
   1024x768       75.0     60.0  
   800x600        75.0     60.3  
   640x480        75.0     59.9  
HDMI-0 connected 1920x1200+0+430 (normal left inverted right x axis y axis) 546mm x 352mm
   1920x1200      60.0*+
   1920x1080      59.9     50.0     30.0     30.0     25.0  
   1680x1050      60.0  
   1600x1200      60.0  
   1600x1000      60.0  
   1280x1024      75.0  
   1280x960       60.0  
   1280x720       60.0     59.9     50.0  
   1024x768       75.0     60.0  
   800x600        75.0     60.3  
   720x576        50.0     25.0  
   720x480        59.9     30.0  
   640x480        75.0     59.9     59.9

(In reply to comment #2)
> I think this is bug #308853 (the explanation of the problem there might be
> wrong / unsharp)

Can’t tell, but there’s at least one difference from the report there: I my case the mouse is not allowed to exit the bounds of the monitor, but that report says “The mouse also is not restricted traveling out of bounds.” (The grammar sounds iffy, so depending on the missing word it might not mean what I think it means.)

_NET_WM_STRUT(CARDINAL) = 0, 0, 4294966891, 0
                                                    ^^^^^^^^^^^^^

We've a winner.
It seems the strut is seems set by a weird "screen / root pos" mapping.
The value is apparently a strut of "-405"

1. negative struts don't exist in the first place.
2. struts have to be in root coordinates (the netwm spec is initially quite confusing about this but at some point clearly states this: "Struts MUST be specified in root window coordinates, that is, they are not relative to the edges of any view port or Xinerama monitor.")

Since your horizontal screen is at y=430 and the panel 25px high, this means the strut seems calculated as
   "panel bottom in screen coordinates" - "screen top" | 25 - 430 = -405
while it should be 
   "panel bottom in screen coordinates" + "screen top"  | 25 + 430 = 455

what's obviously equal if "screen top" is "0" only.

Seems to be a bug in the plasma panel containment strut calculation, eventually some sublying library.

(In reply to comment #4)

> report says “The mouse also is not restricted traveling out of bounds.” (The
> grammar sounds iffy, so depending on the missing word it might not mean what I think it means.)

Either this means the setup is broken (and the screen continues outside the viewport) or he's referring to the fact that mouse movement is not restricted at common screen edges - resp. for older Xorg version was not restricted to the viewport at all (ie. could be moved outside all over the root window) - we'll need a reply over there to finally say.

(In reply to comment #5)
> It seems the strut is seems set by a weird "screen / root pos" mapping.
> Seems to be a bug in the plasma panel containment strut calculation,
> eventually some sublying library.

I’m not a KDE hacker, but I’m a programmer, so if there’s anything I can do to help that doesn’t require a week of learning how KDE/Plasma works let me know.

Out of curiosity, I looked through plasma/desktop/shell/panelview.cpp, and I don’t think I get it. PanelView::updateStruts has this (edited slightly to fit better):

>       //Extended struts against a screen edge near to another screen are really harmful, 
>       //so windows maximized under the panel is a lesser pain
>        //TODO: force "windows can cover" in those cases?
>        const int numScreens = PlasmaApp::self()->corona()->numScreens();
>        for (int i = 0; i < numScreens; ++i) {
>            if (i == containment()->screen()) continue;
>            const QRect otherScreen = PlasmaApp::self()->corona()->screenGeometry(i);
>            switch (location()){
>            case Plasma::TopEdge:
>                if (otherScreen.bottom() <= thisScreen.top()) { /* BAD TEST HERE, I think */
>                    KWindowSystem::setExtendedStrut(winId(), 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0);
>                    return;
>                }

If I understand what it does, then for that panel in particular that last “if” is true and the function returns here. But in that case it sets all-zero struts, so I don’t understand where the negative value is coming from.

That said, I think the condition as written I think is wrong. I think the code is trying to avoid setting struts on panels that lie on a border shared with another adjacent screen. But it doesn’t in fact test if the other screen shares the tested border. Whoever wrote the code probably assumed same-sized and corner-aligned screens. (Though even then it wouldn’t work right, the test would say “true” even if the other screen were below this one, or (my case) if it is on the side.

Assuming I understood the code, the correct test is probably something like:

> if (otherScreen.top() > thisScreen.top()      // the other screen is really above us
>  && otherScreen.left() < thisScreen.right()   // and it’s not too far to the right
>  && otherScreen.right() > thisScreen.left()   // nor too far to the left
>  && otherScreen.bottom() <= thisScreen.top()) // and it actually touches this screen

Though there is a test like this for each case (border), so there might be a way to organize the tests better.

That said, the test for the bottom panel would have the same bug, but it doesn’t manifest in my case, and I checked with xprop and the values seem sane.

*** Bug 323315 has been marked as a duplicate of this bug. ***

I can confirm I have the same problem too.
I use a small laptop with the screen dimensions
1280x800
and the other monitor with the screen dimensions
1920x1080

The bigger one is configured to be above the smaller one and the smaller one
has a panel at the top of the screen.
I have the same problem as described here.

I experience the same behaviour on KF5/Plasma Workspaces (all components from git master as of 2014-05-04).

Primary screen is 1920x1080 (under secondary)
Secondary screen is 2560x1440 (above primary)

Both have a panel at the bottom.
The problem only exists for the panel on the secondary screen, where the panel shares a border with the primary screen.

The strut values for the primary panel are:
_NET_WM_STRUT(CARDINAL) = 0, 0, 0, 30
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 30, 0, 0, 0, 0, 0, 0, 496, 2415
_KDE_NET_WM_ACTIVITIES(STRING) = "00000000-0000-0000-0000-000000000000"

The struct values for the secondary panel are:
_NET_WM_STRUT(CARDINAL) = 0, 0, 0, 0
_NET_WM_STRUT_PARTIAL(CARDINAL) = 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0
_KDE_NET_WM_ACTIVITIES(STRING) = "00000000-0000-0000-0000-000000000000"

Display layout:
eDP1 connected 1920x1080+496+1440 (normal left inverted right x axis y axis) 294mm x 165mm
DP1 connected 2560x1440+0+0 (normal left inverted right x axis y axis) 597mm x 336mm

Moving the secondary panel to the top where it doesn't share a border with the primary screen makes the problem disappear, so it seems to be related to the panel's position in the middle of both screens.

The same goes vice versa for the primary panel (moving it to the top makes the problem appear on the primary screen).

Jakub and Elias - your bug is different, having panels on the shared screen edge is deliberately ignored, see bug 167852

*** Bug 336014 has been marked as a duplicate of this bug. ***

Hello!

This bug report was filed for KDE Plasma 4, which reached end-of-support status in August 2015. KDE Plasma 5's desktop shell has been almost completely rewritten for better performance and usability, so it is likely that this bug is already resolved in Plasma 5.

Accordingly, we hope you understand why we must close this bug report. If the issue described  here is still present in KDE Plasma 5.12 or later, please feel free to open a new ticket in the "plasmashell" product after reading https://community.kde.org/Get_Involved/Bug_Reporting

If you would like to get involved in KDE's bug triaging effort so that future mass bug closes like this are less likely, please read https://community.kde.org/Get_Involved#Bug_Triaging

Thanks for your understanding!

Nate Graham