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
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?
URL: not relevant
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.
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
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".
>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..
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.
I CONFIRM this bug. In the steps to reproduce in comment #6, there may be other attributes like title, dir, lang, etc.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Severity: normal → minor
Priority: -- → P4
Target Milestone: --- → mozilla1.8alpha
not going to block the release on this but we'd consider a fully reviewed patch if one materializes
Flags: blocking1.7? → blocking1.7-
Assignee: composer → nobody
Priority: P4 → --
QA Contact: chrispetersen → composer
Target Milestone: mozilla1.8alpha1 → ---
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
Status: NEW → UNCONFIRMED
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
Status: UNCONFIRMED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.