Closed Bug 49780 Opened 24 years ago Closed 24 years ago

broken textfields on bugzilla page (input type=text inside table)

Categories

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

defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: jrgmorrison, Assigned: karnaze)

References

()

Details

(Whiteboard: [nsbeta3+])

Attachments

(4 files)

Overview Description: broken textfields on bugzilla page (input type=text inside table) Steps to Reproduce: 1) with today's build on windows, load http://bugzilla.mozilla.org/query.cgi 2) scroll down to the section where there are input type=text for entering Summary, Description, URL, etc. Actual Results: On my win2k system, the field for 'Summary:' has a width of ~3px. (At first, I thought I couldn't even set focus in it). However, on a win98 system, this field has normal initial size. If I then resize the page, on either win98 or win2k or mac or linux, the fields will shrink down below their 'size=30' attribute value. Upon typing in the field, the text box will spring out to fill the available space in the table column. Expected Results: <input type=text> are not flexible elements, in general. Reproducibility: always Build Date & Platform Bug Found: 2000082108 linux 2000082108 mac 2000082108 win2k/win98 Additional Information: I'll attach the problem table + textfields
Nominating nsbeta3, this is probably a simple bit of bustage, but it does need to be fixed --- textfields in HTML pages are not flexible (historically), and the fact that they can shrink to almost zero width presents usability and data loss concerns.
Keywords: nsbeta3
believe this should be html form controls, assigning to that component
Assignee: beppe → rods
Component: Editor → HTML Form Controls
QA Contact: sujay → ckritzer
This works fine for me in today's builds.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Okay, this has changed somewhat. verif that this bug report no longer applies. Will file a new bug for the current problem.
Status: RESOLVED → VERIFIED
I don't know why I thought this was "different" this morning. The particular problem on win2k no longer exists, but my main point still stands -- the <input type="text"> fields will shrink below their specified width when the page (and containing table) is resized; they will pop back to their regular width once you begin typing in them. [mac/linux/win95/win2k] (reopening)
Status: VERIFIED → REOPENED
Resolution: WORKSFORME → ---
Here is what is going on: The text field is being resized as the table shrinks the cell, but when the table is being stretched the cell is NOT asking the GfxText to resize. To see this behavior turn on "DO_NOISY_REFLOW" in nsBoxFrame.cpp (GfxText is now a box frame) You can't put a break point in the reflow of nsBoxFrame because the main window is a boxframe. Here is the initial reflow output: (note that the boxframe in question is 0114BF78) -------------Starting BoxFrame Reflow ---------------------------- 011524C8 ** nsBF::Reflow 122 R: Ini AW: 8025 AH: 4470 CW: 8025 CH: 4470 * 011524C8 ** nsBF(done) W:8025 H:4470 MW:? MH:? Enabling Quirk StyleSheet -------------Starting BoxFrame Reflow ---------------------------- 011524C8 ** nsBF::Reflow 123 R: Inc AW: 8025 AH: 4470 CW: 8025 CH: 4470 * -------------Starting BoxFrame Reflow ---------------------------- 0114BF78 ** nsBF::Reflow 124 R: Ini AW: UC AH: UC CW: UC CH: UC * nsGfxText(field) 169,24 237,24 68,0 0114BF78 ** nsBF(done) W:3555 H:360 MW:420 MH:360 011524C8 ** nsBF(done) W:8025 H:4470 MW:? MH:? Here is some output while it is shrinking: -------------Starting BoxFrame Reflow ---------------------------- 0114BF78 ** nsBF::Reflow 204 R: Rsz AW: 2295 AH: UC CW: UC CH: UC * 0114BF78 ** nsBF(done) W:2295 H:360 MW:? MH:? 011524C8 ** nsBF(done) W:4410 H:4470 MW:? MH:? -------------Starting BoxFrame Reflow ---------------------------- 011524C8 ** nsBF::Reflow 205 R: Rsz AW: 4395 AH: 4470 CW: 4395 CH: 4470 * -------------Starting BoxFrame Reflow ---------------------------- 0114BF78 ** nsBF::Reflow 206 R: Rsz AW: 2280 AH: UC CW: UC CH: UC * 0114BF78 ** nsBF(done) W:2280 H:360 MW:? MH:? 011524C8 ** nsBF(done) W:4395 H:4470 MW:? MH:? Here is some output while being stretched: (note that boxframe 0114BF78 is never being reflowed) -------------Starting BoxFrame Reflow ---------------------------- 011524C8 ** nsBF::Reflow 218 R: Rsz AW: 4695 AH: 4470 CW: 4695 CH: 4470 * 011524C8 ** nsBF(done) W:4695 H:4470 MW:? MH:? -------------Starting BoxFrame Reflow ---------------------------- 011524C8 ** nsBF::Reflow 219 R: Rsz AW: 4995 AH: 4470 CW: 4995 CH: 4470 * 011524C8 ** nsBF(done) W:4995 H:4470 MW:? MH:? -------------Starting BoxFrame Reflow ---------------------------- 011524C8 ** nsBF::Reflow 220 R: Rsz AW: 5325 AH: 4470 CW: 5325 CH: 4470 * 011524C8 ** nsBF(done) W:5325 H:4470 MW:? MH:? -------------Starting BoxFrame Reflow ---------------------------- 011524C8 ** nsBF::Reflow 221 R: Rsz AW: 5685 AH: 4470 CW: 5685 CH: 4470 * 011524C8 ** nsBF(done) W:5685 H:4470 MW:? MH:? -------------Starting BoxFrame Reflow ---------------------------- 011524C8 ** nsBF::Reflow 222 R: Rsz AW: 5955 AH: 4470 CW: 5955 CH: 4470 * 011524C8 ** nsBF(done) W:5955 H:4470 MW:? MH:? reassigning
Assignee: rods → attinasi
Status: REOPENED → NEW
I saw this in yesterday's build, but today I am seeing a different problem where the control keeps the correct size but spills out of the cells. The current problem looks related to bug 48295, but there are some differences.
Whiteboard: [nsbeta3+]
Status: NEW → ASSIGNED
Target Milestone: --- → M18
Chris, from Rod's last comment it looks like this is possibly another incremental reflow problem in tables. Can you please check it out?
Assignee: attinasi → karnaze
Status: ASSIGNED → NEW
I'm not seeing any of the reported problems on WinNT.
Status: NEW → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → WORKSFORME
Yep, this is working fine now on win2k/mac/linux. The input/text fields are not changing dimensions when the page is narrowed and resized. Marking verif.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: