215766 - "Advanced Edit" button not greyed out when multiple table cells are selected for property modification

Status: RESOLVED EXPIRED

(SeaMonkey :: Composer, defect)

Description

[Daniel]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3.1) Gecko/20030425

When Multiple Table cells are selected and "Table Cell Properties" is chosen
from the right click menu, in the dialog that appears, the advanced edit option
is available, however any changes made within it are discarded.

When repeating the action with a single cell, and then changing to a multiple
selection from within the dialog box (eg by selecting "column" instead of "cell"
from the "selection" drop-down box) the "Advanced Edit" button is greyed out,
and the hover-text informs the user that "Advanced Edit is not available under
multiple selections".

Reproducible: Always

Steps to Reproduce:
1. Create a table
2. Select Multiple Cells
3. Right click and choose "Table Cell Properties"

Actual Results:  
The "Advanced Edit" button was not greyed out

Expected Results:  
Greyed out the "Advanced Edit" button

Theme: Reverse Modern

Comment 1

[Gérard Talbot]

I was able to select several non-contiguous table cells, then right-click,
choose Table Cell Properties..., then click the Advanced Edit... button and then
added bgcolor olive in the HTML attributes tab, then OK, and then Apply. 
I repeated the same procedure and then added text-align right in the Inline
Style tab.
Changes made in this manner were NOT discarded, changes were saved and rendered.
I can not reproduce the problem. Mozilla 1.7alpha build 2003121908 (themes
Modern) under XP Pro SP1 here.

Reporter, can you try with a recent build?

Comment 2

[Daniel]

Your example behaves as you described on my machine, perhaps because background
colour is also changeable on the properties dialog box. The behaviour is also
inconsistent - sometimes it works, sometimes not.

An alternative is to try changing rowspan to 2. This does not work on multiple
cells in my current browser (I have upgraded since reporting the bug) :
Mozilla/5.0 (Windows; U; Windows NT 5.0; he-IL; rv:1.5) Gecko/20031007
It seems fairly repeatable.

Try this and let me know.

Comment 3

[Gérard Talbot]

You can not <Ctrl>+select non-contiguous or contiguous cells and simply add
rowspan value 2: the software would try to apply that declaration to both cells.
Rowspan and colspan involves table cell/row/column structure; that's not the
case with bgcolor or text-align css property. Merging cells must go through a
different menuitem.
"To join (or merge) adjacent cells:
    * Select adjacent cells by dragging over them.
    * Open the Table menu, and choose Join Selected Cells.
"
coming from
Help/Help Contents/Contents tab/Creating Web Pages/Adding Tables to Your
Page/Adding-Deleting Rows, Columns, and Cells

"try changing rowspan to 2"
Click the top cell, shift+click the bottom cell, now both cells should have a
thicker black border, right-click either of these 2 cells, choose "Join selected
cells", right-click that merged cell, choose "Table cells properties...", Cells
tab, Advanced Edit... button, HTML Attributes will show Attribute rowspan value 2.

Bugzilla bug writing guidelines:
"(...) Next, be sure that you've reproduced your bug using a build released
within the past three (3) days. Our development process moves at lightning
speed, and the bug you've found may already have been fixed. (Nightly builds can
be downloaded from the mozilla.org binaries page.)"
http://www.mozilla.org/quality/bug-writing-guidelines.html

Comment 4

[Daniel]

OK, so my example was not the best. My intention was not to join two cells.

I downloaded 1.7a and tried setting "align" to "right" in the advanced edit
dialog box. I observed the same behaviour that I have reported - the change is
not executed.

w.r.t. the bgcolor example that you gave, mozilla automatically converts it to
an HTML tag parameter, as opposed to a stylesheet parameter, the former being
controlled from the "Table Properties" dialog box, not "Advanced Edit".

Comment 5

[Gérard Talbot]

>OK, so my example was not the best. My intention was not to join two cells.

Quite on the contrary, I think your example is useful. If the user <Ctrl>+select
adjacent or non-adjacent cells, then I think Composer should not offer the
option of modifying the rowspan or colspan on such cells. I.e.: setting rowspan
= 2 on 2 cells is over-redundant, confusing and Composer would have to delete,
remove one of the 2 cells on his own, just by himself. It does not make sense
for the software to offer choices, options which imply modifying the table
structure and table cell structure when sometimes it would not even be possible
to do so anyway (in case of non-adjacent cells).

>I downloaded 1.7a and tried setting "align" to "right" in the advanced edit
dialog box. I observed the same behaviour that I have reported - the change is
not executed.
In case of getting different results, then steps to reproduce are important to
communicate so that anyone can best test, verify. Here's what I did. First I
checked the
Edit/Preferences.../Composer/Use CSS styles instead of HTML elements and attributes
checkbox.
Then loaded a test table, <Ctrl>+clicked to select 3 table cells (2 in the same
column, 2 in the same row: this is for making a good test). The borders of each
cells were thick black.
Then I right-clicked one of them, chose "Table Cells Properties..." , then click
the "Advanced Edit..." button, then in the HTML Attributes tab, I chose
Attribute: align and Value: center from the drop-down list. Then I clicked OK
and Apply and I immediately saw the change happening. During all these
operations, I was in HTML tags editing mode.
I repeated the whole procedure with unchecking the "Use CSS styles instead of
HTML elements and attributes" checkbox to see how Composer was rendering the
HTML code. I also tried without the "Advanced Edit..." button, by just changing
the "Content Alignment/Horizontal" drop-down list (in the Table Properties/Cells
tab). Again, the changes were rendered as soon as I clicked the Apply button.
Mozilla 1.7alpha build 2003122409 under XP Pro SP1 here.

>w.r.t. the bgcolor example that you gave, mozilla automatically converts it to
an HTML tag parameter, as opposed to a stylesheet parameter, the former being
controlled from the "Table Properties" dialog box, not "Advanced Edit".
That issue depends on your checkbox setting at
Edit/Preferences.../Composer/Use CSS styles instead of HTML elements and attributes
As far as I can see, Composer will respect that setting regardless of the window
you use to make the changes in the application, ie regardless of if you use the
"Table Properties"/Cells tab or the "Advanced Edit..." button/etc..

Comment 6

[Gerke Kok]

I can reproduce this behaviour on by build of Mozilla (Mozilla/5.0 (Windows; U;
Win98; en-US; rv:1.7b) Gecko/20040318)

I intended to change a set of cells to css-class="result". This failed.

To reproduce:
1 Select a range of cells (I only did ones that are under each other)
2 Select "Table Cell Properties"
3 Hit "Advanced Edit"
4 Enter:
      Attribute: class
      Value: result
5 Hit ok
6 Hit ok
7 Check on the source tab to find that non of the cells have their call changed.

Hope this will change, as changing these type of thing for multiple cells can be
very handy.

Comment 7

[Gérard Talbot]

I CONFIRM this bug. In the steps to reproduce in comment #6, there may be other
attributes like title, dir, lang, etc.

Comment 8

[Asa Dotzler [:asa]]

not going to block the release on this but we'd consider a fully reviewed patch
if one materializes

Comment 9

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

[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