Re: [whatwg] Document's base URI should use the document's *current* address

[Sean Hogan]

On 16/02/12 5:03 PM, Justin Lebar wrote:

On Wed, Feb 15, 2012 at 5:31 PM, Ian Hickson  wrote:

On Wed, 15 Feb 2012, Justin Lebar wrote:

  - It sets "the document's current address" to ".../page.html#foo".

Well, this is pretty bad.  document.location is the document's current
address [1].  So clicking #foo changed document.location from page2.html
to page.html#foo, which I certainly wouldn't expect (and does not match
implementations).

Seems to me we should change the implementations then. There isn't any
fundamental difference between linking to #foo and linking to
page.html#foo if the base URL is page.html, as far as I can tell.

If the implementations can't change, then I'll change the spec, but it
really seems bad to me that relative URLs will break depending on when
they are resolved relative to pushState() changes.

When I implemented pushState, I explicitly didn't want authors to have
to rewrite all their anchor links after they changed the document's
current URI.

> From an author's point of view, there's no such thing as the
document's original URI and, unless you're a nerd, you've never heard
of the base URI.  There's just the document's URI, modified by
pushState.

> From this point of view, I'd say it's less surprising that relative
URIs would break when you change directories (hey, you *asked* for it)
than that anchor refs would update the browser's address bar and
document.location relative to the old URI.


I share your perspective, Justin (if I'm interpreting it correctly).

An obvious use-case for pushState() is facilitating an enhanced 
user-experience for page navigation within a site. In this case the 
process of document updates + pushState({},null, "foo/bar.html") should 
result in the same DOM as if foo/bar.html was browsed to directly.


For example, imagine a site that has some pages amenable to this usage:

/page1.html
/page2.html
/subdir/page3.html

These contain some page specific content wrapped in some generic page 
template.
(I'm assuming that pages amenable to document updates + pushState() have 
a lot in common, otherwise why use pushState().)







I hope you are not distracted by my enormous banner. You may want to 
skip directly to the main content of this page. 



 My Site



Page 1
Page 2
Page 3








The following stylesheets and images are used:
/style.css
/logo.png


If page creation was all performed on the server using this template then...
- /page1.html & /page2.html would be okay
- /subdir/page3.html would be broken:
  1.  has a relative path and refs the 
non-existant /subdir/logo.png

  2. Similarly,  with #nav all have rel paths to nowhere
  3. Note that the top skip link is OK in all pages

If a pushState() facilitated mechanism was used for navigation
(a naive implementation which just inserts page-specific content inside 
)
and navigation started at /page1.html, thence to /page2.html and 
/subdir/page3.html,

the images and hyperlinks in /subdir/page3.html would be fine...
except for the top skip link which references the #content anchor.

Obviously this page template needs fixing and for this example, simply 
changing rel paths to absolute will be sufficient for both the server 
generated and browser updated documents. Except that pushState() 
assisted navigation would break the top skip link (assuming the current 
SPECIFIED behavior).


For all the issues in this example I think Justin's proposal is 
preferable to what is currently specified.


By the way, this doesn't quite match what is currently implemented in 
Firefox and Webkit. According to my testing, although the baseURI after 
pushState() is the same as the documentURI (so far I've tested , 
 and  elts) the actual images and stylesheets used for 
rendering aren't updated by the pushState() - they should be updated if 
@src, @href is a rel path. If they were updated then the ones relying on 
rel paths would often break, which I consider a good behavior - an 
obvious visual cue to the page author, etc that something was 
implemented wrongly.


Sean

Re: [whatwg] DND: proposal to expose origin

[Charles Pritchard]

On 2/19/2012 4:28 PM, Adam Barth wrote:

On Sun, Feb 19, 2012 at 2:28 PM, Charles Pritchard  wrote:

On 2/17/12 1:35 AM, Anne van Kesteren wrote:

Our proposal takes its cues and algorithms from the postMessage API, and
allows the source site to restrict drop targets to only those origins which
it trusts, and allows drop targets to see which origin was the source of a
drag. The majority of the algorithm can be copied from postMessage,
including the syntax for allowed target origins.

interface DataTransfer {
  ...
  readonly attribute DOMString origin;
  void allowTargetOrigin(DOMString targetOrigin);
};

Any chance we could get D&D to pass a window object or message port so we
could use postMessage?

The source might be in a different unit of related browsing contexts,
which might mean in a different process in a multi-process browser.
In those cases, we wouldn't want to provide a window reference.


window.open/iframe seems the only way to link; I've used an
iframe+sharedworker setup before, which works pretty well.

Correct.  That's by design.



If contentWindow.postMessage is off the table, how about a message port?
When allowTargetOrigin / origin are setup, it'd be pretty cool to be 
able to have an easy drag and drop of a message port without needing the 
shared worker trampoline.


I had to use the trampoline method for a Chrome extension recently, as 
they don't have Transferrable setup in their chrome.* namespace. It 
worked well.
I'm ok with the iframe+sharedworker design, I'd just like to avoid the 
trampoline if and when possible.



-Charles

Re: [whatwg] DND: proposal to expose origin

[Adam Barth]

On Sun, Feb 19, 2012 at 2:28 PM, Charles Pritchard  wrote:
> On 2/17/12 1:35 AM, Anne van Kesteren wrote:
>>
>> Our proposal takes its cues and algorithms from the postMessage API, and
>> allows the source site to restrict drop targets to only those origins which
>> it trusts, and allows drop targets to see which origin was the source of a
>> drag. The majority of the algorithm can be copied from postMessage,
>> including the syntax for allowed target origins.
>>
>> interface DataTransfer {
>>  ...
>>  readonly attribute DOMString origin;
>>  void allowTargetOrigin(DOMString targetOrigin);
>> };
>
> Any chance we could get D&D to pass a window object or message port so we
> could use postMessage?

The source might be in a different unit of related browsing contexts,
which might mean in a different process in a multi-process browser.
In those cases, we wouldn't want to provide a window reference.

> window.open/iframe seems the only way to link; I've used an
> iframe+sharedworker setup before, which works pretty well.

Correct.  That's by design.

Adam

Re: [whatwg] DND: proposal to expose origin

[Ryosuke Niwa]

This proposal sounds reasonable.

On Fri, Feb 17, 2012 at 1:35 AM, Anne van Kesteren  wrote:
>
> Names are chosen to be compatible with those used by HTML5 Web Messaging.
>
> dataTransfer.origin
>  Returns a DOMString consisting of the protocol, domain and optional port,
> of
>  the origin where the drag started:
>  http://evilsite.com
>  http://evilsite.com:8080
>
>  If the drag was not started on an origin (such as a dragged file from the
>  desktop), or on a URL that is not a scheme/host/port tuple, the value
> should
>  be the string value "null". This conforms with HTML5 subsection "Unicode
>  serialization of an origin" -
>  http://dev.w3.org/html5/spec/**origin-0.html#unicode-**
> serialization-of-an-origin
>  Attempts to write to dataTransfer.origin will be ignored but not throw an
>  error, in accordance with WebIDL.
>
> dataTransfer.**allowTargetOrigin(**targetOrigin)
>  Defines an origin match for sites which may receive the dropped data. If
> this
>  method is not called, then all sites and applications may be considered
>  dropzones.
>

As Michal mentioned, can we make the default action not to make
cross-origin pages dropzones? Or at least let implementors choose?

Alternatively, you can make this property an array (e.g.
allowedTargetOrigins) and UA can fill in the default.
e.g. allowedTargetOrigins will be ["*"] on UAs that allows cross-origin by
default but will be ["http://banksite.com/";] on UAs that doesn't allow it
by default.

- Ryosuke

Re: [whatwg] DND: proposal to expose origin

[Michal Zalewski]

The security problems with drag-and-drop are significantly more
pronounced than just the banking scenario you are describing. Because
the drag-and-drop action is very similar to other types of legitimate
interaction (e.g., the use of scrollbars), many practical
content-stealing attacks have been demonstrated (e.g., theft of
anti-XSRF tokens).

Consequently, I believe that Chrome disallows drag-and-drop between
non-same-origin frames completely, and Firefox is planning to do the
same (https://bugzilla.mozilla.org/show_bug.cgi?id=605991).

I strongly suspect that given the broad and serious exposure, I think
this should be the default; with certain origins being able to specify
that they want to allow cross-origin drag-and-drop, perhaps leveraging
this API.

/mz

Re: [whatwg] DND: proposal to expose origin

[Charles Pritchard]

On 2/17/12 1:35 AM, Anne van Kesteren wrote:
Our proposal takes its cues and algorithms from the postMessage API, 
and allows the source site to restrict drop targets to only those 
origins which it trusts, and allows drop targets to see which origin 
was the source of a drag. The majority of the algorithm can be copied 
from postMessage, including the syntax for allowed target origins.


interface DataTransfer {
  ...
  readonly attribute DOMString origin;
  void allowTargetOrigin(DOMString targetOrigin);
}; 


Any chance we could get D&D to pass a window object or message port so 
we could use postMessage?


window.open/iframe seems the only way to link; I've used an 
iframe+sharedworker setup before, which works pretty well.

Re: [whatwg] Caching of identical files from different URLs using checksums

[Julian Reschke]

On 2012-02-18 14:45, Sven Neuhaus wrote:

...


Stop here. That's not what the fragment identifier is for.

Instead, you could specify the hash as a separate attribute on the
containing element.


The relevant section from RFC 3986 reads:

   "The fragment identifier component of a URI allows indirect
identification of a secondary resource by reference to a primary
resource and additional identifying information.  The identified
secondary resource may be some portion or subset of the primary
resource, some view on representations of the primary resource, or
some other resource defined or described by those representations."


..but it goes on saying:

"The semantics of a fragment identifier are defined by the set of 
representations that might result from a retrieval action on the primary 
resource. The fragment's format and resolution is therefore dependent on 
the media type [RFC2046] of a potentially retrieved representation, even 
though such a retrieval is only performed if the URI is dereferenced. If 
no such representation exists, then the semantics of the fragment are 
considered unknown and are effectively unconstrained. Fragment 
identifier semantics are independent of the URI scheme and thus cannot 
be redefined by scheme specifications."



This description is not contradicting the use of checksum as fragment
identifiers. They are "additional identifying information."


It is contradicting the concept of being defined by the media type.


However, if there is a consensus that checksums shouldn't be stored in
the fragment part of the URL, a new attribute would be a good alternative.

Regards,
-Sven Neuhaus



Best regards, Julian