Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#5290 closed change (fixed)

Provide test builds utilizing UIWebView and WKWebView

Reported by: mario Assignee:
Priority: P2 Milestone: Adblock-Browser-for-iOS-1.5.3
Module: Adblock-Browser-for-iOS Keywords:
Cc: jand, tomasnovella Blocked By:
Blocking: Platform: Adblock Browser for iOS
Ready: yes Confidential: no
Tester: Scheer Verified working: yes
Review URL(s):

Description (last modified by mario)

Background

Since we experience multiple different issues when either using WKWebView or UIWebView for background scripts, we intend to perform extended testing with both components. In order to do so, we'll need two test builds, one utilizing UIWebView and one utilizing WKWebView.

What to change

  • Implement UIWebView for background scripts
  • Implement WKWebView for background scripts
  • Add an option to Settings -> Devbuild Settings called "Background script component"
    • Add an option to the "Background script component" area called "UIWebView" (preselected)
    • Add an option to the "Background script component" area called "WKWebView"
    • If this option is changed, the background script component switches accordingly

Hint for testers

This change was introduced to monitor the performance of the two rendering components - WKWebView and UIWebView - over short- and long term. Initially we found an issue concerning WKWebView which was filed under #5227. This was most likely introduced due to the switch to WKWebView during the release of ABB 1.5.2. However #5227 was addressed without changing back the component.
Since WKWebView already caused additional issues, we opted for a possibility to switch between both in order to compare results regarding current or future instabilities.
In general the components can be seen as follows:

  • UIWebView is a legacy component, which is used for rendering websites and letting ABP run in the background. We are forced to use this component for rendering websites, since only this component supports enough control over its content for us to block ads. The background thread where ABP runs in, though, can be changed to WKWebView. WKWebView is not prone to crashes due to memory pressure, so we hoped to experience fewer crashes by doing so.
  • WKWebView is UIWebViews successor and is in general more stable and not prone to memory pressure (at least memory pressure can be caught using WKWebView and doesn't cause the app to shut down completely). Since it lacks control, we can't use it for rendering websites, but we can use it for ABP to run in.

Attachments (1)

reloading.png (327.5 KB) - added by traynard 3 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 Changed 3 years ago by mario

  • Cc jand tomasnovella added

comment:2 Changed 3 years ago by jand

  • Resolution set to fixed
  • Status changed from new to closed

comment:3 Changed 3 years ago by mario

  • Milestone set to Adblock-Browser-for-iOS-next
  • Ready set

comment:4 Changed 3 years ago by mario

  • Description modified (diff)

comment:5 Changed 3 years ago by traynard

UIWebView works well and as expected. No ads shown, no forced reloads etc. However, WKWebView causes issues while surfing sites like radaronline.com. Ads are shown after a while of surfing and often forcibly reloads the page and displays a "Reloading.. WebView has een reloaded" message. Screenshot attached.

Changed 3 years ago by traynard

comment:6 Changed 3 years ago by scheer

  • Tester changed from Unknown to Scheer
  • Verified working set
  • An option is now available in Settings -> Devbuild Settings called "Background script component"
  • An option is now available in the "Background script component" area called "UIWebView" (that is preselected)
  • An option is now available in the "Background script component" area called "WKWebView"
  • If this option is changed, the background script component switches accordingly

ABB 1.5.3 (1557)
iPhone 6s Plus
iOS 10.2.1

comment:7 Changed 3 years ago by scheer

One thing I would comment on here is, that we use WKWebView as default now, but the default setting for this feature is UIWebView. The default should always be the current default WebView we use as if it is not, then the tester must change the setting each and every time for testing.

Note: See TracTickets for help on using tickets.