"package/" under the web/ directory. Resolution under 'lib' is the same, but it and gives better suggestions if the path looks wrong. This summarizes what changed:
- source file: lib/b.html
import to "packages/c/d.html" was error, now is error + suggestion
import to "../packages/c/d.html" was error, now is error + suggestion
import to "../../packages/c/d.html" was resolved, now is resolved too
- source file: lib/a/b.html
import to "packages/c/d.html" was error, now is error + suggestion
import to "../packages/c/d.html" was error, now is error + suggestion
import to "../../packages/c/d.html" was error, now is error + suggestion
import to "../../../packages/c/d.html" was resolved, now is resolved too
- source file: web/b.html
import to "packages/c/d.html" was and continues to be resolved
import to "../packages/c/d.html" was error, now is resolved
- source file: web/a/b.html
import to "packages/c/d.html" was error, now is resolved
import to "../packages/c/d.html" was and continues to be resolved
import to "../../packages/c/d.html" was and continues to be resolved
Note: polymer-build and development mode are slightly different: polymer-build
detects and issues an error for bad paths inside lib/. These are not detected by
our package-resolution in loader.dart, but as long as users are not creating
symlinks by hand, Dartium should detect if the paths are wrong.
When we switch to start using pub-serve by default, we should be able to go back
to the web-ui style of using "package:" urls directly in HTML.
R=jmesserly@google.com, kustermann@google.com
Review URL: https://codereview.chromium.org//148913003
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@32170 260f80e4-7a28-3924-810f-c04153c831b5
I am aware that we should not clutter up the message that we show to developers, but I think it is important to validate that we actually send the onDone message to the driver page.
We should also put in functionality for tracking network errors in the browser_controller generated js (+potentially retrying the send of the message)
R=kustermann@google.com
Review URL: https://codereview.chromium.org//96503002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@30771 260f80e4-7a28-3924-810f-c04153c831b5
Currently test.py will look for FAIL/PASS messages in the DOM to determine if a
test has failed or not. test_controller.js will add these PASS/FAIL messages to
the DOM (in addition to other messages).
This approach has several issues:
- The test itself could create nodes in the DOM containing FAIL/PASS. This means
that the outcome of a test cannot be reliably determined.
- The test ifself can remove nodes from the DOM (e.g. setting
document.body.innerHTML). This could result in a situation where the
stacktraces/... test_controller.js prints to the DOM are lost.
- It is unclear which parts of the DOM we see in test failure messages
(reported by test.py) come from the test itself and which parts come from
test_controller.js.
This CL tries to fix this by recording all events that happend with global
variables in test_controller.js and send back a JSON string with information
about
- debug messages
- posted messages
- print() calls of the test
- DOM
- errors (from window.onerror, script.onerror ...)
Furthermore this CL fixes unittest to report
unittest-suite-success/unittest-suite-fail instead of unittest-suite-done (which
is broken).
R=ricow@google.com
Review URL: https://codereview.chromium.org//36913002
git-svn-id: https://dart.googlecode.com/svn/branches/bleeding_edge/dart@30407 260f80e4-7a28-3924-810f-c04153c831b5
whesse@google.com