578179 - Option to wrap text to screen width (rather than container width)

Status: NEW

(Core :: Layout: Block and Inline, defect)

Description

[Matt Brubeck (:mbrubeck)]

WebKit on Android has an option to wrap text so that lines of text are no wider than the screen width.  This means that text reflows to fit the screen as the user zooms in and out.  The width of block-level elements does not change - the overall layout of the page stays the same, and only the text wrapping is altered.

We want this option for Fennec, since (a) it makes many web pages much easier to read on small screens, especially in portrait orientation, and (b) we want to convince Android users to switch from the default browser, where many of them rely on this feature.

For reference, the Android WebKit code is enabled by the "kLayoutFitColumnToScreen" preference:
http://www.google.com/codesearch?q=kLayoutFitColumnToScreen+package:"git://android.git.kernel.org/platform/external/webkit.git"

Comment 1

[Robert O'Callahan (:roc) (email my personal email if necessary)]

We could also hack in a similar pref. One place would be at nsBlockFrame::DoReflowInlineFrames, where we compute availWidth ... try capping it to the width of the screen.

Comment 2

[Madhava Enros [:madhava]]

It's probably clear already, but two important things to do here will be:

1. Only activate this on structured zoom-in (i.e. continuous pinch-zoom in shouldn't do this)

2. The page should put itself back together when the user zooms out by _either_ double-tap zoom or pinch zoom.  In the latter case, we'd have to pick the right point at which to trigger the re-reflow, and how to hide it in the zoom animation.

Comment 3

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

We might need to do more than just cap the width -- i.e., also make sure that the width ends up in the right place (i.e., with the edges of the text just barely inside the edges of the viewport).

I scribbled down some notes about this a few months ago, but I'm having a little trouble decoding the notes.  I think my basic idea was that one way of doing this boils down to switching to "text zoom" rather than "full zoom" in certain cases (which should be relatively easily detectable as when the area the user is zooming in on is primarily text), plus the correct positioning algorithm.


(In reply to comment #2)
> It's probably clear already, but two important things to do here will be:
> 
> 1. Only activate this on structured zoom-in (i.e. continuous pinch-zoom in
> shouldn't do this)

I'm curious what you mean by structured zoom-in -- though perhaps it's my lack of familiarity with Android UI.  Are multiple methods of zoom discoverable enough that users will use both enough to discover the differences between them?

Comment 4

[Madhava Enros [:madhava]]

(In reply to comment #3)

> I'm curious what you mean by structured zoom-in -- though perhaps it's my lack
> of familiarity with Android UI.  Are multiple methods of zoom discoverable
> enough that users will use both enough to discover the differences between
> them?

Heh - I'm just dropping in jargon unhelpfully.

What I mean by structured zoom is the mechanism where a user double-taps on some element in the page, and then the broswers zooms-to-fit that element -- so a column width, or the width of a picture, etc.  This is in contrast to "continuous/arbitrary zoom," which we're implementing as pinch-to-zoom , which ignores the structure of the page.

Comment 5

[Benjamin Stover (:stechz)]

Also, it's very important that we try to keep the element the user wanted to view onscreen after reflow.  Some Android browsers do not do this, and it is really annoying.

Comment 6

[Henri Sivonen (:hsivonen)]

(In reply to comment #2)
> 1. Only activate this on structured zoom-in (i.e. continuous pinch-zoom in
> shouldn't do this)

Why not? In Android's default browser (on Froyo on Desire at least), pinch-zoom does line rewrapping to fit lines to the screen and it's *awesome*.

Comment 7

[Henri Sivonen (:hsivonen)]

(In reply to comment #6)
> (In reply to comment #2)
> > 1. Only activate this on structured zoom-in (i.e. continuous pinch-zoom in
> > shouldn't do this)
> 
> Why not? In Android's default browser (on Froyo on Desire at least), pinch-zoom
> does line rewrapping to fit lines to the screen and it's *awesome*.

Apparently that doesn't happen on all devices. It doesn't happen on Samsung Galaxy Tab. Weird.

FWIW, I had a chance to play with Firefox 4 beta on Galaxy Tab and the lack of line wrapping to screen width *when pinching to zoom* was what bugged me the most about Firefox on the device (to the point that the lack of this feature was one of the top 3 reasons why I didn't buy the device).

Comment 9

[Madhava Enros [:madhava]]

(In reply to comment #7)

> Apparently that doesn't happen on all devices. It doesn't happen on Samsung
> Galaxy Tab. Weird.

Yeah - odd. It doesn't do it on the N1 with froyo, which is where my experience with this behavior is coming from.

Comment 12

[dalingrin]

The text zoom in the pre-beta 4 nightlies works pretty well. One issue I have with it is that the physical text resizing mangles the layout and look of many of the websites I frequent. 
Is there a way to rely primarily on viewport zooming rather than text resizing? I believe this would look better across more websites such as how Android's stock browser reflows text.

Comment 13

[Matt Brubeck (:mbrubeck)]

We currently plan to ship Fennec 4.0 using textZoom in the front-end code for reformatting text to fit the screen (bug 611555).  However, I agree with comment 12 that wrapping text to fit a smaller viewport is less likely to mangle page layouts, so I am leaving this Core:Layout bug open in hope that we'll switch to this method in a future version.

Comment 14

[Mark Finkle (:mfinkle) (use needinfo?)]

Is bug 627842 the way we really want to go?

Comment 16

[BugBot [:suhaib / :marco/ :calixte]]

The severity field for this bug is relatively low, S3. However, the bug has 3 duplicates and 18 votes.
:jfkthame, could you consider increasing the bug severity?

For more information, please visit auto_nag documentation.

Comment 17

[BugBot (nomail) [:suhaib / :marco/ :calixte]]

The last needinfo from me was triggered in error by recent activity on the bug. I'm clearing the needinfo since this is a very old bug and I don't know if it's still relevant.