265145 - Using dialog's box horizontal line Properties, width isn't modified

Status: RESOLVED EXPIRED

(SeaMonkey :: Composer, defect)

Description

[Alain Riffart]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040115
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.6) Gecko/20040115

When one writes in the field width, a new width of horizontal line and that one
clicks on OK, width of the line is not modified.

Reproducible: Always
Steps to Reproduce:
1.
2.
3.

Comment 1

[Gérard Talbot]

Please define what setting you have for
Edit/Preferences.../Composer/Cascading Style Sheets (CSS) Editing/Use CSS styles
instead of HTML elements and attributes checkbox

Then define exactly the steps (step by step) you execute to modify the width of
an horizontal rule, how you select the horizontal rule. Identify the window with
its title (e.g. Advanced Property Editor window for <hr> with HTML attributes tab).

Note that you're using a 9+ months old Mozilla version.
"be sure that you've reproduced your bug using a build released within the past
three days. Our development process moves at lightning speed, and the bug you've
found may already have been fixed."

How to Write a Useful Bug Report
http://www.mozilla.org/quality/bug-writing-guidelines.html

Comment 2

[Alain Riffart]

(In reply to comment #1)
> Please define what setting you have for
> Edit/Preferences.../Composer/Cascading Style Sheets (CSS) Editing/Use CSS styles
> instead of HTML elements and attributes checkbox
> 
> Then define exactly the steps (step by step) you execute to modify the width of
> an horizontal rule, how you select the horizontal rule. Identify the window with
> its title (e.g. Advanced Property Editor window for <hr> with HTML attributes
tab).
> 
> Note that you're using a 9+ months old Mozilla version.
> "be sure that you've reproduced your bug using a build released within the past
> three days. Our development process moves at lightning speed, and the bug you've
> found may already have been fixed."
> 
> How to Write a Useful Bug Report
> http://www.mozilla.org/quality/bug-writing-guidelines.html

I'm using the version 1.7.1 under Windows XP. This bug did not exist in the
versions 1.5.x and 1.6.x of Mozilla.  It is reproducible in all the versions
1.7.x of Mozilla under Windows and Linux.

Edit/Preferences...  Composer...  Use CSS styles of HTML elements and attributes
is selected.

I create a horizontal line by using menu Insert/Horizontal Line.  This line is
created normally in Composer.  When I want to modify the width of this line, I
select it and I use the dialog box Horizontal Line Properties. If, for example,
the initial value of the width were 100 % of window, in the field width.  I
write 50 in this field then I click on button OK. 

I note whereas the horizontal line did not change dimension.  By opening tab <
HTML > source, code HTML, also, did not change to him, it is always:  
< hr style="width:  100%;  height:  2px;">.  


Well on, I can always modified the source code in:  

< hr style="width:  50%;  height:  2px;">.  

But the goal of the dialog box Horizontal line Properties, isn't to allow the
users who do not know HTML and the CSS to create Web pages? 

I notice however that when Use CSS styles of HTML elements and attributes in
menu Edit/preferences...  Composer..., is not selected, the redimensioning of
the horizontal line functions.  

The same errors occur for the redimensioning of the image and the modifications
of fill color of the page when the menu Edit/Preferences...  Compose...  Use CSS
styles of HTML elements and attributes is selected.

Is it necessary to give up an automatic writing of code which manages the CSS
suitably?

I allow myself to insist I still have just tested it, under Linux and Windows,
these bugs did not exist in version 1.5 and 1.6 of Mozilla.  When menu
Edit/Preferences...  Composer...  Use CSS styles of HTML elements and attributes
was selected, the redimensioning of the horizontal lines, the images and the
modifications of the fill color of page functioned.

I have, unfortunately for me and the trainees discovered these bugs during a
training course which I animated.  The administrator of the computer room
believed to please to me by installing the most recent version of Mozilla
(1.7.3).  Personally, I used on my portable version 1.6.  I made a beautiful
speech on the respect of the standards, in particular CSS by Mozilla and after
two hours of tatonnement, I asked to unselect menu Edit/Preferences... 
Composer...  Use CSS styles of HTML elements and attributes.  And as we were on
the network of a school establishment, the trainees thus did not have access to
the modification of the profiles...And thus when the trainees run again Mozilla,
the default profile was charged and menu Edit/Preferences...  Composer...  Use
CSS styles of HTML elements and attributes was selected.  The administrator of
the network was occupied elsewhere.  In short, a quite beautiful day.

Comment 3

[Boris Zbarsky [:bzbarsky]]

This is the usual problem with using setAttribute() instead of
setAttributeOrEquivalent()....  This time in ValidateNumber() in
editor/ui/dialogs/content/EdDialogCommon.js, I bet.

Note also that there are issues with this in
editor/ui/dialogs/content/EdHLineProps.js as well.

See similar bug 239476 and bug 237628.

Perhaps we should land those on branch, given that these are all issues with
1.7, by the way?  Daniel?

Comment 4

[Kathleen :Brade]

I've seen this problem as well as related problems with Table Properties dialog.

If I create a table with the dialog, switch to HTML mode and switch back I can't
change some fo the properties via the table dialog any more.  I haven't had a
chance to research it but it is definitely a regression in the 1.7 timeframe. 
Boris (comment 3) probably has pinned the problem down.

Comment 5

[Gérard Talbot]

Table Properties dialog is bug 244834.

Comment 6

[Asa Dotzler [:asa]]

Daniel, are you able to look into this for 1.8a6?

Comment 7

[Asa Dotzler [:asa]]

too late for 1.8a6. blocking-

Comment 8

[Philip K. Warren]

This problem appears to be fixed with the change for Bug 244834.

Comment 9

[Boris Zbarsky [:bzbarsky]]

I suppose we could mark this fixed if we have a bug filed to track auditing all
the editor UI for this sort of breakage...

Comment 10

[Asa Dotzler [:asa]]

removing blocking flag.

Comment 11

[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 12

[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