Bug 84186 - (FontBoosting) Text Autosizing for mobile browsers (master bug)
(FontBoosting)
: Text Autosizing for mobile browsers (master bug)
Status: ASSIGNED
Product: WebKit
Classification: Unclassified
Component: Text
: 528+ (Nightly build)
: All All
: P2 Enhancement
Assigned To: John Mellor
: WebExposed
Depends on: 94371 94491 94528 94590 96557 102408 102504 102509 102559 104897 105196 106797 107300 87394 88655 90561 90741 91660 92882 93862 94227 96143 96673 96848 97025 98809 100633 102409 102560 102562 103627 103840 104702 104925 105188 106014 106792 106929 107446 108205
Blocks:
  Show dependency treegraph
 
Reported: 2012-04-17 13:16 PDT by John Mellor
Modified: 2015-04-10 10:34 PDT (History)
39 users (show)

See Also:


Attachments
Patch (222.76 KB, patch)
2012-05-22 15:43 PDT, John Mellor
webkit.review.bot: commit‑queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from ec2-cr-linux-03 (699.08 KB, application/zip)
2012-05-22 17:05 PDT, WebKit Review Bot
no flags Details
Archive of layout-test-results from ec2-cr-linux-01 (652.75 KB, application/zip)
2012-05-22 18:16 PDT, WebKit Review Bot
no flags Details
Screenshot of this bug page being rendered unusable by font boosting on a high-resolution phone. (361.88 KB, image/png)
2014-09-16 01:12 PDT, ntucker-webkit.org
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description John Mellor 2012-04-17 13:16:13 PDT
Master bug to track progress and related issues.

When viewing desktop websites on mobile devices, browsers usually layout the page at a fixed width of about 980 CSS pixels due to the default viewport settings. The user usually can't read the text when the page is initially displayed, but can zoom in to read it. However on a portrait phone screen, once zoomed in such that text is a legible size, only about a 320 CSS pixel wide area of content fits onscreen at a time.

For wide columns of text, this means you'd either need to zoom out and look at tiny unreadable / barely readable text, or you'd need to pan left and right for every line of text you read. The same thing happens (though less severely) on landscape phones and on portrait tablets.

To prevent such situations, this bug tracks adding support for Font Boosting (upstreamed from Chrome for Android). When pages load, Font Boosting increases the font size of text in wide columns, so you won't have to zoom in on them as much and hence every column fits onscreen at a legible text size.

Related Links
-------------
Firefox Mobile:
- Description: http://dbaron.org/log/20111126-font-inflation
- Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=627842
- Dev doc: https://developer.mozilla.org/en/CSS/text-size-adjust
Mobile Safari:
- Dev doc: http://goo.gl/rRIiF
Internet Explorer:
- Dev doc: http://msdn.microsoft.com/en-us/library/ff462082(v=vs.92).aspx#sectionToggle2
- Interaction with Compatibility View: http://goo.gl/QdhRm
Comment 1 Simon Hausmann 2012-04-18 01:43:44 PDT
For reference, bug #73546 is about upstreaming the iOS feature.
Comment 2 Adam Barth 2012-05-08 22:45:27 PDT
What's the next step here?
Comment 3 John Mellor 2012-05-22 15:43:42 PDT
Created attachment 143381 [details]
Patch
Comment 4 Adam Barth 2012-05-22 15:47:02 PDT
Comment on attachment 143381 [details]
Patch

Clearing the review flag because the ChangeLog says this patch isn't meant for review.
Comment 5 WebKit Review Bot 2012-05-22 15:48:09 PDT
Please wait for approval from abarth@webkit.org, dglazkov@chromium.org, fishd@chromium.org, jamesr@chromium.org or tkent@chromium.org before submitting, as this patch contains changes to the Chromium public API. See also https://trac.webkit.org/wiki/ChromiumWebKitAPI.
Comment 6 WebKit Review Bot 2012-05-22 15:49:12 PDT
Attachment 143381 [details] did not pass style-queue:

Source/WebCore/rendering/style/RenderStyle.cpp:336:  Should have only a single space after a punctuation in a comment.  [whitespace/comments] [5]
Source/WebCore/rendering/style/RenderStyle.cpp:368:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:369:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:370:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:371:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:372:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:373:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:374:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:375:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:376:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:377:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:378:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:379:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:380:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:381:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:382:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:383:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:384:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/rendering/style/RenderStyle.cpp:385:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/dom/Document.h:275:  Missing space before {  [whitespace/braces] [5]
Source/WebCore/dom/Document.h:282:  The parameter name "node" adds no information, so it should be removed.  [readability/parameter_name] [5]
Source/WebCore/dom/Document.h:283:  Extra space before ( in function call  [whitespace/parens] [4]
Source/WebCore/dom/Document.h:284:  Extra space before ( in function call  [whitespace/parens] [4]
Source/WebCore/rendering/FontBoostingCluster.cpp:41:  Use 'using namespace std;' instead of 'using std::max;'.  [build/using_std] [4]
Source/WebCore/rendering/FontBoostingCluster.cpp:42:  Use 'using namespace std;' instead of 'using std::min;'.  [build/using_std] [4]
Source/WebCore/rendering/FontBoostingCluster.cpp:100:  Should have a space between // and comment  [whitespace/comments] [4]
Source/WebCore/rendering/FontBoostingCluster.cpp:133:  One line control clauses should not use braces.  [whitespace/braces] [4]
Source/WebCore/rendering/FontBoostingCluster.cpp:220:  MAX_X_DISTANCE is incorrectly named. Don't use underscores in your identifier names.  [readability/naming] [4]
Source/WebCore/rendering/FontBoostingCluster.cpp:221:  MAX_Y_DISTANCE is incorrectly named. Don't use underscores in your identifier names.  [readability/naming] [4]
Source/WebCore/rendering/FontBoostingCluster.cpp:286:  RATE_OF_INCREASE_OF_BOOSTED_SIZE_AFTER_MIN_SIZE is incorrectly named. Don't use underscores in your identifier names.  [readability/naming] [4]
Source/WebKit/chromium/src/WebSettingsImpl.cpp:495:  Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons.  [readability/comparison_to_zero] [5]
Source/WebCore/rendering/RenderObject.h:220:  The parameter name "inclusionFunction" adds no information, so it should be removed.  [readability/parameter_name] [5]
Source/WebCore/rendering/RenderObject.h:221:  The parameter name "inclusionFunction" adds no information, so it should be removed.  [readability/parameter_name] [5]
Source/WebCore/rendering/RenderObject.h:224:  The parameter name "render" adds no information, so it should be removed.  [readability/parameter_name] [5]
Source/WebCore/dom/Document.cpp:5242:  Should have a space between // and comment  [whitespace/comments] [4]
Source/WebCore/dom/Document.cpp:5309:  Place brace on its own line for function definitions.  [whitespace/braces] [4]
Source/WebCore/dom/Document.cpp:5310:  Should have a space between // and comment  [whitespace/comments] [4]
Source/WebCore/dom/Document.cpp:5419:  One line control clauses should not use braces.  [whitespace/braces] [4]
Source/WebCore/rendering/RenderBlock.cpp:74:  FB_SET_ATTR is incorrectly named. Don't use underscores in your identifier names.  [readability/naming] [4]
Source/WebCore/rendering/RenderBlock.cpp:7345:  Declaration has space between type name and * in RenderText *renderText  [whitespace/declaration] [3]
Source/WebCore/rendering/RenderBlock.cpp:7347:  Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons.  [readability/comparison_to_zero] [5]
Source/WebCore/rendering/RenderBlock.cpp:7350:  Place brace on its own line for function definitions.  [whitespace/braces] [4]
Source/WebCore/rendering/RenderBlock.cpp:7395:  Tests for true/false, null/non-null, and zero/non-zero should all be done without equality comparisons.  [readability/comparison_to_zero] [5]
Source/WebCore/rendering/RenderBlock.cpp:7403:  One line control clauses should not use braces.  [whitespace/braces] [4]
Source/WebCore/rendering/RenderBlock.cpp:7468:  Declaration has space between type name and * in RenderText *text  [whitespace/declaration] [3]
Source/WebCore/rendering/RenderBlock.cpp:7469:  Declaration has space between type name and * in RenderStyle *oldStyle  [whitespace/declaration] [3]
Source/WebCore/rendering/RenderBlock.cpp:7516:  One line control clauses should not use braces.  [whitespace/braces] [4]
Source/WebCore/rendering/RenderBlock.cpp:7518:  One line control clauses should not use braces.  [whitespace/braces] [4]
Source/WebCore/rendering/style/StyleInheritedData.h:58:  specified_line_height is incorrectly named. Don't use underscores in your identifier names.  [readability/naming] [4]
Source/WebCore/renderFailed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'LayoutTests/ChangeLog', u'LayoutTests/plat..." exit_code: 1
ing/RenderBlockLineLayout.cpp:1548:  TEXT_REFLOW_MARGIN_PADDING is incorrectly named. Don't use underscores in your identifier names.  [readability/naming] [4]
Source/WebCore/rendering/RenderObject.cpp:85:  "Settings.h" already included at Source/WebCore/rendering/RenderObject.cpp:66  [build/include] [4]
Source/WebCore/platform/graphics/FontDescription.h:171:  Place brace on its own line for function definitions.  [whitespace/braces] [4]
Source/WebCore/platform/graphics/FontDescription.h:171:  Extra space before ( in function call  [whitespace/parens] [4]
Source/WebCore/platform/graphics/Font.h:233:  Place brace on its own line for function definitions.  [whitespace/braces] [4]
Source/WebCore/platform/graphics/Font.h:233:  Extra space before ( in function call  [whitespace/parens] [4]
Source/WebCore/platform/graphics/Font.h:234:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Source/WebCore/platform/graphics/Font.h:235:  Boolean expressions that span multiple lines should have their operators on the left side of the line instead of the right side.  [whitespace/operators] [4]
Tools/DumpRenderTree/chromium/WebViewHost.cpp:742:  An else statement can be removed when the prior "if" concludes with a return, break, continue or goto statement.  [readability/control_flow] [4]
Total errors found: 58 in 45 files


If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 7 John Mellor 2012-05-22 15:49:45 PDT
Comment on attachment 143381 [details]
Patch

NOT FOR REVIEW! This patch contains the full Font Boosting implementation from Chrome for Android (rebased onto upstream WebKit). This is purely for reference, to give a global overview of how everything currently fits together. I will upload actual patches incrementally, incorporating appropriate cleanups & refactoring (for example I would like to move code out of generic files like Document.cpp into Font Boosting-specific files).

You can try this patch out on desktop Chrome if you set the compile flags ENABLE_FONT_BOOSTING=1 and HACK_ENABLE_FONT_BOOSTING_ON_DESKTOP=1. It will boost all pages as if they were 980px wide and the device-width was 320px. Don't try this on mobile pages (with a meta viewport tag) or you'll get undefined results!
Comment 8 John Mellor 2012-05-22 15:51:53 PDT
(In reply to comment #7)
> (From update of attachment 143381 [details])
> You can try this patch out on desktop Chrome if you set the compile flags ENABLE_FONT_BOOSTING=1 and HACK_ENABLE_FONT_BOOSTING_ON_DESKTOP=1.

Oops, I mean HACK_FORCE_FONT_BOOSTING_ON_DESKTOP=1 not HACK_ENABLE_FONT_BOOSTING_ON_DESKTOP=1.
Comment 9 Kenneth Rohde Christiansen 2012-05-22 16:33:21 PDT
Thanks for posting this! The basic idea seems quite similar to what we did, but I have to dig into all the special cases.

Instead of hardcoding the size of 320 why don't you use the actual CSS width of the viewport. That is what you zoom into when doing double-tap to zoom, and you want to ensure the minimum fonts size when zoomed into exactly that. Wouldn't that not make it testable on the desktop without the current hacks. People will just have to resize the view instead.
Comment 10 WebKit Review Bot 2012-05-22 17:05:17 PDT
Comment on attachment 143381 [details]
Patch

Attachment 143381 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12749479

New failing tests:
platform/chromium-android/fast/font-boosting/various-tricky-cases.html
Comment 11 WebKit Review Bot 2012-05-22 17:05:24 PDT
Created attachment 143401 [details]
Archive of layout-test-results from ec2-cr-linux-03

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-03  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Comment 12 WebKit Review Bot 2012-05-22 18:16:25 PDT
Comment on attachment 143381 [details]
Patch

Attachment 143381 [details] did not pass chromium-ews (chromium-xvfb):
Output: http://queues.webkit.org/results/12771044

New failing tests:
platform/chromium-android/fast/font-boosting/various-tricky-cases.html
Comment 13 WebKit Review Bot 2012-05-22 18:16:34 PDT
Created attachment 143425 [details]
Archive of layout-test-results from ec2-cr-linux-01

The attached test failures were seen while running run-webkit-tests on the chromium-ews.
Bot: ec2-cr-linux-01  Port: <class 'webkitpy.common.config.ports.ChromiumXVFBPort'>  Platform: Linux-2.6.35-28-virtual-x86_64-with-Ubuntu-10.10-maverick
Comment 14 John Mellor 2012-05-23 13:04:51 PDT
(In reply to comment #9)
> Thanks for posting this! The basic idea seems quite similar to what we did, but I have to dig into all the special cases.
> 
> Instead of hardcoding the size of 320 why don't you use the actual CSS width of the viewport. That is what you zoom into when doing double-tap to zoom, and you want to ensure the minimum fonts size when zoomed into exactly that. Wouldn't that not make it testable on the desktop without the current hacks. People will just have to resize the view instead.

Yes, there are quite a few similarities.

Since desktop Chrome doesn't have pinch zoom, when testing on desktop I find it easiest to resize the browser window to 980px wide but have the page boosted as if it were being rendered on a mobile device (I'll recompile with a different value instead of 320 to simulate other screen sizes like tablets). If I had to resize my browser window to 320px in order for text to be boosted, I would get a good representation of how unboosted text will look after zooming in, but boosted paragraphs would all be wider than the browser window and there would be no way of "zooming out".
Comment 15 Kenneth Rohde Christiansen 2012-05-23 13:55:10 PDT
(In reply to comment #14)
> (In reply to comment #9)
> > Thanks for posting this! The basic idea seems quite similar to what we did, but I have to dig into all the special cases.
> > 
> > Instead of hardcoding the size of 320 why don't you use the actual CSS width of the viewport. That is what you zoom into when doing double-tap to zoom, and you want to ensure the minimum fonts size when zoomed into exactly that. Wouldn't that not make it testable on the desktop without the current hacks. People will just have to resize the view instead.
> 
> Yes, there are quite a few similarities.
> 
> Since desktop Chrome doesn't have pinch zoom, when testing on desktop I find it easiest to resize the browser window to 980px wide but have the page boosted as if it were being rendered on a mobile device (I'll recompile with a different value instead of 320 to simulate other screen sizes like tablets). If I had to resize my browser window to 320px in order for text to be boosted, I would get a good representation of how unboosted text will look after zooming in, but boosted paragraphs would all be wider than the browser window and there would be no way of "zooming out".

You could try testing with Qt and use the MiniBrowser. It supports emulating touch points (create using ctrl plus mouse button), as well as double tap to zoom and pinch zoom.
Comment 16 Rich Bradshaw 2012-07-21 03:09:39 PDT
As a Web Developer, this is causing me a few issues in Chrome for Android – is there a way to disable it (either meta tag, header or CSS?) - if not, can there be?

This feature means that some paragraphs are huge in comparison to others, and that small text in footers is often bigger than body text!

I'm using Chrome on a Nexus 7 as my reference point btw.
Comment 17 John Mellor 2012-07-23 03:25:43 PDT
(In reply to comment #16)
> As a Web Developer, this is causing me a few issues in Chrome for Android – is there a way to disable it (either meta tag, header or CSS?) - if not, can there be?
> 
> This feature means that some paragraphs are huge in comparison to others, and that small text in footers is often bigger than body text!
> 
> I'm using Chrome on a Nexus 7 as my reference point btw.

Currently the only side-effect free way to disable Chrome for Android's Font Boosting is to set CSS max-height:1000000px on the block that contains the text (any fixed height greater than the actual height will do); setting it on the parent or grandparent block (but not higher up than that) will usually also work.

For example, putting the rule "#footer, #footer * { max-height:1000000px; }" at the top of your CSS would disable Font Boosting for the element with id "footer" and all its descendants (putting this at the top of your CSS makes it easier for subsequent rules that set max-height to override it).

Think carefully about why you're disabling Font Boosting though, and make sure to test on a (portrait) phone afterwards to make sure that your site is still legible. If you disable it on wide blocks of text, users will get tiny illegible text (if they fit the block to the screen), or can zoom in but will then have to scroll from side to side to read each line of text, which is a terrible user experience (unless it's for something short and rarely read like a footer).

A cleaner API will be provided for disabling Text Autosizing (the upstream implementation, which is the subject of this bug; feel free to email me if you have further Chrome for Android specific questions).
Comment 18 John Mellor 2012-08-01 05:47:11 PDT
Mozilla posted a very interesting description of how their Font Inflation algorithm works, going into detail on a bunch of their heuristics:
http://jwir3.wordpress.com/2012/07/30/font-inflation-fennec-and-you/

They've also drafted a spec for the CSS text-size-adjust property that web developers can use to control text autosizing:
http://dev.w3.org/csswg/css-size-adjust/

I recommend that interested parties read their algorithm description. I'll probably try and use some of their heuristics instead of some of the ones I was planning to upstream from Chrome for Android, for the sake of making text autosizing more uniform across browsers (and hence easier for web developers to deal with).
Comment 19 Adam Barth 2012-08-01 11:44:58 PDT
> I'll probably try and use some of their heuristics instead of some of the ones I was planning to upstream from Chrome for Android, for the sake of making text autosizing more uniform across browsers (and hence easier for web developers to deal with).

That sounds great.
Comment 20 Adam Barth 2012-10-17 12:59:23 PDT
This work has progressed to the point where it no longer blocks Bug 66687.  :)
Comment 21 John Mellor 2012-11-05 08:29:35 PST
The broad strokes of Text Autosizing are now implemented. I'm re-focusing this master bug to track remaining improvements that can be made, and issues that this causes.
Comment 22 Anton Obzhirov 2013-04-09 03:58:09 PDT
Hi, I was wondering if you are going to finish this feature now after the latest news :) I am enabling it for GTK port. We can help to complete it if needed.
Comment 23 Arvid Nilsson 2013-04-09 04:18:03 PDT
(In reply to comment #22)
> Hi, I was wondering if you are going to finish this feature now after the latest news :) I am enabling it for GTK port. We can help to complete it if needed.

The BlackBerry port maintainers are interested in helping to develop this feature.
Comment 24 John Mellor 2013-04-11 12:15:45 PDT
Hi Anton and Arvid!

As expected, avayvod, timvolodine and I will be focusing on Blink for now, but Text Autosizing is fortunate in being very self contained (most code is in TextAutosizer.cpp/.h). Hence I don't expect this feature to diverge as quickly as the rest of Blink, and it definitely seems feasible to keep the Blink and WebKit implementations in sync if you guys are interested in contributing.

In terms of status, this is shipping in stable Chrome for Android with acceptable quality. We're ramping down development, and from now on expect to do a slow but steady trickle of patches to address the most glaring user issues we discover. Bugs reported by users and QA are on the chromium bug tracker, with the Cr-Blink-TextAutosize label:

https://code.google.com/p/chromium/issues/list?q=Cr=Blink-TextAutosize&can=2&sort=pri
Comment 25 Anton Obzhirov 2013-04-15 08:16:33 PDT
(In reply to comment #24)
> Hi Anton and Arvid!
> 
> As expected, avayvod, timvolodine and I will be focusing on Blink for now, but Text Autosizing is fortunate in being very self contained (most code is in TextAutosizer.cpp/.h). Hence I don't expect this feature to diverge as quickly as the rest of Blink, and it definitely seems feasible to keep the Blink and WebKit implementations in sync if you guys are interested in contributing.
> 
> In terms of status, this is shipping in stable Chrome for Android with acceptable quality. We're ramping down development, and from now on expect to do a slow but steady trickle of patches to address the most glaring user issues we discover. Bugs reported by users and QA are on the chromium bug tracker, with the Cr-Blink-TextAutosize label:
> 
> https://code.google.com/p/chromium/issues/list?q=Cr=Blink-TextAutosize&can=2&sort=pri


Hi, 
Yep, we will be definitely keeping an eye on it, I am going to register in chromium bug tracker to follow your updates for Blink and helping bringing those changes to WebKit.

Arvid, what do you think?
Comment 26 Arvid Nilsson 2013-05-30 01:44:09 PDT
(In reply to comment #25)
> (In reply to comment #24)
> > Hi Anton and Arvid!
> > 
> > As expected, avayvod, timvolodine and I will be focusing on Blink for now, but Text Autosizing is fortunate in being very self contained (most code is in TextAutosizer.cpp/.h). Hence I don't expect this feature to diverge as quickly as the rest of Blink, and it definitely seems feasible to keep the Blink and WebKit implementations in sync if you guys are interested in contributing.
> > 
> > In terms of status, this is shipping in stable Chrome for Android with acceptable quality. We're ramping down development, and from now on expect to do a slow but steady trickle of patches to address the most glaring user issues we discover. Bugs reported by users and QA are on the chromium bug tracker, with the Cr-Blink-TextAutosize label:
> > 
> > https://code.google.com/p/chromium/issues/list?q=Cr=Blink-TextAutosize&can=2&sort=pri
> 
> 
> Hi, 
> Yep, we will be definitely keeping an eye on it, I am going to register in chromium bug tracker to follow your updates for Blink and helping bringing those changes to WebKit.
> 
> Arvid, what do you think?

Sounds great! From the way the BlackBerry port uses the FrameView::fixedLayoutSize(), I've found that we'd like to make it possible to obtain the windowInfo.minLayoutSize from a setting, much like it's already possible to get the windowSize from Settings::textAutosizingWindowSizeOverride(). Then we can tweak these parameters from our WebKit layer. Otherwise text autosizing seems to work as advertised =)
Comment 27 tesoro302 2013-08-27 01:06:34 PDT
I have a question on stackoverflow including example code which demonstrates a Font Boosting problem on mobile Chrome:

http://stackoverflow.com/questions/18422311/long-h1-increases-font-size-of-all-statically-positioned-text-in-mobile-browsers

The problem was indeed fixed by adding "h1,div {max-height: 100000px;}".  Should I file a bug somewhere?  Thank you.
Comment 28 ntucker-webkit.org 2014-09-16 01:09:26 PDT
I must say, I think this font boosting heuristic is a total failure.  It routinely results in pages rendering with comical disparities in font sizes, where wide blocks of text, such as forum posts, are ridiculously large, with three words barely fitting across the screen, but the smaller text elements surrounding them (e.g. forum post headers with username, date, etc) are so tiny as to be completely illegible.  Even loading this very bug report page results in this.  I will attach a screenshot.
Comment 29 ntucker-webkit.org 2014-09-16 01:12:19 PDT
Created attachment 238157 [details]
Screenshot of this bug page being rendered unusable by font boosting on a high-resolution phone.

Screenshot of this bug page being rendered unusable by font boosting on a high-resolution phone.
Comment 30 ntucker-webkit.org 2014-09-16 01:16:15 PDT
Apologies for the blurry image.  Chrome dev tools seems to be resampling the screenshot.  However, it's actually fairly representative of how usable that text is when rendered so small on my phone.  The normal sized text is so small you are forced to zoom, but the font boosting has made the other text so absurdly large that zooming is counterproductive.
Comment 31 mishamsk 2014-12-14 12:06:47 PST
Found yet another bug with this. Full description here: http://stackoverflow.com/questions/27473365/how-to-keep-fonts-consistent-and-respect-text-scaling-on-android-bizarre-bug-of

Basically font scaling stops working when <h6> contains more than two anchors inside (did not check for other header tags)