Angular.js: Resumen infinito sobre el cambio de ubicación en iOS 9 con UIWebView (no en Safari / WKWebView)
El siguiente HTML simple demuestra el problema:
<!DOCTYPE html>
<html>
<head>
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.3.16/angular.js"></script>
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.3.16/angular-route.js"></script>
<script>
angular.module('fail', ['ngRoute'])
.config(function($routeProvider) {
$routeProvider
.when('/a', {
template: '<a ng-href="#/b">a</a>'
})
.when('/b', {
template: '<a ng-href="#/a">b</a>'
})
.otherwise({
redirectTo: '/a'
});
});
</script>
</head>
<body ng-app="fail">
<div ng-view></div>
</body>
</html>
Esto se ejecuta como se esperaba en la mayoría de los dispositivos, pero arroja una excepción de resumen infinito en iOS 9.
Puedo reproducir tanto en iPad Air 2 como en iPad de cuarta generación con iOS 9 beta 2.
Me doy cuenta de que probablemente sea un problema en iOS, pero aún así podría valer la pena investigarlo.
ttopalov
Todos 154 comentarios
Encontré un problema similar, que sucedió en ios 9, pero funcionó bien en otros dispositivos.
cxm01
en 1 jul. 2015
Reproduje este problema con el mismo código proporcionado por santaslow en 1.4.1 / ios 9:
<!DOCTYPE html>
<html>
<head>
<script src="../static/js/angular/angular.1.4.1.js"></script>
<script src="../static/js/angular-route/angular-route.1.4.1.js"></script>
<script>
angular.module('fail', ['ngRoute'])
.config(function ($routeProvider) {
$routeProvider
.when('/a', {
template: '<a ng-href="#/b">a</a>'
})
.when('/b', {
template: '<a ng-href="#/a">b</a>'
})
.otherwise({
redirectTo: '/a'
});
}).factory('$exceptionHandler', ['$log', function($log) {
return function(exception, cause) {
var message = 'angularjs exception: '+exception.message+': caused by "' + cause+ '\njs stack:\n'+exception.stack;
$log.error(message);
};
}]);
</script>
</head>
<body ng-app="fail">
<div ng-view></div>
</body>
</html>
El código anterior se ejecuta normalmente en el navegador de escritorio, android e ios 8 webview, pero en ios 9 arrojará una excepción cuando hago clic en el enlace:
2015-07-02 11:00:09 ... angularjs exception: [$rootScope:infdig] 10 $digest() iterations reached. Aborting!
Watchers fired in the last 5 iterations: []
http://errors.angularjs.org/1.4.1/$rootScope/infdig?p0=10&p1=%5B%5D: caused by "undefined
js stack:
file:///.../static/js/angular/angular.js:68:32
$digest<strong i="10">@file</strong>:///.../static/js/angular/angular.js:15705:35
$apply<strong i="11">@file</strong>:///.../static/js/angular/angular.js:15935:31
file:///.../static/js/angular/angular.js:12070:30
eventHandler<strong i="12">@file</strong>:///.../static/js/angular/angular.js:3264:25
Ya no puedo reproducir en iOS 9 Beta 3.
ttopalov
en 9 jul. 2015
Recibo el mismo error con la beta pública de ios9 (13A4293g)
aexei
en 11 jul. 2015
Verifiqué el código anterior en ios 9 beta 3 (13A4293g), ya no es una excepción. Pero la aplicación que usa ng-view todavía arroja excepciones de infdig en ios 9 beta 3.
cxm01
en 13 jul. 2015
Recibo el mismo error con la beta pública de ios9 (13A4293g)
Error: [$ rootScope: infdig ] Se
Vigilantes despedidos en las últimas 5 iteraciones: []
http://errors.angularjs.org/1.3.13/ $ rootScope / infdig? p0 = 10 & p1 =% 5B% 5D
file: ///Users/mac5/Library/Developer/CoreSimulator/Devices/749DE7E3-D93F-47F9-A1FC-E3D54A1CCEEE/data/Containers/Bundle/Application/9B5EE368-F2A0-4C99-807B-EA/17B24hops79.awww /lib/ionic/js/ionic.bundle.js:8762:32
$ digest @ file : /// Users / mac5 / Library / Developer / CoreSimulator / Devices / 749DE7E3-D93F-47F9-A1FC-E3D54A1CCEEE / data / Containers / Bundle / Application / 9B5EE368-F2A0-4C99-807B-EA17B2479E58 / BAShops. app / www / lib / ionic / js / ionic.bundle.js: 22980: 35
$ apply @ file : /// Users / mac5 / Library / Developer / CoreSimulator / Devices / 749DE7E3-D93F-47F9-A1FC-E3D54A1CCEEE / data / Containers / Bundle / Application / 9B5EE368-F2A0-4C99-807B-EA17B2479E58 / BAShops. app / www / lib / ionic / js / ionic.bundle.js: 23205: 31
file: ///Users/mac5/Library/Developer/CoreSimulator/Devices/749DE7E3-D93F-47F9-A1FC-E3D54A1CCEEE/data/Containers/Bundle/Application/9B5EE368-F2A0-4C99-807B-EA/17B24hops79.awww /lib/ionic/js/ionic.bundle.js:54879:24
eventHandler @ file :
dispatchEvent @ [código nativo]
triggerMouseEvent @ file :
tapClick @ file : ///Users/mac5/Library/Developer/CoreSimulator/Devices/749DE7E3-D93F-47F9-A1FC-E3D54A1CCEEE/data/Containers/Bundle/Application/9B5EE368-F2A0-4C99BAS2479.app-EA /www/lib/ionic/js/ionic.bundle.js:2852:20
tapTouchEnd @ file :
arkomr
en 13 jul. 2015
También estamos recibiendo este error en la Beta 3 pública de iOS 9 con nuestra propia aplicación Angular. No ocurre en iOS 8.
epaga
en 15 jul. 2015
Como solución alternativa, escribí una directiva simple para reemplazar ng-view y angular-route.js. La solución funcionó bien en nuestra propia aplicación, todas las excepciones de infdig desaparecieron en ios 9 beta / beta 3. A continuación se muestra el código simplificado, que es solo para nuestra propia aplicación, no se consideran los casos de uso general. NO recomiendo a otras personas que utilicen esto:
(function (window) {
'use strict';
var myApp = angular.module("myApp");
var $route = {};
// replace $routeProvider.when with the function below:
window.routeWhen = function(path, route) {
$route[path] = route;
};
myApp.directive("myView", ['$compile', '$controller', '$http', '$rootScope', function ($compile, $controller, $http, $rootScope) {
return {
priority: -400,
link: function (scope, element) {
var parentScope = scope;
scope = null;
window.updateView = function (path) {
location.hash = '#'+url;
if (scope) scope.$destroy();
scope = parentScope.$new();
var route = $route[path];
var linkView = function(html) {
element.html(html);
var link = $compile(element.contents());
var controller = $controller(route.controller, {$scope: scope});
element.data('$ngControllerController', controller);
element.children().data('$ngControllerController', controller);
link(scope);
scope.$emit('$viewContentLoaded');
if (!$rootScope.$$phase && !scope.$$phase) scope.$apply();
};
if (route.templateCache) linkView(route.templateCache)
else if (route.template) {
route.templateCache = document.getElementById(route.template).innerHTML;
linkView(route.templateCache)
}
else $http.get(route.templateUrl;).success(function(html) {
route.templateCache = html;
linkView(html);
});
};
//updateView(initialPath);
// call updateView(path) to set location at other places of the app
}
};
}]);
})(window)
Acabo de instalar iOS 9 Beta 4 y todavía tengo el mismo problema. ¿Alguien mas?
raftheunis87
en 22 jul. 2015
Lo vi en iOS 9 Beta 3 y todavía lo veo en iOS 9 Beta 4.
craig-at-rsg
en 22 jul. 2015
+1
aexei
en 22 jul. 2015
Sí, también estamos viendo el mismo problema incluso con el enrutador de interfaz de usuario angular. ¿Alguien tiene una solución válida para este problema mientras tanto?
vincentdu101
en 29 jul. 2015
Viendo el mismo problema en uiWebView en el último iOS9.
viattik
en 31 jul. 2015
¿Alguien tiene alguna actualización sobre este tema?
raftheunis87
en 3 ago. 2015
Esto sigue siendo un problema. Reapertura
lgalfaso
en 3 ago. 2015
Parece un problema de iOS. ¿Se rastrea esto en algún sitio web?
Narretz
en 4 ago. 2015
+1
mike1e
en 4 ago. 2015
+1
RolfDeVries
en 5 ago. 2015
Aquí igual. Nuestra aplicación Cordova funciona bien si se ejecuta como web en el iPad Safari, pero el resumen infinito ocurre si se ejecuta como una aplicación Cordova (UIWebView).
borrull
en 5 ago. 2015
¡Exactamente los mismos problemas que @borrull ! Ya experimenté con WKWebView y luego el problema no existe. Pero no podemos usar WKWebView ya que necesitamos Servicio de archivos local (y no queremos ejecutar un servidor local en nuestra aplicación) y cookies. Entonces tiene que hacer algo con UIWebView en combinación con Cordova / Mobile Safari en iOS 9. Actualmente estoy depurando $ locationWatch en Angular porque veo que nuestra aplicación quiere hacer la transición a una ubicación diferente varias veces y luego (después de 10 veces ) se lanza el error de resumen.
raftheunis87
en 5 ago. 2015
mismo problema aquí en iOS9 béta4
Bucle $ digest infinito angular; (
axelsegers
en 5 ago. 2015
+1, solo en UIWebView, no en WKWebView pero solo podemos usar UIWebView en nuestra aplicación cordova.
andyverbunt
en 5 ago. 2015
+1
laurentverbruggen
en 5 ago. 2015
Si se trata de un problema específico de iOS, abra un problema en el rastreador de problemas de webkit y proporcione una demostración. Es probable que +1 aquí no cambie nada, ya que realmente suena como un error del navegador.
Narretz
en 5 ago. 2015
¿Alguien informó este error a Apple para su investigación?
aexei
en 6 ago. 2015
Informé este error a Apple. Pero tal vez todos deberían hacer lo mismo para llamar su atención sobre el error.
axelsegers
en 6 ago. 2015
¿Puedes darnos un enlace para que podamos hacer +1?
RolfDeVries
en 6 ago. 2015
Está en nuestra cuenta personal de Apple a través del informe de errores ... así que no hay un enlace público; (
axelsegers
en 6 ago. 2015
¿Podrías publicarlo en openradar y compartir la identificación del rdar para que podamos engañarlo?
epaga
en 6 ago. 2015
lo mismo en iOS9 béta 5:
funciona en safari móvil
funciona en WKWebview que no podemos usar porque no puede servir archivos locales y no es compatible con NSProtocol
NO funciona en UIWebView
axelsegers
en 7 ago. 2015
lo mismo aquí en IOS 9 Beta 5
mk2988
en 7 ago. 2015
También presenté un error a Apple. El enlace de Open Radar es: https://openradar.appspot.com/22186109 (Esto debería ayudar a los perezosos a presentar un error). Deje comentarios si puede mejorar la redacción / explicación del error ;-) Puede descargar el proyecto Xcode para adjuntarlo con la presentación del error en el ticket de Open Radar (Gracias a @santaslow por el JS en el OP)
borrull
en 7 ago. 2015
Creé una versión del mismo proyecto Xcode (de @borrull) pero con ui-router en lugar de ng-route. Exactamente el mismo problema. Para las personas interesadas, pueden encontrar el proyecto aquí: http://s000.tinyupload.com/index.php?file_id=87281871603760127355
raftheunis87
en 7 ago. 2015
También estamos viendo este problema. Pude resolver el problema de que las propiedades de location. * No se actualizan de inmediato cuando angular está en la mezcla. Si intenta asignar un valor a location.hash (como lo que se está haciendo detrás del servicio de ubicación), luego vuelva a leerlo inmediatamente, el valor no ha cambiado. Parece que se producen algunos efectos secundarios como resultado de los controladores jqlite adjuntos a los eventos popstate y hashchanged.
Intentaré subir una muestra cuando esté en una computadora.
CleverCoder
en 7 ago. 2015
+1
abrahamrkj
en 8 ago. 2015
@CleverCoder ¿ Alguna actualización sobre la muestra?
raftheunis87
en 10 ago. 2015
Tendré que terminar el caso de reproducción por la mañana, como el código, ya que he estado atado todo el fin de semana. ¡Gracias por el empujón! Mientras iOS 9 cuenta regresivamente, tenemos un gran interés en que esto se resuelva. Subiré algo tan pronto como pueda.
CleverCoder
en 10 ago. 2015
+1
mk2988
en 10 ago. 2015
He reproducido lo que creo que es la causa raíz, donde la configuración del hash de ubicación o las propiedades href no se "aplican" de inmediato.
Aquí hay un enlace al proyecto XCode:
https://www.dropbox.com/s/2jkwv2thhm86nly/iOS%209%20Location%20Bug.zip?dl=0
Avísame si no puedes acceder al archivo.
Observe el valor resultante en location.hash, además de adjuntar Safari para depurar. Parece que hay algo que difiere el cambio como resultado de algunos eventos de plomería basados en los eventos 'popstate' y 'hashchange'.
Espero que esto sea útil.
- Sean
CleverCoder
en 10 ago. 2015
Estamos usando window.location.href en lugar de state.go y parece estar funcionando por ahora. Menos buggy.
mike1e
en 10 ago. 2015
El valor de location.hash será correcto después de un giro del runloop. Angular puede solucionar fácilmente este problema retrasando location.hash get en un setTimeout (..., 0). Creo que esto sería ~ 2 cambios en angular.js / src / ng / location.js.
hober
en 10 ago. 2015
@hober Probó el tiempo de espera con angular como este:
// update $location when $browser url changes
$browser.onUrlChange(function(newUrl, newState) {
$rootScope.$evalAsync(function() {
var oldUrl = $location.absUrl();
var oldState = $location.$$state;
var defaultPrevented;
$location.$$parse(newUrl);
$location.$$state = newState;
defaultPrevented = $rootScope.$broadcast('$locationChangeStart', newUrl, oldUrl,
newState, oldState).defaultPrevented;
// if the location was changed by a `$locationChangeStart` handler then stop
// processing this location change
if ($location.absUrl() !== newUrl) return;
if (defaultPrevented) {
$location.$$parse(oldUrl);
$location.$$state = oldState;
setTimeout(function(){ setBrowserUrlWithFallback(oldUrl, false, oldState) }, 0);
} else {
initializing = false;
afterLocationChange(oldUrl, oldState);
}
});
if (!$rootScope.$$phase) $rootScope.$digest();
});
y
// update browser
$rootScope.$watch(function $locationWatch() {
var oldUrl = trimEmptyHash($browser.url());
var newUrl = trimEmptyHash($location.absUrl());
var oldState = $browser.state();
var currentReplace = $location.$$replace;
var urlOrStateChanged = oldUrl !== newUrl ||
($location.$$html5 && $sniffer.history && oldState !== $location.$$state);
if (initializing || urlOrStateChanged) {
initializing = false;
$rootScope.$evalAsync(function() {
var newUrl = $location.absUrl();
var defaultPrevented = $rootScope.$broadcast('$locationChangeStart', newUrl, oldUrl,
$location.$$state, oldState).defaultPrevented;
// if the location was changed by a `$locationChangeStart` handler then stop
// processing this location change
if ($location.absUrl() !== newUrl) return;
if (defaultPrevented) {
$location.$$parse(oldUrl);
$location.$$state = oldState;
} else {
if (urlOrStateChanged) {
setTimeout(function(){ setBrowserUrlWithFallback(newUrl, currentReplace,
oldState === $location.$$state ? null : $location.$$state) }, 0);
}
afterLocationChange(oldUrl, oldState);
}
});
}
$location.$$replace = false;
// we don't need to return anything because $evalAsync will make the digest loop dirty when
// there is a change
});
Así que agregué un setTimout alrededor del método setBrowserUrlWithFallback pero no resuelve el problema.
raftheunis87
en 11 ago. 2015
Aquí hay un caso de prueba reducido que no depende de Angular y que demuestra la solución. No me queda claro cómo implementar realmente la solución alternativa en Angular. https://gist.github.com/hober/a29b6c28ac1744c800dd
hober
en 11 ago. 2015
Llegué un poco más lejos en este caso. Hice un cambio en Angular con respecto a la ubicación.
En la parte "actualizar navegador", he cambiado $ rootScope. $ EvalAsync a $ rootScope. $ ApplyAsync.
Los dos métodos parecen hacer exactamente lo mismo. La diferencia no se hace evidente hasta que observa la ejecución real de $ digest. Cuando AngularJS ejecuta un resumen, recorre el árbol de alcance y ejecuta los enlaces $ watch () hasta que no se produzcan más datos sucios. Durante este ciclo de vida, tanto la cola $ applyAsync () como la cola $ evalAsync () se vacían; pero esto sucede en dos lugares muy diferentes.
La cola $ applyAsync () solo se vacía en la parte superior de $ digest antes de que AngularJS comience a buscar datos sucios. Como tal, la cola $ applyAsync () se vaciará, como máximo, una vez durante un $ digest y solo se vaciará si la cola ya estaba llena antes de que comenzara $ digest.
La cola $ evalAsync (), por otro lado, se vacía en la parte superior del bucle while que implementa la "verificación sucia" dentro del $ digest. Esto significa que cualquier expresión agregada a la cola $ evalAsync () durante un resumen se ejecutará en un punto posterior dentro del mismo resumen.
Para hacer esta diferencia más concreta, significa que las expresiones asincrónicas agregadas por $ evalAsync () desde dentro de un enlace $ watch () se ejecutarán en el mismo resumen. Las expresiones asincrónicas agregadas por $ applyAsync () desde dentro de un enlace $ watch () se ejecutarán en un momento posterior (~ 10ms).
Espero que esto ya les ayude a algunos de ustedes :-).
// update browser
$rootScope.$watch(function $locationWatch() {
var oldUrl = trimEmptyHash($browser.url());
var newUrl = trimEmptyHash($location.absUrl());
var oldState = $browser.state();
var currentReplace = $location.$$replace;
var urlOrStateChanged = oldUrl !== newUrl ||
($location.$$html5 && $sniffer.history && oldState !== $location.$$state);
if (initializing || urlOrStateChanged) {
initializing = false;
$rootScope.$applyAsync(function() {
var newUrl = $location.absUrl();
var defaultPrevented = $rootScope.$broadcast('$locationChangeStart', newUrl, oldUrl,
$location.$$state, oldState).defaultPrevented;
// if the location was changed by a `$locationChangeStart` handler then stop
// processing this location change
if ($location.absUrl() !== newUrl) return;
if (defaultPrevented) {
$location.$$parse(oldUrl);
$location.$$state = oldState;
} else {
if (urlOrStateChanged) {
setBrowserUrlWithFallback(newUrl, currentReplace,
oldState === $location.$$state ? null : $location.$$state);
}
afterLocationChange(oldUrl, oldState);
}
});
}
$location.$$replace = false;
// we don't need to return anything because $evalAsync will make the digest loop dirty when
// there is a change
});
Aquí hay otro enfoque. No estoy tan familiarizado con el código base de Angular, pero la lógica parece racional. La función de la URL del navegador (...) depende actualmente de que location.href devuelva inmediatamente la URL correcta. Debido a que este método se llama en el mismo ciclo de ejecución, dentro del ciclo de estabilización $ digest, continúa obteniendo la URL anterior. Este parche aprovecha un 'pendienteHref' para rastrear la asignación, devolviendo ese valor en su lugar, si está configurado. Una vez que el valor se alinea con location.href, se borra el valor pendiente. Durante un conjunto de la URL, se establece un temporizador con 0 ms para detectar el caso en el que no se llama a una URL (). No es perfecto, pero la lógica parece funcionar. Esto es principalmente para considerar un enfoque alternativo que no cree retrasos en el rendimiento. Esto se basa en la etiqueta Angular v1.4.3.
diff --git a/src/ng/browser.js b/src/ng/browser.js
index 928de95..3b9957e 100644
--- a/src/ng/browser.js
+++ b/src/ng/browser.js
@@ -87,7 +87,9 @@ function Browser(window, document, $log, $sniffer) {
var cachedState, lastHistoryState,
lastBrowserUrl = location.href,
baseElement = document.find('base'),
- reloadLocation = null;
+ reloadLocation = null,
+ pendingHref = null,
+ pendingHrefTimer = null;
cacheState();
lastHistoryState = cachedState;
@@ -124,6 +126,18 @@ function Browser(window, document, $log, $sniffer) {
if (location !== window.location) location = window.location;
if (history !== window.history) history = window.history;
+ // Schedule cleaning up pendingHref on the next run loop for setting URL. This is to handle
+ // the case where the browser doesn't update the location.* properties immediately
+ if (!pendingHrefTimer && pendingHref && url) {
+ pendingHrefTimer = setTimeout(function () {
+ if (location.href == pendingHref) {
+ console.log('Actual href updated... setting pendingHref to null from setTimeout');
+ pendingHref = null;
+ }
+ pendingHrefTimer = null;
+ }, 0);
+ }
+
// setter
if (url) {
var sameState = lastHistoryState === state;
@@ -147,6 +161,7 @@ function Browser(window, document, $log, $sniffer) {
// Do the assignment again so that those two variables are referentially identical.
lastHistoryState = cachedState;
} else {
+ pendingHref = url;
if (!sameBase || reloadLocation) {
reloadLocation = url;
}
@@ -161,10 +176,22 @@ function Browser(window, document, $log, $sniffer) {
return self;
// getter
} else {
+ var href = location.href.replace(/%27/g, "'");
+ if (pendingHref) {
+ //console.log('.. using pendingHref for url() return value');
+ href = pendingHref;
+ }
+
+ if (location.href == pendingHref) {
+ console.log('Actual href updated... setting pendingHref to null in getter');
+ pendingHref = null;
+ }
+
+ //var href = location.href.replace(/%27/g,"'");
// - reloadLocation is needed as browsers don't allow to read out
// the new location.href if a reload happened.
// - the replacement is a workaround for https://bugzilla.mozilla.org/show_bug.cgi?id=407172
- return reloadLocation || location.href.replace(/%27/g,"'");
+ return reloadLocation || href;
}
};
¡Gracias @CleverCoder por la solución! ¡Parece funcionar a las mil maravillas! : +1:
raftheunis87
en 14 ago. 2015
@CleverCoder
Sería genial si realiza una solicitud de extracción con esto para el equipo angular.
viattik
en 14 ago. 2015
@viattik Me sorprendería un poco si el equipo angular adoptara una solución alternativa para UIWebView en iOS9, ya que el error está en UIWebView (Apple). Pero siempre puedes intentar ...
raftheunis87
en 14 ago. 2015
@ raftheunis87
Hay muchos errores en diferentes navegadores y muchas soluciones para esos errores en el código angular.
Aunque no son oficialmente compatibles con UIWebView, muchas aplicaciones híbridas se romperán y el uso de angular será imposible en las aplicaciones híbridas en el último iOS hasta que Apple corrija ese error. Y ese es un problema bastante importante, diría yo.
Así que lo probaría.
viattik
en 14 ago. 2015
@viattik Estoy totalmente de acuerdo. Y por cierto: Apple nos comunicó que es poco probable que solucionen el error de UIWebView. Entonces, de hecho: pruébalo ;-)
raftheunis87
en 14 ago. 2015
Amigos, si pudieran publicar esto como un error de webkit, idealmente con un caso de reproducción, haré un seguimiento con algunos de nuestros contactos en el lado de WebKit. https://bugs.webkit.org/
naomiblack
en 14 ago. 2015
@naomiblack
No estoy seguro si es un error de webkit. Porque solo sucede en UIWebView en iOS9. Safari en iOS9 funciona bien.
viattik
en 14 ago. 2015
@ raftheunis87 gracias por sus sugerencias de código, funcionó perfectamente
ajrmspwd
en 14 ago. 2015
@ raftheunis87 @CleverCoder es una forma de trabajar con ionic-angular? ¿Puedes ser mas específico?
abrahamrkj
en 15 ago. 2015
@abrahamrkj No tengo ninguna experiencia con ionic. ¿Pero sus personalizaciones son angulares cuando se usa iónico? De lo contrario, diría que la misma solución funcionaría con ionic-angular ...
raftheunis87
en 15 ago. 2015
@ raftheunis87 https://github.com/driftyco/ionic/tree/master/js este es el angular que están usando.
abrahamrkj
en 15 ago. 2015
@CleverCoder +1 para la solicitud de extracción. Estoy de acuerdo con @viattik en que este es un tema importante, ya que romperá muchas aplicaciones híbridas.
borrull
en 17 ago. 2015
Una solicitud de extracción puede ser en un futuro cercano, aunque dudo ya que no estoy tan cerca de la base de código Angular como otros. Revisaré la solución pronto y trataré de que sea a prueba de balas. Parece extraño que una propiedad en el objeto window.location no cambie 'inmediatamente'. En las pruebas que hice, noté que el cambio se mantuvo siempre que los ganchos de eventos 'popstate' y 'hashchange' no estuvieran en su lugar, lo que me llevó a pensar que la causa del cambio diferido en realidad puede ser hacer algo. más ... Quizás el momento de esos eventos ha cambiado (creo que eso es lo que estaba observando).
Voy a ver esto durante los próximos días, y si no surge nada mejor, profundizaré un poco más para confirmar lo que sé hasta ahora y que no hay un mejor lugar para abordar el cambio de comportamiento. Perdón si esto es confuso. Están sucediendo muchas cosas bajo el capó que todavía no entiendo completamente con respecto a esos eventos.
¡Salud!
CleverCoder
en 17 ago. 2015
... y sí, @borrull , estoy de acuerdo. Si Apple no hace más cambios, entonces esta es una bomba de tiempo seria que realmente conducirá a una mala prensa y a señalar con el dedo. No soy un fanático de los temporizadores como solución alternativa (preferiría haber mejorado el flujo lógico en torno a estas propiedades integradas), pero si no podemos depender de que el valor cambie una vez que esté configurado, ¿dónde dibujamos el ¿línea? ¿En qué otras propiedades no podemos confiar? Es extraño.
CleverCoder
en 17 ago. 2015
@CleverCoder Solo quería
tfujii
en 18 ago. 2015
@CleverCoder Gracias por la solución proporcionada.
Derivé una solución que usa la función decoradora de angular y viene sin parchear la fuente angular.
Con cssua, esta configuración se puede configurar para usarse solo en entornos específicos.
app.config(['$provide', ($provide) => {
$provide.decorator('$browser', ['$delegate', ($delegate) => {
var origUrl = $delegate.url;
var pendingHref = null;
var pendingHrefTimer = null;
var newUrl = function (url, replace, state) {
if (url) {
// setter
var result = origUrl(url, replace, state);
if (window.location.href != url) {
if (pendingHref != url) {
pendingHref = url;
if (pendingHrefTimer) clearTimeout(pendingHrefTimer);
pendingHrefTimer = setTimeout(function () {
if (window.location.href == pendingHref) {
pendingHref = null;
}
pendingHrefTimer = null;
}, 0);
}
}
return result;
} else {
// getter
if (pendingHref == window.location.href) {
pendingHref = null;
}
return pendingHref || origUrl(url, replace, state);
}
};
$delegate.url = newUrl;
return $delegate;
}]);
}]);
realityfilter
en 20 ago. 2015
@CleverCoder Ver # 12635
jd-carroll
en 20 ago. 2015
@ jd-carroll: Eso es realmente interesante. Podría volver a visitar esto un poco más tarde hoy, cuando tenga tiempo. Bastante inundado de cosas. Eso solo crea más misterio, ya que parece un problema separado que no debería introducir un retraso en la actualización de los valores de location. *.
@realityfilter : Es curioso que menciones al decorador ... Acabo de terminar de implementar algo usando la funcionalidad del decorador angular. ¡Lindo!
CleverCoder
en 20 ago. 2015
Oigan todos,
Solo quería agregar que esta corrección introdujo un error en nuestro código que fue fácil de corregir.
Nuestras plantillas tenían etiquetas de anclaje que usaban href = "#" y ng-click = "someCall ()". El href estaba provocando que el sitio fuera a index.html usando esta corrección. Eliminar el href solucionó el problema.
jyc66
en 20 ago. 2015
Nuestra aplicación se rompe durante la navegación del botón Atrás en Ionic, primero va a la nueva vista, luego regresa parcialmente a la vista anterior y luego vuelve a la nueva vista en IOS9 beta cualquier resolución para Ionic
ajaybeniwal
en 21 ago. 2015
El mismo problema con iOS 9 beta 5 13A4325c, Angular 1.4.0 (con cordova-ios 3.9.1). ¡Con suerte, se solucionará el error subyacente de UIWebView!
aderowbotham
en 31 ago. 2015
El mismo problema ocurre en Angular v1.2.27
markoivanovski
en 1 sept. 2015
Lo he rastreado hasta la versión 1.2.27, el error no está en la versión 1.2.26 anterior.
Específicamente, este compromiso es el culpable.
damrbaby
en 3 sept. 2015
@damrbaby Parece que podría tener algo que ver con eso.
Pero el hecho de que esté trabajando con la última versión de angular en Mobile Safari aclara que tiene que ver algo con uiWebView en iOS 9. Por lo tanto, el cambio que hicieron en el código fuente de Angular no es necesariamente algo malo.
raftheunis87
en 3 sept. 2015
@CleverCoder @realityfilter @ jyc66 Solo quería darte las gracias, acabas de salvarme el día.
Kira2
en 9 sept. 2015
El problema sigue presente en iOS9 GM Seed, ¡así que actualice sus aplicaciones!
markoivanovski
en 9 sept. 2015
Puedo confirmar que el problema sigue presente en iOS9 GM (13A340)
richardbrammer
en 10 sept. 2015
Entonces, esto significa que Apple rompió algo y tenemos que actualizar nuestras aplicaciones nuevamente (algunas de las cuales no han cambiado durante meses o incluso más de un año) para evitar que se bloqueen. Tiene sentido :(. Preferiría que Apple lo arreglara para los lanzamientos de iOS9. Ir a la última versión de Angular en una aplicación antigua seguramente romperá algunas otras cosas también.
Dudo mucho que Angular sea el único marco que tiene problemas con iOS9.
Martinspire
en 10 sept. 2015
Entonces, @adamdbradley , @perrygovier y @mhartington del equipo Ionic han estado trabajando todo el día en una solución que funcionará para Ionic y también para aplicaciones simples de Angular. El objetivo es ser una solución inmediata que no requiera modificar Angular y (con suerte) funcionará en la mayoría de las versiones 1.2+ Angular.
Aquí está nuestra solución empaquetada actual que decora y corrige $browser aplicando este parche . Nota: esto se basa en Angular 1.4.3 y es una especie de "clon con correcciones" de browser.js de Angular propiamente dicho: https://github.com/driftyco/ionic/blob/ios9-patch/js /angular/service/decorators/ios9-browser-fix.js
También colocamos el parche en nuestro CDN. No recomiendo usar el archivo CDN para la producción, solo está allí, por lo que es más fácil de probar en este momento.
Para probarlo, coloque esta etiqueta de secuencia de comandos debajo de su archivo angular o ionic.bundle.js:
<script src="https://code.ionicframework.com/patch/ios9-$browser-patch.js"></script>
Además, ahora mismo aplica el parche ya sea que esté ejecutando iOS9 o no. Eso pronto se solucionará de modo que solo se ejecute en iOS 9 UIWebView.
Siga el problema Ionic correspondiente aquí: https://github.com/driftyco/ionic/issues/4082#issuecomment -139079725
mlynch
en 10 sept. 2015
Hola todos,
UI-sref funciona a la perfección, pero $ state.go rompe la animación del botón de retroceso
y la página parpadea mucho incluso después de aplicar esta corrección.
Saludos,
Ajay Singh
El jueves 10 de septiembre de 2015 a las 6:23 a. M., Max Lynch [email protected] escribió:
Entonces, @adamdbradley https://github.com/adamdbradley , @perrygovier
https://github.com/perrygovier y @mhartington
https://github.com/mhartington del equipo Ionic han estado trabajando
todo el día en una solución que funcionará para Ionic y para aplicaciones simples de Angular como
bien. El objetivo es ser una solución inmediata que no requiera modificaciones.
Angular, y (con suerte) funcionará en la mayoría de las versiones 1.2+ Angular.Aquí está nuestra solución empaquetada actual que decora y corrige $ browser por
aplicando este parche
https://github.com/angular/angular.js/issues/12241#issuecomment -130744518.
Nota: esto se basa en Angular 1.4.3 y es una especie de "clon con correcciones" de
browser.js de Angular propiamente dicho:
https://github.com/driftyco/ionic/blob/ios9-patch/js/angular/service/decorators/ios9-browser-fix.jsTambién colocamos el parche en nuestro CDN. No recomiendo usar el archivo CDN
para la producción, solo está ahí, por lo que es más fácil probarlo ahora mismo.Pruébelo y háganos saber cómo va, gracias.
Para probarlo, coloque esta etiqueta de secuencia de comandos debajo de su angular o
Archivo ionic.bundle.js:Also, right now it applies the patch whether you're running on iOS9 or
not. That will soon be fixed such that it runs only on the iOS 9 UIWebView.—
Reply to this email directly or view it on GitHub
https://github.com/angular/angular.js/issues/12241#issuecomment-139082474
.
ajaybeniwal
en 10 sept. 2015
Puedo confirmar que este error todavía está presente en iOS 9.1 Beta 1
hmrc87
en 10 sept. 2015
Usamos mucho $state.go y todavía está parpadeando entre estados / no está haciendo la transición correctamente.
tcrammond
en 10 sept. 2015
Lo siento, la solución funciona para nuestra aplicación ahora, lo único que necesitamos es incluir https
El enlace CND en lugar de http CDN parece que ios9 solo permite https dentro del
aplicación, así que después de usar https, nuestra aplicación funcionó.
https://code.ionicframework.com/patch/ios9- $ browser-patch.js
El jueves 10 de septiembre de 2015 a las 3:22 p.m., Tyler Crammond Notifications@github.com
escribió:
Usamos mucho $ state.go y todavía está parpadeando entre estados / no
haciendo la transición correctamente.-
Responda a este correo electrónico directamente o véalo en GitHub
https://github.com/angular/angular.js/issues/12241#issuecomment -139189216
.
ajaybeniwal
en 10 sept. 2015
ios9- $ browser-patch.js también me funciona. Pero genera algunos errores de jshint. ¿Hay alguna forma de contribuir al parche para ayudar a eliminar los errores?
richardbrammer
en 10 sept. 2015
No creo que este parche sea del todo correcto, ya que no le permite actualizar la ubicación desde fuera de Angular. Probablemente esto no sea un problema para la mayoría de las aplicaciones, pero estamos trabajando para ver si hay una solución mejor ...
petebacondarwin
en 10 sept. 2015
ios9- $ browser-patch.js no funcionó para mí. Cuando me muevo de mi vista de lista a una vista de detalle, uso $ state.go () para moverme entre las páginas. La primera vez que hago esto, se desliza hacia el otro lado y luego hacia atrás, luego hago clic de nuevo y funciona. UI-sref funciona como se desea, pero no me permitirá hacer la lógica condicional que necesito hacer.
jeverington
en 10 sept. 2015
Desafortunadamente, descargar el parche, almacenarlo y cargarlo desde ./lib/ (verifiqué que esté cargado), no cambió nada para mí:
Error: [$rootScope:infdig] 10 $digest() iterations reached. Aborting!
Watchers fired in the last 5 iterations: []
http://errors.angularjs.org/1.3.13/$rootScope/infdig?p0=10&p1=%5B%5D
iOS 9 GM, iónico 1.0.0.
jorisw
en 10 sept. 2015
Jorisw, intente deshabilitar el código de detección de ios9 y vea si funciona:
var isIOS9 = (navigator.userAgent.indexOf ('Versión / 9.')! = -1) && (navigator.appVersion.indexOf ('9_0')! = -1);
if (! isIOS9) {
// no parchear si no es iOS9 UIWebView
return $ navegador;
}
jyc66
en 10 sept. 2015
@ jyc66 Eso funciona, gracias. ¿Cómo me aseguro de que no rompa iOS <9?
jorisw
en 10 sept. 2015
El método isIOS9 es defectuoso. Debe comprobarse con:
> navigator.userAgent
< "Mozilla/5.0 (iPhone; CPU iPhone OS 9_0 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/13A340 (2065230368)" = $1
> navigator.appVersion
< "5.0 (iPhone; CPU iPhone OS 9_0 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/13A340 (2065230368)" = $2
Sí, alternativamente, puede probar el sistema operativo menos de 9 y deshabilitar la solución en esos casos. La verificación actual se romperá en iOS 9.1, que también saldrá pronto.
jyc66
en 10 sept. 2015
Estoy haciendo esto ahora, hasta que a mí oa alguien se le ocurra una mejor:
// only provide the patch for iOS9 on UIWebView
var isIOS9 = (navigator.userAgent.indexOf(' OS 9') != -1) && (navigator.appVersion.indexOf(' OS 9') != -1);
if (!isIOS9) {
// do not patch if not iOS9 UIWebView
return $browser;
}
Sí, eso es similar a lo que estoy haciendo.
jyc66
en 10 sept. 2015
¿Alguien sabe si la aplicación del parche a las versiones de iOS> = 9.0 causará problemas si / cuando Apple solucione el problema en una versión posterior de iOS?
JeremyPlease
en 10 sept. 2015
@JeremyPor favor , estoy cargando 9.1 beta ahora mismo y lo comprobaré
mhartington
en 10 sept. 2015
Funcionó para mí cuando desactivé la verificación del agente de usuario, sirviendo el parche como parte del paquete minificado. Es una aplicación angular no iónica. Investigaré más a fondo esta noche y me aseguraremos de que todo funcione como se esperaba.
¡Gracias al equipo iónico por el esfuerzo!
dac09
en 10 sept. 2015
Así que la versión 9.1 beta uno aún no tiene la solución. No sorprendido.
mhartington
en 10 sept. 2015
Esto puede parecer extraño, pero ¿alguien ve que la función String.split () no funciona correctamente cuando se aplica el parche en iOS 9? (probado hasta ahora solo en simulador). Aquí hay una captura de pantalla del depurador de Safari: https://www.dropbox.com/s/hxgct9y0f9z6yci/Screenshot%202015-09-11%2000.40.26.png?dl=0
¡Estoy perplejo! Funciona bien en iOS8.4 y Chrome, por supuesto.
Actualización : String.split no parece funcionar en el simulador de iOS 9 iPhone 6 y 6s para mí, nada que ver con el parche.
Por cierto, esto es lo que usé para la verificación del agente de usuario:
var isIOS9WebView = (navigator.userAgent.indexOf('Safari') === -1) && (navigator.appVersion.indexOf('OS 9') !== -1);
if (!isIOS9WebView) {
// do not patch if not iOS9 UIWebView
return $browser;
}
Creo que la mejor solución tal vez sea en la solicitud de extracción de Igor, pero esto funciona para mí sin aplicar el parche en iOS 9 Safari, sino solo en UIWebView.
dac09
en 11 sept. 2015
@ dac09 Quiero probar su commet, pero no sé qué archivo tiene que modificar ...
¿U puede decirme qué archivo tiene que modificar?
joinsik
en 11 sept. 2015
Estoy usando el parche de @CleverCoder , en el que se basa el parche de ionic, sin una restricción de que deba ejecutarse en iOS9 UIWebView únicamente, y no tiene consecuencias en UIWebView iOS8, safari o Android para el caso.
damrbaby
en 11 sept. 2015
Hola amigos, ¿pueden probar este parche? Https://gist.github.com/IgorMinar/863acd413e3925bf282c
Debería funcionar con Angular 1.2 - 1.4.5 y no requiere actualizaciones de Angular. Las instrucciones sobre cómo aplicar esto a su aplicación están en la esencia.
Vamos a tener una solución adecuada en 1.4.6, pero mientras tanto, este parche independiente está destinado a facilitar la implementación y la implementación de una solución para que pueda implementarla rápidamente.
IgorMinar
en 11 sept. 2015
Hola @IgorMinar : recibo el siguiente error en mi implementación de Angular 1.3 (Ionic beta-14). No creo que el método .decorator esté disponible en el módulo 1.3.
Uncaught TypeError: angular.module (...). Decorator no es una función (función anónima) @ angular-ios9-uiwebview.patch.js: 33
rajatrocks
en 11 sept. 2015
@rajatrocks uhh .. buen punto. module.decorator es solo una característica 1.4. déjame cambiar el parche.
IgorMinar
en 11 sept. 2015
@rajatrocks Actualicé la esencia
IgorMinar
en 11 sept. 2015
Gracias @IgorMinar , "instala" bien ahora. Dejaré mis comentarios en el hilo de Ionic ya que están más relacionados con eso.
rajatrocks
en 11 sept. 2015
@IgorMinar He incluido su archivo js y agrego lo siguiente en mi app.js. No soluciona mi problema.
jprangenbergde
en 11 sept. 2015
@IgorMinar Tu parche no solucionó mi problema, pero el de @mlynch sí.
Para asegurarme de que solo se aplique a la plataforma iOS, he creado un simple gancho de Cordova:
https://gist.github.com/DURK/f2acd6bca4759e719801
Actualización : Ah, veo que el parche ahora contiene una marca de verificación, por lo que solo se aplica en iOS9.
DURK
en 11 sept. 2015
@IgorMinar Siguiendo con lo que informaron @DURK y @jprangenberg , parece haber un problema con la función "isIOS9UIWebView" cuando se prueba en un iPad Air 2. Si fuerzo la aplicación de la calza siempre, el parche funciona.
tfujii
en 11 sept. 2015
De mi comentario en: https://github.com/driftyco/ionic/issues/4082#issuecomment -139567128
@IgorMinar , su parche funciona muy bien en iOS 9 iPhone UIWebView, pero hay algunos problemas con la detección de agentes de usuario para iPad.
Agente de usuario de iPhone iOS 9 en UIWebView:
Mozilla/5.0 (iPhone; CPU iPhone OS 9_0 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/13A340
Agente de usuario de iPad iOS 9 en UIWebView:
Mozilla/5.0 (iPad; CPU OS 9_0 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/13A340
La expresión regular que coincidirá de manera confiable con todos estos es:
function isIOS9UIWebView(userAgent) {
return /(iPhone|iPad|iPod);.*OS 9_\d/.test(userAgent) && !/Version\/9\./.test(userAgent);
}
He bifurcado la esencia de @IgorMinar e hice los cambios aquí: https://gist.github.com/JeremyPlease/72cb3bf98279fefed4e3
JeremyPlease
en 11 sept. 2015
El gancho
IgorMinar
en 11 sept. 2015
@JeremyPlease Safari en iOS9 no se ve afectado. realmente queremos aplicar el parche solo cuando estamos en UIWebView.
IgorMinar
en 11 sept. 2015
@JeremyPlease Safari iOS 9 no es el problema, por lo que la comprobación de
Funciona muy bien para mi.
dac09
en 11 sept. 2015
Me di cuenta de que esto es solo un problema en UIWebView, así que actualicé mi esencia para que no se aplique cuando estoy en Safari:
function isIOS9UIWebView(userAgent) {
return /(iPhone|iPad|iPod);.*OS 9_\d/.test(userAgent) && !/Version\/9\./.test(userAgent);
}
Publiqué v1.0.3 del parche
IgorMinar
en 11 sept. 2015
@IgorMinar ¿Esta solución simplemente funciona, si usa ngRoute? La solución no funciona para mí… :-(
jprangenbergde
en 11 sept. 2015
@jprangenberg sí. mi aplicación con ngroute funciona bien en iphone / ipad. ¿puedes darme mas detalles? también asegúrese de que está utilizando v1.0.3 + del parche
IgorMinar
en 11 sept. 2015
@IgorMinar La versión 1.0.3 del parche funciona correctamente en mi entorno.
tfujii
en 11 sept. 2015
index.html:
<script src="lib/ionic/js/ionic.bundle.js"></script>
<script src="lib/ngCordova/dist/ng-cordova.min.js"></script>
<script src="js/libs/angular-ios9-uiwebview.patch.js"></script>
app.js:
angular.module('starter', [
'ionic',
'ngCordova',
'ngIOS9UIWebViewPatch',
'ionic.service.core',
'ionic.service.push',
'angular-loading-bar',
'starter.services',
'starter.controllers'
])
app.js (Ruta):
$stateProvider.state('app.regions', {
cache: false,
url: "/states/:state_id/regions",
views: {
'menuContent': {
templateUrl: "templates/regions.html",
controller: 'RegionsCtrl'
}
}
})
No es posible navegar por la aplicación. Si hace clic en un elemento de la lista, verá la vista actual. El botón de historial cambia. Si hace clic en el botón de historial, puede ver la vista del clic en el elemento de la lista.
<ion-list>
<ion-item ng-repeat="state in states" href="#/app/states/{{state.id}}/regions">
{{state.name}}
</ion-item>
</ion-list>
@IgorMinar No me funciona. ¿Alguien tiene alguna idea?
jprangenbergde
en 11 sept. 2015
@jprangenberg, ¿está utilizando la versión parcheada del paquete Ionic o una versión?
perrygovier
en 11 sept. 2015
@perrygovier Estoy usando la versión 1.0.3 de @IgorMinar
jprangenbergde
en 11 sept. 2015
@jprangenberg correcto, pero el ionic.bundle.js. ¿Qué versión es esa?
perrygovier
en 11 sept. 2015
Versión de mi ionic.bundle.js:
window.ionic.version = '1.0.0';
@perrygovier ¡ Gracias por tu ayuda!
jprangenbergde
en 11 sept. 2015
Por curiosidad, ¿ayuda el uso de la versión 1.1.0 del paquete?
http://code.ionicframework.com/1.1.0/js/ionic.bundle.min.js
Probablemente también necesite el CSS actualizado
http://code.ionicframework.com/1.1.0/css/ionic.min.css
perrygovier
en 11 sept. 2015
Hola @jprangenberg , mientras todos estamos trabajando juntos en esto, continuemos con esta discusión relacionada con iónica sobre el tema iónico para que no enviemos spam a los usuarios angulares habituales driftyco / ionic # 4082
perrygovier
en 11 sept. 2015
Entonces, ¿este error no afecta a WKWEBVIEW cuando se usa https://github.com/Telerik-Verified-Plugins/WKWebView ?
jason-engage
en 11 sept. 2015
El error solo está en UIWebView de iOS 9. No está presente cuando se usa WKWebView.
perrygovier
en 11 sept. 2015
Gracias por su trabajo en esto, chicos, pero desafortunadamente no me está funcionando. Recibo animaciones rotas, páginas que no se cargan en absoluto, páginas que no se cargan correctamente, básicamente el enrutador es completamente inestable.
Estoy usando el paquete Ionic 1.1.0 y iOS 9.1 en un iPhone 6, junto con el archivo de parche en https://code.ionicframework.com/patch/ios9- $ browser-patch.js. Veo errores como este:
Error: [$ rootScope: infdig ] Se
Vigilantes despedidos en las últimas 5 iteraciones: []
¿Alguna sugerencia?
¡Gracias!
scottopolis
en 11 sept. 2015
@scottopolis , https://gist.github.com/IgorMinar/863acd413e3925bf282c
petebacondarwin
en 11 sept. 2015
@petebacondarwin ya gracias, el parche de Igor funciona para mí. Mis animaciones de transición de página están entrecortadas, pero el enrutador parece estar arreglado. Estaré atento a este problema.
scottopolis
en 11 sept. 2015
Algunas pruebas aquí y el parche de @IgorMinar están causando problemas con las animaciones y los controladores del botón Atrás. Veo el controlador de la pantalla que estoy evitando que se vuelva a crear cuando hago clic en Atrás. Esto hace que las animaciones se ejecuten en esa vista mientras se navega fuera de la pantalla, todo tipo de cosas raras.
Hasta ahora, no veo problemas con el uso nocturno de iónico, pero actualizando la detección de iOS9.
var userAgent = navigator.userAgent,
isIOS9 = /(iPhone|iPad|iPod).* OS 9_\d/.test(userAgent) && !/Version\/9\./.test(userAgent);
aphex
en 11 sept. 2015
Acabo de enviar la versión 1.1.0 del parche: https://gist.github.com/IgorMinar/863acd413e3925bf282c
Junto con el equipo iónico, ya no podemos reproducir ningún parpadeo con esta versión del parche.
Actualice y avísenos si ve más problemas. (también asegúrese de que no está utilizando ningún otro parche para este problema además de la v1.1.0 del parche).
Aterrizaremos una solución en el maestro la próxima semana, por lo que Angular v1.4.6 ya no necesita ser parcheado.
IgorMinar
en 12 sept. 2015
Esta nueva versión del parche me está funcionando perfectamente. ¡Gracias @IgorMinar!
scottopolis
en 12 sept. 2015
¿La versión 1.4.6 soluciona este problema para siempre?
alexislg2
en 18 sept. 2015
@ alexislg2 : sí, esta versión debería solucionar el problema, por lo que no es necesario que aplique el parche.
petebacondarwin
en 18 sept. 2015
Confirmado, funciona para mí en el simulador y el dispositivo, solo necesito que mis usuarios esperen 2 semanas para la aprobación de Apple ;-(
dbroadhurst
en 18 sept. 2015
@dbroadhurst Escuché que es posible que pueda citar el informe de error https://openradar.appspot.com/22186109 para acelerar la actualización de su aplicación.
petebacondarwin
en 18 sept. 2015
Puede seguir este error de WebKit para obtener actualizaciones.
hober
en 22 sept. 2015
Hola, parece que has resuelto el problema de la llamada asíncrona de iOS9 en el cambio de hash en Angular.js.
Hice investigaciones, también las publiqué en stackoverflow, pero la única solución que encontré hasta ahora está en su parche angular browser.js.
No estoy realmente familiarizado con angular y me gustaría entender qué hizo que arreglara disponible en
cada aplicación web basada en Hash Routing
¿Podría explicar cómo identificó y solucionó el problema?
lchenneberg
en 25 sept. 2015
@lchenneberg : la confirmación que soluciona el problema en AngularJS está aquí https://github.com/angular/angular.js/commit/8d39bd8abf423517b5bff70137c2a29e32bff76d
El problema es que este navegador en particular no actualiza el valor de window.location.href hasta la próxima ejecución del bucle de eventos de JavaScript. Esto significa que si escribe en ese valor y luego lo vuelve a leer inmediatamente, obtiene un valor diferente:
console.log(window.location.href) // -> http://my.domain.com/path/to/page
window.location.href = 'http://my.domain.com/path/to/other/page';
console.log(window.location.href) // -> http://my.domain.com/path/to/page
// next tick of the event loop
console.log(window.location.href) // -> http://my.domain.com/path/to/other/page
Observe que el segundo console.log devuelve el valor anterior, no el nuevo. Una vez que se completa el ciclo de eventos actual, el valor se actualiza, como se puede ver en el tercer console.log
La solución que hemos encontrado es almacenar en caché el valor que escribimos, si el navegador no se actualiza de forma síncrona, y luego usar ese valor a partir de ese momento, en lugar del valor devuelto desde window.location.href , hasta hay un evento hashchange , que nos dice que el navegador finalmente se ha solucionado.
Espero que ayude.
petebacondarwin
en 25 sept. 2015
El parche de @IgorMinar funcionó bien para mí. Estoy usando las siguientes versiones de Angular & Ionic:
window.ionic.version "1.0.1"
angular.version
Object {full: "1.3.13", major: 1, minor: 3, dot: 13, codeName: "meticulous-riffleshuffle"}
jasdeepsingh
en 30 sept. 2015
El parche de @IgorMinar también nos funcionó. ¡¡Gracias!!
Pero tengo otra pregunta que uno de ustedes podría responder:
O, lo que es más importante, ¿acceder a una aplicación web de esta manera aprovecha el motor de renderizado Nitro?
tpeiffer
en 1 oct. 2015
@tpeiffer usarían wkwebview, ya que es solo un safari sin la barra de direcciones.
mhartington
en 1 oct. 2015
Hola, tengo exactamente el mismo problema con una versión anterior de angular: 1.0.6
Veo que todas las correcciones son para versiones más nuevas, ¿sabe dónde debería buscar para ver si puedo solucionar este problema? Gracias.
tzamora
en 2 oct. 2015
@tzamora ¿Has probado a aplicar el parche de @IgorMinar ? Quizás 1.0.6 sea demasiado pronto para que funcione.
petebacondarwin
en 2 oct. 2015
@petebacondarwin el parche de @IgorMinar se refiere a un archivo llamado browser.js. No tengo ningún archivo llamado browser.js
tzamora
en 2 oct. 2015
Para su información, una solución para el problema subyacente aterrizó en WebKit el otro día:
http://trac.webkit.org/changeset/190092
http://trac.webkit.org/changeset/190100
hober
en 2 oct. 2015
Conseguí que esto funcionara con el parche js, pero no de inmediato. Nuevo en esto (angularjs e Ionic), así que si alguien pudiera verificar esto y hacerme saber si me he perdido algo importante, ¡realmente lo agradecería! (por ejemplo, el objeto de la plataforma es muy ineficiente, etc.)
Nota:
- Descargué el ios9- $ browser-patch.js local
- Descubrí que no resolvió mi problema, pero forzar a isIOS9UIWebView a devolver verdadero, funcionó muy bien
- Reescribí la verificación de parches usando métodos de la plataforma Ionic, que ahora funciona bien. (He dejado el código antiguo comentado aquí para mostrar la evolución)
function isIOS9UIWebView(userAgent) {
return (/9\.[0-9]\.[0-9]/.test(ionic.Platform.version()) && /iOS/.test(ionic.Platform.device() ));
//return true;
//return (navigator.userAgent.indexOf(' OS 9') != -1) && (navigator.appVersion.indexOf(' OS 9') != -1);
//return /(iPhone|iPad|iPod).* OS 9_\d/.test(userAgent) && !/Version\/9\./.test(userAgent);
// only provide the patch for iOS9 on UIWebView
}
var1ableX
en 5 oct. 2015
Me encontré con este problema en 8.4 en el simulador; así que no creo que se limite solo a iOS 9. Acabo de actualizar la verificación de la cadena del agente para incluir las versiones iOS 8 y 9. Aquí está la cadena del agente.
"Mozilla / 5.0 (iPhone; CPU iPhone OS 8_4 como Mac OS X) AppleWebKit / 600.1.4 (KHTML, como Gecko) Mobile / 12H141 (140307121489296)"
scott-phillips-sp
en 6 oct. 2015
+1
StevenStar
en 20 oct. 2015
Hola
¿Alguien puede confirmar si esto se resolvió en ios 9.2? (beta)
Gracias :)
FreudGit
en 11 nov. 2015
No puedo replicar el problema a partir de esta actualización de la mañana a iOS 9.2 (13C75) en el iPhone 6. Se ve bien hasta ahora. Sin embargo, este error aún está abierto: https://openradar.appspot.com/22186109
mrowles
en 10 dic. 2015
Si se aplica este parche, ¿podría tener algún efecto negativo en iOS 9.2 y versiones posteriores? Probaré esto con nuestra propia aplicación, pero quiero asegurarme de no presentar problemas que no se muestren al probar nuestra situación particular.
Por lo que puedo ver, todos los parches usan una expresión regular que filtra iOS 9 en adelante, pero no específicamente 9.x hasta 9.1 inclusive.
martijntraa
en 21 dic. 2015
Hola chicos, este problema está sucediendo actualmente en iPhone 6 con iOS 9, ¿alguien puede decirme por qué?
https://forum.ionicframework.com/t/ios-9-beta-slide-menu-app-transition-issue/30768
¿Hay otro parche que debo aplicar? Por favor, avíseme, realmente necesito solucionar ese problema de superposición de pantalla.
bruno-serfe
en 21 dic. 2015
La actualización a iOS 9.2 parece resolverlo para mí también.
brechtcs
en 21 dic. 2015
@ bruno-serfe, este es un problema sobre cómo iOS maneja window.location que está presente solo en iOS 9.0.x. Si puede actualizar a Angular 1.4.6+, entonces no hay nada más que tenga que hacer ya que esta versión contiene la solución. Si no puede actualizar, el parche en https://github.com/angular/angular.js/issues/12241#issuecomment -139446288 tiene la misma solución.
Como se indicó anteriormente, este problema solo está presente en iOS 9.0.x, ya que se solucionó en iOS 9.1.0.
El problema publicado en ionic parece el mismo problema, por lo que la misma solución debería funcionar en ambos sentidos.
lgalfaso
en 21 dic. 2015
@lgalfaso gracias por la respuesta, intentaré corregir un error de resumen que encontré, si eso no resuelve el problema, intentaré actualizar angular, ¡gracias por la respuesta !.
bruno-serfe
en 21 dic. 2015
Gracias @lgalfaso : +1:
mrowles
en 22 dic. 2015
Tuve este problema cuando agregué la aplicación web a la pantalla de inicio y la usé de forma independiente, sin embargo, la actualización de AngularJS 1.4.5 a 1.5 resolvió completamente el problema y aceleró la navegación como el infierno.
tjespe
en 30 ene. 2016
@volgwfang ¿ El problema que tienes no está relacionado con este tema?
raftheunis87
en 15 mar. 2016
Temas relacionados
WesleyKapow
·
3Comentarios
tdumitrescu
·
3Comentarios
cmplank
·
3Comentarios
visnup
·
3Comentarios
awerlang
·
3Comentarios
Comentario más útil
Llegué un poco más lejos en este caso. Hice un cambio en Angular con respecto a la ubicación.
En la parte "actualizar navegador", he cambiado $ rootScope. $ EvalAsync a $ rootScope. $ ApplyAsync.
Los dos métodos parecen hacer exactamente lo mismo. La diferencia no se hace evidente hasta que observa la ejecución real de $ digest. Cuando AngularJS ejecuta un resumen, recorre el árbol de alcance y ejecuta los enlaces $ watch () hasta que no se produzcan más datos sucios. Durante este ciclo de vida, tanto la cola $ applyAsync () como la cola $ evalAsync () se vacían; pero esto sucede en dos lugares muy diferentes.
La cola $ applyAsync () solo se vacía en la parte superior de $ digest antes de que AngularJS comience a buscar datos sucios. Como tal, la cola $ applyAsync () se vaciará, como máximo, una vez durante un $ digest y solo se vaciará si la cola ya estaba llena antes de que comenzara $ digest.
La cola $ evalAsync (), por otro lado, se vacía en la parte superior del bucle while que implementa la "verificación sucia" dentro del $ digest. Esto significa que cualquier expresión agregada a la cola $ evalAsync () durante un resumen se ejecutará en un punto posterior dentro del mismo resumen.
Para hacer esta diferencia más concreta, significa que las expresiones asincrónicas agregadas por $ evalAsync () desde dentro de un enlace $ watch () se ejecutarán en el mismo resumen. Las expresiones asincrónicas agregadas por $ applyAsync () desde dentro de un enlace $ watch () se ejecutarán en un momento posterior (~ 10ms).
Espero que esto ya les ayude a algunos de ustedes :-).