173363 - Depending on where the selection is made on text, font information gets lost when drag & drop.

Status: RESOLVED FIXED

(Core :: DOM: Selection, defect, P1)

Description

[Hansoo Kim]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; YComp 5.0.0.0)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.1) Gecko/20020613

Depending on where the selection is made on text, font information gets lost 
when drag & drop.

I will include the test page after filing.

Basically the test page has  four lines with different font sizes.
Depending on where you highlight, when dragged and dropped, the font size 
information gets lost.
( Looking at the output from modified code, it actually lose ALL font 
information. )

For example,
if there was a line, "This is a complete line."

If you highlight all of it, when dragged and dropped, it displays with the same 
font size.
But if you only highlight the portion of the sentence, the font information 
gets lost and it's displayed with a default font size of editor where you drop 
the content to.

It seems like Wordpad does not do a good job as drop target.
MS Words is more reliable when re-producing this bug.

The following are excerpt ( but modified to ooutput strings ) from 
nsContentAreaDragDrop::DragGesture() in nsContnetAreaDragDrop.cpp

  // crawl the dom for the appropriate drag data depending on what was clicked
  PRBool startDrag = BuildDragData(inMouseEvent, urlString, titleString, 
htmlString, getter_AddRefs(image), &isAnchor);
  if ( startDrag ) {

/**Modi begin **/
	nsCAutoString strTemp;
	
	strTemp = "Title string is ";
	strTemp.AppendWithConversion(titleString);
	NS_ASSERTION( PR_FALSE , strTemp.get() );

	strTemp = "urlString string is ";
	strTemp.AppendWithConversion(urlString);
	NS_ASSERTION( PR_FALSE , strTemp.get() );


	strTemp = "htmlString string is ";
	strTemp.AppendWithConversion(htmlString);
	NS_ASSERTION( PR_FALSE , strTemp.get() );
/**Modi end **/


    // build up the transferable with all this data.
    nsCOMPtr<nsITransferable> trans;

Reproducible: Always

Steps to Reproduce:
1. Load up the test case, which I will put soon.
2. Load up MS Words side by side with the mozilla browser.
3. Highlight some line ( the whole line - try to highlight from the blank line 
above and below also ) and drag the selectin to Words.
4. You will see it displays as the same size.
5. Now highlight only the portion of the line.
6. Do the drag on Words.
7. Size information is lost ( whole font information is lost... )


Actual Results:  
See Step to reproduce.

Expected Results:  
Size and all other font information ( ex, font name, etc ) should not be lost
even though any part of surrounded text is dragged.

Comment 1

[Hansoo Kim]

Attachment: Test case html with diff font sizes

Here is the promised test case.

Comment 2

[Michael Dunn]

Internal Reference:
http://bugscape.mcom.com/show_bug.cgi?id=20438

Comment 3

[Michael Dunn]

Pmac can you confirm?

Comment 4

[Hansoo Kim]

Can anyone confirm this and assign so that we can have some actions on this 
bug ?

Thank you.

Comment 5

[Teruko Kobayashi]

I can reproduce this in Netscape 7.0, 10-21 branch, and 10-21 trunk build. 
I confirm this problem.

Comment 6

[Patty Mac]

It happens when you drag them to the MS Words only (netscape trunk build:
2002-10-21-08-TRUNK)

Comment 7

[Hansoo Kim]

I think it has been verified by at least three people.

Can we assign this to a proper department so that we can have some action on 
it ?

Thank you.

HK

Comment 8

[Teruko Kobayashi]

This is very important feature for Embedding projects.  Please fix as soon as
possible.

Comment 9

[Hansoo Kim]

Adding Jud and Chak in CC list so that they can coordinate this bug
for better handling of the bug.

Chak and Jud... thank you in advance.

HK ( Hansoo Kim )

Comment 10

[mjudge]

i am looking at this. I will either fix it or make sure the person that should
fix it gets it.

Comment 11

[mjudge]

kin said I should just go ahead and bounce this to you joe.  If you cant look at
this right away, let me know and I will do what I can.

Comment 12

[Kevin McCluskey (gone)]

nsbeta1+. 

Comment 13

[Joe Francis]

ironically this bug is fixed by some work i did as part of the cf_html effort. 
That should land on the trunk very soon.

Comment 14

[Joe Francis]

wait a minute, this bug isn't what i thought it was.  Is everyone in agreement
that this is only seen when pasting from mozilla into word?  No one is talking
about paste or drag from mozilla to mozilla, right?

Comment 15

[Joe Francis]

I think this will be fixed by upcoming patch for bug 183582

Comment 16

[Kathleen :Brade]

-->kaie

Comment 17

[Kai Engert [:KaiE:]]

I agree this will be resolved by bug 183582.
The original patch in bug 183582 is no longer valid because of conflicts, but
I've attached an updated patch.

Comment 18

[Kai Engert [:KaiE:]]

Marking fixed, because bug 183582 got fixed.
Please reopen if you still see the problem.