Note: There are a few cases of duplicates in user autocompletion which are being worked on.

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

NEW
Unassigned

Status

()

Core
Layout: Block and Inline
7 years ago
a year ago

People

(Reporter: mbrubeck, Unassigned)

Tracking

(Blocks: 1 bug)

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(fennec-)

Details

(Reporter)

Description

7 years ago
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"
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.
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.
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?
(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.
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.
tracking-fennec: ? → 2.0b2+

Updated

7 years ago
Assignee: nobody → mark.finkle

Updated

7 years ago
tracking-fennec: 2.0b2+ → 2.0-
(Reporter)

Updated

7 years ago
Blocks: 545703
(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*.
(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).
Duplicate of this bug: 607342
(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.
Duplicate of this bug: 611555
Duplicate of this bug: 603006
(Reporter)

Updated

7 years ago
Blocks: 538117

Comment 12

7 years ago
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.
(Reporter)

Comment 13

7 years ago
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.
(Reporter)

Updated

7 years ago
Blocks: 623820
Is bug 627842 the way we really want to go?
Duplicate of this bug: 669847
Assignee: mark.finkle → nobody
You need to log in before you can comment on or make changes to this bug.