This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 20791 - From http://jackiszhp.info/postMessage.html <h1>The postMessage design outlined in the W3C document edited by Ian Hickson is not good!</h1> The <a href="http://www.w3.org/TR/webmessaging/#web-messag [...]
Summary: From http://jackiszhp.info/postMessage.html <h1>The postMessage design outl...
Status: RESOLVED DUPLICATE of bug 20790
Alias: None
Product: WHATWG
Classification: Unclassified
Component: HTML (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: Unsorted
Assignee: Ian 'Hixie' Hickson
QA Contact: contributor
URL: http://www.whatwg.org/specs/web-apps/...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-01-28 04:34 UTC by contributor
Modified: 2013-03-21 19:01 UTC (History)
2 users (show)

See Also:


Attachments

Description contributor 2013-01-28 04:34:23 UTC
Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/web-messaging.html
Multipage: http://www.whatwg.org/C#introduction-10
Complete: http://www.whatwg.org/c#introduction-10

Comment:
From http://jackiszhp.info/postMessage.html   <h1>The postMessage design
outlined in the W3C document edited by Ian Hickson is not good!</h1> The <a
href="http://www.w3.org/TR/webmessaging/#web-messaging">design</a> of the
cross document messaging by <a href="mailto:ian@hixie.ch">Ian Hickson</a>
(Google, Inc.) is very bad. <br/> Even <a
href="http://dev.w3.org/html5/postmsg/#web-messaging">the last version</a> is
not good either. The design can be sketched here as follows.	    <pre> The
sender: var o = document.getElementsByTagName('iframe')[0];
o.contentWindow.postMessage('Hello world', 'http://b.example.org/');   The
receiver: window.addEventListener('message', receiver, false); function
receiver(e) {	if (e.origin == 'http://example.com') {     if (e.data ==
'Hello world') {       e.source.postMessage('Hello', e.origin);     } else {  
    alert(e.data);     }   } }	     </pre> This design was messed up by
pulling "origin" (a word that some people put too much attention more than
should). <br/> Even worse, it requires "o.contentWindow", this is really no
professional sense. Because of this design, if I open two tabs with the same
url http://www.google.com/ they are not able to communicate.	    <br/><br/>
      My proposal is discard the "o.contentWindow" part requirement.	  
<br/>	    <br/>	<br/>	    <h1>My better proposal</h1>       <pre>
the sender: window.postMessage(messageObject,targetDomain optional,windowIDs
optional);  Either targetDomain or windowIDs should present. I propose to use
ID rather than name (though window can have a name), since window.name is not
required to be unique within the browser.   then the user agent(i.e. the
browser, such as firefox) will do the following  var e={source: {href: get the
sender's window.location.href,		       windowID: unique windowID
within this browser		   },	     target: {domain: targetDomain as
the sender requested,		      windows: the array of windowID	      
     },        data: JSON.parse(JSON.stringtify(messageObject)),	ts:
the timestamp when the post is requested       }; if(windowIDs presents){  
postEvent to those windows. } else {   traverse the list of all windows   for
(each window){	   if(the domain of the window matches the target domain of
the message) {	   postEvent(e);   } }	 the receiver /* return true to
indicate to continue to receive message from this sender return false to
indicate to deny messages from this sender forever   (as long as the browser
can remember this) */ function receiver(e) {   if (e.source is accepted) {    
take the e.data to do whatever as desired.     return true;   }   return
false; }  window.addEventListener('message', receiver, false);	  if the
receiver wants to respond to the sender
window.postMessage(messageObject,targetDomain optional,windowIDs optional);   
     targetDomain can be found from e.source.href	  windowID can be
found from e.source.windowID	     messageObject is the message object
intended to be sent.	    </pre>  <br/> <br/> <h2>About domain match</h2>
the specification of the target domain can be <pre>  www.google.com or
google.com  this should match *.google.com or com      this should match *.com
or ""  as for all or https://www.google.com or http://www.google.com:9876/abc/
 </pre> For the last case, if a
window.location.href=="http://www.google.com:9876/def/", then they do not
match. <br/> <br/> <h2>About Security</h2> As long as the receiver check who
is the sender which is identified by the user agent, there is no security
issue at all.	  <h2>About context sharing within the browser</h2> Whether
session data should be shared among the different processes of the same
browser. such as cookies. It seems that firefox does not allow 2 different
processes unless use different profile. <p> Here, one more setting, whether
the windowIDs should be unique across different process. Within the same
process among different tabs, they must be unique. If no more than one process
is allowed, then such setting is not relevant. </p> <br/><br/><br/><br/> <br/>
<h3>Challenge</h3> A bad design waste people's energy & time, to promote the
better solution. I am offering a reward for the 1st one who implement my
proposal. If you can do this before march 1st, 2013, I will give you $10. 
<br/> <!--  browser.js search.js   nameOf: function TabUtils_nameOf(tab) {  
URLOf: function TabUtils_URLOf(tab) {		  let tab =
gBrowser.tabs[browserIndex];		 win.gBrowser.tabls --> <br/> <br/>
<br/> <br/> jackiszhp@gmail.com <br/> <br/> <br/> <br/> <br/> <br/> <br/>
<br/> <br/> <a href="postMessage.pdf">pdf version</a> <br/> Last update:
2013.01.27 21:30

Posted from: 99.233.154.108
User agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0
Comment 1 Ian 'Hixie' Hickson 2013-03-21 19:01:57 UTC

*** This bug has been marked as a duplicate of bug 20790 ***