Skip to content
This repository has been archived by the owner on Feb 22, 2018. It is now read-only.

Travis failing: linked to support for relative URLs ? #1439

Open
vicb opened this issue Sep 9, 2014 · 7 comments
Open

Travis failing: linked to support for relative URLs ? #1439

vicb opened this issue Sep 9, 2014 · 7 comments
Labels
action: cleanup type: bug
Milestone
post v1.0

Comments

@vicb
Copy link
Contributor

vicb commented Sep 9, 2014

There is a Travis failure that seems to be linked to the recent PRs about resolving relative URLs.

Please not that the test pass even if a 404 is returned. Is this expected ?

@dsalsbury @chirayuk could you please take a look at this ?
@vicb
Copy link
Contributor Author

vicb commented Sep 10, 2014

Also note those analyzer warnings:

Building angular_dart_example...
[Warning from _Serial on angular_dart_example|web/form.dart]:
line 5, column 1 of web/form.dart: Unable to find form_controller.html at angular_dart_example|form_controller.html
@Component(
^^^^^^^^^^^
[Warning from _Serial on angular_dart_example|web/bouncing_balls.dart]:
line 31, column 1 of web/bouncing_balls.dart: Unable to find bouncing_controller.html at angular_dart_example|bouncing_controller.html
@Component(
^^^^^^^^^^^

@vicb
Copy link
Contributor Author

vicb commented Sep 10, 2014

The failures seem to be linked to access body then I suspect the following code:

HtmlDocument document = new DomParser().parseFromString(
"<!doctype html><html><body>$html</body></html>", "text/html");

I someone with a a Mac and Safari could take a look, it would really help, Thanks.

Edit: the reported error is "NullError: Cannot call "get$body" on null"

@chirayuk
Copy link
Contributor

@vicb: For the 404, that is expected.  It's because we're using an img tag for the test and the browsers aggressively request the resource right away.  We only care about the resolved URL so it's ok if the image doesn't exist.  Perhaps we could stick in a 0 byte image there to get rid of the error.

For the NullError – this is a new one.  I'll take a look.

@chirayuk
Copy link
Contributor

@vicb:  It turns out that Safari's DOMParser does not parse HTML (but does parse XML, etc.)  It seems to be the only mainstream desktop browser that can't do this.  I'm working on a fix.

chirayuk added a commit that referenced this issue Sep 12, 2014
@chirayuk
fix(resource_url_resolver): fix DOM parsing for Safari
609116b 
Closes #1439
chirayuk added a commit that referenced this issue Sep 12, 2014
@chirayuk
fix(resource_url_resolver): fix DOM parsing for Safari
35e4787 
Closes #1439
chirayuk added a commit that referenced this issue Sep 12, 2014
@chirayuk
fix(resource_url_resolver): fix DOM parsing for Safari
bb16d38 
Closes #1439
chirayuk added a commit that referenced this issue Sep 14, 2014
@chirayuk
fix(resource_url_resolver): fix DOM parsing for Safari
7921d3a 
Closes #1439
@vicb
Copy link
Contributor Author

vicb commented Sep 15, 2014

@chirayuk thanks for the fix

@vicb
Copy link
Contributor Author

vicb commented Sep 15, 2014

@chirayuk re-opening this, the analyzer warnings are not fixed (see the first comment after the headline). This force us to have html files listed in the pubspec

@vicb vicb reopened this Sep 15, 2014
@vicb vicb mentioned this issue Sep 15, 2014
Closed
@chirayuk chirayuk added this to the v1.0 milestone Oct 2, 2014
@naomiblack
Copy link
Contributor

This should be resolved by the fix in #1455 when done.

@rkirov rkirov modified the milestones: 1.1, v1.0 Oct 10, 2014
@rkirov rkirov modified the milestones: v1.2.0, 1.1 Jan 14, 2015
@naomiblack naomiblack modified the milestones: v1.2.0, post v1.0 Sep 7, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
action: cleanup type: bug
Milestone
post v1.0
Development

No branches or pull requests
4 participants
@chirayuk @rkirov @vicb @naomiblack