Bug 84186 - (FontBoosting) Text Autosizing for mobile browsers (master bug)
(FontBoosting)
: Text Autosizing for mobile browsers (master bug)
Status: ASSIGNED
: WebKit
Text
: 528+ (Nightly build)
: All All
: P2 Enhancement
Assigned To:
:
: WebExposed
: 87394 88655 90561 90741 91660 92882 93862 94227 94371 94491 94528 94590 96143 96557 96673 96848 97025 98809 100633 102408 102409 102504 102509 102559 102560 102562 103627 103840 104702 104897 104925 105188 105196 106014 106792 106797 106929 107300 107446 108205
:
  Show dependency treegraph
 
Reported: 2012-04-17 13:16 PST by
Modified: 2013-08-27 01:06 PST (History)


Attachments
Patch (222.76 KB, patch)
2012-05-22 15:43 PST, John Mellor
webkit.review.bot: commit‑queue-
Review Patch | Details | Formatted Diff | Diff
Archive of layout-test-results from ec2-cr-linux-03 (699.08 KB, application/zip)
2012-05-22 17:05 PST, 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 PST, WebKit Review Bot
no flags Details


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2012-04-17 13:16:13 PST
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 From 2012-04-18 01:43:44 PST -------
For reference, bug #73546 is about upstreaming the iOS feature.
------- Comment #2 From 2012-05-08 22:45:27 PST -------
What's the next step here?
------- Comment #3 From 2012-05-22 15:43:42 PST -------
Created an attachment (id=143381) [details]
Patch
------- Comment #4 From 2012-05-22 15:47:02 PST -------
(From update of attachment 143381 [details])
Clearing the review flag because the ChangeLog says this patch isn't meant for review.
------- Comment #5 From 2012-05-22 15:48:09 PST -------
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 From 2012-05-22 15:49:12 PST -------
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 From 2012-05-22 15:49:45 PST -------
(From update of attachment 143381 [details])
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 From 2012-05-22 15:51:53 PST -------
(In reply to comment #7)
> (From update of attachment 143381 [details] [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 From 2012-05-22 16:33:21 PST -------
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 From 2012-05-22 17:05:17 PST -------
(From update of attachment 143381 [details])
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 From 2012-05-22 17:05:24 PST -------
Created an attachment (id=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 From 2012-05-22 18:16:25 PST -------
(From update of attachment 143381 [details])
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 From 2012-05-22 18:16:34 PST -------
Created an attachment (id=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 From 2012-05-23 13:04:51 PST -------
(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 From 2012-05-23 13:55:10 PST -------
(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 From 2012-07-21 03:09:39 PST -------
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 From 2012-07-23 03:25:43 PST -------
(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 From 2012-08-01 05:47:11 PST -------
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 From 2012-08-01 11:44:58 PST -------
> 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 From 2012-10-17 12:59:23 PST -------
This work has progressed to the point where it no longer blocks Bug 66687.  :)
------- Comment #21 From 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 From 2013-04-09 03:58:09 PST -------
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 From 2013-04-09 04:18:03 PST -------
(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 From 2013-04-11 12:15:45 PST -------
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 From 2013-04-15 08:16:33 PST -------
(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 From 2013-05-30 01:44:09 PST -------
(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 From 2013-08-27 01:06:34 PST -------
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.