Closed Bug 801277 Opened 7 years ago Closed 7 years ago

resizer in corner of text-area does not draw correctly when page is zoomed

Categories

(Core :: Widget: Cocoa, defect)

x86_64
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla19

People

(Reporter: jfkthame, Assigned: jfkthame)

References

Details

Attachments

(5 files)

When zooming out on a page with a resizable text area (such as this Bugzilla field), the resizer in the corner becomes correspondingly smaller, but it "drifts" away from the corner of the area. Looks like the scaled-down resizer is being drawn at the same (top-left) origin of its original non-scaled bounding rect.

Conversely, when zooming in, the resizer begins to disappear outside the bottom-right of the text area, as it is scaled up but drawn at the same unscaled origin, so an increasing amount of the graphic gets clipped away.

Attached screenshot shows an example after zooming out by three steps; note how the resizer has begun to "float away" from the corner of the text area.
Assuming we do want the resizer to scale with page zoom (which could be debated, but on the whole I think it's probably the right thing to do), this seems to fix the issue I'm seeing; don't know if it's really the right place to fix it, though.
Attachment #671087 - Flags: review?(roc)
Comment on attachment 671087 [details] [diff] [review]
option 1 - adjust resizer rect to account for page zoom factor.

Review of attachment 671087 [details] [diff] [review]:
-----------------------------------------------------------------

Generally we size native form controls in device pixels, so fullzoom doesn't change their size. I think this is usually the right thing to do since native form controls often look pretty bad when scaled and they should already be the correct size for usability.

What I don't understand in this bug is why the resizer box is moving away from the corner of the textbox. Does zooming in change the device-pixel scrollbar width on Mac? It doesn't on Windows.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #2)
> Comment on attachment 671087 [details] [diff] [review]
> adjust resizer rect to account for page zoom factor.
> 
> Review of attachment 671087 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Generally we size native form controls in device pixels, so fullzoom doesn't
> change their size. I think this is usually the right thing to do since
> native form controls often look pretty bad when scaled and they should
> already be the correct size for usability.
> 
> What I don't understand in this bug is why the resizer box is moving away
> from the corner of the textbox. Does zooming in change the device-pixel
> scrollbar width on Mac? It doesn't on Windows.

No, scrollbar width is unchanged - and the native resizer that we show when scrollbars are present is also unaffected. But when there's no scrollbar, we don't use the native-theme resizer on Mac (http://mxr.mozilla.org/mozilla-central/source/widget/cocoa/nsNativeThemeCocoa.mm#2926), and that's when this issue appears.
I still don't get why it's moving away from the corner of the textbox. We should be drawing it to fill the size we allocated for it. Do you know why we aren't?
I haven't looked into how we draw the (non-native) resize-grabber graphic. (Where do we do that?) It looks like it's simply being drawn scaled from its default size according to page-zoom (like other widgets such as popup menus, radiobuttons, checkboxes, etc.), rather than fitted into the rect we allocated for it.
resizer.css makes it just an image, 15x15 pixels I think.

I think what's happening here is that as you zoom out, the scrollbar width and height is a constant number of device pixels, as intended. When this exceeds 15px, the size of the resizer image, we're making the resizer box bigger than 15px but the image is still only 15px and is rendered at the top left hand corner of the resizer's box.

So the main question is whether we want the resizer's size to change as we zoom (like regular Web content) or not (like native-themed widgets such as scrollbars). I lean towards the latter, because of its close relationship with the scrollbars. What do you think?

If you agree, then "nscoord defaultSize = nsPresContext::CSSPixelsToAppUnits(15);" should be changed to 15 *device* pixels. And we need to resize the background image to fit the box. background-size:100% 100% in resizer.css should do it.
(In reply to Robert O'Callahan (:roc) (Mozilla Corporation) from comment #7)
> So the main question is whether we want the resizer's size to change as we
> zoom (like regular Web content) or not (like native-themed widgets such as
> scrollbars). I lean towards the latter, because of its close relationship
> with the scrollbars. What do you think?

Yes, that's the question we need to decide in order to choose which way to fix this. My inclination was to suggest that the resizer *should* zoom along with web content (see comment 1), as that's what we do with other elements such as popups, radiobuttons, checkboxes, at least on OS X. However, that would lead to an inconsistency in that when a scrollbar is present, we use the native resizer and *don't* zoom it, so the behavior would vary according to presence/absence of the scrollbar.

I notice that we're not very consistent across platforms regarding zoom behavior, anyway; just tried zooming a bugzilla page Linux, and notice that while popups themselves zoom, their double-arrow indicators don't; and while checkbox labels zoom along with the rest of the page, the box itself remains fixed-size. Pretty messy.

So really, I don't have a hugely strong opinion one way or the other. I'd still lean towards zooming the resizer when possible, and consider the fact that scrollbars (and the native resizer, when we show it) don't zoom to be a regrettable anomaly; I think that as a matter of principle, page zoom *should* uniformly zoom everything in the page. The fact that certain native controls don't render nicely when zoomed, and so we've decided to lock their dimensions, is a limitation of some implementations, and it makes for fairly ugly results when they're used on highly-zoomed pages. Where possible, we should avoid it.

But if you feel strongly that we should treat the resizer (even when fixed-size native scrollbars aren't present) as unzoomable, I can try putting together that version of the patch.
Yup, to prevent the resizer being scaled, it seems to be sufficient to set an explicit background-size in the CSS. Question remains, which option do we want to use?
Attachment #671870 - Flags: review?(roc)
Attachment #671087 - Attachment description: adjust resizer rect to account for page zoom factor. → option 1 - adjust resizer rect to account for page zoom factor.
I don't have a strong opinion in the abstract. Option 1 looks better in your screenshots, for sure. But what if the textarea has a vertical scrollbar showing? Won't the mismatch between the width of the scrollbar and the size of the resizer look shabby?
On OS X, at least, we switch to the native-theme resizer when a scrollbar appears, and that doesn't get zoomed. (See comment 8.) Of course, that'd mean there would be a possibly-jarring change as the textarea is resized and/or its content changes, so that the scrollbar appears or disappears.

Ideally, I think we'd scale *everything*, including scrollbars. But if scaled scrollbars look bad, I guess there's no perfect solution.
Comment on attachment 671870 [details] [diff] [review]
option 2 - prevent the resizer graphic being scaled by page zoom.

Review of attachment 671870 [details] [diff] [review]:
-----------------------------------------------------------------

Let's do this then. It should be better than the status quo. If you want to zoom the scrollbars, which sounds fine to me, you can file another bug about that; even if we do that, this patch should still be OK.
Attachment #671870 - Flags: review?(roc) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/af26f70eb73e

I won't pursue zooming scrollbars for the time being - we know that on OS X 10.6, they render badly, so we're pretty much stuck with leaving them unzoomed. Maybe some day...
Assignee: nobody → jfkthame
Target Milestone: --- → mozilla19
Attachment #671087 - Flags: review?(roc)
https://hg.mozilla.org/mozilla-central/rev/af26f70eb73e
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.