[Dark Shell] Window border appears on second monitor when maximized

[Icexist]

Using Windows 7 64-bit and Brackets 31 (sprint 31 experimental build 0.31.0-9569 (On branch sprint-31-hotfix,sprint-31-hotfix dd28c6a))

Using dual monitors, a narrow band of the window overlaps into the second window when Brackets is fully maximized.

Attached images display the problem from both the right and left screens, the arrows indicating the split between monitors.

How to reproduce:

1. Open Brackets in a dual-monitor environment.
2. Open fullscreen by either pressing the fullscreen button or dragging to the top of the screen in Windows 7

[taylorthurlow]

Can confirm. I'm running 3 monitors - the middle on has fullscreened Brackets loaded - each side of brackets has that white bar that extends onto each other monitor.

[peterflynn]

Assigned @JeffryBooher. I can confirm too if I plug my Win 7 laptop into a second monitor.

[JeffryBooher]

This is actually an FOL of all Windows that turn off theming except Microsoft Apps. So rather than have different code for XP and Windows Vista and Windows 8 -- we went with this. We should probably push this to PM since he would need to decide if he wants to invest in fixing this. It's only a problem when brackets has an active frame

[JeffryBooher]

Actually it happens with an inactive frame as well...

[peterflynn]

@JeffryBooher I disagree about FOL... It doesn't happen with Office, Chrome, or iTunes -- all of which also have custom window chrome. That seems like good evidence that it's feasible to fix.

[peterflynn]

Clarified title

[JeffryBooher]

@peterflynn I can send you a non themed app that's out of the box and it will do the same thing. This was something that I noticed early on and I posted to Microsoft's MSDN message board and the only response I got was that this is how it works on Windows with multiple monitors.

I'll ping @adrocknaphobia and see if he can get us some help from Microsoft. I spent a few days trying to solve it but came to the conclusion that it was just how it goes with this and that it wasn't worth spending a lot of time on. I have a barebones app that I wrote a back when I was trying to solve this that I can send to MS to see if anyone there has any suggestions...

[taylorthurlow]

@JeffryBooher It seems like more of a problem that it is worth to have the new 'dark' theme. Admittedly I like the dark more than the original windows styling but if it means having this white bar on my preview monitors then I'd go back to windows themed aero any day. Perhaps an option to enable/disable the dark mode?

[njx]

@peterflynn mentioned that Chrome doesn't exhibit this problem on Windows. Have we checked Chromium? If it doesn't have the problem, maybe we could look at the source to see what it's doing.

[peterflynn]

@JeffryBooher
Interesting behavior I noticed last night... perhaps a clue: other apps like Outlook & Chrome still seem to have a hit area that extends slightly onto the next monitor -- they just manage not to draw anything there. With Chrome, I actually get the horizontal-resize cursor over that area, even though the pixels there are from the app that legit belongs on that monitor. But with both apps, if the app doesn't have focus, clicking in that little strip will focus its window.

[genericandy]

I am seeing this behavior as well. If you cannot solve the problem, at least allow us to disable the dark theme so those of use who are working in a 2 monitor environment can work around the problem.

[pthiess]

tagged for Sprint 33

[HamsterCoder]

Wow, I would have never noticed this about chrome =) Cheers for windows!

Confirm this bug on Win 7, x64, starting sprint 31.

[mabasic]

Same bug here.
Windows 7 x64, Brackets sprint 31.

[madcampos]

i've got this bug on windows 8.1, brakets sprint 31.

as a posible solution on an app with custom chrome using node-webkit i overwride the default maximize and restore actions to just resize the window to the maximun available space.
the code is the following:

var config,
    gui = require('nw.gui'),
    win = gui.Window.get(),
    unmaximizedWindow = [window.outerWidth, window.outerHeight, window.screenLeft, window.screenTop];

win.maximize = function(){
    unmaximizedWindow = [window.outerWidth, window.outerHeight, window.screenLeft, window.screenTop];
    window.resizeTo(screen.availWidth, screen.availHeight);
    window.moveTo(0, 0);
}

win.unmaximize = function(){
    window.resizeTo(unmaximizedWindow[0], unmaximizedWindow[1]);
    window.moveTo(unmaximizedWindow[2] - screen.availLeft, unmaximizedWindow[3] - screen.availTop);
}

[JeffryBooher]

Moving to sprint 34 as there won't be enough time left in 33 to fix; Moved this bug to the backlog to be reviewed and prioritized for sprint 34 (https://trello.com/c/pFO0rgs9)

[StanFisher]

I see this issue in Windows 7 in Sprint 34. The maximized window is also overlapping behind the taskbar a little.

[vfalconi]

I also see this issue in Win 7 with Sprint 34. I don't see the overlap with the taskbar (or maybe we're using different terms for the same thing...), but the icon in the top left of the window seems to be cut off slightly by the menu bar.

Not maximized:

Maximized:

[peterflynn]

@vfalconi That sounds like a different issue. Can you file that as a new bug? (With the same two screenshots attached)

[VizuaaLOG]

Just wondering if there is a fix for this as I regularly use two monitors and it is quite distracting when changing windows and seeing the white bar appearing or disappearing.

[peterflynn]

@VizuaaLOG It's marked 'fix in progress' and set to the Sprint 36 milestone, so it should land in the first release in January.

This bug has fallen out of several sprints in the past, so those indicators aren't as reliable as they would be for most bugs... but in this case I believe @JeffryBooher has said he's very close to a finished fix now -- he's been working on it for quite some time already.

[sirodoht]

Win 8.1, x64, sprint 34
When Brackets is maximized it extends some pixels below the taskbar. Probably the same bug?

[VizuaaLOG]

@peterflynn Oh ok will look forward to that release :)

[Studio384]

I can confirm the issue sirodoht mentioned here.

[mikkotikkanen]

Same here.

[VizuaaLOG]

@mikkotikkanen Kind of off topic but what theme is that?

[mikkotikkanen]

Ambiance from Themes for Brackets -extension

[VizuaaLOG]

@mikkotikkanen Thanks :)

[peterflynn]

@JeffryBooher I'm going to bump this up to a High so we really focus extra attention on getting the fix landed in Sprint 36. At this point this is basically our most-duped bug ever, so it is very high-profile. Lmk if you disagree with the priority.

[peterflynn]

Note: I've archived the user story https://trello.com/c/pFO0rgs9/1044-window-border-appears-on-second-monitor-when-maximized-windows-only which was basically just a dupe of this bug. We never pulled it into the sprints where this work was ongoing, and now the fix is about to land... so there didn't seem much point in keeping the card around anymore.

[JeffryBooher]

FBNC @peterflynn -- Fixed for Vista/7/8

[WebsiteDeveloper]

@JeffryBooher actually this reoccurs in the latest shell. but in a different way.
So far i only got it to happen when dragging a non maximized window to the top of the screen, in windows 7. But in contrast to the original bug the white border isn't click-able anymore.

[peterflynn]

Hmm. I very occasionally see an issue where nothing is visible on the 2nd monitor, but a small strip there remains sensitive to the mouse (e.g. clicking it activates the Brackets window). Almost as if the bug still occurs but with transparent pixels instead of white. (I also see this same bug very frequently in Chrome, fwiw).

However, I can't get consistent repro steps for that issue. Since it's both less prevalent & less serious, I suggest we close this and open a new bug if we're ever able to nail down steps for the bit that's left.

[TimoPot]

Using sprint 36 experimental build on win 7 pro.

There is a border visible on the left of brackets using dual screen setup.