An example of a bug in HTC ViewLink Documents

Introduction

HTC ViewLink Content does not allow (successful) cut/copy/paste operations when it is viewed via an IFRAME. The context menu is displayed but does not perform successful operations. This does not occur when the same file is viewed in its own window.

Given an IFRAME in an HTML file:
<HTML><HEAD></HEAD><BODY>
<IFRAME src=page1.html></IFRAME>
</BODY></HTML>

And this HTML file (page1.html):
<HTML xmlns:myNameSpace>
<?IMPORT namespace="myNameSpace" implementation="IMP.htc" >
<HEAD>
</HEAD>
<BODY>
<myNameSpace:myTag />
</BODY>
</HTML>

And this HTC ViewLink Behavior Implementation file (Imp.htc):
<PUBLIC:COMPONENT tagName="myTag">
<PUBLIC:DEFAULTS viewLinkContent/>
</PUBLIC:COMPONENT>
<BODY>
Cannot cut/copy this text when parent document is in an IFRAME"
<INPUT VALUE="Cannot cut/copy this text when parent document is in an IFRAME">
</BODY>

Cut/Copy/Paste operations are not successful on the HTC ViewLink Behavior Implementation Content file if the content is being viewed thru an IFRAME or FRAME
ie IFRAME-->HTML File containing Master Element-->HTC ViewLink Content.
Cut/Copy/Paste operations are successful however if the content is not viewed thru an IFRAME or FRAME
ie HTML File containing Master Element-->HTC ViewLink Content.

What do you think?

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Author

cowtram

United States

Member

Article Top

Poor

Excellent

Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

You must Sign In to use this message board. (secure sign-in)

Search this forum
	Profile popups Noise Layout Per page

Element HTCs with ViewLink are the sexiest thing to hit the web, EVER!

Member 2407014

3:15 24 Apr '08

Element HTCs with ViewLink are the sexiest thing to hit the web, EVER!
They (or an equivalent) will for the basis of Web 3.0 (the next generation of web applications), like AJAX formed the basis of web 2.0.
My “conspiracy theory” is that Microsoft made a mistake to allowing the ability to create element HTCs, because they (or an equivalent) will result in the demise of the desktop (Windows) as we know it.
Element HTCs provide developers with the ability to create web application UIs that are as powerful as desktop application UIs. If you are interested I will forward you a few prototypes that I have created. One can even create “Windows” for the web in an elegant manner using HTCs.
HTCs, MVC (Model-View-Controller) and Web Services will form the basis of web 3.0… or maybe a hybrid equivalent of these.
If you are interest mail me at: froddy@ananzi.co.za.

There is a fix for this...

tad_orman

10:27 12 Nov '03

I struggled with this problem for a long while. There is a registry setting that you set to enable a fix that was part of IE6 SP1. Here is the KB article on the subject. http://support.microsoft.com/default.aspx?scid=kb;en-us;300829
Sign In·View Thread·Permalink	5.00/5 (1 vote)

Solution

CodeWrangler

0:32 23 Oct '03

I also hit this bug, but eventually managed to get around it using execCommand clipboard methods.

Basically, when your document is within a FRAME or IFRAME you have to do the copy/cut/paste operations yourself manually, rather than relying on the browser to do it for you.

Here's how I did it (this works in IE6, but I can't vouch for other browsers) ...

1) Script within viewlink element HEAD (this handles keyup events on the text field(s) in question):

   <SCRIPT FOR="inputField" EVENT="onkeyup" TYPE="text/javascript">
      fnInputKeyUp();
   </SCRIPT>

2) Form text fields within viewlink element BODY (these are the ones you want to perform clipboard operations on):

   <INPUT ID="txtField1" NAME="inputField" TYPE="TEXT">
   <INPUT ID="txtField2" NAME="inputField" TYPE="TEXT">
   <INPUT ID="txtField3" NAME="inputField" TYPE="TEXT">

3) Script function within viewlink element HEAD, instream or external file (this performs the clipboard operations manually, IF the viewlink's document is not the top level document - i.e. within an FRAME or IFRAME):

   function fnInputKeyUp() {

      switch (window.event.keyCode) {

         case 67: //--- c
            if (window.event.ctrlKey) { //--- Ctrl-c (Copy to clipboard)
               if (element.document != top.document) { //--- Manual clipboard operation required
                  document.selection.createRange().execCommand("Copy")
               }
            }
            break

         case 86: //--- v
            if (window.event.ctrlKey) { //--- Ctrl-v (Paste from clipboard)
               if (element.document != top.document) { //--- Manual clipboard operation required
                  document.selection.createRange().execCommand("Paste")
               }
            }
            break

         case 88: //--- x
            if (window.event.ctrlKey) { //--- Ctrl-x (Cut to clipboard)
               if (element.document != top.document) { //--- Manual clipboard operation required
                  document.selection.createRange().execCommand("Cut")
               }
            }
            break

      }

   }

Cool | :cool:

Quark
ianapier@bigfoot.com
http://www.geocities.com/ianapier

This isn't a bug I'm afraid

Captain Scarlett

4:02 28 Mar '03

This isn't a bug it's by design.

I think it's to stop a cross-site security issue(bug) where by the iframe could have loaded a page from a different domain(i.e. someone's nasty page), and then data is passed to that domain via the clipboard( i.e. cookie info, user logon info, credit card info etc).

I think htas (html application in IE) can get around it by setting the application="true" attribute on the iframe tag so the iframe is trusted, but I don't think you can get round it within IE.

Cheers

Mark Cool | :cool:

Captain Scarlet

Captain Scarlet is indestructible, you are not.

Remember this, do not try to imitate him...

Re: This isn't a bug I'm afraid

cowtram

22:42 31 Mar '03

Captain (Mark), Thanks for your comments.

However if this were the case, why would IE allow copy/pasting operations
on a doc in the same domain when viewed thru an IFRAME?

i.e. p2.htm is viewd via an IFRAME contained in p1.htm. Copy/Pasting Operations are allowed.

The same issues you have highlighted would apply in this case.

Why would MS allow copy/paste operations on a normal HTML page viewed thru an IFRAME but disallow copy/paste operations on an HTC doc viewed thru an IFRAME?

I welcome your reply.

Re: This isn't a bug I'm afraid

Captain Scarlet

23:34 31 Mar '03

As you say, it works if the pages are on the same domain, but not for different ones. IE detects when the domains differ and stops the action.

This happens similarly for other actions. Try accessing an element via scripting (e.g. access a page element from the page loaded in the iframe).

If the documents are in the same domain, it'll work, but different domains give security errors.

e.g.

parent page: Remove * (just to get code to show in page)

<html>

<body><*div id="mydiv">here is some text<*/div>

<iframe id="myframe"src="child.html" width="300" height="300"></frame>

</body>

</html>

child page

<html>

<script language="Javascript">

function GetText()

{

	alert(top.mydiv.innerText);

}

</script>

<body  önload="GetText();">

child div

</body>

</html>

place the pages in your root web folder and run the parent page via localhost (e.g. http://localhost/parent.html). you'll get an alert with "here is some text"

now change parent to make the iframe

src="http://<<replace with machine name>>/child.html"

so you are accessing the parent page via localhost and the child via your machine name (so it's in a different domain).

you'll get a permission denied error.

The situation is the same with the clipboard except the error is silent (i.e. no error is raised, just nothing happens).

Hope this helps

Mark

Captain Scarlet

Captain Scarlet is indestructible, you are not.

Remember this, do not try to imitate him...

Re: This isn't a bug I'm afraid

cowtram

0:15 1 Apr '03

You correctly point out that IE detects when the domains differ and stops the action. My point is that IE allows the actions on the SAME DOMAIN for an HTML page viewed thru an IFRAME so why does it not allow the actions on the SAME DOMAIN for an HTC page viewed thru an IFRAME. Surely this is a a bug? I welcome your comments Chris.
Sign In·View Thread·Permalink