Last Comment Bug 578179 - Option to wrap text to screen width (rather than container width)
: Option to wrap text to screen width (rather than container width)
Status: NEW
:
Product: Core
Classification: Components
Component: Layout: Block and Inline (show other bugs)
: Trunk
: All All
: -- normal with 18 votes (vote)
: ---
Assigned To: Mark Finkle (:mfinkle) (use needinfo?)
:
Mentors:
: 603006 607342 669847 (view as bug list)
Depends on:
Blocks: 538117 545703 623820
  Show dependency treegraph
 
Reported: 2010-07-12 14:48 PDT by Matt Brubeck (:mbrubeck)
Modified: 2015-03-24 12:45 PDT (History)
32 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-


Attachments

Description Matt Brubeck (:mbrubeck) 2010-07-12 14:48:19 PDT
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) (Exited; email my personal email if necessary) 2010-07-12 15:19:13 PDT
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] 2010-07-12 15:34:34 PDT
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-7 (review requests must explain patch) 2010-07-12 17:40:47 PDT
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] 2010-07-20 15:04:37 PDT
(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) 2010-07-21 10:19:12 PDT
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) 2010-10-14 03:40:20 PDT
(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) 2010-10-23 07:05:36 PDT
(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 8 Brad Lassey [:blassey] (use needinfo?) 2010-10-26 13:41:38 PDT
*** Bug 607342 has been marked as a duplicate of this bug. ***
Comment 9 Madhava Enros [:madhava] 2010-11-02 12:39:27 PDT
(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 10 Dietrich Ayala (:dietrich) 2010-11-12 08:25:02 PST
*** Bug 611555 has been marked as a duplicate of this bug. ***
Comment 11 Aakash Desai [:aakashd] 2010-11-12 08:40:46 PST
*** Bug 603006 has been marked as a duplicate of this bug. ***
Comment 12 dalingrin 2011-01-10 23:08:34 PST
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) 2011-01-11 03:49:22 PST
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?) 2011-03-18 12:15:05 PDT
Is bug 627842 the way we really want to go?
Comment 15 Kevin Brosnan [:kbrosnan] 2011-07-07 11:01:23 PDT
*** Bug 669847 has been marked as a duplicate of this bug. ***

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