Open Bug 16909 Opened 20 years ago Updated 3 years ago

Word-wrap text/plain content pref UI

Categories

(SeaMonkey :: UI Design, enhancement)

enhancement
Not set

Tracking

(Not tracked)

People

(Reporter: dmose, Unassigned)

References

(Blocks 1 open bug, )

Details

Attachments

(3 files, 2 obsolete files)

Text files with very long lines (like the chat log in the URL field of this
bug) are extremely unpleasant to read with the browser.  There needs to be
a way to force documents like this to wrap instead of creating a
way-too-wide scrollbar, as happens now.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
There is. You can use the -moz-pre-wrap style

Here's an example from the ua style sheet:

pre[wrap] {
  white-space: -moz-pre-wrap;
}
Status: RESOLVED → REOPENED
Component: Layout → UE/UI
More specifically, there should be UI to allow the user to do this trivially.
Probably a menu item and a preference.  Resetting the component to UI/UE and
reassigning.
Assignee: troy → shuang
Status: REOPENED → NEW
QA Contact: petersen → claudius
Resolution: INVALID → ---
In 4.x we had pref of wrap text under Mail prefs. To me, I think it will be lot
easier to make this wrapping happen by default in Browser if possible. Would any
type of user prefer to "not wrap" the text and rather scroll further to read it?
I realy doubt.
Thoughts?
I agree with shuang; this particular pref is really useful for all of the
browser, not just for the special case of mail/news.
Assignee: shuang → troy
I think troy should have this bug...
Assignee: troy → don
Component: UE/UI → XPApps
It can't go back to me. We already have a layout pseudo style that gets you the
behavior Mose wants. We just don't have a way in the UI to specify it.

I'll give it to Gramps. He'll know what to do.
Assignee: don → mcafee
Summary: no way to word-wrap text/plain content → [FEATURE] need UI pref for word-wrap text/plain content
Target Milestone: M14
Severity: normal → enhancement
Summary: [FEATURE] need UI pref for word-wrap text/plain content → [RFE] Word-wrap text/plain content pref
Target Milestone: M14 → M15
Change to RFE and move to M15 for later evaluation.
spam: added self to cc list as this might affect my realm.
Move to M16 for now ...
Target Milestone: M15 → M16
Target Milestone: M16 → Future
Summary: [RFE] Word-wrap text/plain content pref → [RFE] Word-wrap text/plain content pref UI
nav triage team:

Not a beta1 stopper, marking nsbeta1-
Keywords: nsbeta1-
over to vishy to find an owner
Assignee: mcafee → vishy
I encounter this a lot when using view-source to read the raw html-code. Often,
it's generated code and the entire html-code can be found on a single line. Or
(as seen on many news-sites) part of the file is from a template (correctly
wrapped), and part of is included from a database without any wrapping at all.
Scrolling can be very annoying in this case.
I can make a UI for this if someone tells me how to actually enable the wrapping
for a www page.  Do I apply white-space: -moz-pre-wrap; to the container holding
the text file?
Since vishy's no longer around, reassigning to Ben Goodger; he'll have some idea
of who should really own it, if it's not him.
Assignee: vishy → ben
Attached patch Word wrap patch (obsolete) — Splinter Review
This patch works, but I have no idea if I've done it properly.  I just hacked at
navigator.js until the menu option worked the way I wanted it.

The option is disabled until mozilla comes across a text/plain document.  It
also forgets the word wrap option between pages because I didn't make a pref.  I
figured it wasn't necessary.
We should really support this.

I'm surprised this would work, since it seems to be looking for a pre tag and I
wouldn't have thought that a plaintext document would have a pre tag (I would
have expected us just to show it with pre style but not actually insert that tag
into the tree).  But it does indeed work.

Adding Daniel (CSS guru) -- Daniel, is there a straightforward way that we could
just add a wrap style to our style sheet, instead of adding a style tag on the
first pre node?  If so, would that be a better way of accomplishing this?

I went through the dom tree manually and I believe a plain text doc looks like 
this:

<html><head></head><body><pre>text</pre></body></html>

I looked to see if there was an id="" on the pre tag like View Source, but I 
couldn't find one.
Just for the record, WRAP is not an attribute of PRE, so we have to use CSS but
we can't use the rule that Troy Chevalier gave above.

Akkana: that depends if we want a pref or not, an automatic wrapping or not.

1) if we want all text documents to be rendered with wrapping, I suggest to add
   the following rule to our default stylesheet

      body > pre:first-child:last-child {
        white-space: -moz-pre-wrap;
      }

   it will also apply to HTML documents consisting of only a PRE but we're really
   in the same case than a text/plain doc, aren't we ?

2) if we want this feature to be user-selectable by a selectable menu item for
   instance, I would suggest a preference. The menu item is selectable only
   if the document is text/plain.
   If the pref changes to true, do the following :
     a) the menu item being selectable only for a text/plain document, insert
        in HEAD a LINK element to a resource stylesheet containing the rule
        above. P.ex:

      <link rel="stylesheet" type="text/css" href="resource:///res/pre-wrap.css">

     b) make the parser automatically generate this LINK element into the HTML
        document containers for text/plain objects; this LINK will never be
        saved because the document is text/plain...
 
   If the pref changes to false, do the following :
        remove the LINK element from the HEAD of the current document
        (or perhaps documentS... You'll have to look at all rendered docs)

A variant of (2) is the application/removal of a specific UA stylesheet
containing the rule above.

From my personal user's perspective, (1) is not desirable. I don't want the UA
to decide for me if it does wrapping or not. That should be my choice and only
my choice.
Keywords: patch, review
QA Contact: claudius → sairuh
I've pretty much got a patch made which will insert the link tag into the 
document, I'm just wondering... is my call to updateWordWrap is in the correct 
place in the code?
Attached patch Updated wordwrap diff (obsolete) — Splinter Review
This new version attaches a <link> tag at runtime.  The rest of the patch is
above my head and I need some help with it (This SHOULD be the easy stuff).

1) it needs to be applied as soon as a page of content-type: text/plain is
loaded
2) the menu option needs to be grayed out when the document isn't wrappable.
3) I'm using patch maker so I couldn't attach the .css file in the patch.
4) Make a pref and have the checkmark reflect it

and finally an optional 
5) Make it work on html documents with <pre> tags.  For some reason, it won't
work if there are other objects in the <head> of the document, but I can't see
what, in the code, is wrong.
Can someone obsolete Word wrap patch   patch   11/02/01 15:16?
Attachment #56318 - Attachment is obsolete: true
Just a few comments:

1)  We likely want to be able to apply this to application/x-javascript,
    text/javascript, text/css, and the like, not just to text/plain.
2)  When the user toggles wrap, I feel that documents in other windows should
    not be affected until the user loads a new document in those windows.  This
    is similar to how toolbar visibility and the like works (and to how word
    wrap works in view-source)
3)  There is really no reason to remove the link tag.  Simply disabling the
    style sheet will do (so add the tag the first time, then just toggle
    whether the sheet is enabled).  In fact, the simplest way to do the whole
    thing, in my view, is to have the parser generate an alternate stylesheet
    <link> with the above rule for non-html content.  Then the user can use the
    normal alternate stylesheet selection menu to toggle whether the sheet is on 
    or off. The only problem with this solution is that it's not persisted....

4)  +    var header = plainTextDoc.getElementsByTagName('HEAD')[0]
    +      if (header != null) {

This will not work.  For backwards compat, the DOM0 [] notation returns 
"undefined" instead of "null" if there is no such node, whereas item() returns 
"null" per DOM2.  Just test for truth of |header|, which will cover both cases.
"2)  When the user toggles wrap, I feel that documents in other windows should
    not be affected until the user loads a new document in those windows."

Isn't this whats happening currently (Haven't looked at the code in a while)?  
If not, do you have any ideas on how to fix it?


"3)  There is really no reason to remove the link tag.  Simply disabling the
    style sheet will do"

How do you disable a stylesheet?  Is the code in the use stylesheet section?


"Just test for truth of |header|, which will cover both cases."

Okay
Attached patch wordwrap diffSplinter Review
I added a user pref, a semi-colon :) and it now takes into account the other
content types.	I changed patch so it now executes every time a web page is
loaded.  I hope this doesn't affect page load times much.

There is one case where the checkmark on the menu option will be totally wrong,
and the menu option is never greyed out because I can't figure out how to do it
without a lot of javascript.

I think I've done as much as I can to this patch.  Someone with more knowledge
will need to pick it up and finish it or they could always tell me how to
finish it :)
Attachment #60365 - Attachment is obsolete: true
> Isn't this whats happening currently 
It should be, reading the code.  It wasn't clear that this was agreed on.  :)

> How do you disable a stylesheet?

If "elt" is a Link element:

elt.disabled = true;  (or false to enable)
*** Bug 126115 has been marked as a duplicate of this bug. ***
Bug 114707 seems related (but it is for all kinds of files).
I would really like to see this in the trunk and have it work for text/html as
well.  So often web pages have annoying text wrapping issues, and to be able to
force all the text of the page to fit in the window would be excellent.  (For an
example, see above bug 114707.)
Summary: [RFE] Word-wrap text/plain content pref UI → Word-wrap text/plain content pref UI
*** Bug 206969 has been marked as a duplicate of this bug. ***
Can some kind person please send a really simple person a really simple guide to doing this patch? I don't really understand what I need to do. All I want to do is set Mozilla up so .TXT files are displayed with long lines wrapped to the window width. That's all. Thanks in advance!
Mark, you can use Neil's existing patches in this bug as a guide....
*** Bug 229678 has been marked as a duplicate of this bug. ***
Mass reassign of my non-Firefox bugs to ben_seamonkey@hotmail.com
Assignee: bugs → ben_seamonkey
This looks like low hanging fruit with a nice bang for the buck. I just checked,
and the latest IE does not do this. This would be a really nice little thing to
demo to someone.


> Comment #1: You can use the -moz-pre-wrap style

The functionality is basically done.


> Comment #2: there should be UI to allow the user to do this trivially.

> Comment #3: lot easier to make this wrapping happen by default ... Would any
type of user prefer to "not wrap" the text and rather scroll further to read it?

> bug 114707, Comment #2: toggle ... Apache logs without hte wrapping, one hit
at a line and with the wrapping - all info on the screen without scrolling.


Imo, you should make plain text wrap by default, with no UI in the standard
product to do otherwise. Then someone can write an extension to support a no
wrap stylesheet, or better yet, arbitrary user stylesheets with nowrap being an
example supplied with the extension.
Flags: blocking1.8a?
> Imo, you should make plain text wrap by default

Sorry, but this would probably break a lot of things out there, especially since
IE doesn't do it.

Argue for things if you will, but have some perspective.
>> Imo, you should make plain text wrap by default

> this would probably break a lot of things out there, especially since IE
doesn't do it.

Well yeah, I'm hoping it will indeed *break* lots of *long lines*. ;>

What you say is correct. And it maybe that the change I suggest is a bad one.
But the latter doesn't follow from the former; it doesn't necessarily follow
from "this would probably break a lot of things out there" that one shouldn't
make the change. It depends on what "break" means, what the benefits of the
change are, and other factors. Imo, when one takes a quick look at the details,
the change I suggest is a compelling one:

1. For each page that ends up "broken" as a result of a default plain text wrap,
I would expect there to be rather more pages that users would say are rendered
"fixed", or at least "better, on balance". Ime, I'd guess a couple orders of
magnitude more. I think that's about right for the average web user too.

2. In all the "broken" cases I can think of, I would expect "broken" to mean a
minor presentational problem. One of the more problematic cases would be
technical content such as programming code or log data that contains long lines.
But see point 4 below. Another might be artistic pages, where horizontal
scrolling is intended: see point 5 below. I could just about conceive of a page
where wrapping has a minor input or ui impact, but I don't think I've seen such
a page. Again, see point 5 below.

3. In almost all "fixed" cases (which, as I said, are quantitively greater), the
improvement is qualitatively greater than the degradation is for "broken" pages.
Text is presented wrapped, which by definition of this point 3 is desirable. And
the user doesn't have to scroll.

4. I believe it would be relatively trivial for users, especially technical
ones, to override the default, reverting behavior to be no wrap.

5. I believe it would be relatively trivial for authors to override the default,
reverting behavior to be no wrap.
Flags: blocking1.8a? → blocking1.8a-
<Neil> CTho: well, it looks as if what you need to do is to make the plain text
sink add in the link element, and the stylesheet switcher will do the rest
<CTho> is there no way from JS to check the content-type and then set the
stylesheet? 
<Neil> CTho: far too hacky
Flags: blocking1.8a4?
Flags: blocking-aviary1.0PR?
Attached patch Proof of conceptSplinter Review
This patch works as long as my computer is on to serve the css file.  It's ugly
and incomplete.
<bz> I think asking jst for review would be a good idea.  And checking whether
he prefers a separate plaintext DTD...
Status: NEW → ASSIGNED
too late for this in firefox PR. it needs to be baked on the trunk for a while
if it is going to go on branches.
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-
So I don't think the approach in this patch is how we would want to solve this.
This code will inject a link tag into the token stream which means that now if
this pref is set, every DOM tree will get this magic link tag from nowhere that
scripts etc may not expect etc. Seems like this is a probem that should be
solved in the presentation layer (i.e. layour/css code), not in the HTML parser.
Sorry, didn't realize this would happen only for text/plain documents, so
injecting an element into the DOM isn't as bad. But I'm still of the oppinion
that the more correct fix for this would be in layout/css code...
Assignee: cst → jag
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: bugzilla → pawyskoczka
Target Milestone: Future → ---
Flags: blocking1.8a4?
Flags: blocking1.8a4-
Flags: blocking1.8a1-
Flags: blocking-aviary1.0PR-
Flags: blocking-aviary1.0-
*** Bug 248290 has been marked as a duplicate of this bug. ***
Product: Core → Mozilla Application Suite
(In reply to comment #2)

> More specifically, there should be UI to allow the user to do this trivially.
> Probably a menu item and a preference.  Resetting the component to UI/UE and
> reassigning.

This post is a "me too" reply and a bump. I'd like to see this feature (the option of wrapping long lines 
in plain text output), but the ticket appears to have been abandoned.
*** Bug 303717 has been marked as a duplicate of this bug. ***
Blocks: 253564
*** Bug 362600 has been marked as a duplicate of this bug. ***
The implementation of this RFE was actively discussed until a little more than two years ago.  Then nothing.  Is this dead, or will it be implemented?  

Note:  After reading the discussion, I believe -- 

1.  This should be an option to avoid breaking pages where tabular or artistic layout is important.  The discussion seemed to conclude with this intent.  

2.  This should be limited to pages that have NO HTML markup.  Content within <pre> </pre> obviously is intended to be displayed as written, even if that means annoying horizontal scrolling.  Content not within <pre> </pre> already has its wrapping defined, either implicitly by default or as specified via explicit HTML and CSS.  
Hi, I´m a newbie so sorry if I might post wrong!

Could you integrate this Add-on (https://addons.mozilla.org/en-US/firefox/addon/2547) into the standard FF? This is standard of IE 7 so FF should be at the same level. ;-)
(In reply to comment #50) 
> Could you integrate this Add-on
> (https://addons.mozilla.org/en-US/firefox/addon/2547) into the standard FF?

Link Wrapper does not seem appropriate to this bug... Am I right that it does not wrap plain text files -- only long links?

There has been a lengthy, detailed discussion of line breaks at <news://news.mozilla.org:119/mozilla.dev.tech.layout> in the thread "Line Breaking".  The main problem is that humans can judge when to break a line, but it's very difficult to create an algorithm that will always be correct.  

One example discussed is the breaking of a line at a /.  While long URIs might be broken before /, the term "c/o" (for "care of") should not be broken.  There was also some discussion whether long URIs should break just before or just after /.  

By the way, Micro$oft does not create standards.  Thus, the fact that IE 7 does something may be a poor reason for Mozilla to also do it.  Too often, the way IE 7 does something is just plain wrong.  
That has nothing to do with this bug. This bug is about making text files with long lines wrap *at all*, not about exactly where they should wrap (which is a CSS issue) or what IE does (which, for this, is irrelevant).
QA Contact: pawyskoczka
Bug 253564 is shown as being blocked by this, but apart from that it isn't mentioned here.  People may be interested in the workaround mentioned there (bug 253564, comment #1).


In response to comment #52, I agree that there may be no perfect algorithm for line breaking, but Mozilla products already include attempts to come close - for example, the text box that I am typing into right now!


To mitigate concerns though, I do agree it should be up to the user whether to 'wrap'.  Perhaps a page-specific option in the View menu?

This option could even be generalized beyond plain text pages.  It could say "Attempt to fit page to available width" and do various additional things to try and get rid of the horizontal scroll bar, such as shrinking too-wide images and ignoring <pre> tags.  (If so, it might then cover bug 114707.)
Assignee: jag → nobody
QA Contact: ui-design
No longer blocks: 253564
Depends on: 253564
When the patch in bug 253564 gets merged to mozilla-central, this bug can be fixed by setting the plain_text.wrap_long_lines pref to true in the Seamonkey default preferences.
Depends on: 849422
I much prefer the ability to wrap only selected Web pages via the Toggle Word Wrap extension from <https://addons.mozilla.org/addon/toggle-word-wrap/>.  This provides a Word Wrap item in the pull-down context menu when I right-click on a Web page, thus avoiding the need to repeatedly toggle a preference.
(In reply to David E. Ross from comment #56)
> I much prefer the ability to wrap only selected Web pages via the Toggle
> Word Wrap extension from
> <https://addons.mozilla.org/addon/toggle-word-wrap/>.  This provides a Word
> Wrap item in the pull-down context menu when I right-click on a Web page,
> thus avoiding the need to repeatedly toggle a preference.

This bug is for Seamonkey. If you are looking for a context-menu toggle for Firefox, see bug 849373.
Re comment #57:  

Mozilla/5.0 (Windows NT 5.1; rv:19.0) Gecko/20100101 SeaMonkey/2.16.1

I have NEVER been a Firefox user.  I migrated from Netscape 4.x to the Mozilla Suite to SeaMonkey.  You will note from the above UA string that I do not even advertise Firefox compatibility.  

The Toggle Word Wrap extension provides a capability that is easier to use than any preference.  As I noted in comment #56, this is via an entry in the pull-down context menu of a page, which means I do not have to use about:config or navigate to [Edit > Preferences > ??] to toggle a preference.  

Why cannot the code in Toggle Word Wrap be implemented within SeaMonkey?
You need to log in before you can comment on or make changes to this bug.