Word wrap problems in 36.0
When entering text into a web form the text no longer "wraps" at the end of the box. The first part of the text runs off the left side. It is working fine in THIS text entry box but is now a problem on some other sites.
See: http://www.thedirectoryclassifieds.com. Start placing a listing and then start entering text into the description box. Once you reach the end of the line the text does not wrap, just runs off the left side as typing continues. After this testing, just exit (back out) without continuing placing the listing.
When encountering this problem I did a test on another computer that had 35.0.1 and word wrapping worked fine. Then I upgraded to 36.0 on that computer and now the problem is there too.
So this definitely means a problem with 36.0 as it wasn't there in earlier versions.
Chosen solution
That particular form control has:
<textarea id="main_description" name="b[description]" style="white-space: pre;" class="editor field"></textarea>
For the first time in Firefox 36, the white-space property is being honored for textarea controls. So there's your trouble: "pre" means Firefox should emulate the preformatted tag, which requires manual line breaks.
It would be great if you can convince the site to change this to:
<textarea id="main_description" name="b[description]" style="white-space: pre-wrap;" class="editor field"></textarea>
which is supported by all modern browsers (per the compatibility table here: https://developer.mozilla.org/docs/We.../white-space#Browser_compatibility).
But that likely will take some time, so what is the best short-term workaround? I need to think about that a bit.
To manually hack this form control, you can right-click it and choose Inspect Element (Q). This should open the web console to the Inspector in the lower part of the tab. Firefox should highlight the HTML tag I listed first above, and on the right, show the style rules for it. Under "This Element" you can uncheck the box for that rule to have the textarea styled using default rules. But you would need to do this after each time you load the page, which is a hassle.
Read this answer in context 👍 7All Replies (4)
Chosen Solution
That particular form control has:
<textarea id="main_description" name="b[description]" style="white-space: pre;" class="editor field"></textarea>
For the first time in Firefox 36, the white-space property is being honored for textarea controls. So there's your trouble: "pre" means Firefox should emulate the preformatted tag, which requires manual line breaks.
It would be great if you can convince the site to change this to:
<textarea id="main_description" name="b[description]" style="white-space: pre-wrap;" class="editor field"></textarea>
which is supported by all modern browsers (per the compatibility table here: https://developer.mozilla.org/docs/We.../white-space#Browser_compatibility).
But that likely will take some time, so what is the best short-term workaround? I need to think about that a bit.
To manually hack this form control, you can right-click it and choose Inspect Element (Q). This should open the web console to the Inspector in the lower part of the tab. Firefox should highlight the HTML tag I listed first above, and on the right, show the style rules for it. Under "This Element" you can uncheck the box for that rule to have the textarea styled using default rules. But you would need to do this after each time you load the page, which is a hassle.
Thank you. Got it fixed already.
I have this problem also.
Here's a solution -
a) Word wrap was working fine until 36.0
b) It no longer works on most sites
c) Adjust 36.0 and future versions back to when it did work
Why is Firefox breaking things that work?
That is what MS does. Mozilla should be simplifying, not making worse.
Hi zzyzzk, let's continue your discussion with your question here: https://support.mozilla.org/questions/1070624
(To address your point: Earlier versions of Firefox did not fully implement the CSS standard in this area and newer versions have caught up. There is always pain when sites rely on nonstandard browser behaviors because sooner or later, those behaviors will change, assuming browser makers continue to make progress toward supporting standards.)