244834 - Table width changes in table properties are not applied

Status: RESOLVED FIXED

(SeaMonkey :: Composer, defect)

Description

[Daniel Küstner]

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.

Comment 1

[Daniel Küstner]

Can see this with nVu 0.2 too.

Comment 2

[Tracy Walker [:tracy]]

probably a dupe of 237628

Comment 3

[Daniel Küstner]

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.

Comment 4

[Gérard Talbot]

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.

Comment 5

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

*** Bug 255984 has been marked as a duplicate of this bug. ***

Comment 6

[Gérard Talbot]

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.

Comment 7

[Gérard Talbot]

*** Bug 261227 has been marked as a duplicate of this bug. ***

Comment 8

[Daniel Barowy]

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.

Comment 9

[Gérard Talbot]

*** Bug 274213 has been marked as a duplicate of this bug. ***

Comment 10

[Kathleen :Brade]

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.

Comment 11

[Gérard Talbot]

(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.

Comment 12

[Kathleen :Brade]

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.).

Comment 13

[Boris Zbarsky [:bzbarsky]]

See bug 265145 comment 3.

Comment 14

[Oscar van Vliet]

Is this related to bug 170436?

Comment 15

[Philip K. Warren]

Attachment: Patch v1

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.

Comment 16

[Kathleen :Brade]

r=brade
Daniel--please r/sr/moa :-)

Comment 17

[Philip K. Warren]

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

Comment 18

[Philip K. Warren]

*** Bug 241891 has been marked as a duplicate of this bug. ***