To be more precise, the resizing strip seems thicker than in other applications. Jimm, do you know if this is something we control?

When draw in titlebar is set yes we do. I remember back when we did the titlebar work we had bug about making it thicker which landed. So I'm tempted to mark this wontfix since I think we've had this discussion.

Do you recall off-hand where we control this? Theme or widget code? Also, do you recall a good reason for having a thicker resize strip than other applications at the top of the window?

(In reply to Dão Gottwald [:dao] from comment #3) > Do you recall off-hand where we control this? Theme or widget code? Also, do http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsWindow.cpp#280 > you recall a good reason for having a thicker resize strip than other > applications at the top of the window? It's what our users wanted? Or maybe it's a regression and we never noticed? No idea.

Dão, what do you mean when you say "eats away too much from the tabstrip" ? The tabs are 15px below the top of the window (http://mxr.mozilla.org/mozilla-central/source/browser/themes/windows/browser.css#68) so I'm confused how the 3px resize strip makes a difference there...

The area reserved for resizing can't be used for dragging the Window (or any other interaction, but we mostly care about dragging here).

I think this might be a high-DPI bug. Do we treat kResizableBorderMinSize as CSS pixels rather than device pixels?

I suppose using CSS pixels is actually more sensible, but Windows doesn't seem to do this? In any case, when I set the Windows scaling to 100%, we seem to be using the same size as Explorer. When set to 200%, there's a discrepancy.

(In reply to Dão Gottwald [:dao] from comment #7) > I think this might be a high-DPI bug. Do we treat kResizableBorderMinSize as > CSS pixels rather than device pixels? Looks like it uses hardcoded device pixels. Shouldn't be too hard to touch up, we have GetDefaultScale on nsIWidget which I believe returns the factor we need.

(In reply to Dão Gottwald [:dao] from comment #1) > To be more precise, the resizing strip seems thicker than in other > applications. Hmm, are you sure about this? From experimenting with Firefox, Chrome, and Edge... I see a resize zone that 6-8 CSS pixels wide around all of them, except for Edge's top border -- see below. I was testing on a monitor at 200%, so that's actually 12-15 physical pixels. I might be off by a pixel or two, because it's kinda tricky to test this accurately. Specifically, at the top of the Firefox window, the resizable zone was 13 physical pixels tall, starting from the window border and extending inwards. Chrome's was 15 pixels tall. So our zone is slightly smaller than Chrome. But bug 1186250 is shrinking down the space above the tabs even more than Chrome, so I think we still need to shrink our resize zone. Or prune the space so much. Or live with it being hard to drag the top border. A couple other oddities I noticed: * I don't understand how resizing works on the top border of Edge. Sometimes moving the arrow changes to a resize cursor, sometimes it doesn't. Even weirder, sometime a click-and-drag when the resize cursor is showing will actually drag the window instead of resizing it. O_O I'm not sure if they're trying to do something clever here or if it's just buggy. * The resize area on the left side of Chrome is weird. (And probably the right, I only tested one.) Their window seems to have a double border (the normal Windows border, and something inside that, each 2 physical pixels wide at 200%. Edge has a ~15px wide resizeable size, starting from the border (inclusive) to 13px to the left of the window border. Chrome's 12 pixels wide, starting from their weird inner border, and extending 8px to the left of the border.

I'm pretty sure we tested this with Explorer or some other "simple" stock application. I'll double-check. Edge and Chrome are more likely to have their own set of bugs, so taking them as references doesn't seem like a good idea.

Comment 8 confirms that I was testing with Explorer :) ... although that was some time after philipp and I originally investigated this.

FWIW, we ideally should focus on moving that resize area outside of the window. This is what already happens on all other sides of the window (the resize area starts at the border and extends a few pixels outward). That way we can preserve most of the drag space and still reduce the padding. I tested a bunch of Windows apps, and the one that behaves the most like I think it should is Word 2016. There's little consistency here across apps, but there are really good reasons (see above) to move the resize area outside the window.

(In reply to Philipp Sackl [:phlsa] please use needinfo from comment #13) > FWIW, we ideally should focus on moving that resize area outside of the > window. This is what already happens on all other sides of the window (the > resize area starts at the border and extends a few pixels outward). That way > we can preserve most of the drag space and still reduce the padding. It's non-obvious to me how to do this (although I'm hardly a win32 expert). I got as far as seeing that the winrect we get from the OS includes the resize margin on the sides and bottom, but does not extend beyond the top border. Jimm? > I tested a bunch of Windows apps, and the one that behaves the most like I > think it should is Word 2016. There's little consistency here across apps, > but there are really good reasons (see above) to move the resize area > outside the window. Do any other Windows apps have a resizable region beyond the top border? I don't have Office installed, but the other apps all seem to behave without any extended top resizable margin.

I guess Visual Studio 2013 works this way too. Though it's obvious they're not using native window caption buttons. We're not either, but we've got a bunch of goop to account for them. Maybe we should just be creating a plain resizable window with no title bar / caption buttons / etc, as we're doing it all ourselves now?

(In reply to Justin Dolske [:Dolske] from comment #14) > (In reply to Philipp Sackl [:phlsa] please use needinfo from comment #13) > > FWIW, we ideally should focus on moving that resize area outside of the > > window. This is what already happens on all other sides of the window (the > > resize area starts at the border and extends a few pixels outward). That way > > we can preserve most of the drag space and still reduce the padding. > > It's non-obvious to me how to do this (although I'm hardly a win32 expert). > I got as far as seeing that the winrect we get from the OS includes the > resize margin on the sides and bottom, but does not extend beyond the top > border. Jimm? You make the outer resize area of the window transparent and render your window contents in the inner areas. bug 590945 was an attempt to get the entire window rendered in xul so we could do things like this, but unfortunately we ran into a lot of problems trying to get that working reliably. We could also try implement support in win32 widget directly. The code here is getting pretty crazy though thanks to all the work we've done supporting various windows desktop themes. :)

> We're not either, but we've got a bunch of goop to account for them. Maybe > we should just be creating a plain resizable window with no title bar / > caption buttons / etc, as we're doing it all ourselves now? This was a goal, it's the same approach Chrome takes. However we run into problems in that we try to accelerate the entire window all the way out to the window edge. Other browsers only accelerate content. This caused weird driver refresh problems in bug 590945.

(In reply to Justin Dolske [:Dolske] from comment #15) > I guess Visual Studio 2013 works this way too. Though it's obvious they're > not using native window caption buttons. > > We're not either, but we've got a bunch of goop to account for them. Maybe > we should just be creating a plain resizable window with no title bar / > caption buttons / etc, as we're doing it all ourselves now? Office also seems to be using something other than the native window implementation. Their shadows etc. look quite different.

Not an immediate priority per phlsa.

This is still blocking bug 1173731, so let's not get sidetracked by bug 590945 or other complex solutions and focus on fixing up kResizableBorderMinSize: (In reply to Jim Mathies [:jimm] from comment #9) > (In reply to Dão Gottwald [:dao] from comment #7) > > I think this might be a high-DPI bug. Do we treat kResizableBorderMinSize as > > CSS pixels rather than device pixels? > > Looks like it uses hardcoded device pixels. Shouldn't be too hard to touch > up, we have GetDefaultScale on nsIWidget which I believe returns the factor > we need. I assumed we were using CSS pixels instead of device pixels, as this would explain why the resizing area is larger than it is in other applications. If we are using device pixels, that doesn't really explain the bug. In any case, I still suspect this might be an easy fix for someone who knows what they're doing. Jim, is this something you could justify freeing some time for or could you suggest another widget hacker?

Maybe I'm missing something here, the thickness seems the same as other apps on a surface pro @ 150%? The top edge might be a pixel to two thicker, maybe.

(In reply to Jim Mathies [:jimm] from comment #21) > Maybe I'm missing something here, the thickness seems the same as other apps > on a surface pro @ 150%? I still see it at 200% (haven't checked 150% at this time). I found this to be the easiest way to reproduce it: 1. open Nightly and Windows Explorer, both unmaximized 2. position them such that their top borders overlap exactly 3. focus the Nightly window and move the mouse pointer towards the top pixel by pixel until the resize cursor appears 4. Alt-Tab to the Explorer window Now you should still get the resize cursor if both windows' resizable area had the same thickness. I get the normal cursor instead. > The top edge might be a pixel to two thicker, maybe. Then that's what we'd like to get rid of :)

I don't have the time for this right now. we're trying to put together a new team for this type of work, so maybe in a few months.

(In reply to Dão Gottwald [::dao] from comment #22) > (In reply to Jim Mathies [:jimm] from comment #21) > > Maybe I'm missing something here, the thickness seems the same as other apps > > on a surface pro @ 150%? > > I still see it at 200% (haven't checked 150% at this time). > > I found this to be the easiest way to reproduce it: > > 1. open Nightly and Windows Explorer, both unmaximized > 2. position them such that their top borders overlap exactly > 3. focus the Nightly window and move the mouse pointer towards the top pixel > by pixel until the resize cursor appears > 4. Alt-Tab to the Explorer window > > Now you should still get the resize cursor if both windows' resizable area > had the same thickness. I get the normal cursor instead. > > > The top edge might be a pixel to two thicker, maybe. > > Then that's what we'd like to get rid of :) We need this again for Photon since UX wants to get rid of the space above tabs.

oops, didn't mean to change that. I'm tracking these over on the platform integration wiki. https://wiki.mozilla.org/Platform/Integration#Priority_Lists

I've tested on a laptop set at 250%, and the resize area above the tabs is so small I can barely grab it. The area is also much smaller than in Explorer. To me, the bug is that the amount of space we provide is too small on higher dpi displays. I know we've been back and forth on this before Dao, but I'm still not clear on what change this bug is requesting.

(In reply to Jim Mathies [:jimm] from comment #26) > I've tested on a laptop set at 250%, and the resize area above the tabs is > so small I can barely grab it. > > The area is also much smaller than in Explorer. To me, the bug is that the > amount of space we provide is too small on higher dpi displays. > > I know we've been back and forth on this before Dao, but I'm still not clear > on what change this bug is requesting. Looks like things have changed in Windows or on our side since two years ago. I can't reproduce this anymore using the steps from comment 22. As you say, the area now seems too narrow, which seems problematic too but doesn't block the photon tab strip changes.

Moving to p3 because no activity for at least 1 year(s). See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information