{"action":"created","issue":{"url":"https://api.github.com/repos/servo/servo/issues/21333","repository_url":"https://api.github.com/repos/servo/servo","labels_url":"https://api.github.com/repos/servo/servo/issues/21333/labels{/name}","comments_url":"https://api.github.com/repos/servo/servo/issues/21333/comments","events_url":"https://api.github.com/repos/servo/servo/issues/21333/events","html_url":"https://github.com/servo/servo/issues/21333","id":347269725,"node_id":"MDU6SXNzdWUzNDcyNjk3MjU=","number":21333,"title":"[meta] UI for Desktop port","user":{"login":"paulrouget","id":373579,"node_id":"MDQ6VXNlcjM3MzU3OQ==","avatar_url":"https://avatars0.githubusercontent.com/u/373579?v=4","gravatar_id":"","url":"https://api.github.com/users/paulrouget","html_url":"https://github.com/paulrouget","followers_url":"https://api.github.com/users/paulrouget/followers","following_url":"https://api.github.com/users/paulrouget/following{/other_user}","gists_url":"https://api.github.com/users/paulrouget/gists{/gist_id}","starred_url":"https://api.github.com/users/paulrouget/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/paulrouget/subscriptions","organizations_url":"https://api.github.com/users/paulrouget/orgs","repos_url":"https://api.github.com/users/paulrouget/repos","events_url":"https://api.github.com/users/paulrouget/events{/privacy}","received_events_url":"https://api.github.com/users/paulrouget/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":4,"created_at":"2018-08-03T06:01:50Z","updated_at":"2018-08-09T16:38:11Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"We eventually want to have a minimal UI for the desktop port.\r\n\r\nThis would include a toolbar and a list of tabs.\r\n\r\nThe constrains we have are:\r\n- multiplatform (Linux/Windows/Mac)\r\n- in Rust or JS (we want to limit the amount of toolchain to support)\r\n- no intrusive changes in the engine (as in, under /components/) or web standards bending\r\n\r\nNon goals:\r\n- Innovative UI: we are not trying to build a next generation user interface. The UI will just be here to make it easier to test servo.\r\n- Mobile support: we already have an android port.\r\n\r\nMVP:\r\n- tabs\r\n- multi windows support\r\n- back, forward, reload, stop buttons and urlbar\r\n\r\n## Suggested approach\r\n\r\nThis requires 2 big changes:\r\n\r\n### 1. Graphic:\r\n\r\n- draw 2 WR documents in one glutin window: chrome and content\r\n- content WR document will display multiple top level pipelines, aka tabs (already supported)\r\n- chrome WR document will load one single HTML document, the UI\r\n\r\n### 2. Controls:\r\n\r\nports/servo/ will be in charge of all the wiring. All events from the content (see `EmbedderMsg`) will be used to update the state of the browser, in Rust. This state will forwarded to the chrome document as it changes. The chrome document will be able to send message back to ports/servo/.\r\n\r\nExample: **State forwarding: port to chrome document**. If the title of a web page changes, a Rust `EmbedderMsg` is sent to ports/servo, which will update the state of the browser. The state will then be forwarded to the chrome document, which will update its UI to reflect the new title. **Message passing: chrome document to port**. If the user clicks on the reload button, the chrome document will send a message to ports/servo that will perform the reload.\r\n\r\nThe state forwarding and the message passing mechanisms between the chrome document and ports/main still need to be defined. We don't want to introduce security issues and we don't want to invent a new standard. A possible approach would be to rely on postMessage. \r\n\r\n## Difference with browserhtml\r\n\r\nEven though the buttons and url will be drawn in HTML, this approach is different from browserhtml. We are not introducing new JS APIs, we do not introduce new HTML elements, we do not use iframes or webviews or mozbrowsers, and the browser logic is still written in Rust. The HTML/JS part will only be here to draw the UI based on the state sent from ports/servo.\r\n\r\n## Status\r\n\r\nNothing has been done yet for the controls part.\r\n\r\nFor the graphic part, WR already supports multiple documents (I believe this is how it works in Firefox+WR), but Servo's compositor doesn't. I have a WIP branch that introduces areas, which are WR documents in one GL buffer. See previous discussion about tab support: https://github.com/servo/servo/issues/20335\r\n\r\nFor multi windows support, still more work needs to be done at the compositor level: https://github.com/servo/servo/issues/13997\r\n\r\nScreenshot of a WIP prototype:\r\n\r\n![zind1jm](https://user-images.githubusercontent.com/373579/43626322-aaadf59e-96f1-11e8-9d08-ea608c43add2.png)"},"comment":{"url":"https://api.github.com/repos/servo/servo/issues/comments/411820587","html_url":"https://github.com/servo/servo/issues/21333#issuecomment-411820587","issue_url":"https://api.github.com/repos/servo/servo/issues/21333","id":411820587,"node_id":"MDEyOklzc3VlQ29tbWVudDQxMTgyMDU4Nw==","user":{"login":"fabricedesre","id":984767,"node_id":"MDQ6VXNlcjk4NDc2Nw==","avatar_url":"https://avatars0.githubusercontent.com/u/984767?v=4","gravatar_id":"","url":"https://api.github.com/users/fabricedesre","html_url":"https://github.com/fabricedesre","followers_url":"https://api.github.com/users/fabricedesre/followers","following_url":"https://api.github.com/users/fabricedesre/following{/other_user}","gists_url":"https://api.github.com/users/fabricedesre/gists{/gist_id}","starred_url":"https://api.github.com/users/fabricedesre/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/fabricedesre/subscriptions","organizations_url":"https://api.github.com/users/fabricedesre/orgs","repos_url":"https://api.github.com/users/fabricedesre/repos","events_url":"https://api.github.com/users/fabricedesre/events{/privacy}","received_events_url":"https://api.github.com/users/fabricedesre/received_events","type":"User","site_admin":false},"created_at":"2018-08-09T16:38:11Z","updated_at":"2018-08-09T16:38:11Z","author_association":"CONTRIBUTOR","body":"Let me recap a bit:\r\n- the chrome WR doc will render eg. the address bar and tap strip using HTML/CSS/js.\r\n- the Rust embedder will position content WR Docs, making all layout calculation to be positioned and sized properly and (usually) not overlap with the chrome doc.\r\n- when something like window.alert(\"Servo!\") is called, the Rust embedder decides how to handle it. This usually is tab-modal, so needs to be drawn on top of the content doc caller. It seems to me that this rules out rendering that by the chrome WR doc, and mandates rendering using a \"native\" toolkit instead.\r\n\r\nThat looks complicated, and I'm worried that it will be hard to achieve eg. consistent animations when using different rendering stacks.  I struggle to see how useful the chrome document is since it can't be used to render all the chrome UI."}}
{"actor":{"display_login":"fabricedesre"}}