Ответ 1
Я обнаружил, что добавив "-webkit-transform: translateZ (0px);" к прокручиваемому контенту (у меня есть div внутри моего прокручиваемого контейнера), он исправил проблему для меня. Надеюсь, это поможет.
При работе с iOS 8 я начал видеть следующее исключение из глубины UIWebView
:
[WebActionDisablingCalayerDelegate setBeingRemoved:]: непризнанный селектор, отправленный экземпляру 0x167ee900
* WebKit отменил неперехваченное исключение в webView: willRemoveScrollingLayer: withContentsLayer: forNode: delegate: - [WebActionDisablingCalayerDelegate setBeingRemoved:
Это происходит, когда я меняю некоторые ограничения на свой UIWebView
, а затем вызываю:
self.webViewWidthConstraints.constant = newWidth;
[self.webView setNeedsLayout];
[self.webView layoutIfNeeded];
(Это значит, что содержимое веб-просмотра повторно отображается так, чтобы оно соответствовало его ширине).
К счастью, исключение отбрасывается, поэтому приложение не сбой. Почему это происходит, и есть ли способ предотвратить это?
Я обнаружил, что добавив "-webkit-transform: translateZ (0px);" к прокручиваемому контенту (у меня есть div внутри моего прокручиваемого контейнера), он исправил проблему для меня. Надеюсь, это поможет.
Не уверен, что это ваш случай, но я также начал видеть эту проблему в iOS 8, и мы отследили ее до использования следующего свойства CSS в iframe:
-webkit-overflow-scrolling: touch;
После того, как мы удалили его, у нас больше не было этих сообщений об ошибках.
Примечание: в моем случае это не произошло в ответ на изменение каких-либо ограничений, а скорее это произошло во время навигации по HTML.
Поскольку ни один из приведенных ответов не помог мне, мне пришлось решить эту проблему с помощью Objective-C runtime.
Сначала я предоставил простую функцию:
id setBeingRemoved(id self, SEL selector, ...)
{
return nil;
}
Затем эти две строки:
Class class = NSClassFromString(@"WebActionDisablingCALayerDelegate");
class_addMethod(class, @selector(setBeingRemoved:), setBeingRemoved, NULL);
И он работает.
Используйте WKWebView вместо UIWebView. (он был впервые включен в iOS 8). Я пробовал это, и кажется, что у него нет этой ошибки. Кроме того, это может улучшить производительность по сравнению с предшественником. Похоже, что Apple сделает де-факто стандарт в ближайшем будущем, если не сейчас. Он имеет интерфейсы и делегаты, несколько похожие на UIWebView. Определенно стоит попробовать.
Если вы настроили таргетинг на pre-iOS 8, вы можете реализовать резервные процедуры для загрузки UIWebView или WKWebView, здесь вы вне -полная реализация
В моем случае проблема была <table> внутри содержимого iframe. Ширина таблицы была больше ширины iframe, определенной с помощью CSS. Прокрутка iframe была выключена, и таблица растянула iframe до минимальной расчетной ширины таблицы. Другой побочный эффект: содержимое iframe не было полностью видимо (отрезано с правой стороны).
|--- Available viewport width -------------|
|--- defined and estimated iframe width ---|
|--- table width in the iframe content > than defined iframe width ---|
|--- iframe stretched to the calculated table width ------------------|
Удаление формы таблицы iframe устраняет проблему.
Как сказал @André Morujão, удаление -webkit-overflow-scrolling:touch;
из элемента прокрутки останавливает исключение. Но я обнаружил, что исключение происходило только тогда, когда я добавил display:none
css в элемент прокрутки.
Изменить: я смог продолжить использование display:none
, чтобы скрыть свой прокручивающий элемент, поместив -webkit-overflow-scrolling:touch;
внутри своего собственного класса .scroll
и используя jquery для добавления и удаления этого класса из моего прокручиваемого элемента до и после его скрытия
<style>
.scroll
{
-webkit-overflow-scrolling:touch;
}
</style>
<script>
function hide()
{
$('#scrolling_element).removeClass('scroll');
$('#scrolling_element).css('display', 'none');
}
function show()
{
$('#scrolling_element).css('display', 'block');
$('#scrolling_element).addClass('scroll');
}
</script>