46474 - starting a new block kills off style selections

Status: VERIFIED FIXED

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

Description

[Joe Francis]

start a new block when editing (like making a new paragraph, list item, etc, all 
doable from typing) casues any style choices (font, bold, etc) to revert to their 
defaults for the new block.  We should hold on to the users style if they are 
creating new blocks just by typing.

Comment 1

[Joe Francis]

accept

Comment 2

[Joe Francis]

nominating for b3

Comment 3

[rubydoo123]

Add correctness and nsbeta3+

Comment 4

[rubydoo123]

setting priority in status whiteboard

Comment 5

[rubydoo123]

m18

Comment 6

[rubydoo123]

setting to future and adding helpwanted

Need to triage bugs to meet the glidepath for pr3

Comment 7

[Joe Francis]

moz 0.9

Comment 8

[Joe Francis]

moving a bunch of 0.9 bugs to 0.9.1

Comment 9

[Joe Francis]

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

Comment 10

[rubydoo123]

just a note to look at bug 68795 (hitting return and terminating format)

we just need to ensure that the nesting is legal HTML

Comment 11

[Joe Francis]

097

Comment 12

[Joe Francis]

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

Comment 13

[Joe Francis]

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

Comment 14

[Joe Francis]

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

Comment 15

[Syd Logan]

triage team plussing

Comment 16

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Ok, got it :

1) launch composer (HTML or CSS mode, does not matter)
2) switch to AllTags mode
3) enter "aaaa"
4) select "Paragraph" from toolbar's pulldown menu
5) click on B and I buttons
6) enter "bbbb"
7) hit twice the Enter key

It creates a new paragraph, with the two nested stylistic elements (B and I in
HTML mode, two spans in CSS mode) and the caret is **before** the elements, but
should be of course inside !

Comment 17

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Attachment: patch v1.0

Joe, I took this one from your plate. Can you review it please ?

Comment 18

[Joe Francis]

I think we may need more.  For instance: creating new list items via return; 
breaking out of header via return.

Comment 19

[Joe Francis]

another scenario that needs to be dealt with:
user chooses inline style on blank line, then chooses
{indent/paragraph-style/list}.  We should hold on to the style.

Comment 20

[Joe Francis]

Comment on attachment 68140 [details] [diff] [review]
patch v1.0

this patch is good, but don't close out the bug when landing it.  We have more
to do.

Comment 21

[Joe Francis]

I have incorporated Daniels work into bug 98286, which fixes other problems in
the same routine...

Comment 22

[Joe Francis]

Comment on attachment 68140 [details] [diff] [review]
patch v1.0

obsoleted by patch in 98286; but we still need to fix other issues I raised in
earlier comment so we can't close bug

Comment 23

[saari (gone)]

if this will reproduce in the embedded editor case, it is also topembed

Comment 24

[Joe Francis]

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

Comment 25

[Syd Logan]

Reassigning to daniel

Comment 26

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Fix in hand for list case :-) Will attach it monday morning since I really have to
go home for now.

Comment 27

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Attachment: work-in-progress #1

Joe, is this the right approach for fixing the list case ? It works fine but
I need your views on the problem.

Comment 28

[Joe Francis]

Comment on attachment 72402 [details] [diff] [review]
work-in-progress #1

Daniel, this is exactly the kind of thing I think needs to happen.  There are
several places to put this kind of thing: ReturnInHeader(),
ReturnInParagraph(), and ReturnInListItem().  In the last case, we also want to
preserve the style when you use return to "kill" a list and pop out to a higher
list level (or to the enclosing non-list block).

Comment 29

[kinmoz]

Comment on attachment 72402 [details] [diff] [review]
work-in-progress #1

sr=[e-mail]

Comment 30

[rubydoo123]

removing myself from the cc list

Comment 31

[Asa Dotzler [:asa]]

Comment on attachment 72402 [details] [diff] [review]
work-in-progress #1

a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Comment 32

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

patch in attachment 72402 [details] [diff] [review] checked in ; IRC discussion with Joe about
attachment 68140 [details] [diff] [review] because I still see the original problem.

Comment 33

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

checked in ; other issues spun off in different bugs by Joe.

Comment 34

[sujay]

verified in 4/23 trunk build.