88.41 KB, image/png
69.34 KB, image/png
94.31 KB, image/png
Remove OS X resolution-changing hack from DoResetWidgetBounds, and get the scale from the device context instead (because it will be up to date already, while the widget may not); and fix scaling in nsCocoaWindow::Resize to work properly with custom devPi
3.27 KB, patch
|Details | Diff | Splinter Review|
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:33.0) Gecko/20100101 Firefox/33.0 Build ID: 20141011015303 Steps to reproduce: Setting layout.css.devPixelsPerPx preference more than 1.0, e.g. 1.10, cuts off panes and context menus. Actual results: After increasing layout.css.devPixelsPerPx, you can open up Preferences pane from Thunderbird Menu > Thunderbird > Preferences. As attached General_Pane.png shows, lower end of the window is cut off. Clicking on tab buttons on the Preferences pane will gradually increase cut off for each related tab pane. You can also notice the cut off for context menu if you right click on "thread pane" or simply clicking on a toolbar menu button. Expected results: layout.css.devPixelsPerPx should not interfere with pane and context menus. This issue also happens for Mac version of Firefox if again layout.css.devPixelsPerPx is set more than 1.0. This issue does not happen for Windows version of Thunderbird and Firefox. layout.css.devPixelsPerPx is mostly used by visually impaired and senior users to zoom interface so that they can see the UI better. Mac users having difficulty to use layout.css.devPixelsPerPx feature properly because of this bug.
Summary: Increasing layout.css.devPixelsPerPx prefence cuts off Panes and Popups for Mac Thunderbird → Increasing layout.css.devPixelsPerPx preference cuts off Panes and Popups for Mac Thunderbird
Switching pane tabs further increase cuts off
Popup menus and context menus are also affected by the bug.
Looks like an OS X dupe of bug 840881 which was already addressed separately for Windows when it was created. Probably also related to bug 861112
I should note that I am also experiencing this on 33.0.2 for OS X (Yosemite).
After comment 0 this also happens with Firefox on OS X. Moving to core.
Component: Theme → Widget: Cocoa
Product: Thunderbird → Core
Version: 31 → unspecified
Summary: Increasing layout.css.devPixelsPerPx preference cuts off Panes and Popups for Mac Thunderbird → Increasing layout.css.devPixelsPerPx preference cuts off Panes and Popups on Mac
I should also point out that while the menu panes are cut off, they are also positioned incorrectly in relation to the mouse and to its correct location. For example, the main Firefox pop-down menu is somewhere around 200-300 pixels off from its proper screen position. The popup menus are also many pixels off from where they should appear. Additionally, many of the functions that appear on the menus act erratic when hovering the mouse directly over the menu item. In fact, it seems that the location where the mouse activates the menu item and where the menu item visually appears is many pixels off.
On MBP with retina display, I found that, if devPixelsPerPx can only set to 2. If smaller the 2, the preference windows would expand on every tab change, however, if larger than 2, the preference windows would strink on every tab change.
my case is under thuderbird 38.3.0
Still problematic under 44.0.2 (This was originally reported in 2014 and status still shows as "UNCONFIRMED"
(In reply to sk5223 from comment #9) > Still problematic under 44.0.2 > > (This was originally reported in 2014 and status still shows as "UNCONFIRMED" +1. Can someone take a look at this bug?
This is a Seamonkey, Firefox and Thunderbird issue, and it's quite big, most non-web layout is broken, clicks aren't captured because they're in the 'wrong' area, etc. Some web layout is broken too, it's mostly when layout relies on image size, iiuc. Notice that changing devPixelsPerPx is the only sensible way to handle nowaday's immense resolutions. Back when everyone was on 1280x1024, this was not an issue. Nowadays it is.
Confirming; this is still happening in Dev Edition 48.0a2 on OS X 10.10.5 on a Macbook Air Retina.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This bug - logged here since 2014 - is more important than one might think. Because it seriously hampers accessibility. Although readability of content can be altered to improve accessibility, readability of menu buttons and flyover text cannot. The add-on called "Theme and Font Size Changer" is meant to address this, but because of this bug, that add-on doesn't work. Mozilla proudly proclaims "Firefox includes many features to make the browser and web content accessible to all users, including those who have low vision . . ." With this bug unresolved that statement remains far from achieved.
Having lived with it for a day now, it is definitely painful not to be able to use multiple context menu items from the main content context menu. David, what's the best way to get this bug on the right radar for further triage?
FWIW, I've run across this because I've been trying to use the add-on sk5223 mentioned in comment 13 to make working on small HiDPI screen less uncomfortable.
Markus or Jonathan, can you take a look?
I'm sympathetic to wanting to be able to read fonts and I want to understand the use case better. On a Mac if the system fonts are too small generally a user would presumably change that setting, or use the built in zoom mode (option-command-8) or some third party magnification. Do we use fonts smaller that the system setting for popups? I don't remember the history of layout.css.devPixelsPerPx... was that intended for a11y?
The pref was initially added in bug 493202, which refers to a bug about bad scaling with some Linux window managers. So not really an a11y thing. Do we know why the addon is not just changing font sizes?
The issue is not fonts. Yes, the fonts are small, but they're only part of the problem. The problem is that with today's humongous resolutions, everything is tiny: text, controls, images and icons. Yes, I often use the native Mac zoom feature, but that's when the application doesnt give me an alternative. For content consumption, having to use the native zoom is annoying. devPixelsPerPx does the job of scaling the UI beautifully... it's only the issues with interaction, as explained (has anyone mentioned <select> elements?), that break the UX, and I *still* keep the UI upscaled even with the issues, just to give an idea of how important this is.
To answer mstange's question, the add-on does currently allow one to change most of the fonts. Unfortunately, for the reasons that entonio cites, that tends to have a somewhat painful user-experience (which typically looks odd or is cropped because things are out of propertion to each other, and often still requires some squinting, because it doesn't catch all the problems). In contrast to that, tweaking devPixelsPerPx keeps everything effectively perfectly layed out, and feels like substantially less painful UX. Another aspect of this is that even if it _were_ possible to get similarly good UX using just font settings, it's an extremely fragile approach, which is likely to break regularly with different releases, as the internal DOM and CSS structures of the front-end evolve.
To answer dbolter's question about what Mac users generally do, the OS X user experience itself is also fairly patchwork, and not particularly great here: http://superuser.com/questions/253973/how-can-i-change-the-system-font-size-in-os-x has a long discussion about this. Another long convoluted thread is here: <https://discussions.apple.com/message/29413101?tstart=0#29413101>. One can use Tinkertool to change the fonts, but it has the same set of problems described in the last few comments, and isn't even able to change all of the system fonts, from what I can tell. I think that we probably have an opportunity to do substantially better than the existing experiences here, hopefully for not too much work.
(The reason this is so important to me is that I want to be able to keep using Firefox on Mac and Mac itself without further exacerbating RSI problems that are currently causing me significant discomfort and nerve issues).
(In reply to entonio from comment #19) > The issue is not fonts. Yes, the fonts are small, but they're only part of > the problem. The problem is that with today's humongous resolutions, > everything is tiny: text, controls, images and icons. entonio: To help understand the context here with a specific example, could you let us know what screen size (physical dimensions and pixel resolution) you have, and what devPixelsPerPx value you're using to get suitable scaling? Thanks.
Flags: needinfo?(jfkthame) → needinfo?(entonio)
My specific setup is as follows, but I've had different ones and the problem is the same: - iMac 27 with native 5160x2880, but that's not the logical resolution - Logical 1600x900 which makes things generally more than comfily legible because they're fixed elements I don't really have to read, only recognise. That applies to most of OS and apps, but not to 'reading' apps such as a browser or pdf viewer. - devPixelsPerPx usually set to 1.2
Thanks. So the Mac OS X default ("best for Retina") logical size for that display would presumably be 2580x1440, right? But you've adjusted that to 1600x900 so that everything is displayed larger. What happens if devPixelsPerPx is reset to its default (-1.0; a negative value means "set it automatically") on that system? If you then load https://people.mozilla.org/~jkew/tests/devPixRatio.html, what does it display for device pixel ratio?
devPixelsPerPx preference already working for Windows without any issues. Because it is not available appropriately for Mac OS X is not easy to describe for Mac users. The feature should be all or nothing. Firefox should support all OS or no OS. As add-on developer, I find it very difficult to explain the bug for the users. Some use Windows computers for work and Mac OS X for home. Having Zoom feature at Windows but not for Mac OS X continuously increase bug reports and support request for me. Especially request are directed by senior or visually impaired people. So the bug deserves to be fixed because there is a genuine need by required people. As stated by other commentators, font size can be increased by the add-on. But for a toolbar button in Firefox's toolbar, the text gets bigger and bigger but the icon next to button stay same. This creates visual inconsistencies. UI does not look fine. And user who need to request text size also do have the same need for increase of icon size for visual reasons. But icon size can not be increased appropriately because it gets blurred when enlarged. That is why devPixelsPerPx is necessary to keep the proportions both for Text and Image. Again for visual reasons, users need to zoom both Firefox UI and Web elements at the same time. Having a zoom effect by font size is feasible for Firefox UI but things get complicated for web pages. Many designs are fixed and increasing font size for web page elements generally breaks the layout and create huge bugs. Because there are uncountable of web sites and web design, attempting to change font size of web page is very risky. And even it may cause huge performance penalty. But devPixelsPerPx solves the need of user for zooming both for Firefox UI and Web pages at the same time. No eye squint, no design breaks and no web page issues. Also some Operating System zoom features work global, if enabled. Some users work with multi monitors. While keeping default resolution in Laptop screen, they prefer to have zoomed Firefox on external computer screen or HD TVs. Especially Firefox UI gets so tiny on big screen TVs, using Zoom feature comes necessary for even normal sighted people. Nevertheless most users even visually impaired people prefer Theme Font Size Changer over OS zoom utilities. But devPixelsPerPx is a big issue for Mac OS X users to have the add-on fully working. The bug importance seems to be minor, just a few users commented about bug, but indeed need is there for many people and impacts are very dramatic if it gets fixed. As a developer I do not rely Zoom feature but the feature makes very sense for the people who need and use it. Hope it gets fixed.
By resetting the value to -1.0, that page tells me ``` Device Pixel Ratio: 1 innerWidth: 1558 innerHeight: 760 screenX: 42 screenY: 23 Sample of 10px Arial Sample of 9px Arial Sample of 8px Arial Sample of 7px Arial Sample of 6px Arial Sample of 5px Arial Sample of 4px Arial Sample of 3px Arial ``` In varying font sizes, of course. I must say Baris Derin summed it all quite well, imo. I must apologise for my earlier 5160 mistake, it's 5120 so 2560.
The widget sizing problem here is a result of the OS X-only hack in DoResetWidgetBounds(), which is not correct when devPixelsPerPx has been overridden. We can simply remove that, if we get the scale factor from the device context instead of the widget (which may be stale), and that fixes the panel-sizing bugs here, AFAICT. The remaining issue then is that some drop-downs -- in particular, the awesomebar results and the Pocket panel -- flicker rapidly between a somewhat offset position and their correct location. That's because nsCocoaWindow::Resize is applying the wrong scale to the window's current location, so it inadvertently moves it, and then we have to move it right back again. With that also fixed, custom devPixelsPerPx values seem to work well in my testing.
Attachment #8751222 - Flags: review?(mstange)
Assignee: nobody → jfkthame
Status: NEW → ASSIGNED
Comment on attachment 8751222 [details] [diff] [review] Remove OS X resolution-changing hack from DoResetWidgetBounds, and get the scale from the device context instead (because it will be up to date already, while the widget may not); and fix scaling in nsCocoaWindow::Resize to work properly with custom devPi Review of attachment 8751222 [details] [diff] [review]: ----------------------------------------------------------------- Cool!
Attachment #8751222 - Flags: review?(mstange) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/a74ef371c48f64d673d2790557a29aed9b409346 Bug 1087964 - Remove OS X resolution-changing hack from DoResetWidgetBounds, and get the scale from the device context instead (because it will be up to date already, while the widget may not); and fix scaling in nsCocoaWindow::Resize to work properly with custom devPixelsPerPx. r=mstange
Backed out for failing for failing elementFromPoint.html on OSX 10.10 debug. Backout: https://hg.mozilla.org/integration/mozilla-inbound/rev/fd319e90068059710f3e753c8adb52902f86d042 Failure log: https://treeherder.mozilla.org/logviewer.html#?job_id=27738739&repo=mozilla-inbound
Mozilla way again. Thank you very much for your all help and time for fixing this important issue. Many people will be grateful for that. Thanks also for the commentators that helped this bug to be brought into attention by their feedback and support. Much appreciated.
Thanks so much Jonathan, Markus, and everyone else; this is great! Baris, thank you for linking to this bug from your support page; otherwise I never would have known to nudge it along.
@Dan, I personally thank you for your prompt attention and help for fixing this bug. Could we also expect this patch to be included in Thunderbird ans SeaMonkey for Mac OS X? I did not test SeaMonkey yet, but Zoom issue persists for latest Thunderbird nightly. Could you please help those applications also have the patch? Especially Thunderbird is a must.
Baris, the patch here was a change in the code that Thunderbird & SeaMonkey share with Firefox, so it should be included automatically. You might want to wait a day or two, just to ensure that you're trying a build that have the patch.
(In reply to Jonathan Kew (:jfkthame) from comment #30) > https://hg.mozilla.org/integration/mozilla-inbound/rev/ > a74ef371c48f64d673d2790557a29aed9b409346 > Bug 1087964 - Remove OS X resolution-changing hack from DoResetWidgetBounds, > and get the scale from the device context instead (because it will be up to > date already, while the widget may not); and fix scaling in > nsCocoaWindow::Resize to work properly with custom devPixelsPerPx. r=mstange Hi Jonathan, When will this fix be available? Does the "Target Milestone: mozilla49" mean Firefox 49?
Yes. It's currently in Nightly builds; according to the release schedule, it should appear in Firefox Developer Edition next week, then in Firefox Beta and Release channels in due course (assuming no problems are found that force us to revert/reconsider the fix).
Seamonkey nightly builds don't seem to be fixed yet, is that normal?
(In reply to entonio from comment #40) > Seamonkey nightly builds don't seem to be fixed yet, is that normal? They should be. Are you sure you're using a nightly build made from recent source? That is, a build from https://archive.mozilla.org/pub/seamonkey/nightly/latest-comm-central-trunk/ (the latest build there seems to be from June 6). The reason I ask is that the download link at http://www.seamonkey-project.org/dev/nightly seems to point to a much older build...
You need to log in before you can comment on or make changes to this bug.