192217 - CSSized attributes conflict with Advanced Edit

Status: RESOLVED EXPIRED

(SeaMonkey :: Composer, defect)

Description

[Jani Patokallio]

User-Agent:       Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021212
Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3a) Gecko/20021212

If an <IMG> image's width/height is specified by a style attribute, the Advanced
Edit dialog seemingly allows the user to make changes, but does not save them. 
The settings of the Dimensions tab (Actual/Custom Size) do not affect this,
although this tab can be used to change the size as designed.  Changes to other
parameters seem to work.

If the image's width is specified by separate width=x height=y tags, any changes
are made, displayed and saved correctly -- exactly once.  However, Composer
automatically changes these into a composite style tag, which can no longer be
edited!


Reproducible: Always

Steps to Reproduce:
1. Open a new document.
2. Add an image.
3. Select Image Properties -> Advanced Edit... and modify the value of the
"width" and "height" attributes.


Actual Results:  
The Advanced Property Editor displays the new value, but upon exiting the
Dimensions tab retain the old value.  After OK/Apply, the image remains at the
old size and, if saved, the dimension is unchanged.



Expected Results:  
The change should immediately be reflected in the Dimensions tab, the displayed
image size should change and the new dimension should be saved.


I'm reporting this on a Windows machine, but the problem manifested on a Linux
box also running vanilla 1.3alpha.

This may not be unrelated to bug 191127, which features similar flakiness when
the style parameter is involved.

When editing documents created with the old NS 4.7 Composer and replacing old
images with new ones, I have once or twice run into a situation where Mozilla
refuses to acknowledge the size change at all.  I'm still trying to isolate a
reproducible case, but this is most probably related.

Comment 1

[Kathleen :Brade]

cc Neil in case he can make a similar fix for this bug

Comment 2

[Jani Patokallio]

Regarding my last own comment about size changes being ignored when the image is
changed, turns out this happens only when the previous image had a custom size
specified, in which case the custom size is retained and the new image is
squished to fit.  This is *probably* the way it should be; but it would be
nice(tm) if the constraint was more clearly visible.

Comment 3

[[e-mail]]

What's happening is this:

The dialog sets the width and height attributes on the element for advanced
edit. Unfortunately the values that it reads back are the styles for height and
width. This means that if you change the height and width, go into advanced edit
and click OK then your changes are lost.

This problem applies to any use of advanced edit.

Comment 4

[Kathleen :Brade]

-->glazman

Comment 5

[Asa Dotzler [:asa]]

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

Comment 6

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614

Comment 7

[Robert Kaiser]

MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420