lots of regions on the titlebar can't be dragged but should be able to be dragged

[bbondy]

Did you search for similar issues before submitting this one?
Yes

Describe the issue you encountered:
Some important areas of the Window are not draggable on Windows.

Expected behavior:
The expected areas in the screenshot should allow dragging.

• Platform (Win7, 8, 10? macOS? Linux distro?):
  Windows 7
• Brave Version:
  0.12.2
• Steps to reproduce:
  1. Try to drag one of the areas in the screenshot
  2. It doesn't drag.
• Screenshot if needed:
  
• Any related issues:
  Titlebar on Windows has a lot of wasted space #3036

[bsclifton]

Reproduced- only happened when magnification was set to 150%

[srirambv]

Similar issue with RC3 build on Windows 10. System magnification is set at 125%. Irrespective of the magnification level same result on Win 10.

[srirambv]

Similar drag issue on Linux. When trying to drag in titlebar regions it shows bookmark contents

[luixxiul]

You cannot drag the area in the screenshot.

[bsclifton]

Some of these areas are going to be REALLY hard to get working. There are problems to be aware of with marking every single pixel as draggable on Windows:

1. when it's close to the edge of the window, the cursor won't allow resize unless your mouse is directly over the very edge pixel. Marking as non-draggable gives more leniency (maybe 5px hitbox for resizing). This is why I've put padding around the edges.
2. Any areas marked as draggable will show the windows system menu (min/max/restore/close/etc) when right clicked. This means we can't show custom menus here. This is why the bookmarks toolbar area is not draggable, same with the tabs row. If we make them draggable, the right click -> add bookmark/add folder/etc context menu will no longer show up
3. Areas being marked as draggable alter divs which overlap it, even if the div has a higher z order. This broke the menus (making the first item not selectable unless you were near the bottom). This (and modals not dismissing when clicking) was fixed by removing the drag style at runtime when we didn't want window to drag (modal being shown, etc)

CC: @bbondy and @bradleyrichter - what is the acceptable criteria with respect to dragging? I'm hesitant to make any changes because I've spent hours compromising between draggability and fixing bugs (which might seem unrelated) caused by dragging 😦

[bbondy]

re 1: We want to work like normal windows, which should be possible considering chrome does the same.
re 2: that's fine, we don't have bookmarks toolbar draggable already in older builds on windows.
re 3: disable the draggability when the menu is expanded.

[bbondy]

Note that there is an area above the urlbar that has no resize cursor and the window is not draggable.

[bbondy]

I'm still having the following areas that are not draggable in 150% DPI.
It feels like the app is completely broken right now because it feels like the window can't be dragged, I have to work hard to successfully move the window, usually after about 30 seconds of trying to drag it in various locations. After spending more time I figured out the draggable and non draggable areas. In pink is the parts I can't drag at all, in yellow is the parts I can usually drag but sometimes doesn't work because it changes to a text input cursor:

I don't want to do it because there are a lot of changesets but we might need to revert titlebar out of master if we can't get this solved so we can get 0.12.2 out the door and reland when the draggable region is working. Anyone who experiences the above that I did would stop using the browser so let me know your preferences if we should revert for now or not. 125% DPI seems not so bad, but there is an area above the urlinput that can't be dragged and it's not a resize region either. I suspect some code in electron that is responsible for the drag region on windows is not taking dpi into consideration.