Open
Bug 285635
Opened 20 years ago
Updated 4 years ago
Hard coded body and html prevent metadata gathering from drag and drop
Categories
(Core :: DOM: Copy & Paste and Drag & Drop, defect, P5)
Tracking
()
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
|
||
Comment 2•20 years ago
|
||
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
|
||
Updated•20 years ago
|
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.
|
||
Comment 4•19 years ago
|
||
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/
|
|
||
Comment 5•19 years ago
|
||
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 → ---
|
||
Updated•15 years ago
|
QA Contact: drag-drop
|
||
Comment 7•13 years ago
|
||
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.
|
||
Comment 8•4 years ago
|
||
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.
Description
•