Changed the title to: "Dartium and "build.dart" differ in behavior for paths in img tag".

--deploy is doing the rightish thing. Native HTML Imports aren't behaving correctly with URL resolution. I think Polymer is always using polyfills at the moment. I had to workaround this when porting the new TodoMVC from Polymer (https://codereview.chromium.org/60353013/).

Here's the Blink bug for this feature: https://code.google.com/p/chromium/issues/detail?id=240592

I don't think we can workaround this in HTML Imports Polyfill anymore (now that webkitStartDart is gone), so I think we just have to wait for a fix on the C++ side.

I did workaround it in my app so feel free to use that (somewhat ugly) technique.

Removed Area-Polymer, Library-PolymerBuild labels.
Added Area-Dartium label.

I'm surprised that there is any URL rewriting. Why is the URL rewritten? That is, why is the --deploy "smarter" here?

I'm surprised that there is any URL rewriting. Why is the URL rewritten? That is, why is the --deploy "smarter" here?

1. HTML Imports loads things from URLs relative to the imported document's URL. (At least, that is how the polyfill works, so presumably that is/was matching spec'd behavior.)
2. polymer.dart deploy tool, like Polymer's own Vulcanizer, inlines HTML documents for deployment.
3. Inlining moves things from one URL to another, therefore we/they must fix URLs (see https://github.com/Polymer/vulcanize/blob/37826f88bf7f1672eed21465a0ef25276c24027c/lib/vulcan.js#L36)

aha, I think I know why you're surprised. This used to work, because Dartium and Polymer.js both used HTML Imports Polyfill for development, and build.dart/Vulcanizer for deployment.

But we changed to native HTML Imports recently. Polymer-js is not using it yet. That's why we hit bugs like https://code.google.com/p/dart/issues/detail?id=12434#c21, but they haven't hit them yet.

Was it premature to switch to native? Perhaps. I certainly didn't expect so many issues :|.

We could go back to adding this to your HTML page:

    <script src="packages/html_imports/html_imports.js">

... but we'd need to flip the experimental flag for HTML Imports back to OFF. Because if native is turned on, it will finish before the Polyfill has a chance.

Anyway I'd suggest some people (perhaps sigmund@ vsm@) follow up with morrita@ and figure out what is best for Dartium given the Blink implementation timeline.

cc @sigmundch.
cc @vsmenon.

I'm afraid that switching back might not be that easy. Part of the problem here is how we load and bootstrap the code in Dartium. Without native support, we would have to require that our users write extra import statements, or go back to do something like we did with 'boot.js'. The latter is especially hard now that webkitStartDart is gone.

Another alternative would be to keep using the native implementation, but do some url-fixes in our loader code to compensate for that bug in blink.

Thanks, I didn't realize that pub build inlines. If so, makes sense it's changing paths.

Thank you for following up! The difference in behavior is certainly confusing.

And yes, I used to have to do this:

a href="../#foo"

But now I have to do this:

a href="#foo"

So something certainly changed.

I have no problem including any number of extra files to get consistent behavior. I assume a building script will take care of concatenating/minifying/etc

Thanks guys!

And for the record, if we know of the blink bug we can drop a link there.

Siggi: is there something we need to do here in Dartium?

Set owner to @sigmundch.
Added this to the M9 milestone.
Added NeedsInfo label.

Removed this from the M9 milestone.
Added this to the 1.1 milestone.

No that I know of. This seems like a blink bug, but I haven't found a bug item for them that I can link here, so we might have to file one for them.

I filed a bug for blink here with a small repro example:

https://code.google.com/p/chromium/issues/detail?id=319598

Thanks! Starred.

This comment was originally written by fayb...@gmail.com

This could be a temp solution, as long as when you run in production your image is in the folder img in the root directory.

Attachment:
common-element.dart (809 Bytes)

Removed the owner.
Added Waiting label.

Removed this from the 1.1 milestone.
Added this to the 1.3 milestone.

Removed this from the 1.3 milestone.
Added this to the 1.6 milestone.

Removed this from the 1.6 milestone.
Added Oldschool-Milestone-1.6 label.

Removed Oldschool-Milestone-1.6 label.