There is a section in the WeChat documentation that explains “Restrictions on the Use of Native Components” with a paragraph like this

"Because native components are removed from the WebView rendering process, they have the following limitations when used: The native component is the highest level, so whatever z-index is set for other components in the page, Native components are not available in scroll view, swiper, picker-view, and movable-view. Some CSS styles cannot be applied to native components, such as: Unable to set CSS animation on native component Unable to define native component as position: fixed Unable to use overflow on parent node: The bindEventName is only supported for bindEventName. The catch and capture event bindings are also not supported for native components. For the time being, touch related events are not supported in native components. In terms of tools, native components are emulated with Web components, so in many cases, it is not very good to restore the performance of the real machine. It is recommended that developers try to debug on the real machine when using native components.


The so-called Native components, that is, non-Web components system extension Native components. Because the applet uses WebView in view rendering, while in components such as Video and Map, the experience of WebCore rendering using WebView has always been criticized, and the standards are different. The applet cannot extend the Web native tag because it uses the native WebView for rendering, rather than the modified WebView kernel (at least not on iOS). Based on user experience and technical limitations, the applet proposes the concept of native components, which is to fix the user experience problems of such components by filling in placeholder elements with native components on the WebView. Since WebView and native components are not a rendering level in the application layer themselves, the labels on the Web cannot float above the Video (the nightmare of live streaming applications). Under the premise of not changing the technical ideas, position: fixed, overflow: An attribute such as hidden is not likely to be used for styling a native component. Pseudo-layering is not impossible, however, as it is possible to render native components according to the level of the hollowed-out area.

Especially, there has always been the criticism of poor experience after using WebView as rendering on Map, especially in heavy scenes with too many marker markers on the Map. The C-end provided by the Web end of AutoNavi Map in the company where the author works has anti-human experience, such as Map dragging speed and slow click response. Loading map area waiting too long. Video, on the other hand, supports a limited number of formats. Some browsers support the following:

Firefox supports Ogg Vorbis and Wav Opera supports Ogg Vorbis and Wav Safari supports MP3, AAC, and MP4 Chrome: Supports Ogg Vorbis, MP3, WAV, AAC and MP4 Internet Explorer 9+ : Supports MP3, AAC formats, and MP4 iOS: Supports MP3, AAC formats, and MP4 Android: Supports AAC and MP3

Above, you can see that video support is limited (copyright only). As for the mobile terminal iOS and Android that we focus on, we may have the following requirements to achieve a video playback: 1. Fullscreen processing; 2. Overburden effect; 3. Automatic playback; 4. Play control; 5. Hide the playback control; On iOS, the fact that you can’t change the tools in full screen with WebView is enough to drive any product manager crazy, let alone on so many Android devices. Overlay effects on WeChat have to use WeChat to provide a native Cover-View implementation, which is limited by the native implementation.

Design scheme

1. The component layer is above the WebView layer

This should also be the approach the WeChat small program team is using at this stage, using GetboundingClientRect to get the component location through a special placeholder label, while the native components scroll along with the WebView.

Talking is cheap. Show me your code. Here’s what you can do with your code.

As you can see from the figure, the overlay does lie below the native component.

2. The component layer is below the WebView layer

This approach is slightly more complicated. It needs to be implemented by the Component Layer under the WebView scroll, which is linked to the WebView, and the WebView background is set to transparent. As for events, they are passed to the Component Layer through the WebView event passthrough, which is implemented by overriding the hitTest method by caching the elements in the WebView and then calculating whether they are clicked. The benefits of implementing this technical approach are also obvious, as the Native component layer is often at the bottom of the heap, while components on the Web can easily overlay Native without the need for hacks such as cover-views.

The effect is shown below


There’s one thing in particular to watch out for on iOS about UIWebView pits. When using -webkit-overflow-scrolling, you will notice that the Momentum Scroll phase does not trigger a scroll event, and the scrollTop property does not change, and of course GetboundingClientRect is also invalid. If you consider using an event like TouchMove you will fire only when your finger is still on the screen, and the GetboundingClientRect that detects elements inside the scrolling area is also invalid.

And of course, luckily, this big hole only happens in UIWebView, it doesn’t affect WKWebView.