Closed Bug 17408 Opened 25 years ago Closed 24 years ago

textarea WRAP=HARD doesn't

Categories

(Core :: Layout: Form Controls, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED WORKSFORME
Future

People

(Reporter: akkzilla, Assigned: kinmoz)

References

Details

(Keywords: helpwanted)

Use mozilla to file a bugzilla bug, and type in the Description box. When you get to the end of the box, the text wraps, but not at the right place: a horizontal scrollbar appears, and the textarea scrolls right so that you can't see the beginnings of the lines as you continue to type.
Assignee: karnaze → rods
sounds like something rod changed this week.
This is likely a platform-specific problem; tried to replicate on Windows NT with the 1999-10-27-08-M11 binary, and the textarea wrapping seems to work as expected, exactly when the next character would appear on top of the vertical scrollbar. More importantly, the *horizontal* scrollbar is there from the beginning. Why is this important? The fix for Bug 7461 was making sure that both scrollbars appear from the start on TEXTAREAs. By the reporter's description, this isn't the way it is on Linux. That probably makes this a DUP of bug 7461, and probably means that bug 7461 isn't quite ready to be verified. (note, enter_bug.cgi consistently crashes this build at the "select product" stage, but there is no reason to suspect anything too different about the TEXTAREAs on that page compared to this one, is there?)
Assignee: rods → buster
This is a sizing issue that is realted to the webshell sizing and how it handles scrollbars and not a general gfx sizing issue. The internal viewable area is too large by the size of the scrollbar. Steve, I think this has to do with what I was showing you yesterday.
Target Milestone: M13
setting to M13, should be looked at for beta
Status: NEW → ASSIGNED
Blocks: 16936
Blocks: 7461
I believe that bug 12825 is relevant to this bug; this bug may in fact depend on it. The report for 12825 describes a hack to get around problems with hidden scrollbars affecting sizing. The hack may not be working properly on Linux. A clean implementation of textarea scrollbars, including support for the scroll CSS property, may not be possible without a FIX for bug 12825.
QA Contact update.
Depends on: 12825
kin, you and I should talk about this bug and its relationship to 12825.
Summary: textarea size isn't right → textarea WRAP=HARD doesn't
The partial fix for bug 17303 has fixed most of the problems discussed here. I see three remaining problems with text area sizes: (1) The textarea is much wider than in 4.x because of the serif font: that's covered in bug 17303 and is not an issue for this bug. (2) The textarea is one character too wide. That's the subject of bug 7461, but that bug was marked fixed even though it's not, based on the existance of another bug involving scrollbar visibility. (3) If I type a line of characters with no spaces into the 80-column text area in this bugzilla page, 4.x will wrap at the edge of the text field even though there are no spaces, while mozilla will show a horizontal scrollbar and continue on the same line. I like the 4.x behavior better. Is there some justification for doing it the new way? Or is there already a bug on this? The text area is specified with WRAP=HARD COLS=80. Since 3 is the only remaining issue that isn't already covered by other bugs, rather than close this and file a new bug, I'm changing the summary of this one. This is not an M13-critical issue.
Target Milestone: M13 → M15
problem is less severe now that partial fixes are in and it is better understood. Moving to M15.
moving all buster m15 bugs to m16.
Target Milestone: M15 → M16
the remaining problem is minor. the behavior might even be correct. Pushing out to M20.
Severity: normal → minor
Target Milestone: M16 → M20
Reassigning to beppe (editor).
Assignee: buster → beppe
Status: ASSIGNED → NEW
reassigning to Kin
Assignee: beppe → kin
Accepting bug.
Status: NEW → ASSIGNED
moving to future milestone
Assignee: kin → beppe
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
reassign back to Kin
Assignee: beppe → kin
Status: ASSIGNED → NEW
Target Milestone: M20 → Future
Accepting bug.
Status: NEW → ASSIGNED
*** Bug 41403 has been marked as a duplicate of this bug. ***
*** Bug 45503 has been marked as a duplicate of this bug. ***
adding help wanted keyword
Keywords: helpwanted
Referencing bug 41403, which has been marked as a duplicate of this bug. I downloaded nightly build 2000080113 for Linux x86 and checked for the text wrapping problem described in bug 41403. I don't know when it happened, but it appears that the problem is gone! I don't know who to thank, but excellent work! :-) - Joseph Edward Miele
Yes, this does look solidly WORKSFORME on Windows too. Cool. See http://landfill.bluemartini.com/bugzilla/show_bug.cgi?id=50, entered using 2000-08-01-04-M17 on WinNT: the first two lines were typed as one line, but wrapping happened during typing.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Updating QA contact.
QA Contact: ckritzer → bsharma
Worksforme: Platform: PC OS: Red Hat 6.2 (Linux 2.2.14) Mozilla: 2000101212 M18 Trunk Build Marking as Verified.
Status: RESOLVED → VERIFIED
Blocks: 124140
You need to log in before you can comment on or make changes to this bug.