If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

VERIFIED FIXED in mozilla1.0



16 years ago
16 years ago


(Reporter: sujay, Assigned: Joe Francis)




Firefox Tracking Flags

(Not tracked)


(Whiteboard: [QAHP] EDITORBASE+; FIXINHAND; need a=)


(1 attachment)



16 years ago
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 beppe@netscape.com 2001-07-19 14:20 -------

assigning to jfrancis

------- Additional Comments From jfrancis@netscape.com 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 jfrancis@netscape.com 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.


16 years ago
Keywords: nsbeta1
Whiteboard: [QAHP]
Target Milestone: --- → mozilla1.0

Comment 1

16 years ago
*** Bug 91518 has been marked as a duplicate of this bug. ***
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 ?


16 years ago
Priority: -- → P3


16 years ago
Whiteboard: [QAHP] → [QAHP] EDITORBASE; 2 days


16 years ago
Blocks: 104166

Comment 3

16 years ago
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 
Target Milestone: mozilla1.0 → mozilla1.0.1

Comment 4

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

Comment 5

16 years ago
worksforme Linux, marking works for me, plussing it as well incase it gets reopened.
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
Whiteboard: [QAHP] EDITORBASE; 2 days → [QAHP] EDITORBASE+; 2 days

Comment 6

16 years ago
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.
Resolution: WORKSFORME → ---


16 years ago
Keywords: nsbeta1+

Comment 7

16 years ago
Target Milestone: mozilla1.0.1 → mozilla1.1


16 years ago
Keywords: topembed
Bulk moving all nsbeta1+ bugs which were targetted after Mozilla1.0 to Mozilla1.0
Target Milestone: mozilla1.1 → mozilla1.0


16 years ago
Keywords: topembed → topembed+

Comment 9

16 years ago
pri = 2 for original 1.0 EB+ bugs
Priority: P3 → P2

Comment 10

16 years ago
Created attachment 74632 [details] [diff] [review]
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.


16 years ago
Whiteboard: [QAHP] EDITORBASE+; 2 days → [QAHP] EDITORBASE+; FIXINHAND; need r=,sr=,a=
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
the incredible time you are going to spend on it. I have to point out that this
is consistent with the CSS copy/paste of <span style="font-size: larger"> for

Attachment #74632 - Flags: review+

Comment 12

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

Attachment #74632 - Flags: superreview+


16 years ago
Whiteboard: [QAHP] EDITORBASE+; FIXINHAND; need r=,sr=,a= → [QAHP] EDITORBASE+; FIXINHAND; need a=

Comment 13

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

a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #74632 - Flags: approval+

Comment 14

16 years ago
checked in on trunk with daniel's corrections
Last Resolved: 16 years ago16 years ago
Resolution: --- → FIXED

Comment 15

16 years ago
Verified on Win 98 and Mac OSX using the 03-22 trunk build.
You need to log in before you can comment on or make changes to this bug.