Angular.js: Resumo infinito sobre mudança de localização no iOS 9 com UIWebView (não no Safari / WKWebView)
O seguinte HTML simples demonstra o 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>
Isso funciona como esperado na maioria dos dispositivos, mas lança uma exceção de resumo infinito no iOS 9.
Consigo reproduzir no iPad Air 2 e no iPad de 4ª geração com iOS 9 beta 2.
Sei que provavelmente é um problema no iOS, mas ainda pode valer a pena investigar.
ttopalov
Todos 154 comentários
Eu encontrei um problema semelhante, que aconteceu no ios 9, mas funcionou bem em outros dispositivos.
cxm01
em 1 jul. 2015
Reproduzi esse problema com o mesmo código fornecido por santaslow em 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>
O código acima é executado normalmente no navegador de desktop, android e ios 8 webview, mas no ios 9 ele lançará uma exceção quando eu clicar no link:
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
Não consigo mais reproduzir no iOS 9 Beta 3.
ttopalov
em 9 jul. 2015
Recebo o mesmo erro com iOS9 público beta (13A4293g)
aexei
em 11 jul. 2015
Eu verifiquei o código acima no ios 9 beta 3 (13A4293g), sem exceção mais. Mas o aplicativo com o uso do ng-view ainda lança exceções infdig no ios 9 beta 3.
cxm01
em 13 jul. 2015
Recebo o mesmo erro com iOS9 público beta (13A4293g)
Erro: [$ rootScope: infdig ] 10 $ digest () iterações alcançadas. Abortando!
Observadores acionados nas últimas 5 iterações: []
http://errors.angularjs.org/1.3.13/ $ rootScope / infdig? p0 = 10 & p1 =% 5B% 5D
arquivo: ///Users/mac5/Library/Developer/CoreSimulator/Devices/749DE7E3-D93F-47F9-A1FC-E3D54A1CCEEE/data/Containers/Bundle/Application/9B5EE368-F2A0-4C99-807B-8wops /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-8wops /lib/ionic/js/ionic.bundle.js:54879:24
eventHandler @ file : ///Users/mac5/Library/Developer/CoreSimulator/Devices/749DE7E3-D93F-47F9-A1FC-E3D54A1CCEEE/data/Containers/Bundle/Application/9B5EE368-F2A0-4Containers/Bundle/Application/9B5EE368-F2A0-4C579-807ops.17A7B5EE368-F2A0-4C579-8h7-807ops /www/lib/ionic/js/ionic.bundle.js:11713:25
dispatchEvent @ [código nativo]
triggerMouseEvent @ file : ///Users/mac5/Library/Developer/CoreSimulator/Devices/749DE7E3-D93F-47F9-A1FC-E3D54A1CCEEE/data/Containers/Bundle/Application/9B5EE368-F2A0-9-4C4C9B5EE368-F2A079-4C /www/lib/ionic/js/ionic.bundle.js:2863:20
tapClick @ file : ///Users/mac5/Library/Developer/CoreSimulator/Devices/749DE7E3-D93F-47F9-A1FC-E3D54A1CCEEE/data/Containers/Bundle/Application/9B5EE368-F2A0-4CE5B-80h7B7ops /www/lib/ionic/js/ionic.bundle.js:2852:20
tapTouchEnd @ file : ///Users/mac5/Library/Developer/CoreSimulator/Devices/749DE7E3-D93F-47F9-A1FC-E3D54A1CCEEE/data/Containers/Bundle/Application/9B5EE368-F2A0BE5-4C8998-F2A1FC-E3D54A1CCEEE/data/Containers/Bundle/Application/9B5EE368-F2A0BE579-99app780B780B7ops. /www/lib/ionic/js/ionic.bundle.js:2975:13
arkomr
em 13 jul. 2015
Também estamos recebendo esse erro no Beta 3 público do iOS 9 com nosso próprio aplicativo Angular. Isso não ocorre no iOS 8.
epaga
em 15 jul. 2015
Como solução alternativa, escrevi uma diretiva simples para substituir ng-view e angular-route.js. A solução funcionou bem em nosso próprio aplicativo, todas as exceções infdig desapareceram no ios 9 beta / beta 3. Abaixo está o código simplificado, que é apenas para nosso próprio aplicativo, casos de uso gerais não são considerados. NÃO recomendo que outras pessoas usem isto:
(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)
Acabei de instalar o iOS 9 Beta 4 e ainda tenho o mesmo problema. Alguém mais?
raftheunis87
em 22 jul. 2015
Eu vi no iOS 9 Beta 3 e ainda estou vendo no iOS 9 Beta 4.
craig-at-rsg
em 22 jul. 2015
+1
aexei
em 22 jul. 2015
Sim, estamos vendo o mesmo problema, mesmo com o roteador ui angular. Alguém tem uma solução alternativa válida para esse problema nesse meio tempo?
vincentdu101
em 29 jul. 2015
Observando o mesmo problema no uiWebView no iOS9 mais recente.
viattik
em 31 jul. 2015
Alguém tem atualizações sobre esse problema?
raftheunis87
em 3 ago. 2015
Isso ainda é um problema. Reabertura
lgalfaso
em 3 ago. 2015
Parece um problema de iOS. Isso é rastreado no webkit em algum lugar?
Narretz
em 4 ago. 2015
+1
mike1e
em 4 ago. 2015
+1
RolfDeVries
em 5 ago. 2015
Mesmo aqui. Nosso aplicativo Cordova funciona bem se for executado como web no iPad Safari, mas o resumo infinito acontece se for executado como um aplicativo Cordova (UIWebView).
borrull
em 5 ago. 2015
Exatamente os mesmos problemas que @borrull ! Já experimentei com WKWebView e então o problema não existe. Mas não podemos usar WKWebView, pois precisamos do Local File Serving (e não queremos executar um servidor local em nosso aplicativo) e cookies. Portanto, ele tem que fazer algo com UIWebView em combinação com Cordova / Mobile Safari no iOS 9. No momento, estou depurando o $ locationWatch no Angular porque vejo que nosso aplicativo deseja fazer a transição para um local diferente várias vezes e então (após 10 vezes ) o erro de resumo é lançado.
raftheunis87
em 5 ago. 2015
mesmo problema aqui no iOS9 béta4
Loop infinito angular $ digest; (
axelsegers
em 5 ago. 2015
+1, apenas em UIWebView, não em WKWebView, mas só podemos usar UIWebView em nosso aplicativo Cordova.
andyverbunt
em 5 ago. 2015
+1
laurentverbruggen
em 5 ago. 2015
Se este for um problema específico do iOS, abra um problema no rastreador de problemas do webkit e forneça uma demonstração! +1 aqui provavelmente não mudará nada, pois realmente parece um bug do navegador.
Narretz
em 5 ago. 2015
Alguém relatou esse bug à Apple para investigação?
aexei
em 6 ago. 2015
Eu relatei esse bug para a apple. Mas talvez todos vocês devam fazer o mesmo para chamar a atenção deles para o bug.
axelsegers
em 6 ago. 2015
Você pode nos dar um link para que possamos marcar com +1?
RolfDeVries
em 6 ago. 2015
Ele está em nossa conta pessoal da apple por meio do relator de bug ... portanto, nenhum link público; (
axelsegers
em 6 ago. 2015
Você poderia postá-lo no openradar e compartilhar o id do rdar para que possamos enganá-lo!
epaga
em 6 ago. 2015
mesmo no iOS9 béta 5:
funciona em safari móvel
funciona em WKWebview que não podemos usar porque não pode servir arquivos locais e não suporta NSProtocol
NÃO funciona em UIWebView
axelsegers
em 7 ago. 2015
mesmo aqui no IOS 9 Beta 5
mk2988
em 7 ago. 2015
Também registrei um bug na Apple. O link do Open Radar é: https://openradar.appspot.com/22186109 (Isso deve ajudar os preguiçosos a registrar um bug). Por favor, deixe comentários se você pode melhorar o texto / explicação do bug ;-) Você pode baixar o projeto Xcode para anexar com o arquivamento de bug no tíquete do Open Radar (Obrigado a @santaslow pelo JS no OP)
borrull
em 7 ago. 2015
Eu criei uma versão do mesmo projeto Xcode (de @borrull), mas com ui-router em vez de ng-route. Exatamente o mesmo problema. Para os interessados, você pode encontrar o projeto aqui: http://s000.tinyupload.com/index.php?file_id=87281871603760127355
raftheunis87
em 7 ago. 2015
Também estamos vendo esse problema. Consegui identificar o problema de que as propriedades location. * Não são atualizadas imediatamente quando o angular está no mix. Se você tentar atribuir um valor a location.hash (como o que está sendo feito por trás do serviço de localização), então leia imediatamente, o valor não mudou. Parece haver alguns efeitos colaterais que ocorrem como resultado dos manipuladores jqlite anexados a eventos popstate e hashchanged.
Vou tentar fazer o upload de uma amostra quando estiver em um computador.
CleverCoder
em 7 ago. 2015
+1
abrahamrkj
em 8 ago. 2015
@CleverCoder Alguma atualização na amostra?
raftheunis87
em 10 ago. 2015
Terei que terminar o caso de reprodução pela manhã, conforme o código, pois estive amarrado o fim de semana todo. Obrigado pelo cutucão! Na contagem regressiva do iOS 9, temos grande interesse em ver isso resolvido. Vou fazer o upload de algo assim que puder.
CleverCoder
em 10 ago. 2015
+1
mk2988
em 10 ago. 2015
Eu reproduzi o que acredito ser a causa raiz, onde definir as propriedades hash ou href do local não "se aplicam" imediatamente.
Aqui está um link para o projeto XCode:
https://www.dropbox.com/s/2jkwv2thhm86nly/iOS%209%20Location%20Bug.zip?dl=0
Avise-me se você não conseguir acessar o arquivo.
Observe o valor resultante em location.hash, bem como anexe o Safari para depuração. Parece haver algo adiando a mudança como resultado de algum encanamento de evento com base nos eventos 'popstate' e 'hashchange'.
Espero que isto seja útil.
- Sean
CleverCoder
em 10 ago. 2015
Estamos usando window.location.href em vez de state.go e parece estar funcionando por enquanto. Menos bugado.
mike1e
em 10 ago. 2015
O valor de location.hash estará correto após um giro do runloop. O Angular pode facilmente contornar esse problema atrasando o get location.hash em um setTimeout (..., 0). Acho que seriam cerca de 2 mudanças para angular.js / src / ng / location.js.
hober
em 10 ago. 2015
@hober tentou o tempo limite com angular assim:
// 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();
});
e
// 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
});
Portanto, adicionei um setTimout ao método setBrowserUrlWithFallback, mas isso não resolve o problema.
raftheunis87
em 11 ago. 2015
Aqui está um caso de teste reduzido que não depende do Angular e que demonstra a solução alternativa. Como realmente implementar a solução alternativa no Angular não está claro para mim. https://gist.github.com/hober/a29b6c28ac1744c800dd
hober
em 11 ago. 2015
Aproximei-me um pouco mais deste. Fiz uma alteração no Angular em relação ao local.
Na parte "atualizar navegador", alterei $ rootScope. $ EvalAsync para $ rootScope. $ ApplyAsync.
Os dois métodos parecem fazer exatamente a mesma coisa. A diferença não se torna evidente até que você observe a execução real de $ digest. Quando o AngularJS executa um resumo, ele percorre a árvore do Escopo e executa ligações $ watch () até que nenhum dado mais sujo seja produzido. Durante esse ciclo de vida, a fila $ applyAsync () e a fila $ evalAsync () são liberadas; mas, isso acontece em dois lugares muito diferentes.
A fila $ applyAsync () só é liberada no início do $ digest antes que o AngularJS comece a verificar os dados sujos. Assim, a fila $ applyAsync () será liberada, no máximo, uma vez durante um $ digest e só será liberada se a fila já tiver sido preenchida antes do $ digest começar.
A fila $ evalAsync (), por outro lado, é liberada no topo do loop while que implementa a "verificação suja" dentro do $ digest. Isso significa que qualquer expressão adicionada à fila $ evalAsync () durante um resumo será executada posteriormente no mesmo resumo.
Para tornar essa diferença mais concreta, isso significa que as expressões assíncronas adicionadas por $ evalAsync () de dentro de uma ligação $ watch () serão executadas no mesmo resumo. Expressões assíncronas adicionadas por $ applyAsync () de dentro de uma associação $ watch () serão executadas em um momento posterior (~ 10 ms).
Espero que isso já ajude alguns de vocês :-).
// 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
});
Aqui está outra abordagem. Não estou familiarizado com a base de código Angular, mas a lógica parece racional. A função url do navegador (...) atualmente depende de location.href retornar imediatamente o URL correto. Como esse método é chamado no mesmo loop de execução, dentro do ciclo de estabilização $ digest, ele continua obtendo a URL antiga. Este patch utiliza um 'pendingHref' para rastrear a atribuição, retornando esse valor, se estiver definido. Uma vez que o valor esteja alinhado com location.href, o valor pendente é apagado. Durante uma configuração do url, um cronômetro é definido com 0 ms para detectar o caso em que um url () get não é chamado. Não é perfeito, mas a lógica parece funcionar. Isso é principalmente para considerar uma abordagem alternativa que não crie atrasos no desempenho. Isso é baseado na tag 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;
}
};
Obrigado @CleverCoder pela solução! Parece funcionar como um encanto! : +1:
raftheunis87
em 14 ago. 2015
@CleverCoder
seria ótimo se você fizesse uma solicitação de pull com isso para a equipe angular.
viattik
em 14 ago. 2015
@viattik Eu meio que me surpreenderia se a equipe angular adotasse uma solução alternativa para o UIWebView no iOS9, já que o bug está no próprio UIWebView (Apple). Mas você sempre pode tentar ...
raftheunis87
em 14 ago. 2015
@ raftheunis87
Existem muitos bugs em navegadores diferentes e muitas soluções alternativas para esses bugs no código angular.
Embora não sejam oficialmente compatíveis com UIWebView, muitos aplicativos híbridos serão quebrados e o uso do angular será impossível em aplicativos híbridos no iOS mais recente até que a Apple conserte esse bug. E esse é um grande problema, eu diria.
Então, eu tentaria.
viattik
em 14 ago. 2015
@viattik concordo totalmente. E a propósito: a Apple nos comunicou que é improvável que consertem o bug do UIWebView. Então, de fato: experimente ;-)
raftheunis87
em 14 ago. 2015
Pessoal, se vocês pudessem postar isso como um bug do webkit, de preferência com um caso de reprodução, farei o acompanhamento com alguns de nossos contatos do lado do WebKit. https://bugs.webkit.org/
naomiblack
em 14 ago. 2015
@naomiblack
Não tenho certeza se é um bug do webkit. Porque isso só acontece em UIWebView no iOS9. Safari no iOS9 funciona bem.
viattik
em 14 ago. 2015
@ raftheunis87 obrigado por suas sugestões de código, funcionou perfeitamente
ajrmspwd
em 14 ago. 2015
@ raftheunis87 @CleverCoder é uma forma de trabalhar com angular iônico? você pode ser mais específico?
abrahamrkj
em 15 ago. 2015
@abrahamrkj Não tenho nenhuma experiência com iônico. Mas suas personalizações são angulares ao usar iônicos? Caso contrário, eu diria que a mesma correção funcionaria com angular iônico ...
raftheunis87
em 15 ago. 2015
@ raftheunis87 https://github.com/driftyco/ionic/tree/master/js este é o angular que eles estão usando.
abrahamrkj
em 15 ago. 2015
@CleverCoder +1 para a solicitação de pull. Eu concordo com @viattik que essa é uma questão importante, pois vai quebrar muitos aplicativos híbridos.
borrull
em 17 ago. 2015
Uma solicitação de pull pode estar em um futuro próximo, embora eu hesite, pois não estou tão perto da base de código Angular quanto os outros. Vou revisitar a solução em breve e tentar torná-la à prova de balas. Parece estranho que uma propriedade no objeto window.location não mude 'imediatamente'. Nos testes que fiz, percebi que a mudança permaneceu contanto que os ganchos de evento 'popstate' e 'hashchange' não estivessem no lugar, o que me levou a pensar que a causa da mudança adiada pode realmente ser fazer algo mais ... Talvez o tempo desses eventos tenha mudado (acho que é isso que eu estava observando).
Vou assistir a isso nos próximos dias e, se nada melhor aparecer, vou cavar um pouco mais fundo para confirmar o que sei até agora e que não há um lugar melhor para lidar com a mudança de comportamento. Desculpe se isso é confuso. Há muita coisa acontecendo sob o capô que eu ainda não entendo completamente com relação a esses eventos.
Saúde!
CleverCoder
em 17 ago. 2015
... e sim, @borrull , concordo. Se a Apple não fizer mais alterações, então esta é uma bomba-relógio séria que realmente levará a uma má publicidade e acusações. Eu não sou um fã dos temporizadores como uma solução alternativa (eu preferia ter melhorado o fluxo lógico em torno dessas propriedades integradas), mas se não podemos depender da mudança de valor depois de definido, então onde desenhamos o linha? Em que outras propriedades não podemos confiar? É estranho.
CleverCoder
em 17 ago. 2015
@CleverCoder Só queria agradecer, seu patch realmente salvou o dia!
tfujii
em 18 ago. 2015
@CleverCoder Obrigado pela solução alternativa.
Eu deduzi uma solução que usa o recurso de decorador angular e vem sem corrigir a origem angular.
Com o cssua, esta configuração pode ser configurada para ser usada apenas em ambientes 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
em 20 ago. 2015
@CleverCoder Veja # 12635
jd-carroll
em 20 ago. 2015
@ jd-carroll: Isso é muito interessante. Posso revisitar isso um pouco mais tarde hoje, quando tiver tempo. Muito inundado com coisas. Isso só cria mais mistério, já que parece ser um problema separado que não deve apresentar um atraso na atualização dos valores de location. *.
@realityfilter : Engraçado você mencionar o decorador ... Acabei de implementar algo usando a funcionalidade do decorador Angular. Legal!
CleverCoder
em 20 ago. 2015
Olá a todos,
Só queria acrescentar que essa correção introduziu um bug em nosso código que era fácil de corrigir.
Nossos modelos tinham tags âncora que usavam href = "#" e ng-click = "someCall ()". O href estava fazendo com que o site fosse para index.html usando esta correção. Remover o href corrigiu o problema.
jyc66
em 20 ago. 2015
Nosso aplicativo está quebrando durante a navegação com o botão Voltar no Ionic, ele primeiro vai para uma nova visão, depois volta para a visão antiga parcialmente e depois volta novamente para a nova visão no IOS9 beta quaisquer resoluções para Ionic
ajaybeniwal
em 21 ago. 2015
Mesmo problema com iOS 9 beta 5 13A4325c, Angular 1.4.0 (com cordova-ios 3.9.1). Esperamos que o bug UIWebView subjacente seja corrigido!
aderowbotham
em 31 ago. 2015
O mesmo problema ocorre no Angular v1.2.27
markoivanovski
em 1 set. 2015
Eu rastreei até a versão 1.2.27, o bug não está na versão 1.2.26 anterior.
Especificamente, esse commit é o culpado.
damrbaby
em 3 set. 2015
@damrbaby Parece que posso ter algo a ver com isso.
Mas o fato de estar funcionando com a versão mais recente do angular no Mobile Safari esclarece que tem que fazer algo com o uiWebView no iOS 9. Portanto, a mudança que eles fizeram no código-fonte do Angular não é necessariamente uma coisa ruim.
raftheunis87
em 3 set. 2015
@CleverCoder @realityfilter @ jyc66 Eu só queria dizer obrigado, você acabou de salvar meu dia.
Kira2
em 9 set. 2015
O problema ainda está presente no iOS9 GM Seed, então atualizem seus aplicativos, pessoal!
markoivanovski
em 9 set. 2015
Posso confirmar que o problema ainda está presente no iOS9 GM (13A340)
richardbrammer
em 10 set. 2015
Então, isso significa que a Apple quebrou algo e temos que atualizar nossos aplicativos novamente (alguns dos quais não mudam há meses ou até mesmo mais de um ano) para evitar que travem. Faz sentido :(. Prefiro que a Apple o conserte para os lançamentos do iOS9. Ir para a versão Angular mais recente em um aplicativo antigo pode quebrar algumas outras coisas também.
Eu duvido que o Angular seja o único framework que está tendo problemas com o iOS9.
Martinspire
em 10 set. 2015
Portanto, @adamdbradley , @perrygovier e @mhartington da equipe Ionic têm trabalhado o dia todo em uma correção que funcionará para Ionic e também para aplicativos Angular simples. O objetivo é ser uma correção temporária que não exija a modificação do Angular e funcione (com sorte) na maioria das versões 1.2+ do Angular.
Aqui está nossa solução empacotada atual que decora e corrige $browser aplicando este patch . Observação: isso é baseado no Angular 1.4.3 e é uma espécie de "clone com correções" de browser.js do Angular adequado: https://github.com/driftyco/ionic/blob/ios9-patch/js /angular/service/decorators/ios9-browser-fix.js
Também colocamos o patch em nosso CDN. Não recomendo usar o arquivo CDN para produção, ele está lá apenas para ser mais fácil de testar agora.
Para testá-lo, coloque esta tag de script abaixo do arquivo angular ou ionic.bundle.js:
<script src="https://code.ionicframework.com/patch/ios9-$browser-patch.js"></script>
Além disso, agora ele aplica o patch, esteja você executando no iOS9 ou não. Em breve, isso será corrigido de forma que ele funcione apenas no iOS 9 UIWebView.
Siga o problema Ionic correspondente aqui: https://github.com/driftyco/ionic/issues/4082#issuecomment -139079725
mlynch
em 10 set. 2015
Olá a todos,
UI-sref funciona perfeitamente, mas $ state.go quebra a animação do botão Voltar
e a página pisca muito mesmo depois de aplicar essa correção.
Cumprimentos,
Ajay Singh
Na quinta-feira, 10 de setembro de 2015 às 6h23, Max Lynch [email protected] escreveu:
Então, @adamdbradley https://github.com/adamdbradley , @perrygovier
https://github.com/perrygovier e @mhartington
https://github.com/mhartington da equipe Ionic tem trabalhado
o dia todo em uma correção que funcionará para Ionic e para aplicativos Angular simples como
Nós vamos. O objetivo é ser uma correção imediata que não exija modificação
Angular, e funcionará (com sorte) na maioria das versões 1.2+ do Angular.Aqui está nossa solução empacotada atual que decora e corrige $ navegador por
aplicando este patch
https://github.com/angular/angular.js/issues/12241#issuecomment -130744518.
Nota: isso é baseado no Angular 1.4.3 e é uma espécie de "clone com correções" de
browser.js do Angular apropriado:
https://github.com/driftyco/ionic/blob/ios9-patch/js/angular/service/decorators/ios9-browser-fix.jsTambém colocamos o patch em nosso CDN. Eu não recomendo usar o arquivo CDN
para produção, está lá apenas para ser mais fácil de testar agora.Faça um teste e diga-nos como foi, obrigado.
Para testá-lo, coloque esta tag de script abaixo de seu angular ou
Arquivo 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
em 10 set. 2015
Posso confirmar que esse bug ainda está presente no iOS 9.1 Beta 1
hmrc87
em 10 set. 2015
Usamos $state.go muito e ainda está oscilando entre os estados / não está fazendo a transição corretamente.
tcrammond
em 10 set. 2015
Desculpe, a correção funciona para nosso aplicativo agora, apenas precisamos incluir https
Link CND em vez de http CDN parece que ios9 só permite https dentro do
app então depois de usar https nosso app funcionou.
https://code.ionicframework.com/patch/ios9- $ browser-patch.js
Na quinta-feira, 10 de setembro de 2015 às 15:22, Tyler Crammond notifications@github.com
escrevi:
Usamos $ state.go muito e ainda está oscilando entre os estados / não
fazendo a transição corretamente.-
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/angular/angular.js/issues/12241#issuecomment -139189216
.
ajaybeniwal
em 10 set. 2015
ios9- $ browser-patch.js funciona para mim também. Mas isso gera alguns erros jshint. Existe uma maneira de contribuir com o patch para ajudar a remover os erros?
richardbrammer
em 10 set. 2015
Não acho que este patch seja totalmente correto, pois não permite que você atualize a localização de fora do Angular. Isso provavelmente não é um problema para a maioria dos aplicativos, mas estamos trabalhando para ver se há uma solução melhor ...
petebacondarwin
em 10 set. 2015
ios9- $ browser-patch.js não funcionou para mim. Quando estou passando da minha visualização de lista para uma visualização de detalhes, eu uso $ state.go () para mover entre as páginas. Na primeira vez que faço isso, ele desliza para a frente e depois para trás, clico novamente e funciona. UI-sref funciona como desejado, mas não me permite fazer a lógica condicional que preciso fazer.
jeverington
em 10 set. 2015
Infelizmente, fazer o download do patch, armazená-lo e carregá-lo de ./lib/ (verifiquei se ele está carregado) não mudou nada para mim:
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
em 10 set. 2015
Jorisw, tente desativar o código de detecção ios9 e veja se funciona:
var isIOS9 = (navigator.userAgent.indexOf ('Version / 9.')! = -1) && (navigator.appVersion.indexOf ('9_0')! = -1);
if (! isIOS9) {
// não faça patch se não for iOS9 UIWebView
return $ browser;
}
jyc66
em 10 set. 2015
@ jyc66 Isso funciona, obrigado. Como posso ter certeza de que ele não danifica o iOS <9?
jorisw
em 10 set. 2015
O método isIOS9 está com defeito. Deve verificar em relação a:
> 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
Sim, como alternativa, você pode testar sistemas operacionais menores que 9 e desabilitar a correção nesses casos. A verificação atual será interrompida no iOS 9.1, que também será lançada.
jyc66
em 10 set. 2015
Estou fazendo isso agora, até que eu ou alguém venha com um melhor:
// 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;
}
Sim, isso é semelhante ao que estou fazendo.
jyc66
em 10 set. 2015
Alguém sabe se a aplicação do patch nas versões do iOS> = 9.0 causará problemas se / quando a Apple corrigir o problema em uma versão posterior do iOS?
JeremyPlease
em 10 set. 2015
@JeremyPlease Estou carregando a versão 9.1 beta agora e vou dar uma olhada
mhartington
em 10 set. 2015
Funcionou para mim quando desativei a verificação do agente do usuário, disponibilizando o patch como parte do pacote minimizado. É um aplicativo angular não iônico. Investigarei mais tarde esta noite e garantirá que tudo funcione conforme o esperado.
Obrigado à equipe iônica por se esforçar!
dac09
em 10 set. 2015
Portanto, o 9.1beta um ainda não tem a correção. Não surpreso.
mhartington
em 10 set. 2015
Isso pode parecer estranho - mas alguém vendo a função String.split () não funcionar corretamente quando o patch é aplicado no iOS 9? (testado até agora apenas no simulador). Aqui está uma captura de tela do depurador do Safari: https://www.dropbox.com/s/hxgct9y0f9z6yci/Screenshot%202015-09-11%2000.40.26.png?dl=0
Estou perplexo! Funciona bem no iOS8.4 e no Chrome, é claro.
Atualização : String.split não parece funcionar no simulador iOS 9 iPhone 6 e 6s para mim, nada a ver com o patch.
A propósito, aqui está o que usei para verificar o agente do usuário:
var isIOS9WebView = (navigator.userAgent.indexOf('Safari') === -1) && (navigator.appVersion.indexOf('OS 9') !== -1);
if (!isIOS9WebView) {
// do not patch if not iOS9 UIWebView
return $browser;
}
Acredito que a melhor solução talvez seja a solicitação de pull do Igor, mas isso funciona para mim, embora não aplique o patch no iOS 9 Safari, mas apenas no UIWebView.
dac09
em 11 set. 2015
@ dac09 Quero testar seu comunicado, mas não sei qual arquivo deve ser modificado ...
Você pode me dizer qual arquivo deve ser modificado?
joinsik
em 11 set. 2015
Estou usando o patch do @CleverCoder , no qual o patch da ionic se baseia, sem restrição de que deve ser executado apenas no iOS9 UIWebView, e não tem consequências no UIWebView iOS8, safari ou Android.
damrbaby
em 11 set. 2015
Olá pessoal, vocês podem testar este patch: https://gist.github.com/IgorMinar/863acd413e3925bf282c
Ele deve funcionar com Angular 1.2 - 1.4.5 e não requer nenhuma atualização Angular. As instruções sobre como aplicar isso ao seu aplicativo estão na essência.
Teremos uma correção adequada em 1.4.6, mas, enquanto isso, esse patch autônomo visa facilitar a implementação e implantação de uma correção para que você possa implementá-la rapidamente.
IgorMinar
em 11 set. 2015
Olá @IgorMinar - Estou recebendo o seguinte erro na minha implantação do Angular 1.3 (Ionic beta-14). Não acho que o método .decorator esteja disponível no módulo 1.3?
TypeError não capturado: angular.module (...). Decorator não é uma função (função anônima) @ angular-ios9-uiwebview.patch.js: 33
rajatrocks
em 11 set. 2015
@rajatrocks uhh .. bom ponto. module.decorator é o recurso 1.4 apenas. deixe-me mudar o patch.
IgorMinar
em 11 set. 2015
@rajatrocks Eu atualizei a essência
IgorMinar
em 11 set. 2015
Obrigado @IgorMinar , "instala" bem agora. Vou deixar meus comentários sobre o segmento Ionic, já que eles estão mais relacionados a isso.
rajatrocks
em 11 set. 2015
@IgorMinar Incluí seu arquivo js e adicionei o seguinte em meu app.js. Isso não resolve meu problema.
jprangenbergde
em 11 set. 2015
@IgorMinar Seu patch não corrigiu meu problema, mas o de @mlynch corrigiu .
Para garantir que seja aplicado apenas à plataforma iOS, criei um gancho Cordova simples:
https://gist.github.com/DURK/f2acd6bca4759e719801
Atualização : Ah, vejo que o patch agora contém uma verificação, então só é aplicado no iOS9.
DURK
em 11 set. 2015
@IgorMinar Seguindo o que @DURK e @jprangenberg relataram, parece haver um problema com a função "isIOS9UIWebView" ao testar em um iPad Air 2. Se eu forçar a aplicação do shim sempre, o patch funcionará.
tfujii
em 11 set. 2015
Do meu comentário em: https://github.com/driftyco/ionic/issues/4082#issuecomment -139567128
@IgorMinar , seu patch funciona muito bem no iOS 9 iPhone UIWebView, mas há alguns problemas com a detecção do agente do usuário para iPad.
Agente de usuário do iPhone iOS 9 em 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 usuário iOS 9 iPad em UIWebView:
Mozilla/5.0 (iPad; CPU OS 9_0 like Mac OS X) AppleWebKit/601.1.46 (KHTML, like Gecko) Mobile/13A340
A regex que corresponderá de forma confiável a todos esses é:
function isIOS9UIWebView(userAgent) {
return /(iPhone|iPad|iPod);.*OS 9_\d/.test(userAgent) && !/Version\/9\./.test(userAgent);
}
Eu bifurquei a essência de https://gist.github.com/JeremyPlease/72cb3bf98279fefed4e3
JeremyPlease
em 11 set. 2015
O gancho
IgorMinar
em 11 set. 2015
@JeremyPlease Safari no iOS9 não é afetado. realmente queremos aplicar o patch apenas quando em UIWebView.
IgorMinar
em 11 set. 2015
@JeremyPlease Safari iOS 9 não é o problema, então a verificação de @IgorMinar está correta - para limitá-la especificamente a UIWebViews, eu acredito.
Funciona muito bem para mim.
dac09
em 11 set. 2015
Percebi que isso é apenas um problema no UIWebView, então atualizei minha essência para não se aplicar no Safari:
function isIOS9UIWebView(userAgent) {
return /(iPhone|iPad|iPod);.*OS 9_\d/.test(userAgent) && !/Version\/9\./.test(userAgent);
}
Publiquei v1.0.3 do patch
IgorMinar
em 11 set. 2015
@IgorMinar Essa correção simplesmente funciona, se você usar o ngRoute? A correção não funciona para mim ... :-(
jprangenbergde
em 11 set. 2015
@jprangenberg sim. meu aplicativo com ngroute funciona bem no iphone / ipad. você pode fornecer mais detalhes? também certifique-se de usar v1.0.3 + do patch
IgorMinar
em 11 set. 2015
@IgorMinar A versão 1.0.3 do patch está funcionando corretamente em meu ambiente.
tfujii
em 11 set. 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 (rota):
$stateProvider.state('app.regions', {
cache: false,
url: "/states/:state_id/regions",
views: {
'menuContent': {
templateUrl: "templates/regions.html",
controller: 'RegionsCtrl'
}
}
})
Não é possível navegar pelo aplicativo. Se você clicar em um item da lista, verá a tela atual. O botão de histórico muda. Se você clicar no botão histórico, poderá ver a visualização do clique no item da lista.
<ion-list>
<ion-item ng-repeat="state in states" href="#/app/states/{{state.id}}/regions">
{{state.name}}
</ion-item>
</ion-list>
@IgorMinar Não funciona para mim. Alguém tem alguma ideia?
jprangenbergde
em 11 set. 2015
@jprangenberg, você está usando a versão corrigida do pacote Ionic ou uma versão?
perrygovier
em 11 set. 2015
@perrygovier Estou usando a versão 1.0.3 de @IgorMinar
jprangenbergde
em 11 set. 2015
@jprangenberg certo, mas o ionic.bundle.js. Que versão é essa?
perrygovier
em 11 set. 2015
Versão do meu ionic.bundle.js:
window.ionic.version = '1.0.0';
@perrygovier Obrigado pela ajuda!
jprangenbergde
em 11 set. 2015
Por curiosidade, usar a versão 1.1.0 do pacote ajuda?
http://code.ionicframework.com/1.1.0/js/ionic.bundle.min.js
Você provavelmente precisará do CSS atualizado também
http://code.ionicframework.com/1.1.0/css/ionic.min.css
perrygovier
em 11 set. 2015
Olá @jprangenberg , enquanto estamos todos trabalhando nisso juntos, vamos continuar essa discussão relacionada a iões sobre a questão iônica para não enviar spam para usuários regulares do Angular driftyco / iônico # 4082
perrygovier
em 11 set. 2015
Portanto, esse bug não afeta WKWEBVIEW ao usar https://github.com/Telerik-Verified-Plugins/WKWebView ?
jason-engage
em 11 set. 2015
O bug está apenas no UIWebView do iOS 9. Não está presente ao usar WKWebView.
perrygovier
em 11 set. 2015
Obrigado pelo seu trabalho com esse pessoal, mas infelizmente não está funcionando para mim. Estou recebendo animações quebradas, páginas que não carregam, páginas que não carregam corretamente. Basicamente, o roteador está completamente instável.
Estou usando o pacote Ionic 1.1.0 e iOS 9.1 em um iPhone 6, junto com o arquivo de patch em https://code.ionicframework.com/patch/ios9- $ browser-patch.js. Estou vendo erros como este:
Erro: [$ rootScope: infdig ] 10 $ digest () iterações alcançadas. Abortando!
Observadores acionados nas últimas 5 iterações: []
Alguma sugestão?
Obrigado!
scottopolis
em 11 set. 2015
@scottopolis você tentou o patch de Igor: https://gist.github.com/IgorMinar/863acd413e3925bf282c
petebacondarwin
em 11 set. 2015
@petebacondarwin ya obrigado, o patch do Igor funciona para mim. Minhas animações de transição de página estão instáveis, mas o roteador parece estar consertado. Vou ficar de olho nesse assunto.
scottopolis
em 11 set. 2015
Alguns testes aqui e o patch de @IgorMinar estão causando problemas com as animações e controladores do botão Voltar. Estou vendo o controlador da tela que evito ser criada novamente quando clico em voltar. Isso está fazendo com que as animações sejam executadas nessa visualização enquanto ela é navegada para fora da tela, todos os tipos de estranhos.
Até agora, não estou vendo problemas com o uso do nightly from ionic, mas com a atualização da detecção do iOS9.
var userAgent = navigator.userAgent,
isIOS9 = /(iPhone|iPad|iPod).* OS 9_\d/.test(userAgent) && !/Version\/9\./.test(userAgent);
aphex
em 11 set. 2015
Acabei de enviar v1.1.0 do patch: https://gist.github.com/IgorMinar/863acd413e3925bf282c
Junto com a equipe iônica, não somos mais capazes de reproduzir qualquer cintilação com esta versão do patch.
Faça upgrade e nos informe se encontrar mais problemas. (também certifique-se de não usar nenhum outro patch para este problema além do v1.1.0 do patch).
Faremos uma correção no master na próxima semana, para que o Angular v1.4.6 não precise mais de patch.
IgorMinar
em 12 set. 2015
Esta nova versão do patch está funcionando perfeitamente para mim. Obrigado @IgorMinar!
scottopolis
em 12 set. 2015
O 1.4.6 lançado corrige esse problema para sempre?
alexislg2
em 18 set. 2015
@ alexislg2 - sim, esta versão deve corrigir o problema, então você não precisa aplicar o patch.
petebacondarwin
em 18 set. 2015
Confirmado, funciona para mim no simulador e no dispositivo, só preciso que meus usuários esperem 2 semanas pela aprovação da Apple ;-(
dbroadhurst
em 18 set. 2015
@dbroadhurst Ouvi dizer que você pode citar o https://openradar.appspot.com/22186109 relatório de bug para rastrear rapidamente a atualização do seu aplicativo.
petebacondarwin
em 18 set. 2015
Você pode seguir este bug do WebKit para atualizações.
hober
em 22 set. 2015
Olá, parece que você resolveu o problema da chamada assíncrona do iOS9 na mudança de hash no Angular.js.
Fiz pesquisas, também postei no stackoverflow, mas a única solução que encontrei até agora está no patch do angular browser.js.
Não estou muito familiarizado com o angular e gostaria de entender o que você fez para disponibilizar o seu conserto em
cada aplicativo da web baseado em roteamento Hash
Você explicaria como identificou e corrigiu o problema?
lchenneberg
em 25 set. 2015
@lchenneberg - o commit que corrige o problema no AngularJS está aqui https://github.com/angular/angular.js/commit/8d39 relevantabf423517b5bff70137c2a29e32bff76d
O problema é que este navegador em particular não atualiza o valor de window.location.href até a próxima execução do loop de eventos JavaScript. Isso significa que se você gravar nesse valor, em seguida, lê-lo imediatamente de volta, você obterá um 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 o segundo console.log retorna o valor antigo, não o novo valor. Após a conclusão do loop de evento atual, o valor é atualizado, como pode ser visto no terceiro console.log
A correção que encontramos é armazenar em cache o valor que escrevemos, se o navegador não estiver atualizando de forma síncrona, e usar esse valor a partir de então, em vez do valor retornado de window.location.href , até há um evento hashchange , que nos diz que o navegador finalmente se resolveu.
Espero que ajude.
petebacondarwin
em 25 set. 2015
O patch de @IgorMinar funcionou bem para mim. Estou usando as seguintes versões de Angular e Ionic:
window.ionic.version "1.0.1"
angular.version
Object {full: "1.3.13", major: 1, minor: 3, dot: 13, codeName: "meticulous-riffleshuffle"}
jasdeepsingh
em 30 set. 2015
O patch de @IgorMinar funcionou para nós também. Obrigado!!
Mas eu tenho outra pergunta que um de vocês pode ser capaz de responder:
Ou, mais importante, acessar um aplicativo da web dessa forma tira vantagem do mecanismo de renderização Nitro?
tpeiffer
em 1 out. 2015
@tpeiffer eles usariam wkwebview, já que é apenas safari sem a barra de endereço.
mhartington
em 1 out. 2015
Olá, tenho exatamente o mesmo problema com uma versão antiga do angular: 1.0.6
Vejo que todas as correções são para versões mais recentes. Você sabe onde devo procurar para ver se consigo corrigir esse problema? Obrigado.
tzamora
em 2 out. 2015
@tzamora Você já tentou aplicar o patch de @IgorMinar ? Talvez 1.0.6 seja muito cedo para funcionar.
petebacondarwin
em 2 out. 2015
@petebacondarwin o @IgorMinar se refere a um arquivo chamado browser.js. Não tenho nenhum arquivo chamado browser.js
tzamora
em 2 out. 2015
Para sua informação, uma correção para o problema subjacente pousou no WebKit outro dia:
http://trac.webkit.org/changeset/190092
http://trac.webkit.org/changeset/190100
hober
em 2 out. 2015
Consegui trabalhar com o patch js, mas não imediatamente. Novo para isso (angularjs e Ionic), então se alguém pudesse verificar isso e me avisar se eu perdi alguma coisa importante, eu realmente apreciaria! (por exemplo, o objeto da plataforma é muito ineficiente etc)
Observação:
- Eu baixei o ios9- $ browser-patch.js local
- Descobri que isso não resolveu meu problema, mas forçar isIOS9UIWebView a retornar verdadeiro funcionou muito bem
- Reescrevi a verificação de patch usando os métodos da plataforma Ionic, que funcionam bem agora. (Deixei o código antigo comentado aqui para mostrar a evolução)
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
em 5 out. 2015
Corri para este problema em 8.4 no simulador; portanto, não acho que esteja limitado apenas ao iOS 9. Acabei de atualizar a verificação da string do agente para incluir as versões iOS 8 e 9. Aqui está a string do 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
em 6 out. 2015
+1
StevenStar
em 20 out. 2015
Oi
Alguém pode confirmar se isso foi resolvido no iOS 9.2? (beta)
Obrigado :)
FreudGit
em 11 nov. 2015
Não consigo reproduzir o problema a partir desta atualização matinal para iOS 9.2 (13C75) no iPhone 6. Parece bom até agora. Este bug ainda está aberto - https://openradar.appspot.com/22186109
mrowles
em 10 dez. 2015
Se este patch for aplicado, ele pode ter algum efeito negativo no iOS 9.2 e superior? Vou testar isso com nosso próprio aplicativo, mas quero ter certeza de que não estou apresentando problemas que não aparecem ao testar nossa situação particular.
Pelo que posso ver, todos os patches usam um regex que filtra o iOS 9 e superior, mas não especificamente 9.x até e incluindo 9.1.
martijntraa
em 21 dez. 2015
Olá pessoal, esse problema está acontecendo no iPhone 6 com iOS 9, alguém pode me dizer por quê?
https://forum.ionicframework.com/t/ios-9-beta-slide-menu-app-transition-issue/30768
é outro patch que preciso aplicar? Informe-me, realmente preciso corrigir esse problema de sobreposição de tela.
bruno-serfe
em 21 dez. 2015
A atualização para o iOS 9.2 parece resolver isso para mim também.
brechtcs
em 21 dez. 2015
@ bruno-serfe este é um problema de como o iOS lida com window.location que está presente apenas no iOS 9.0.x. Se você pode atualizar para o Angular 1.4.6+, não há mais nada que você precise fazer, pois esta versão contém a correção. Se você não puder atualizar, o patch em https://github.com/angular/angular.js/issues/12241#issuecomment -139446288 tem a mesma correção.
Conforme declarado antes, esse problema está presente apenas no iOS 9.0.x, pois isso foi corrigido no iOS 9.1.0.
O problema postado no ionic parece o mesmo, então a mesma correção deve funcionar nos dois sentidos.
lgalfaso
em 21 dez. 2015
@lgalfaso obrigado pela resposta, tentarei consertar um erro de resumo que encontrei, se isso não resolver o problema, tentarei atualizar o angular, obrigado pela resposta !.
bruno-serfe
em 21 dez. 2015
Obrigado @lgalfaso : +1:
mrowles
em 22 dez. 2015
Tive esse problema quando adicionei o aplicativo da web à tela inicial e usei-o como autônomo, no entanto, atualizar do AngularJS 1.4.5 para 1.5 resolveu completamente o problema e acelerou a navegação como o inferno!
tjespe
em 30 jan. 2016
@volgwfang O problema que você está tendo não está relacionado a este tópico?
raftheunis87
em 15 mar. 2016
Questões relacionadas
visnup
·
3Comentários
jetta20162
·
3Comentários
landed1
·
3Comentários
awerlang
·
3Comentários
ashclarke
·
3Comentários
Comentários muito úteis
Aproximei-me um pouco mais deste. Fiz uma alteração no Angular em relação ao local.
Na parte "atualizar navegador", alterei $ rootScope. $ EvalAsync para $ rootScope. $ ApplyAsync.
Os dois métodos parecem fazer exatamente a mesma coisa. A diferença não se torna evidente até que você observe a execução real de $ digest. Quando o AngularJS executa um resumo, ele percorre a árvore do Escopo e executa ligações $ watch () até que nenhum dado mais sujo seja produzido. Durante esse ciclo de vida, a fila $ applyAsync () e a fila $ evalAsync () são liberadas; mas, isso acontece em dois lugares muito diferentes.
A fila $ applyAsync () só é liberada no início do $ digest antes que o AngularJS comece a verificar os dados sujos. Assim, a fila $ applyAsync () será liberada, no máximo, uma vez durante um $ digest e só será liberada se a fila já tiver sido preenchida antes do $ digest começar.
A fila $ evalAsync (), por outro lado, é liberada no topo do loop while que implementa a "verificação suja" dentro do $ digest. Isso significa que qualquer expressão adicionada à fila $ evalAsync () durante um resumo será executada posteriormente no mesmo resumo.
Para tornar essa diferença mais concreta, isso significa que as expressões assíncronas adicionadas por $ evalAsync () de dentro de uma ligação $ watch () serão executadas no mesmo resumo. Expressões assíncronas adicionadas por $ applyAsync () de dentro de uma associação $ watch () serão executadas em um momento posterior (~ 10 ms).
Espero que isso já ajude alguns de vocês :-).