468028 - When Backspace/Delete/Cut Joins Blocks, Resulting Block Has Attributes from Last Selected Block

Status: UNCONFIRMED

(Core :: DOM: Editor, defect, P5)

Description

[Dave]

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4

If you select content across multiple block container tags and use backspace, delete or cut to remove the selection, the attributes from the last block that was included in the selection are the ones that apply to the resulting single block container.  This happens regardless of what tag types are involved, so that even, e.g., inline styles or class attributes from a P tag could be applied to ab H1 tag.

Reproducible: Always

Steps to Reproduce:
A basic case, involving two adjacent P tags, a collapsed selection range, and the delete key:

1. Set up two paragraphs in the Midas demo at http://www.mozilla.org/editor/midasdemo/
2. Check the View HTML Source checkbox
3. Add some attributes to the two P tags so you can tell them apart.  Maybe this:

<p class="test1">test 1</p><p class="test2">test 2</p>

4. Uncheck the View HTML Source checkbox
5. Put the cursor at the end of the first paragraph, and press delete.
6. Check the View HTML Source checkbox to view the source again.
Actual Results:  
The second P tag's attributes override the attributes on the first P tag.

<p class="test2">test 1test 2</p>

Expected Results:  
I really feel that the first P tag's attributes should "win".  I'm not sure if this is a designed or emergent behavior.

If it is designed, I think it is a mistake. I don't really care whether the selection range is collapsed, whether backspace rather than delete is used, or what tag types are involved.  The intention of the user is to remove the selected content and collapse any remaining parts of the blocks into one block.  I don't see why anyone would ever expect that the attributes -- which can include anything from display properties to DOM ids to script handlers -- from the later block container would take precedence when intervening content is deleted.

I also note that if you use different block tag types, you can see that the editor keeps the first block tag type for the combined block.  I don't see why you'd want to keep the tag type for block container 1 while pulling in the attributes for block container 2.  Likewise, it doesn't make sense to me that attributes from a P tag should be applied to an H1 tag if you happen to put your cursor at the end of an H1 tag and press delete to suck in the text from the next sibling P tag.

I don't have access to an IE Windows browser right now, but I don't think IE has this issue.

This is a serious problem for a project I'm working on, and I'm not aware of any workaround for this issue besides editing the underlying HTML, which is really not an option for many users of web-based applications that happen to embed a rich text editor for editing an HTML document.  If the attributes contain unique data that is supposed to persist across revisions, the data is lost, and the user may not even know what has been lost.

I'm currently trying to script my way around this problem.  I am sure I will come up with something I can live with, but if anyone can offer any clever suggestions, I'm all ears.

p.s., what's up b.m.o? It's been awhile.

Comment 1

[Dave]

Changing platform to all / all as I observed this behavior in Firefox 3 on windows.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.4) Gecko/2008102920 Firefox/3.0.4 

I also took the time to confirm that IE7 on Windows does not have this issue; attributes from the first block tag win out over those of the last block tag when the blocks are joined after content is selected and deleted.

I guess Firefox 3 is gecko branch 1.9, but I'm not going to monkey with the version here.

Comment 2

[Jens Stutte [:jstutte]]

Bulk-downgrade of unassigned, >=5 years untouched DOM/Storage bugs' priority and severity.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.