98622 - we don't copy <small> & <big> info for text

Status: VERIFIED FIXED

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

Description

[sujay]

using 7/18 branch windows build

1) launch netscape
2) launch composer
3) enter some text: "Hello" followed by carriage return
4) highlight it.
5) Format | Font | Helvetica
6) then click on "-a" twice making the font size small twice
7) click on Bold also on the toolbar
8) now hilite the following letters in the text: "ello"
9) Edit | Copy
10) click below the text somewhere
11) Edit | Paste

notice what got pasted. we didn't bring over the <small> info from step
6) above.



------- Additional Comments From [e-mail] 2001-07-19 14:20 -------

assigning to jfrancis





------- Additional Comments From [e-mail] 2001-09-06 04:40 -------

This behavior is intentional.  However, it may still be wrong.  :-)

cc'ing a few editor folks for opinions.  I excluded big/small from the long list
of stylistic html inline elements that we force into copy stream if they are
somewhere in parent heirarchy.  The reason I omitted them is because I think
users usually don't want relative size preserved on copy when copy/pasting
*between different documents*.  Eg., when copying some text from
home.netscape.com, and paste into a paragraph in your mail message.

However, when copy/pasting within your own document you probably do want to grab
relative size.  Thoughts?



------- Additional Comments From Daniel Glazman 2001-09-06 04:53 -------

me thinks that you could/should copy the text size if the destination block
element and the source block element have same default font size. For instance,
from a P to another P, from a P to a LI, but not from a LI to a H1.
Does it make sense ?



------- Additional Comments From [e-mail] 2001-09-06 05:31 -------

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



------- Additional Comments From Charles Manske 2001-09-06 09:57 -------

I like Daniel's suggestion.

Comment 1

[sujay]

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

Comment 2

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

Joe Francis said in a "deprecated" place :

> You don't know at copy time what the destination is going to be.

So can we always copy big/small but remove them after paste if we want/need to ?

Comment 3

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 4

[TucsonTester2]

works for me, mac os x build 20011218052... the small tags got copied fine when
i checked the html source.

Comment 5

[Syd Logan]

worksforme Linux, marking works for me, plussing it as well incase it gets reopened.

Comment 6

[michael wendell]

Using the original Steps to reproduce, this appears to be working.  But if you
don't bold the text, the small tags are not carried over.  So it seems that the
small tags are only carried over if another style is applied to the selected
text.  See my new steps for fail case.

Steps to Reproduce:
1. Launch Composer
2. Type the word "hello" followed by a carriage return
3. Highlight the word "hello"
4. Click the "-a" button on the toolbar twice
5. Highlight the letters "ello" and copy them to the clipboard (CTRL - C)
6. Click below the word "hello" and type some characters to verify that the text
is normal size followed by a carriage return
7. Paste the copied text (CTRL - V)

Notice that the pasted text is normal size instead of smaller like it should be.

This was confirmed on Win 2k and Mac OSX both using the 01-24 trunk build.

I am reopening this bug.

Comment 7

[Joe Francis]

1.1

Comment 8

[Kevin McCluskey (gone)]

Bulk moving all nsbeta1+ bugs which were targetted after Mozilla1.0 to Mozilla1.0

Comment 9

[Joe Francis]

pri = 2 for original 1.0 EB+ bugs

Comment 10

[Joe Francis]

Attachment: patch to content

In the end I concluded that it's not really bad to always copy big/small.  I
had to tweak nsDocumentEncoder.cpp and also the html atoms files.

Comment 11

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

Comment on attachment 74632 [details] [diff] [review]
patch to content

>+  // distance down in the parent heirarchy.  Later we will need to add leading/trailing

Typo: hierarchy, not heirarchy.

Handling in a full contextual and wywisyg way big and small is probably not
worth
the incredible time you are going to spend on it. I have to point out that this
fix
is consistent with the CSS copy/paste of <span style="font-size: larger"> for
instance...

r=glazman

Comment 12

[kinmoz]

Comment on attachment 74632 [details] [diff] [review]
patch to content

sr=[e-mail]

Comment 13

[Asa Dotzler [:asa]]

Comment on attachment 74632 [details] [diff] [review]
patch to content

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

Comment 14

[Joe Francis]

checked in on trunk with daniel's corrections

Comment 15

[michael wendell]

Verified on Win 98 and Mac OSX using the 03-22 trunk build.