it looks like under certain circumstances the location service doesn't
propagate chages to window.loction. I'm disabling this test now, it is
passing on the master branch (0.10.0)
- buzz api keeps on throttling our requests which makes our build fail
so I'm disabling the buzz demo e2e test
- the $xhr service jsonp test was modified to use jsonp on angularjs.org
instead of buzz api for the same reason as mentioned above
$new can't be used for creation of temporary scopes because it registers
an onEval listener that doesn't go away and keeps the scope around, we
must use inherit(scope) instead to avoid this issue.
The issue does not apply to the master branch with the new scope which
has a scope descructor to clean up this mess.
In order to avoid unnecesary route reloads when just hashSearch part
of the url changes, it is now possible to disable this behavior by
setting reloadOnSearch param of the route declaration to false.
Closes#354
Change doc_widget.js to:
- render "edit in jsfiddle" button next to all examples
- make opt out certain examples by adding jsfiddle="false" attribute to
doc:source element
it turns out that even with our tricks, jqLite#show is not usable in
practice and definitely not on par with jQuery. so rather than
introducing half-baked apis which introduce issues, I'm removing them.
I also removed show/hide uses from docs, since they are not needed.
Breaks jqLite.hide/jqLite.show which are no longer available.
These widgets are useless and only trigger extra $updateViews.
The only reason we had them was to support ng:change on these widgets,
but since there are no bindings present in these cases it doesn't make
sense to support ng:change here. It's likely just a leftover from
getangular.com
Breaking change: ng:change for input[button], input[submit], input[reset], input[image]
and button widgets is not supported any more
The previous implementation didn't handle situation when in css
something was hidden with a cascaded display:none rule and then we
wanted to show it.
Unfortunatelly our test doesn't test this scenario because it's too
complicated. :-/
both numbers and currency need to be formatted using a generic pattern
which can be replaced for a different pattern when angular is working in
a non en-US locale
for now only en-US locale is supported, but that will change in the
future
