In Firefox, hovering over an option in an open select menu updates the selected property of option
elements. This means that when a render is triggered by the digest cycle, and the list of options
is being rendered, the selected properties are reset to the values from the model and the option
hovered over changes. This fix changes the code to only use DOM elements' selected properties in a
comparison when a change event has been fired. Otherwise, the internal new and existing option
arrays are used.
Closes#2448Closes#5994Closes#6769
`git ls-remote --tags` assumes that you have a remote set up for your
current branch. That isn't the case, at least for me, when I'm working
on local branches. `grunt write` doesn't do the right thing in that
case (`git ls-remote --tags` bails out and the silent: true param makes
this a pain to debug.) Prefer explicit to implicit.
Closes#6678.
In some specific timezones and operating systems, it seems that
getTimezoneOffset() can return an incorrect value for negative timestamps, as
described in #5017. While this isn't something easily fixed in the mock code,
the tests can avoid that particular timeframe by using a positive timestamp.
Closes#5017Closes#6730
Originally we destroyed the oldValue by incrementaly copying over portions of the newValue
into the oldValue during dirty-checking, this resulted in oldValue to be equal to newValue
by the time we called the watchCollection listener.
The fix creates a copy of the newValue each time a change is detected and then uses that
copy *the next time* a change is detected.
To make `$watchCollection` behave the same way as `$watch`, during the first iteration
the listener is called with newValue and oldValue being identical.
Since many of the corner-cases are already covered by existing tests, I refactored the
test logging to include oldValue and made the tests more readable.
Closes#2621Closes#5661Closes#5688Closes#6736
`log.empty()` is the same as `log.reset()`, except thati `empty()` also returns the current array with messages
instead of:
```
// do work
expect(log).toEqual(['bar']);
log.reset();
```
do:
```
// do work
expect(log.empty()).toEqual(['bar']);
```
from our experiements it appears that the presense or absense of the from and resolved properties
makes no difference on the behavior of but updates these properties
with different values depending on different state of the cache and node_modules.
So in order to get clean diffs during updates, we are just going to drop these properties and have
a script to do this automatically.
Long term this should be fixed in npm: https://github.com/npm/npm/issues/3581
PR #5547 introduced conversion of all 0 status codes to 404 for cases
where no response was recieved (previously this was done for the
file:// protocol only). But this mechanism is too eager and
masks legitimate cases where status 0 should be returned. This commits
reverts to the previous mechanism of handling 0 status code for the
file:// protocol (converting 0 to 404) while retaining the returned
status code 0 for all the protocols other than file://
Fixes#6074Fixes#6155
The recent $$RAFProvider which is a wrapper for the native
requestAnimationFrame method doesn't use the mozRequestAnimationFrame.
Old versions of FF (20 for example) crash if ngAnimate is included
No breaking changes and fix issue https://github.com/angular/angular.js/issues/6535Closes#6535Closes#6540
We need to be able to build angular at older shas, without the lock file / shrinkwrap file
the dependencies will resolve differently on different machines and at different times.
This will help us avoid broken builds and hard to track down issues.
I had to manually edit this file after it was generated because `npm shrinkwrap` will install
optional dependencies as if they were hard dependencies.
See: https://github.com/npm/npm/issues/2679#issuecomment-37361236
My manual edit:
```
diff --git a/npm-shrinkwrap.json b/npm-shrinkwrap.json
index 756df44..dc157eb 100644
--- a/npm-shrinkwrap.json
+++ b/npm-shrinkwrap.json
@@ -3110,19 +3110,7 @@
"chokidar": {
"version": "0.8.1",
"from": "https://registry.npmjs.org/chokidar/-/chokidar-0.8.1.tgz",
- "resolved": "https://registry.npmjs.org/chokidar/-/chokidar-0.8.1.tgz",
- "dependencies": {
- "fsevents": {
- "version": "0.1.6",
- "from": "fsevents@0.1.6",
- "resolved": "https://registry.npmjs.org/fsevents/-/fsevents-0.1.6.tgz"
- },
- "recursive-readdir": {
- "version": "0.0.2",
- "from": "recursive-readdir@0.0.2",
- "resolved": "https://registry.npmjs.org/recursive-readdir/-/recursive-readdir-0.0.2.tgz"
- }
- }
+ "resolved": "https://registry.npmjs.org/chokidar/-/chokidar-0.8.1.tgz"
},
"glob": {
"version": "3.2.9",
```
Additionally chokidar doesn't list the dependencies above as optional, but that will hopefully
be soon fixed: https://github.com/paulmillr/chokidar/pull/106
In the meantime the patch from the PR above needs to be applied to
node_modules/karma/node_modules/chokidar/package.json before running `npm shrinkwrap`
----
After this change is applied, angular core developers don't need to do anything differently,
except when updating dependencies we need to call `npm update && npm shrinkwrap --dev`
followed by reappling my patch above until npm's bug.
Closes#6653
for an unknown reason the VMs can't connect to local karma, so all builds on Jenkins (ci.angularjs.org)
are failing right now.
Since we want to kill Jenkins anyway, and travis tests on IE, this should not have any
significant impact on us.
Conflicts:
jenkins_build.sh
