Closed Bug 1193486 Opened 7 years ago Closed 7 years ago

Remove 'Text Size' adjustments in Firefox for Android

Categories

(Firefox for Android Graveyard :: General, defect)

42 Branch
ARM
Android
defect
Not set
normal

Tracking

(fennec43+)

RESOLVED WONTFIX
Tracking Status
fennec 43+ ---

People

(Reporter: aaronmt, Assigned: mcomella)

References

Details

A comment in bug 1124848 reminded me to get this on file. I've had to explain to users for two years now why text-size adjustments does nothing for content in Firefox for Android. Whilst it might have been useful "back in the day" for desktop optimized content, we are a better position today with the content served to us. 

Adjusting this setting does nothing, it is misleading as it has never been explained in product. Kill it 'Great or Dead' style.
Why doesn't the "text size" setting do anything anymore?
Flags: needinfo?(aaron.train)
It has no affect on content fit for mobile. I don't know specifics of what that details.
Flags: needinfo?(aaron.train)
tracking-fennec: ? → 43+
I increased the text size and visited kotaku.com, requested desktop site, and saw no noticeable difference in text size from what I'm accustomed to - seems like we should either fix it or remove it.

Snorp, do you know if the platform code changed here? Is it worth fixing, or do you agree with the removal?

As for the front-end preference, I implemented it as an intern, so it only seems right that I be the one to remove it. :P
Assignee: nobody → michael.l.comella
Flags: needinfo?(snorp)
It could be busted, but the font inflation also only kicks in in certain (unknown to me) circumstances. I think we should remove it, as the platform code is unmaintained these days. Additionally, I think people are seeing far fewer desktop sites, making inflation unnecessary. We did discuss adding a way of scaling up *all* text in triage as an a11y feature.
Flags: needinfo?(snorp)
Oh, turns out we disabled font inflation: bug 1127441. There was some controversy in that bug about whether or not it should be removed, but that discussion seems to have stalled - let's remove the setting.
Depends on: 1127441
(In reply to Mark Finkle (:mfinkle) from bug 1127441 comment #4)
> Plan is to set the default to "no inflation" on Fx38, but let the Settings
> UI in place. We'll watch for feedback and telemetry.

Finkle, has there been any telemetry or feedback to suggest that we shouldn't remove the setting?
Flags: needinfo?(mark.finkle)
(In reply to Michael Comella (:mcomella) from comment #6)
> (In reply to Mark Finkle (:mfinkle) from bug 1127441 comment #4)
> > Plan is to set the default to "no inflation" on Fx38, but let the Settings
> > UI in place. We'll watch for feedback and telemetry.
> 
> Finkle, has there been any telemetry or feedback to suggest that we
> shouldn't remove the setting?

There is UI telemetry that tells us how much people use this setting. For reference, look for "font.size.inflation.minTwips" in the settings tab.

I think Barbara should help us decide whether or not we should keep this feature. However, if it's busted, we should either remove it or we need to fix it.
Flags: needinfo?(bbermes)
Font inflation itself is still working - I can see it live in action here on Bugzilla.
I realise this is only anecdotal evidence, but despite mobile-friendly content having become more prevalent, I still find myself using a not very large, but still significant number of pages with desktop content, e.g. a number of forums with software that still doesn't include a mobile-friendly/responsive theme, or some other, general content as well (and Bugzilla itself :-) ).

I've also given the "Reflow Text" setting on Nightly a try, but at least at a quick glance I still prefer Font Inflation - on those pages where I need it, it wirks well enough and seems more intuitively than "Reflow Text".

But I agree that the naming of that setting is less than perfect, as it gives the impression of affecting font sizes everywhere, instead of only on (most) desktop content.
Margaret, I couldn't find anything in UI telemetry about fonts except font-button, is that the one?

As per our funnel discussion, here is my take; this feature is confusing to people, hence we should remove the current implementation but rather consider creating a feature that allows people to change the font size all together throughout the entire page and not as it's done right now.

It might also be worth considering the updated feature to be moved to something more related to accessibility. So let's remove it and create a new bug / feature request to include "resizing font size" no matter if mobile or desktop website.
Flags: needinfo?(bbermes)
(In reply to Barbara Bermes [:bbermes] from comment #9)
> Margaret, I couldn't find anything in UI telemetry about fonts except
> font-button, is that the one?

It's in the Settings tab and is called "font.size.inflation.minTwips"
http://people.mozilla.org/~mfinkle/uitelemetry/#setting-tab
 
> As per our funnel discussion, here is my take; this feature is confusing to
> people, hence we should remove the current implementation but rather
> consider creating a feature that allows people to change the font size all
> together throughout the entire page and not as it's done right now.
> 
> It might also be worth considering the updated feature to be moved to
> something more related to accessibility. So let's remove it and create a new
> bug / feature request to include "resizing font size" no matter if mobile or
> desktop website.

If we hooked the current UI to the textsize pref ("font.minimum-size.%LANG%" ?) and let "font.size.inflation.minTwips" set to zero (0), we should have a desktop-like text size system.
Flags: needinfo?(mark.finkle)
In that case, what would happen to Font Inflation? I feel it still has some value for viewing desktop content, because one basic problem remains: By design, desktop content is rendered much smaller. Zooming in doesn't help, because it introduces horizontal scrolling.
A general font size setting also doesn't help for that use case, because by the time the font size has been bumped up enough for desktop content to become readable, mobile content is way too large - and always having to fiddle with that setting in order to adjust font size isn't exactly comfortable, either.

I've given it a try: I deactivated font inflation and set font.minimum-size.x-western to 42 - on the Apollo Lunar Flight Journal this is approximately comparable to the medium setting for font inflation.
While font.minimum-size works reasonably well for the ALFJ with its very simple HTML content, I've also easily found other pages I regularly visit where using font.minimum-size gives worse results than font inflation, because heavily increasing font sizes everywhere simply breaks the page layout.

And of course, on mobile-friendly pages, that font size setting is now *much* too large - and about:config becomes nearly unusable.
I'm going to investigate what made font inflation stop working - I don't think that bug 1127441 actually removed the code for font inflation (just turned it off by default) but I need to check.
Font inflation still works. Use desktop Wikipedia as a testcase.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Does "WONTFIX" mean the font inflations stays?

Btw, telemetry for font inflation won't probably give real results because it's broken now (wrt orientation change) so I had to switch it off even though I need it. Statistics of use of a partially working feature has little correlation with the need for the working feature.
(In reply to MaximYanchenko from comment #14)
> Does "WONTFIX" mean the font inflations stays?

Yes. The WONTFIX is because we won't be removing the preference, because we won't be removing font inflation.

> Btw, telemetry for font inflation won't probably give real results because
> it's broken now (wrt orientation change)

How is font inflation broken during orientation change?

Good observations about statistics and non-fully functioning features.
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.