Open Bug 285635 Opened 19 years ago Updated 3 years ago

Hard coded body and html prevent metadata gathering from drag and drop

Categories

(Core :: DOM: Copy & Paste and Drag & Drop, defect, P5)

Product:
Core
Component:
DOM: Copy & Paste and Drag & Drop
Platform:
x86
Windows 2000
Type:
defect

Tracking

()

Status:
UNCONFIRMED

People

(Reporter: dcaruso, Unassigned)

References

(Blocks 1 open bug)

Details

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.40607)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113

Information avilable in the <head> and <body> tags is hardcoded rather than 
extracted directly from the page during drag and drop.

Although the presense of the tag is all that is nessisary for CF_HTML spec, 
providing that actually head and body tags will provide applications which need 
to utilize document metadata, a shace to obtain some of it. 

this is realted to bug id 281873, in which it is noted that source url is not 
provided. 

These failures are especially painful to collection building applications which 
allow for drag and drop support. Since these tools utilize informations such 
title and meta fields to arganize collected information. 

This problem is located at 
http://lxr.mozilla.org/mozilla/source/widget/src/windows/nsDataObj.cpp#1190

Although this is (I think) the part that does this on windows, it should also 
be verified that this behavior is consistent on other operating systems.


Reproducible: Always

Steps to Reproduce:
1.Drag and drop a selection from a web page to an application which shows the 
raw contents of the drop session data. 
2. In this case this was done through java. 
3. You will notice that the <head> and <body> tags are not the same as thoes 
present in the document source.

Actual Results:  
recived standard hardcoded <head> and <body> tags

Expected Results:  
It should have givin me the head and body tags along with all thier attributes 
from the page the selected elments were dragged from.
Sorry I changed this to reflect that it is the <body> and <html> tag that are 
hardcoded the <head> tag is simply not there. I will file this as a speerate 
but related bug, see bug id 285893
Summary: Hard coded body and head prevent metadata gathering from drag and drop → Hard coded body and html prevent metadata gathering from drag and drop
So far the difference between IE and Mozilla is that IE puts in the clipboard
the full source page, and the format indicates where the selected part to paste is.

Mozilla only puts the selected part, and create a minimal wrapping around it.

Please give a detailled indication of why it is needed to do it the IE way.
Component: General → XP Toolkit/Widgets
Product: Mozilla Application Suite → Core
Version: unspecified → Trunk
Blocks: 285893
Assignee: general → nobody
Component: XP Toolkit/Widgets → Drag and Drop
QA Contact: general
Not sure why I didn't notice this eaelier and perhaps this should be an 
additional bug, but in addition to the hardcoded <head><body> tag, 
the rest of the document context called for in Microsoft's CF_HTML spec, 
http://msdn.microsoft.com/library/default.asp?
url=/workshop/networking/clipboard/htmlclipboard.asp is not included either.

I'm including a dump from both Mozilla and I.E. Note this is from a JAVA 
program, which strips the description part of the CF_HTML spec out.

Mozilla DUMP

<html><body>
<!--StartFragment -->
<img src="http://www.dgp.utoronto.ca/people/modjeska/Pubs/WWW2002/hg-large.jpg" 
height="367" width="550">
<!--EndFragment-->
</body>
</html>

IE DUMP

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

<HTML><HEAD><TITLE>Hunter Gatherer -WWW2002</TITLE>
<STYLE type=text/css>
<!--
.figure {  margin-left:3em; margin-right:4em; font-family: Verdana, Arial, 
Helvetica, sans-serif; font-size: 0.9em; color: #3333FF}
.copy {  margin-left:0em; margin-right:4em; font-family: Verdana, Arial, 
Helvetica, sans-serif; font-size: 0.8em; color: #000033}
.indent {margin-left:4em; margin-right:6em;}
h1 {  font-family: Georgia, "Times New Roman", Times, serif; color: #333333}
h2 {  font-family: Georgia, "Times New Roman", Times, serif; color: #333333}
h3 {  font-family: Georgia, "Times New Roman", Times, serif; color: #333333}
h4 {  font-family: Georgia, "Times New Roman", Times, serif; color: #333333}
p  {  margin-left:2em; margin-right:4em; font-family: Verdana, Arial, 
Helvetica, sans-serif; font-size: 0.9em;}
-->
</STYLE>
</HEAD>

<BODY bgColor=#ffffff>

<TABLE width=735 border=0>

<TBODY>

<TR>

<TD width="92%">

<P align=center><!--StartFragment--><IMG height=367 src="hg-large.jpg" 
width=550><!--EndFragment--></P>
</TD>
</TR>
</TBODY>
</TABLE>
</BODY>
</HTML>


As you can clearly see here the "context" as descirbed by the CF_HTML spec is 
not included in the data. 

I am not well versed in mozilla source code, but as long as the document's root 
node is available in 
http://lxr.mozilla.org/mozilla/source/widget/src/windows/nsDataObj.cpp the fix 
should be an easy walk up the selected element's parents, to the document root.


This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED

This is still an issue, the relevant code is now @

http://lxr.mozilla.org/mozilla/source/widget/src/windows/nsDataObj.cpp#1405
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---
QA Contact: drag-drop
Internet Explorer provides the whole page and uses the CF_HTML markers:
StartFragment:000003051
EndFragment:000003467

To indicate the location fragment within the context. 

Google chrome does like us and provides only the selection and associated parent context if needed.

Opera does not have support for CF_HTML.

I'm not entirely convinced that providing the whole page is a good idea though.  For one, the user who only selects something small might not know they are exposing the whole page to the program they paste into.

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: -- → P5
You need to log in before you can comment on or make changes to this bug.