Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Hi,is there any docs that I can learn the new headless mode goal/requiremnets? I'm interested in how screen stuff will be used in the headless mode.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Hi,is there any docs that I can learn the new headless mode goal/requiremnets? I'm interested in how screen stuff will be used in the headless mode.
Sure, please check these links:
Chrome new Headless Mode: https://developer.chrome.com/docs/chromium/headless
New Headless Mode vs old Headless: https://developer.chrome.com/blog/chrome-headless-shell
Headless screen configuration: http://go/headless:screen
Dynamic headless screen configuration: http://go/headless:dynamic-screen
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
CHECK(screen);
I'm curious why `CHECK(screen)` if we call `screen->...` in the next line?
.SetIsExtended(screen_info.is_extended)
I wonder who's going to use things like `isExtended` or `isInternal`.
std::unique_ptr<protocol::Emulation::WorkAreaInsets> work_area_insets,
Does this correspond to `availTop` and similar? Why not use consistent naming in both places?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
I'm curious why `CHECK(screen)` if we call `screen->...` in the next line?
Changed it to the recommended way of de-referencing non null pointers.
I wonder who's going to use things like `isExtended` or `isInternal`.
Both are exposed to Web Platform, [here](https://developer.mozilla.org/en-US/docs/Web/API/Screen/isExtended) and [here](https://developer.mozilla.org/en-US/docs/Web/API/ScreenDetailed/isInternal).
`isExtended` tells us if there is more than one display in the system and `isInternal` suggests that the display can be removed from the system.
std::unique_ptr<protocol::Emulation::WorkAreaInsets> work_area_insets,
Does this correspond to `availTop` and similar? Why not use consistent naming in both places?
They are related, however, `availTop` etc. are reported relative to the primary screen origin at `{0,0}` in logical pixels whereas work area insets are specified relative to the edges of the screen being added and in device pixels.
The former is convenient when positioning UI elements on the screen, the process that happens in primary screen coordinate system. The latter is convenient because it specifies widths and heights of sidebars and toolbars on this particular screen we're adding, if any. The coordinate conversion math becomes non trivial especially when screens have different scale factors and we want it to be done by `ui/display` core.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Peter KvitekHi,is there any docs that I can learn the new headless mode goal/requiremnets? I'm interested in how screen stuff will be used in the headless mode.
Sure, please check these links:
Chrome new Headless Mode: https://developer.chrome.com/docs/chromium/headless
New Headless Mode vs old Headless: https://developer.chrome.com/blog/chrome-headless-shell
Headless screen configuration: http://go/headless:screen
Dynamic headless screen configuration: http://go/headless:dynamic-screen
thanks,
Am I correct that new headless means "nvisible/offscreen UI" instead of "no UI"?
Is UI code supposed to run as if there is a display (e.g. it receives begin frame from viz process) ?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Peter KvitekHi,is there any docs that I can learn the new headless mode goal/requiremnets? I'm interested in how screen stuff will be used in the headless mode.
Mitsuru OshimaSure, please check these links:
Chrome new Headless Mode: https://developer.chrome.com/docs/chromium/headless
New Headless Mode vs old Headless: https://developer.chrome.com/blog/chrome-headless-shell
Headless screen configuration: http://go/headless:screen
Dynamic headless screen configuration: http://go/headless:dynamic-screen
thanks,
Am I correct that new headless means "nvisible/offscreen UI" instead of "no UI"?
Is UI code supposed to run as if there is a display (e.g. it receives begin frame from viz process) ?
Yes, the new headless is a mode of operation of the regular Chrome in which UI is not displayed on any physical screen. This makes all existing and future Chrome features available for test automation.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Peter KvitekHi,is there any docs that I can learn the new headless mode goal/requiremnets? I'm interested in how screen stuff will be used in the headless mode.
Mitsuru OshimaSure, please check these links:
Chrome new Headless Mode: https://developer.chrome.com/docs/chromium/headless
New Headless Mode vs old Headless: https://developer.chrome.com/blog/chrome-headless-shell
Headless screen configuration: http://go/headless:screen
Dynamic headless screen configuration: http://go/headless:dynamic-screen
Peter Kvitekthanks,
Am I correct that new headless means "nvisible/offscreen UI" instead of "no UI"?
Is UI code supposed to run as if there is a display (e.g. it receives begin frame from viz process) ?
Yes, the new headless is a mode of operation of the regular Chrome in which UI is not displayed on any physical screen. This makes all existing and future Chrome features available for test automation.
So this is for test automation? I believe Windows and mac team was also working on virtual display support (and Linux and Cros can run test without physical displays). Is this to replace them?
Are you also going to support OS level integration tests or just for unit/browser tests?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Peter KvitekHi,is there any docs that I can learn the new headless mode goal/requiremnets? I'm interested in how screen stuff will be used in the headless mode.
Mitsuru OshimaSure, please check these links:
Chrome new Headless Mode: https://developer.chrome.com/docs/chromium/headless
New Headless Mode vs old Headless: https://developer.chrome.com/blog/chrome-headless-shell
Headless screen configuration: http://go/headless:screen
Dynamic headless screen configuration: http://go/headless:dynamic-screen
Peter Kvitekthanks,
Am I correct that new headless means "nvisible/offscreen UI" instead of "no UI"?
Is UI code supposed to run as if there is a display (e.g. it receives begin frame from viz process) ?
Mitsuru OshimaYes, the new headless is a mode of operation of the regular Chrome in which UI is not displayed on any physical screen. This makes all existing and future Chrome features available for test automation.
So this is for test automation? I believe Windows and mac team was also working on virtual display support (and Linux and Cros can run test without physical displays). Is this to replace them?
Are you also going to support OS level integration tests or just for unit/browser tests?
[Virtual Display Support](https://chromium.googlesource.com/chromium/src/+/main/docs/ui/display/multiscreen_testing.md) is internal, inherently platform specific and tricky to maintain/use, see, for example, [here](https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/ui/exclusive_access/fullscreen_controller_interactive_browsertest.cc;l=1211-1216?q=chrome%2Fbrowser%2Fui%2Fexclusive_access%2Ffullscreen_controller_interactive_browsertest.cc&ss=chromium%2Fchromium%2Fsrc). As a result, the tests that rely on virtual displays are often [skipped](https://ci.chromium.org/ui/test/chromium/ninja%3A%2F%2Fchrome%2Ftest%3Ainteractive_ui_tests%2FMultiScreenFullscreenControllerInteractiveTest.BrowserFullscreenContentFullscreenSwapDisplay).
Headless Mode does not use underlying platform physical screens, so can emulate any desired screen configuration. The tests that rely on headless screen configuration do not require any platform specific configuration and are much simpler to write/maintain, see [here](https://source.chromium.org/chromium/chromium/src/+/main:components/headless/test/data/protocol/shared/window-zoom-on-secondary-screen.js). It is also available for external web developers.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Peter KvitekHi,is there any docs that I can learn the new headless mode goal/requiremnets? I'm interested in how screen stuff will be used in the headless mode.
Mitsuru OshimaSure, please check these links:
Chrome new Headless Mode: https://developer.chrome.com/docs/chromium/headless
New Headless Mode vs old Headless: https://developer.chrome.com/blog/chrome-headless-shell
Headless screen configuration: http://go/headless:screen
Dynamic headless screen configuration: http://go/headless:dynamic-screen
Peter Kvitekthanks,
Am I correct that new headless means "nvisible/offscreen UI" instead of "no UI"?
Is UI code supposed to run as if there is a display (e.g. it receives begin frame from viz process) ?
Mitsuru OshimaYes, the new headless is a mode of operation of the regular Chrome in which UI is not displayed on any physical screen. This makes all existing and future Chrome features available for test automation.
Peter KvitekSo this is for test automation? I believe Windows and mac team was also working on virtual display support (and Linux and Cros can run test without physical displays). Is this to replace them?
Are you also going to support OS level integration tests or just for unit/browser tests?
[Virtual Display Support](https://chromium.googlesource.com/chromium/src/+/main/docs/ui/display/multiscreen_testing.md) is internal, inherently platform specific and tricky to maintain/use, see, for example, [here](https://source.chromium.org/chromium/chromium/src/+/main:chrome/browser/ui/exclusive_access/fullscreen_controller_interactive_browsertest.cc;l=1211-1216?q=chrome%2Fbrowser%2Fui%2Fexclusive_access%2Ffullscreen_controller_interactive_browsertest.cc&ss=chromium%2Fchromium%2Fsrc). As a result, the tests that rely on virtual displays are often [skipped](https://ci.chromium.org/ui/test/chromium/ninja%3A%2F%2Fchrome%2Ftest%3Ainteractive_ui_tests%2FMultiScreenFullscreenControllerInteractiveTest.BrowserFullscreenContentFullscreenSwapDisplay).
Headless Mode does not use underlying platform physical screens, so can emulate any desired screen configuration. The tests that rely on headless screen configuration do not require any platform specific configuration and are much simpler to write/maintain, see [here](https://source.chromium.org/chromium/chromium/src/+/main:components/headless/test/data/protocol/shared/window-zoom-on-secondary-screen.js). It is also available for external web developers.
The display support in indeed platform specific and the problem above seems to be because virtual display support wasn't properly added for linux-chrome.
While this may be okay for WEB API testing, I have concern about making this as an generic solution for multi screen tests in chrome. The display support is inherently platform specific and actual behavior depends on underlying platform.
One of such issues is the coordinate system. CrOS / MacOS and Wayland uses DP based system, and you can layout displays in terms of DP, but Windows and X11 users pixel based coordinate system, and so certain configuration/layout that is possible on DP based system is not possible on pixel based system, and such different may results in incorrect testing.
I think if we can limit this for HTML API testing, that'd be okay but should avoid using this for native chrome testing.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Absolutely! The primary target users of headless are Web Platform Tests and web developers.
Testing with headless is not intended to replace any existing tests. Rather, it complements existing testing by providing an accessible, repeatable, and platform-independent testing environment for web developers who use automation.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Please make sure document it accordingly. I've seen cases where test harness were used incorrectly, which leads to incorrect testing.
Support on Windows and Mac will be added by the follow up CLs.
The link you provided (MultiScreenFullscreenControllerInteractiveTest
) implies virtual display works on Win/Mac/CrOS. What is the issue in using them?
(at least, the multi display testing should be fully functional on CrOS )
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Ack. Mitsuru, we’re planning to publish a public web developer-facing blog post announcing the Headless screen-info functionality in the coming weeks. We’ll make sure to clearly capture this nuance.
Could you please review the CL? Any concerns about the code itself?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Support on Windows and Mac will be added by the follow up CLs.
The link you provided (MultiScreenFullscreenControllerInteractiveTest
) implies virtual display works on Win/Mac/CrOS. What is the issue in using them?(at least, the multi display testing should be fully functional on CrOS )
I'm not sure I follow, could you please be more specific re: MultiScreenFullscreenControllerInteractiveTest?
Headless Mode is currently supported on Linux, Windows and Mac only. It is not supported on CrOS at this time.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Support on Windows and Mac will be added by the follow up CLs.
Peter KvitekThe link you provided (MultiScreenFullscreenControllerInteractiveTest
) implies virtual display works on Win/Mac/CrOS. What is the issue in using them?(at least, the multi display testing should be fully functional on CrOS )
I'm not sure I follow, could you please be more specific re: MultiScreenFullscreenControllerInteractiveTest?
Headless Mode is currently supported on Linux, Windows and Mac only. It is not supported on CrOS at this time.
My undestanding is that the goal of this new headless mode was to support multi display in test automation on linux, as the virtual dispplay isn't available on linux.
This CL makese sense because the display emulation isn't available on liux, but if you're going to expand this to other platforms, I'd like to know what is the issue in using virtual display in tests.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Support on Windows and Mac will be added by the follow up CLs.
Peter KvitekThe link you provided (MultiScreenFullscreenControllerInteractiveTest
) implies virtual display works on Win/Mac/CrOS. What is the issue in using them?(at least, the multi display testing should be fully functional on CrOS )
Mitsuru OshimaI'm not sure I follow, could you please be more specific re: MultiScreenFullscreenControllerInteractiveTest?
Headless Mode is currently supported on Linux, Windows and Mac only. It is not supported on CrOS at this time.
My undestanding is that the goal of this new headless mode was to support multi display in test automation on linux, as the virtual dispplay isn't available on linux.
This CL makese sense because the display emulation isn't available on liux, but if you're going to expand this to other platforms, I'd like to know what is the issue in using virtual display in tests.
I think there's a bit of confusion here. Headless Chrome is production code that we ship to all users of chrome. Yes, it's often used in tests (by the external developers to test their sites and applications, not by chrome developers to test chrome), but its use goes well beyond testing application (web harvesting, agentic use etc) -- pretty much every use case where chrome runs unattended. We should not use anything that is under test/ or has a word test in its name in the production code, so relying on VirtualDisplayUtil in its present shape is not an option. If you have a suggested course of action other than approach taken in this CL, we would appreciate a direct suggestion here. If not, can we please proceed with the actual review of the code here?
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Code-Review | +1 |
thank you for clarification. lgmt with one nit, and also one request for future work. Because all ozone platforms are also aura, I think we can create headless screen for aura and use it for all ozone platforms.
private:
This private isn't much userful because you can always use superclass to acccess them. Just keep them public.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Support on Windows and Mac will be added by the follow up CLs.
Peter KvitekThe link you provided (MultiScreenFullscreenControllerInteractiveTest
) implies virtual display works on Win/Mac/CrOS. What is the issue in using them?(at least, the multi display testing should be fully functional on CrOS )
Mitsuru OshimaI'm not sure I follow, could you please be more specific re: MultiScreenFullscreenControllerInteractiveTest?
Headless Mode is currently supported on Linux, Windows and Mac only. It is not supported on CrOS at this time.
Andrey KosyakovMy undestanding is that the goal of this new headless mode was to support multi display in test automation on linux, as the virtual dispplay isn't available on linux.
This CL makese sense because the display emulation isn't available on liux, but if you're going to expand this to other platforms, I'd like to know what is the issue in using virtual display in tests.
I think there's a bit of confusion here. Headless Chrome is production code that we ship to all users of chrome. Yes, it's often used in tests (by the external developers to test their sites and applications, not by chrome developers to test chrome), but its use goes well beyond testing application (web harvesting, agentic use etc) -- pretty much every use case where chrome runs unattended. We should not use anything that is under test/ or has a word test in its name in the production code, so relying on VirtualDisplayUtil in its present shape is not an option. If you have a suggested course of action other than approach taken in this CL, we would appreciate a direct suggestion here. If not, can we please proceed with the actual review of the code here?
Got in sync during an online meeting, and confirmed it's all clear now. Thank you all for participating!
This private isn't much userful because you can always use superclass to acccess them. Just keep them public.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
13 is the latest approved patch-set.
The change was submitted with unreviewed changes in the following files:
```
The name of the file: ui/ozone/platform/headless/headless_screen.h
Insertions: 1, Deletions: 1.
The diff is too large to show. Please review the diff.
```
[headless] Add DevTools screen management APIs to headless mode on Linux
http://crrev.com/c/6828750 added Emulation.getScreenInfos, .addScreen
and .removeScreen APIs to headless shell. This CL implements these APIs
in Chrome Headless Mode on Linux.
Support on Windows and Mac will be added by the follow up CLs.
Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |