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 email@example.com 2001-07-19 14:20 ------- assigning to jfrancis ------- Additional Comments From firstname.lastname@example.org 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 email@example.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.
*** 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 ?
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)
works for me, mac os x build 20011218052... the small tags got copied fine when i checked the html source.
worksforme Linux, marking works for me, plussing it as well incase it gets reopened.
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.
Bulk moving all nsbeta1+ bugs which were targetted after Mozilla1.0 to Mozilla1.0
pri = 2 for original 1.0 EB+ bugs
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.
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 on attachment 74632 [details] [diff] [review] patch to content firstname.lastname@example.org
Comment on attachment 74632 [details] [diff] [review] patch to content a=asa (on behalf of drivers) for checkin to the 1.0 trunk
checked in on trunk with daniel's corrections
Verified on Win 98 and Mac OSX using the 03-22 trunk build.