Zooming the entire UI almost works, just needs fix for wrong mouse position coordinate transform

[ackalker]

As a visually impaired user, I have difficulty reading text in Brackets in its default configuration, a problem I seem to share with people using HighDPI displays.

While I know I can zoom the editor using Ctrl-Plus/Ctrl-Minus, to make the rest of the UI usable, I either need to switch to a lower resolution video mode or hack around in the CSS.

Just recently, not expecting anything, I tried slapping style="zoom: 2" on the body element using the Developer Tools (yes, I know, big hammer :-) , and I should probably use style="-webkit-transform: scale(2)", but anyway...). Lo and behold, the entire UI scaled nicely and was very usable to me. Menus, sidebars, bottom container for hints / log output, etc. work fine!

Editing using the keyboard works fine, too, but at 200% zoom, left or right clicks inside the editor appear as if the mouse click is registered at a position twice as far from top left of the Brackets window as in reality, i.e. context menus open twce as far down and right, etc.

I'm not yet very much into Bracket's innards, but could this be fixed easily? It would make me and lots of other squinting users very happy :-)

[ackalker]

Forgot to summarize:

• OK: Top menus are scaled correctly and work.
• OK: Side and bottom panes are scaled correctly, clicks on icons, files, and tree expand widgets work
• OK: In the editor, function parameter popups and code completion dropdowns are scaled and show at the correct position w.r.t. the cursor, and clicking in the dropdowns works, too.
• NOT OK: Right click context menus appear shifted down and right in the entire UI.

[dangoor]

To @larz0 to decide on the UX aspects of this.

[larz0]

I wonder if we should take the time to convert px to REMs instead of using CSS transforms to zoom as it's less hacky (although I like the simplicity of the hack :). I can take a crack at it next sprint.

Basically we could set HTML font-size to 1px to make the REM numbers match the px numbers. E.g body font-size 16rem = 16 * 1 px. To enlarge the UI size we just have to change the base font size from 1px to 2px. Hope that makes sense.

[ackalker]

If considering REMs, this component, emify, may be of interest while testing the CSS. Note: Not meant as a shameless plug, I'm not its creator, I just like the simplicity of it :-)

[larz0]

Thanks @ackalker I'll take a look.

[ackalker]

Thanks :-) Regarding the zoom style hack, poking around with Web Developer, I've noticed one problem already: https://github.com/adobe/brackets/blob/master/src/command/Menus.js#L1029 is using Event.pageX/Y when checking for clipping of the context menu. I think this should use clientX/Y (or perhaps even screenX/Y), since it's the client window (or screen*) which would clip the menu, not the rendered HTML document. Placing the context menu by setting its style property should convert these coordinates to document (taking into account scaling, etc.).

*) if the menu would be allowed to reach beyond the edges of the window, but still be within the screen (is this even possible in a browser?)

[ackalker]

hm, no, that isn't the problem... Opening a simple 'image follows mouse' jsfiddle in brackets-shell by doing window.location.href="http://jsfiddle.net/lesson8/SYwba/" in devtools works well, even while zoomed in. Must be some other problem.

[ackalker]

Here is a link that may pertain to this issue: http://bytes.com/topic/javascript/answers/93732-zoom-page-mouse-position-wrong The example page isn't there anymore, it can be found using the Wayback Machine: https://web.archive.org/web/20090414211438/http://www.djwice.com/contextmenu.html

For some reason I've got the feeling that in Brackets there is some weird interaction between jQuery and CodeMirror going on which causes the positioning problems, correct? In this demo of CodeMirror's autocomplete function (without any jQuery on the page): http://codemirror.net/demo/complete.html , the completion dropdown and cursor positioning with mouse click works in my browser (zoomed 200%) without any problems.

I've also noticed that style is forced to { zoom: 1 } in many places in many ways in Brackets (bootstrap, jQuery, etc.). Isn't that meant to be a fix for an IE bug loong time gone? This 'fix' has the weird effect of showing up in devtools in computed styles for elements everywyere, overriding anything I've set myself. I'm unable to find what rule(s) are doing this, probably because 'officially' zoom is not inherited. Weird.

[peterflynn]

Fwiw, for the high DPI use case specifically this shouldn't be needed -- Brackets should just display correctly on its own. That's tracked by High DPI support on Windows and Linux on our feature backlog (it's already working on Mac), and we expect to get this done sometime later this fall once we're able to update to a newer Chromium version.

[larz0]

Removed "[UX]" from title and unassigned myself so this can get fixed.

[abose]

Have you tried using OS features to zoom the UI elements. [Control Panel\All Control Panel Items\Display ans setting the scale factor to 200% or higher.].

[pmario]

@ackalker Hi, Any news on this issue?

Got my XPS13 ubuntu edition lately and the style hack still seems to have the problem described in the OP. It works just fine on my windows machine. any help would be appreciated!