Closed Bug 244834 Opened 21 years ago Closed 20 years ago

Table width changes in table properties are not applied

Categories

(SeaMonkey :: Composer, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED
mozilla1.8alpha6

People

(Reporter: bugzilla, Assigned: Brade)

References

Details

(Keywords: regression)

Attachments

(1 file)

User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7) Gecko/20040514 When changing the width of a table in the Table Properties, the changes are not applied to the table Reproducible: Always Steps to Reproduce: 1. Create a table and select it 2. Go to Table -> Table Properties 3. Change Widtg Actual Results: Nothing. Expected Results: Table width should have changed accordingly.
Can see this with nVu 0.2 too.
probably a dupe of 237628
Bug 237628 is on image size, this one is on table size. They might have the same reason, but this has to be decided by someone who knows the code.
Here's what I notice with Mozilla 1.8a2 build 2004060709 under XP Pro SP1a. Observation 1: If I change the width via the Inline Style tab of the Advanced Property Editor window, then changes are rendered as soon as I click the Apply button of the parent window (Table Properties window). Observation 2: If I change the width via the HTML attributes of the Advanced Property Editor window, then changes are NOT rendered even after clicking the Apply or OK button of the parent window (Table Properties window). Observation 3: If I change the width via the Table Properties window, then changes are NOT rendered even after clicking the Apply button. I notice all this regardless of the setting I have at Edit/Preferences.../Composer category/Cascade Style Sheets (CSS) editing/Use CSS styles instead of HTML elements and attributes Observation 4: If an user resize the table by clicking the [re-]sizing handles around the table and dragging the mouse, then the table is resized immediately and current values in real time are displayed in a tooltip. (that was bug 222299) Can someone confirm observations 1, 2 and 3? I need to carefully verify for a possible duplicate on this. Thanks.
*** Bug 255984 has been marked as a duplicate of this bug. ***
In step 3- (Not using the Advanced Property Editor; we are in the Table Properties window only) a) Change Width value or b) Change Width unit (to pixels or to % of window) 4- Click Apply button Actual: no change, even after clicking OK button Expected: table immediately resize accordingly I could not find a duplicate for this CONFIRMING Mozilla 1.8a3 build 200081709 here.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
*** Bug 261227 has been marked as a duplicate of this bug. ***
Product: Browser → Seamonkey
I can reproduce this bug on Windows XP Pro SP1 ("Typical" install of Mozilla Suite 1.7.3 with default settings) and RH8/x86 (same setup) with the following steps: 1. Create a new document in composer. 2. Create a table by Selecting Insert->Table... 3. Set the rows to 1, columns to 1, width to 100% of window, and border of 1 pixel. Hit OK. 4. Right-click on the table and select Table Cell Properties... 5. Under the Cell tab, set the height to some arbitrary number, say 200 pixels, and hit Apply and hit OK (or just hit OK). Note that the cell's/table's dimensions change. 6. Again, Right-click on the table and select Table Cell Properties... 7. Under the cell tab, Set the height to some new arbitrary number, say 500 pixels. Click Apply or OK. 8. The cell's/table's dimensions will not change. This is reproducable every time on both platforms.
*** Bug 274213 has been marked as a duplicate of this bug. ***
Can someone confirm that this bug is tied to the CSS-preferred preference setting ("Use CSS Styles...")? I think this bug is pretty critical. Novices who are editing their HTML will have to give up on the task because they probably won't know to go manually edit the HTML. I run into this problem frequently.
Severity: normal → critical
Depends on: 274441
Depends on: 265145
(In reply to comment #10) > Can someone confirm that this bug is tied to the CSS-preferred preference > setting ("Use CSS Styles...")? I confirm that this bug has nothing to do really with the CSS-preference setting. I said so in comment #4. > I think this bug is pretty critical. Severity: critical is for bugs which causes crashes, loss of data, severe memory leak. You just can't add critical just like that or just because you rely a lot on table design for your pages. > Novices who are editing their HTML will > have to give up on the task because they probably won't know to go manually > edit the HTML. I'm willing to bet that most novices would see the advanced edit button and then would explore some possibilities like the inline style tab. Some could even try to edit the value in the <HTML> source editing mode. This bug does not depend on bug 265145.
Severity: critical → normal
Depends on: 273458
No longer depends on: 265145, 274441
Perhaps this isn't quite the right bug but it is very similar. I see problems with all of the property windows (the table one being the most annoying). The issue is that the values just don't stick. It isn't just the width of the table (in my experience). This is a major regression (when you consider all of the other property dialogs also seem to have this problem). Has anyone determined a timeframe when this regressed? We know it was a problem in the May 14 2004 build (20040514). I think the problem goes back further but I don't know how much. Regarding comment 11 and novices, I do strongly disagree that novices are likely to press a button called "advanced." Now for the solution: It seems the fix is similar to the fix for 237628. Every editor dialog was apparently broken last January and each needs to be fixed separately. Calls to setAttribute need to be replaced with callsl like: editor.setAttributeOrEquivalent(globalElement, "width", width, true); I may have time to work on this in a week or two (after I release some other software). I'll reassign the bug to myself for now. If someone else can fix this sooner, please comment here (and reassign bug etc.).
Assignee: composer → brade
Severity: normal → major
Target Milestone: --- → mozilla1.8alpha6
Flags: blocking1.8b?
Flags: blocking1.8b? → blocking1.8b+
Is this related to bug 170436?
Attached patch Patch v1Splinter Review
This seems to fix the problem with resizing the table width. I am not positive whether to specify 'true' or 'false' for the last argument to setAttributeOrEquivalent, but hopefully an editor person can help out with that.
Attachment #173386 - Flags: review?(daniel)
r=brade Daniel--please r/sr/moa :-)
Attachment #173386 - Flags: superreview?(neil.parkwaycc.co.uk)
Attachment #173386 - Flags: superreview?(neil.parkwaycc.co.uk) → superreview+
Attachment #173386 - Flags: review?(daniel) → review+
Fixed. Checking in EdDialogCommon.js; /cvsroot/mozilla/editor/ui/dialogs/content/EdDialogCommon.js,v <-- EdDialogCommon.js new revision: 1.150; previous revision: 1.149 done
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
*** Bug 241891 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: