- better compatibility with 3rd party code - we clober 3rd party
style only if it direcrtly collides with 3rd party styles
- better perf since it doesn't execute stuff on every digest
- lots of tests
Unfortunately, there people in our team (me), who are not able to use angular.* namespace prefix
when writing angular-mocks code, so we need to test it...
Commit 5a2dcb9a doesn't properly modify angular-boostrap.js.
This fix resolves issues and makes both the regular and scenario
version of angular-boostrap.js functional.
Having the extra level of indirection by using logs/*.log file
only makes it more difficult to use these scripts. After this
change it will be enough to just start the watchr and watch the
terminal it was started in.
The last script element in the dom is always us if the script that
contains angular is loaded synchronously.
For async loading manual bootstrap needs to be performed.
Close#621
Along the way I also changed the repeater impl to use for loop instead
of for in loop.
Iteration over objects is handled by creating an array of keys, which is
sorted and this array then determines the order of iteration over an
element. This makes repeating over objects deterministic and
cross-browser compatible.
A lot of badness happens when we don't ignore stale xhrs. These
raceconditions are only apparent when user clicks through the app very
quckly without waiting for routes to fully load.
Closes#619
This functionality was previously available only as obscure $browser.defer.cancel.
I also added docs and tests and fixed an issue in .defer.cancel mock.
For example:
<a href="some/link">inner <span>text</span></a>
If you click on "text", then the span element is event.target, so we need to traverse the DOM.
Change introduced by me in 8611ebe6 results in considerable inefficiencies when the compiler
and linker is used from within a widget, in which case, we call $digest unnecessary since it
will be called by the $apply which called the directive/widget in the first place.
There are only two places when the extra $digest call can be useful - when manually bootstrapping
the app or in tests. However even in tests this behavior can result in unwanted results (especially
when ng:controller is involved). So it is better to leave it for the developer to call $digest
when it is really needed.
