On Wednesday, April 12, 2017 at 1:32:40 AM UTC-5, Paul Rouget wrote: > We have been experimenting with embedding Servo in 3rd party rust > application, with the goal to understand better the needs of > embedders, identify issues with current Servo implementation, and > determine which features we wish to be exposed. Some early findings > are documented here: > https://github.com/paulrouget/servoshell/projects/2. Eventually, we > want to get rid of the Browser API, extract it in its own 3rd party > project (if you want to hear more about this, talk to me or Till). > > Some work is already in progress to improve the embedding story > (improving startup code, support multiple top level frame, cosmetic > changes in the servo events/callbacks, exposing history). > > Until the basics of the embedding mechanism is in place, I'd like to > highlight some areas of the engine we are particularly interested in > leveraging in the future. If you are working on any of these features, > and planning to do some fundamental changes, we'd love to be involved > in the discussion: > > - Joint session history: at the moment, the way history is exposed is > very basic (a flatten version of the joint session history). In the > future, we would like the embedder to have better control over the > history and the state of the pipelines (conversation already started > with Alan) > - Multiple compositor/WR instances: this will be a requirement > eventually. From our side, this is blocked on supporting more than one > top level browsing context (work in progress). I know that the work > has already started. This will have an impact on startup code (at the > moment, startup creates the constellation + one (only) browser + one > (only) WR instance). > - Prerendering: we will want to prerender documents. A special kind of > pipeline with black-listed functionalities. > - Navigation hooks: navigating from a top level document should always > involve the embedder (see #15795) > - Browser restoration / LoadData: undoing tab closing, restoring a > session, or cloning a tab, will require serializing the state of a > document. At the moment, we believe this will rely on the LoadData > structure. So we are planning to make LoadData an important part of > the embedding API > - Content blocking: we identify 4 types of content blockers (popup, > tracking, mixed content, custom (extensions / ad blockers for > example)). Not sure how these will work > - libservo public methods / event, and startup code > > If your work is related to any these features, I'd appreciate if you > could cc me to the relevant github issue! > > Thank you.
>From the peanut gallery, when building a WYSIWYG editor using an embedded web >browser as the UI it might be helpful to be able to have some hooks into the >undo / redo stack. For example with a textarea element the browser has an undo / redo history (undoing a few words at a time) that is more sophisticated than can be observed watching value changes alone in the browser / js context. One may also want to be able to intercept and cancel undo / redo operations. For example, a user in the browser context types some text into a textarea. The textarea is then "moved" from the context of the parent app. The user then modifies text from the browser context in the textarea again. Ideally the user should be able to invoke undo through the browser state, the app state, and then the browser state again. The "best" solutions I have seen thus far sum up to trying to intercept the browser in the js context and try to manage undo / redo state in js. It would be great to have more control externally to know and control when records are added or removed from the undo / redo stack. _______________________________________________ dev-servo mailing list dev-servo@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-servo
