Open Bug 1544417 Opened 5 months ago Updated 15 days ago

Implement Emulation.setDeviceMetricsOverride's width and height arguments

Categories

(Remote Protocol :: Emulation, enhancement, P1)

enhancement

Tracking

(Not tracked)

People

(Reporter: ochameau, Unassigned)

References

(Blocks 1 open bug)

Details

Attachments

(2 files)

https://chromedevtools.github.io/devtools-protocol/tot/Emulation#method-setDeviceMetricsOverride
Emulation.setDeviceMetricsOverride:
Overrides the values of device screen dimensions (window.screen.width, window.screen.height, window.innerWidth, window.innerHeight, and "device-width"/"device-height"-related CSS media query results).

For now we exposed Emulation.setDeviceMetricsOverride but with an empty implementation:
https://searchfox.org/mozilla-central/rev/0376cbf447efa16922c550da3bfd783b916e35d3/remote/domains/content/Emulation.jsm#14

Wordpress test suites uses it to change the viewport size over here:
https://github.com/WordPress/gutenberg/blob/b786aad41b4670190b6cac4d99bab3abd3f85049/packages/e2e-test-utils/src/set-browser-viewport.js#L17-L18
and relies on setDeviceMetricsOverride to update the page width and height.
It only requires to implement setDeviceMetricsOverride's width and height arguments.

Component: Agent → Emulation
Type: defect → enhancement
Priority: -- → P3
Priority: P3 → P2

Chrome seems to have a different approach concerning the implementation. When resizing the viewport Chrome only resizes the inner viewport, not the window.

Some consequences of this difference:
1/ you can resize to very small dimensions or very big dimensions, regardless of the limitations of the hardware/OS. The implementation attached here will time out in such cases.
2/ different tabs can be resized independently. Which means among other things that calling browser.newPage on Firefox resets the viewport for previous pages.

For the second patch attached here, I can't get the mentioned test to run properly and consistently.

On a sidenote, I think very few tests are currently blocked by having the empty implementation, so I think I will wait until more crucial APIs are landed to work on this.

(In reply to Julian Descottes [:jdescottes] from comment #3)

Chrome seems to have a different approach concerning the implementation. When resizing the viewport Chrome only resizes the inner viewport, not the window.

Oh that explain why juggler resize the <xul:browser> element:
https://github.com/puppeteer/juggler/blob/master/testing/juggler/protocol/PageHandler.js#L54-L77
https://github.com/puppeteer/juggler/blob/master/testing/juggler/content/PageAgent.js#L31-L43

I found it so weird to do that, but I did not realized it was actually similar to what happens in chrome.
I thought it was a workaround to not have to handle the size of chrome elements.

For the second patch attached here, I can't get the mentioned test to run properly and consistently.

This test is intermittent. It still fails quite often with:

Preview
    ✕ should open a preview window for a new post (7926ms)

  ● Preview › should open a preview window for a new post

    INTERNAL ERROR: missing context with id = 12884901905

(In reply to Julian Descottes [:jdescottes] from comment #3)

1/ you can resize to very small dimensions or very big
dimensions, regardless of the limitations of the hardware/OS. The
implementation attached here will time out in such cases.

But this is ony in headless mode, right?

I believe we can support limitless resizing in headless mode because
all the painting code is mocked out, which means we’re not limited
by the hardware/OS. In normal windowed mode, I would think both
Chrome and we are limited by the surrounding system.

2/ different tabs can be resized independently. Which means among
other things that calling browser.newPage on Firefox resets the
viewport for previous pages.

Interesting find.

(In reply to Alexandre Poirot [:ochameau] from comment #4)

Oh that explain why juggler resize the <xul:browser> element:
https://github.com/puppeteer/juggler/blob/master/testing/juggler/protocol/PageHandler.js#L54-L77
https://github.com/puppeteer/juggler/blob/master/testing/juggler/content/PageAgent.js#L31-L43

I found it so weird to do that, but I did not realized it was actually similar to what happens in chrome.
I thought it was a workaround to not have to handle the size of chrome elements.

Would we be OK to do that?

I guess the primary mode of operation for Puppeteer is headless,
so the users wouldn’t necessarily notice the <xul:browser> extending
beyond the visible application window. But how would we reconcile
this in windowed mode?

(In reply to Andreas Tolfsen 「:ato」 from comment #5)

(In reply to Julian Descottes [:jdescottes] from comment #3)

1/ you can resize to very small dimensions or very big
dimensions, regardless of the limitations of the hardware/OS. The
implementation attached here will time out in such cases.

But this is ony in headless mode, right?

No, it's also the case in regular/non-headless mode.

Few tests impacted, ni? to list impacted tests.

Flags: needinfo?(jdescottes)
Priority: P2 → P3

Setting back to P2, most tests will timeout if we don't resize the window to the proper size at the beginning of the test.

Flags: needinfo?(jdescottes)
Priority: P3 → P2
Assignee: nobody → jdescottes
Status: NEW → ASSIGNED
Priority: P2 → P1
Assignee: jdescottes → nobody
Status: ASSIGNED → NEW
You need to log in before you can comment on or make changes to this bug.