Modify layout-related UI behavior from the browser kernel level

Specifically, there are several different levels of code modification.

At the bottom of the layer tree hardware synthesis acceleration part of the modification, at this level you can do is to let a layer display up or down, and the page's JS code does not know this at all, but note that page interaction depends on the hittest role in this layer, One of the topmost Renderlayer objects is first hittest tested. So you have to make sure that the original HitTest logic is not affected, and the idea is to maintain two sets of indexes: for display, and for model.

Next you can modify the RenderObject layer. In fact, this layer is the core of layout. You need to understand the different renderobject of the OOP hierarchy. For example, the text corresponds to RenderText and the image corresponds to RenderImage. The difference is that when the text is re-layout, the Inlinetextbox that RenderText owns may delete the rebuild, and the structure of the render object's local render subtree may change when the display property of the DOM element changes. When this layer is modified, you may need to use a tool such as the DRT (Dumprendertree) to see the structure of the render subtree unless you have a deep understanding of the WebKit layout principle. Once a subtree property of the render tree has been modified, it can be setneedslayout, and the next layout callback will trigger the re-layout. Note: Triggering a re-layout does not reapply parsing of the CSS string data.

In fact, the current web specification is only for the DOM tree, that is, JS can only change the appearance of the display by setting the style of the DOM element. Recently there is an CSSOM specification, but only for the CSS Computedstyle, has not reached the ability to arbitrarily manipulate JS to modify the render tree level, in fact I hope this can be done. For example, CSS selector can be compiled into machine code with LLVM, and there should be no problem with performance.

Next is the renderobject associated RenderStyle, which is actually the CSS Computedstyle. Because they are data that is parsed from the DOM CSS layer's string parsing and are also dependent on renderobject, modifying this layer may require special attention.

Then to the DOM layer, in the browser kernel directly modify the DOM seems unnecessary, theoretically, should be injected into JavaScript code (USERSCRIPT class plug-in) to do, the problem is some event callback, special state values from the Js/dom defined by the The API is not necessarily available, or can be acquired but cumbersome, so it is necessary to modify the style property of the DOM element object directly in the kernel. Remember that the values set here are string-type CSS values, and the value that is actually set will require further parsing of the application. The advantage is that you don't have to worry about how to consistently apply setneedsstylerecacle such a status bit. The downside is that performance may not be optimal.

The browser kernel also has some kind of contextual concept like the Linux kernel. In a Linux kernel driver, you cannot invoke a function that causes sleep in the context of an interrupt--that can cause a deadlock to trigger kernel panic. The browser kernel also has a similar concept, and you need to understand which thread the current code is running on, in general, a thread cannot modify the state that the B thread owns. Several basic threads: the main ui/event callback, JS, network IO, and so on. Sometimes it is not possible to directly initiate a nested function call, but to set the state first and then wait for the next layout callback to be applied.

Finally, it is the method of injecting JS directly from the WebView interface of the application layer. In fact, this layer can do a lot of things, for example, you cannot directly modify the display of a text object through the DOM API (of course, you can modify the entire text containing the block, but there is no way to directly modify a character), but can indirectly do: by first wrapping a Range object, The Range object is then placed in a new DIV element. The biggest problem with this is changing the structure of the DOM tree, but it's still acceptable.

Modify layout-related UI behavior from the browser kernel level