Open Bug 400364 Opened 12 years ago Updated Last year

full page zoom not applied to radiobuttons and checkboxes

Categories

(Core :: Widget, defect, P3, major)

defect

Tracking

()

People

(Reporter: glazou, Unassigned)

References

()

Details

(4 keywords, Whiteboard: [tpi:+])

Attachments

(1 file)

Please see the attached URL.

On the right hand side of the image, a screenshot of http://lemonde.fr resized to fit into a 240px wide vertical gutter.
On the left hand side, a screenshot of the same page with a full zoom ratio applied so the whole content fits into the same 240px width.

Notice the radiobuttons and checkbox at the top and bottom-right of the left screenshot (the zoomed out one).
I blogged about this:
http://weblogs.mozillazine.org/roc/archives/2007/10/a_tale_of_two_z.html
The Firefox 3 full zoom is intentionally not trying to scale layout perfectly, so we may choose to not fix this. On the other hand, we might want to scale down native-themed controls below their nominal "minimum size", if we're zoomed out a lot. Even if so, though, I doubt we'll want to fix this for Gecko 1.9.
As a side comment, I think the property on the markupDocumentViewer is then
badly named. It's not a "fullZoom" and we may need "fullZoom" in the future.
It's "fullZoomWithHinting".
That name was a natural progression from "textZoom", which just changed font sizes. But yeah.
Duplicate of this bug: 401203
Text Zoom suffered from the same problem.  (Bug 158303) 
This bug is not only a layout issue but an accessibility issue as well. If labels are not associated with their corresponding controls, users with a vision impairment and particularly the elderly (many of whom have deteriorating eyesight) have trouble seeing, or clicking on the small default size of these two controls.

Is anybody able to clarify how difficult this is to fix?
I think it's really a theme issue that should be fixed per-platform. We'd fix it by making the theme able to draw larger checkboxes and radio buttons than normal, perhaps by scaling a regular checkbox/radio button.
Opera 9.26 seems to scale these objects correctly when zooming.
Duplicate of this bug: 425106
Duplicate of this bug: 442940
Guys, i also noticed scrollbars can't been zoomed together with radio and checkbox, that could cause some site's layout break.
(In reply to comment #1)
> I blogged about this:
> http://weblogs.mozillazine.org/roc/archives/2007/10/a_tale_of_two_z.html
> The Firefox 3 full zoom is intentionally not trying to scale layout perfectly,
> so we may choose to not fix this. On the other hand, we might want to scale
> down native-themed controls below their nominal "minimum size", if we're zoomed
> out a lot. Even if so, though, I doubt we'll want to fix this for Gecko 1.9.

I very much prefer firefox's "everything zoom" function than ie's "page zoom", in fact "page zoom" is nonsense, while "everything zoom" ie. "all elements zoom" is indeed useful for millions of handheld devices.
Product: Core → Core Graveyard
I find it odd such a blatant zoom issue isn't on anyone's to do list.
Flags: wanted1.9.2?
Whiteboard: [parity-IE][parity-Opera]
Component: GFX → Widget
Product: Core Graveyard → Core
QA Contact: general → general
Please don't forget to fix this bug for Linux builds, too!
Duplicate of this bug: 733348
This happens on Linux as well, so I am changing this to affect all platforms.
OS: Windows XP → All
Hardware: x86 → All
Works for me in OS X with Firefox 25.
(In reply to Nisse Nordin from comment #17)
> Works for me in OS X with Firefox 25.

Unfortunately Bugzilla only allows a specific operating system or "All", so the only way to indicate the problem exists in Windows (just checked Firefox 24.0) and Linux (just checked Nightly 27) is to say "All".
Added party-chrome, because Chrome zooms these controls correctly too. All major browsers do this except for Firefox.

The ability to zoom these controls is already implemented; CSS3 transform does this (in a blurry fashion). Perhaps Firefox could at least fall back onto the blurry scaling until this is resolved properly?

I'm tentatively bumping the importance because this bug results in broken layout if you zoom out. Please revert if this is not appropriate.
Severity: normal → major
Whiteboard: [parity-IE][parity-Opera] → [parity-IE][parity-Opera][parity-Chrome]
Given how simple these controls are to re-implement, combined with how short the list is of platforms/ui-toolkits for which they would need to be emulated to cover 99.9% of users today, it's bizarre that this bug is 7.5 years old with 20 votes and no one working on it.

Even IE11 doesn't use the "native" controls under Windows 8.1 and scales the rendered controls as expected.
Duplicate of this bug: 1088056
The problem is getting worse (version 37.0.2) If 90% zoom is chosen and the width of the page is decreased, a lot of rubbish is displayed. To eliminate a video driver, can someone try https://support.mozilla.org/en-US/kb/find-what-version-firefox-you-are-using or 
http://ebay.com on a 90% setting? 
Apart from the scrollbar disappearing sometimes the whole page is ruined.
Is this the same bug?
@Henk:
No problems while zooming on that pages. (Although in don't know how to set exactly 90%.)

Firefox 37.0.2 Linux tested.

It looks like you have a video driver problem with windows.
Anybody able to solve this or has a work around.
Opera has similar issues with these input types when scaling with CSS and using page zoom.

http://codepen.io/thedigitalman/pen/bpQZyQ
IE 11 and Chrome exhibit the desired behavior and visualizations.
Priority: -- → P1
Whiteboard: [parity-IE][parity-Opera][parity-Chrome] → [parity-IE][parity-Opera][parity-Chrome][tpi:+]
This works for me now on Windows 10 Nightly 53.0a1 (2016-12-14) (64-bit) thanks to bug 418833.
Whiteboard: [parity-IE][parity-Opera][parity-Chrome][tpi:+] → [parity-Chrome][parity-IE][parity-edge][parity-presto opera][tpi:+]
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Whiteboard: [parity-Chrome][parity-IE][parity-edge][parity-presto opera][tpi:+] → [tpi:+]
Moving to p3 because no activity for at least 24 weeks.
Priority: P1 → P3
You need to log in before you can comment on or make changes to this bug.