The reason the input coordinates are transformed as though we were pinch-zoomed in is that we _are_ pinch-zoomed in, as far as the state stored in `PresShell::mResolution` is concerned. When the page is in desktop mode but the video is not yet fullscreen, the CSS viewport (initial containing block) width is 980 CSS pixels (that's our [desktop-mode viewport width](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/modules/libpref/init/StaticPrefList.yaml#1886-1889)), and the content width of the page when reflowed into that ICB is 1100 CSS pixels. This does not fill the screen width at unit resolution (1920 device pixels / 1.5 device pixel scale = 1280 > 1100), so we render at a resolution of 1.16 to scale up the contents to fit the screen width. When we enter fullscreen mode: * the CSS viewport width is recomputed to fit the screen at unit resolution (i.e. in this case to 1280 CSS pixels), by taking [this branch](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/dom/base/Document.cpp#10636) in `Document::GetViewportInfo()` rather than [this branch](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/dom/base/Document.cpp#10628) * this behaviour was introduced in bug 1696717 * the resolution is [updated](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/dom/base/Document.cpp#15820-15822) in `Document::ApplyFullscreen()` The intention of the code in `ApplyFullscreen()` is to update the resolution to the "intrinsic resolution", which is the resolution that makes the ICB width fit the screen width. The code pre-dates bug 1696717, and so doesn't assume that this resolution is necessarily 1 (prior to bug 1696717, we would have kept the ICB width at 980px in fullscreen mode, and required the resolution to be at e.g. 1.31 to fit the screen). The bug occurs by running into the following failure mode (which happens most of the time): `ApplyFullscreen()` fails to compute the correct intrinsic resolution, because it reads the ICB size from [`MobileViewportManager::mMobileViewportSize`](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/layout/base/MobileViewportManager.cpp#94) before that hast been updated to reflect the new ICB size in fullscreen mode (i.e. it's still at 980px, not 1280px). We therefore set the resolution to an unintended value (such as 1.31). A tweak to `ComputeIntrinsicResolution()` to use the up-to-date `GetViewportInfo().GetSize()` rather than the stored `mMobileViewportSize` fixes the bug for me locally. One thing I do not yet understand is: if the resolution is 1.31 when the video is in fullscreen mode and we have reflowed the page into a 1280 CSS pixel ICB, why isn't the video visually zoomed in (such that its left and bottom parts, including the bottom bar are offscreen)?
Bug 1889017 Comment 18 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
The reason the input coordinates are transformed as though we were pinch-zoomed in is that we _are_ pinch-zoomed in, as far as the state stored in `PresShell::mResolution` is concerned. When the page is in desktop mode but the video is not yet fullscreen, the CSS viewport (initial containing block) width is 980 CSS pixels (that's our [desktop-mode viewport width](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/modules/libpref/init/StaticPrefList.yaml#1886-1889)), and the content width of the page when reflowed into that ICB is 1100 CSS pixels. This does not fill the screen width at unit resolution (1920 device pixels / 1.5 device pixel scale = 1280 > 1100), so we render at a resolution of 1.16 to scale up the contents to fit the screen width. When we enter fullscreen mode: * the CSS viewport width is recomputed to fit the screen at unit resolution (i.e. in this case to 1280 CSS pixels), by taking [this branch](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/dom/base/Document.cpp#10636) in `Document::GetViewportInfo()` rather than [this branch](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/dom/base/Document.cpp#10628) * this behaviour was introduced in bug 1696717 * the resolution is [updated](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/dom/base/Document.cpp#15820-15822) in `Document::ApplyFullscreen()` The intention of the code in `ApplyFullscreen()` is to update the resolution to the "intrinsic resolution", which is the resolution that makes the ICB width fit the screen width. The code pre-dates bug 1696717, and so doesn't assume that this resolution is necessarily 1 (prior to bug 1696717, we would have kept the ICB width at 980px in fullscreen mode, and required the resolution to be at e.g. 1.31 to fit the screen). The bug occurs by running into the following failure mode (which happens most of the time): `ApplyFullscreen()` fails to compute the correct intrinsic resolution, because it reads the ICB size from [`MobileViewportManager::mMobileViewportSize`](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/layout/base/MobileViewportManager.cpp#94) before that has been updated to reflect the new ICB size in fullscreen mode (i.e. it's still at 980px, not 1280px). We therefore set the resolution to an unintended value (such as 1.31). A tweak to `ComputeIntrinsicResolution()` to use the up-to-date `GetViewportInfo().GetSize()` rather than the stored `mMobileViewportSize` fixes the bug for me locally. One thing I do not yet understand is: if the resolution is 1.31 when the video is in fullscreen mode and we have reflowed the page into a 1280 CSS pixel ICB, why isn't the video visually zoomed in (such that its left and bottom parts, including the bottom bar are offscreen)?
The reason the input coordinates are transformed as though we were pinch-zoomed in is that we _are_ pinch-zoomed in, as far as the state stored in `PresShell::mResolution` is concerned. When the page is in desktop mode but the video is not yet fullscreen, the CSS viewport (initial containing block) width is 980 CSS pixels (that's our [desktop-mode viewport width](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/modules/libpref/init/StaticPrefList.yaml#1886-1889)), and the content width of the page when reflowed into that ICB is 1100 CSS pixels. This does not fill the screen width at unit resolution (1920 device pixels / 1.5 device pixel scale = 1280 > 1100), so we render at a resolution of 1.16 to scale up the contents to fit the screen width. When we enter fullscreen mode: * the CSS viewport width is recomputed to fit the screen at unit resolution (i.e. in this case to 1280 CSS pixels), by taking [this branch](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/dom/base/Document.cpp#10636) in `Document::GetViewportInfo()` rather than [this branch](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/dom/base/Document.cpp#10628) * this behaviour was introduced in bug 1696717 * the resolution is [updated](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/dom/base/Document.cpp#15820-15822) in `Document::ApplyFullscreen()` The intention of the code in `ApplyFullscreen()` is to update the resolution to the "intrinsic resolution", which is the resolution that makes the ICB width fit the screen width. The code pre-dates bug 1696717, and so doesn't assume that this resolution is necessarily 1 (prior to bug 1696717, we would have kept the ICB width at 980px in fullscreen mode, and required the resolution to be at e.g. 1.31 to fit the screen). The bug occurs by running into the following failure mode (which happens most of the time): `ApplyFullscreen()` fails to compute the correct intrinsic resolution, because it reads the ICB size from [`MobileViewportManager::mMobileViewportSize`](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/layout/base/MobileViewportManager.cpp#94) before that has been updated to reflect the new ICB size in fullscreen mode (i.e. it's still at 980px, not 1280px). We therefore set the resolution to an unintended value (such as 1.31). A tweak to `ComputeIntrinsicResolution()` to use the up-to-date `GetViewportInfo().GetSize()` rather than the stored `mMobileViewportSize` fixes the bug for me locally. One thing I do not yet understand is: if the resolution is 1.31 when the video is in fullscreen mode and we have reflowed the page into a 1280 CSS pixel ICB, why isn't the video visually zoomed in (such that its left and bottom parts, including the bottom bar, are offscreen)? That's what I would expect the rendering to be in this state (and if that _were_ the rendering, the underlying bug would be much more obvious from the get-go).
The reason the input coordinates are transformed as though we were pinch-zoomed in is that we _are_ pinch-zoomed in, as far as the state stored in `PresShell::mResolution` is concerned. When the page is in desktop mode but the video is not yet fullscreen, the CSS viewport (initial containing block) width is 980 CSS pixels (that's our [desktop-mode viewport width](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/modules/libpref/init/StaticPrefList.yaml#1886-1889)), and the content width of the page when reflowed into that ICB is 1100 CSS pixels. This does not fill the screen width at unit resolution (1920 device pixels / 1.5 device pixel scale = 1280 > 1100), so we render at a resolution of 1.16 to scale up the contents to fit the screen width. When we enter fullscreen mode: * the CSS viewport width is recomputed to fit the screen at unit resolution (i.e. in this case to 1280 CSS pixels), by taking [this branch](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/dom/base/Document.cpp#10636) in `Document::GetViewportInfo()` rather than [this branch](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/dom/base/Document.cpp#10628) * this behaviour was introduced in bug 1696717 * the resolution is [updated](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/dom/base/Document.cpp#15820-15822) in `Document::ApplyFullscreen()` The intention of the code in `ApplyFullscreen()` is to update the resolution to the "intrinsic resolution", which is the resolution that makes the ICB width fit the screen width. The code pre-dates bug 1696717, and so doesn't assume that this resolution is necessarily 1 (prior to bug 1696717, we would have kept the ICB width at 980px in fullscreen mode, and required the resolution to be at e.g. 1.31 to fit the screen). The bug occurs by running into the following failure mode (which happens most of the time): `ApplyFullscreen()` fails to compute the correct intrinsic resolution, because it reads the ICB size from [`MobileViewportManager::mMobileViewportSize`](https://searchfox.org/mozilla-central/rev/a95ca2357da6bccc6c5b12f662dd8a4e5bcbf892/layout/base/MobileViewportManager.cpp#94) before that has been updated to reflect the new ICB size in fullscreen mode (i.e. it's still at 980px, not 1280px). We therefore set the resolution to an unintended value (such as 1.31). A tweak to `ComputeIntrinsicResolution()` to use the up-to-date `GetViewportInfo().GetSize()` rather than the stored `mMobileViewportSize` fixes the bug for me locally. One thing I do not yet understand is: if the resolution is 1.31 when the video is in fullscreen mode and we have reflowed the page into a 1280 CSS pixel ICB, why isn't the video visually zoomed in (such that its right and bottom parts, including the bottom bar, are offscreen)? That's what I would expect the rendering to be in this state (and if that _were_ the rendering, the underlying bug would be much more obvious from the get-go).