Исключение броска UIWebView для [WebActionDisablingCALayerDelegate setBeingRemoved:]

При работе с 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];

(Это значит, что содержимое веб-просмотра повторно отображается так, чтобы оно соответствовало его ширине).

К счастью, исключение отбрасывается, поэтому приложение не сбой. Почему это происходит, и есть ли способ предотвратить это?

Ответ 1

Я обнаружил, что добавив "-webkit-transform: translateZ (0px);" к прокручиваемому контенту (у меня есть div внутри моего прокручиваемого контейнера), он исправил проблему для меня. Надеюсь, это поможет.

Ответ 2

Не уверен, что это ваш случай, но я также начал видеть эту проблему в iOS 8, и мы отследили ее до использования следующего свойства CSS в iframe:

-webkit-overflow-scrolling: touch;

После того, как мы удалили его, у нас больше не было этих сообщений об ошибках.

Примечание: в моем случае это не произошло в ответ на изменение каких-либо ограничений, а скорее это произошло во время навигации по HTML.

Ответ 3

Поскольку ни один из приведенных ответов не помог мне, мне пришлось решить эту проблему с помощью Objective-C runtime.

Сначала я предоставил простую функцию:

id setBeingRemoved(id self, SEL selector, ...)
{
   return nil;
}

Затем эти две строки:

    Class class = NSClassFromString(@"WebActionDisablingCALayerDelegate");
    class_addMethod(class, @selector(setBeingRemoved:), setBeingRemoved, NULL);

И он работает.

Ответ 4

Используйте WKWebView вместо UIWebView. (он был впервые включен в iOS 8). Я пробовал это, и кажется, что у него нет этой ошибки. Кроме того, это может улучшить производительность по сравнению с предшественником. Похоже, что Apple сделает де-факто стандарт в ближайшем будущем, если не сейчас. Он имеет интерфейсы и делегаты, несколько похожие на UIWebView. Определенно стоит попробовать.

Если вы настроили таргетинг на pre-iOS 8, вы можете реализовать резервные процедуры для загрузки UIWebView или WKWebView, здесь вы вне -полная реализация

Ответ 5

В моем случае проблема была <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 устраняет проблему.

Ответ 6

Как сказал @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>