Last Comment Bug 41464 - textarea.wrap not exposed through DOM (IE compatability)
: textarea.wrap not exposed through DOM (IE compatability)
Status: RESOLVED FIXED
: dev-doc-complete, dom0, testcase
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: -- normal with 8 votes (vote)
: mozilla1.9.3a2
Assigned To: :Ms2ger (⌚ UTC+1/+2)
:
Mentors:
: 302710 (view as bug list)
Depends on:
Blocks: 159979
  Show dependency treegraph
 
Reported: 2000-06-04 06:10 PDT by Martin Honnen
Modified: 2010-03-17 12:18 PDT (History)
22 users (show)
dao+bmo: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
bug demo (button click changes the wrap property but wrapping inside the textarea is not changed) (665 bytes, text/html)
2000-06-04 06:12 PDT, Martin Honnen
no flags Details
ancient patch to expose this... (4.14 KB, patch)
2001-03-22 15:12 PST, Eric Pollmann
no flags Details | Diff | Splinter Review
Textarea tester: Dynamically change .wrap; View submission (4.29 KB, text/html)
2006-04-02 13:51 PDT, Csaba Gabor
no flags Details
Patch v1 (8.39 KB, patch)
2010-02-03 08:45 PST, :Ms2ger (⌚ UTC+1/+2)
bzbarsky: review+
Details | Diff | Splinter Review

Description Martin Honnen 2000-06-04 06:10:38 PDT
Textarea elements have a
  wrap
attribute which can have values
  off
  hard
  soft
While mozilla supports setting those via html it fails to change the wrapping 
when the attribute is changed via javascript. IE5 does that nicely.
Comment 1 Martin Honnen 2000-06-04 06:12:13 PDT
Created attachment 9590 [details]
bug demo (button click changes the wrap property but wrapping inside the textarea is not changed)
Comment 2 Kevin McCluskey (gone) 2000-06-09 17:57:56 PDT
Reassigning to Eric, but I'm not sure if pollmann, rods, or mjudge owns this 
one.
Comment 3 Eric Pollmann 2000-06-09 23:04:56 PDT
Hm, I tried returning a hint of REFLOW and FRAMECHANGE for that attribute change 
in nsHTMLTextAreaElement::GetMappedAttributeImpact and neither seemed to have 
any effect.  It would be good to get this working in the Ender lite version, so 
I'll work with Mike try that...
Comment 4 Eric Pollmann 2000-06-09 23:21:35 PDT
Ah, okay...  So the reason why this does nothing is that it is not part of the 
DOM spec.  See:

http://www.w3.org/TR/2000/CR-DOM-Level-2-20000510/html.html#ID-24874179

We have a fairly strict interpretation of the spec in most cases, so that is why 
this attribute is not exposed through the DOM.  I'm CC'ing our DOM guy to see if 
it make sense to add this to our proprietary extensions (i.e. add it to 
NSHTMLTextAreaElement in the idl file)
Comment 5 Johnny Stenback (:jst, jst@mozilla.com) 2000-06-10 15:30:30 PDT
I think it should be possible to solve this without changing any DOM code or
interfaces, the actual wrapping of the text is done in the editor in the
textarea frame (AFAIK) and the testcase here shows that setting and getting the
value of the .wrap property (which just maps to the attribute getter/setter)
does work. It looks like the problem is that the textarea should be reflown when
the wrap attribute changes and nsGfxTextControlFrame::Reflow() needs to change
the wrapping in the editor in the textarea frame...
Comment 6 Eric Pollmann 2000-06-11 18:53:47 PDT
Hmm..  After some testing, I found that we actually do need to change the idl 
interfaces in the DOM in order to let the GfxTextControlFrame know that it needs 
to reflow when the wrap property changes (specifically, adding a wrap attribute 
line to NSHTMLTextAreaElement inside HTMLTextAreaElement.idl).  I've got all the 
changes in my tree needed to fix this bug, though with the change we are giving 
a hint of FRAMECHANGE instead of REFLOW which is not the most efficient way to 
do things (but better than not doing them at all).
Comment 7 Johnny Stenback (:jst, jst@mozilla.com) 2000-06-12 16:11:21 PDT
Hmm, ok, or would it be possible to make this change in
GfxTextControlFrame::AttributeChanged() (plus the DOM changes) and avoid hinting
about possibly unnecessary reflows?
Comment 8 Eric Pollmann 2000-06-12 19:10:06 PDT
Thanks, I didn't try that yet, I'll give it a whirl!
Comment 9 Eric Pollmann 2000-07-31 11:21:40 PDT
This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another 
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.
Comment 10 ckritzer (gone) 2001-03-19 12:52:27 PST
->gerardok
Comment 11 Eric Pollmann 2001-03-22 15:12:07 PST
Created attachment 28528 [details] [diff] [review]
ancient patch to expose this...
Comment 12 Kevin McCluskey (gone) 2001-10-29 11:58:21 PST
Bulk reassigning Eric Pollmann's remaining form submission bugs to Alex.
Comment 13 Johnny Stenback (:jst, jst@mozilla.com) 2001-10-29 21:34:48 PST
Fabian, wanna fix this one now? This one should be trivial now that we're using
XPConnect to talk to the DOM from JS.
Comment 14 Fabian Guisset 2001-10-29 23:14:51 PST
I had this one on my radar just never took the time to investigate it. Will look :-)
Comment 15 Fabian Guisset 2001-11-01 12:59:32 PST
So uh... I mapped .wrap to Get/SetAttribute, but it doesn't do anything. Then I
did a static HTML file with attributes wrap="off", wrap="soft", wrap="hard", and
all of them displayed in the same way??
Do we actually support this attribute?
Comment 16 Martin Honnen 2001-11-01 14:09:38 PST
When I filed this bug (4 June 2000) Mozilla at that time supported the wrap
attribute for textarea elements. It doesn't seem to do it anymore. So it might
seem we first need a 4xp compatibility bug (as wrap is not part of HTML 4)
Comment 17 Johnny Stenback (:jst, jst@mozilla.com) 2001-11-01 14:58:39 PST
Hmm, I still see wrapping related code in nsGftTextControlFrame2.cpp, Rod, did
support for the "wrap" attribute regress lately?
Comment 18 Pascal Chevrel:pascalc 2003-04-17 10:59:16 PDT
Should this bug be marked as invalid ? We do not seem to support wrap which is
not part of the w3c specs. It is not a 4xp compatibilty issue since NS4 didn't
support this part of IE DOM either. RFE ?
Comment 19 Martin Honnen 2003-04-18 06:50:48 PDT
When I try the test case
  http://bugzilla.mozilla.org/attachment.cgi?id=9590&action=view
with the Mozilla 1.3 release build on Win 98 then the wrap="off" setting for the
<textarea> element is recognized, the text line is not wrapped and a horizontal
scrollbar is displayed. Thus at least Mozilla 1.3 supports the HTML attribute
wrap for <textarea> elements and I think it should be scriptable as a property
as well.
Comment 20 Christopher Aillon (sabbatical, not receiving bugmail) 2003-12-09 08:57:02 PST
To default owners.
Comment 21 Boris Zbarsky [:bz] (TPAC) 2004-02-08 13:34:20 PST
Editor questions:

1)  Would it be OK to make SetWrapWidth be a no-op when the width is being set to
    the value it already is?
2)  Would it be OK to change the default wrap width value to -1 (so that regular
    text controls don't take a perf hit from editor munging styles that are
    already correctly set)?
Comment 22 Adam Guthrie 2005-09-03 21:44:04 PDT
*** Bug 302710 has been marked as a duplicate of this bug. ***
Comment 23 VK 2005-10-25 06:10:04 PDT
See <http://groups.google.com/group/comp.lang.javascript/browse_frm/thread/750fa0da420a46a6/eb9efd932d383526?hl=en#eb9efd932d383526> 
for much simplier fix found by BootNic: 
...
txtarea.setAttribute('wrap', mode): 
/*Fix display for mozilla*/ 
txtarea.style.display='none'; 
txtarea.style.display=''; 
...

So it's a rendering failure, not a property access problem. So stop saying wise words and fix it ;-) 

Eric Pollmann wrote:
> So the reason why this does nothing is that it is not part of the 
DOM spec.

Oh com'on guys! Textarea doesn't have wrap property? That's a hot discover since 1995. The only reason it's not on the triple-W site is (I guess) that wrap still have double set of arguments supported:
legacy "off", "virtual", "physical" from the golden era of Netscape
newer "off", "soft", "hard" from Microsoft.

As it happens often in such situations, triple-W prefers to keep silence until it's clear where the wind is coming from.
Comment 24 Csaba Gabor 2006-04-02 13:51:49 PDT
Created attachment 216983 [details]
Textarea tester: Dynamically change .wrap; View submission

Truly, it would be nice to have this fixed.  As regards VK's comments and the notes in Bug 302710.  I could not get any of those methods to work for me in FF 1.5.0.1 on my Win 2K Pro.  Furthermore, it is not simply a display issue (as you may verify by this attachment - but remember to uncheck the checkbox for it), since dynamically changing the .wrap setting (between hard and anything else) and then submitting the textarea does not alter what gets submitted to the server.

The attachment does demonstrate a workaround, however.  Essentially, it is:
  function elem(id) { return document.getElementById(id); }
  ta = elem('myTextareaId');
  ta.setAttribute("wrap",newWrapVal);
  var oldValue = ta.value;
  ta.parentNode.replaceChild(ta.cloneNode(true), ta);
  elem('myTextareaId').value=oldValue;

Whenever the checkbox in the attachment is checked, the workaround is in effect.  You can notice it on the client if you are switching to/from a wrap setting of off.  You can notice it on the server when switching to/from a wrap setting of hard.

Csaba Gabor from Vienna
Comment 25 Jason Barnabe (np) 2006-07-03 12:50:59 PDT
This isn't just IE compatibility - XUL textboxes have a wrap attribute and are affected by the same issue.
Comment 26 :Ms2ger (⌚ UTC+1/+2) 2010-02-03 08:45:33 PST
Created attachment 425002 [details] [diff] [review]
Patch v1

This should fix bug 159979 as well.
Comment 27 Dão Gottwald [:dao] 2010-02-06 00:58:12 PST
http://hg.mozilla.org/mozilla-central/rev/ada1992ccacb
Comment 28 José Jeria 2010-02-07 05:19:41 PST
dev-doc-needed to be included in the next "what's new?"
Comment 29 :Ms2ger (⌚ UTC+1/+2) 2010-02-07 10:56:16 PST
I've added notes to <https://developer.mozilla.org/en/DOM/TextArea> and <https://developer.mozilla.org/en/Upcoming_Firefox_features_for_developers>. Is anything else needed?
Comment 30 Eric Shepherd [:sheppy] 2010-03-17 12:18:52 PDT
No, not now. Eventually this will be documented more fully when textareas are properly documented.

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