Open Bug 1913951 Opened 6 months ago Updated 21 days ago

mako.co.il - Desktop version instead of mobile version received

Categories

(Web Compatibility :: Site Reports, defect, P3)

ARM
Android

Tracking

(Webcompat Priority:P2, firefox129 affected, firefox131 affected)

ASSIGNED
Webcompat Priority P2
Tracking Status
firefox129 --- affected
firefox131 --- affected

People

(Reporter: rbucata, Assigned: hiro)

References

(Depends on 1 open bug, Blocks 1 open bug, )

Details

(Keywords: webcompat:platform-bug, webcompat:site-report, Whiteboard: [webcompat-source:web-bugs])

User Story

platform:android
impact:significant-visual
configuration:general
affects:all
branch:release
diagnosis-team:layout

Attachments

(2 files)

Environment:
Operating system: Android 13
Firefox version: Firefox 129.0

Steps to reproduce:

  1. Navigate to: https://mako.co.il
  2. Observe

Expected Behavior:
Mobile version is received

Actual Behavior:
Desktop version is received

Notes:

  • Reproduces regardless of the status of ETP
  • Reproduces in Firefox Nightly, and Firefox Release
  • Does not reproduce in Chrome

Created from https://github.com/webcompat/web-bugs/issues/140604

I don't think it's the desktop side, but the mobile one. The problem is that the mobile website is broken, and the menu appears next to the main screen.

Severity: -- → S4
User Story: (updated)
Priority: -- → P3

This looks like an APZ figuring-out-the-layout-viewport-when-some-content-is-offscreen-to-the-right sort of issue, similar to bug 1911457.

This reproduces in responsive design mode usually (might require a shift+reload).

Quick analysis: In the initial page rendering, they place the menu off the right side of the screen, and we think that means we should zoom out so that it's visible, but of course the site doesn't intend for that to happen.

Specifically:

  • The body has overflow:hidden
  • The menu is absolutely positioned and shifted offscreen via transform:translate:
.Hamburger_sideMenu__bDy4P {
  transform: translate(100%);
  overflow: auto;
  background-color: #303a51;
  height: 100dvh;
  width: 460px;
  position: absolute;
  top: 0;
  right: 0;

If you tap the hamburger menu icon to open the menu, they add another rule that applies transform: translate(0); to bring it onscreen, and the weird zoom-out effect goes away. But then when you close the menu, the original transform: translate(100%); takes effect and shifts it offscreen again, and you get back to the initial broken rendering.

(Every now and then in Responsive Design Mode, things end up working as-intended (either initially or after I open/close the menu), but I'm not sure precisely why.)

hiro, do you have any insight into what's going on here and why this works out better in Chrome vs. Firefox?

Flags: needinfo?(hikezoe.birchill)
See Also: → 1911457

(Per bug 1911457 comment 14, it sounds like we can group this under "viewport-compat" metabug and known categories-of-issues related to that, and maybe consider that the underlying platform bug, until/unless we get a reduced testcase here that can be spun off to a more-specific platform bug.)

Attached file A reduced test case

The transform: translate(100%) element Daniel found in comment 2 is underflowed in RTL contents, thus it should not affect the minimum-scale size. That's the problem.

That's being said, there may be another problem on the site, https://mako.co.il/ . I have a local patch to fix the underflow problem, with the patch, the site is correctly laid out initially, while being loaded the site at some point, it's rendered incorrectly, and then once after the site has been loaded, it's rendered correctly again.

Anyways, I am going to focus on the underflow problem here.

Flags: needinfo?(hikezoe.birchill)
Assignee: nobody → hikezoe.birchill
Status: NEW → ASSIGNED
See Also: → 1534454
Pushed by hikezoe.birchill@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/c1acf137ed79 Ignore __underflow__ area for the minimum scale size calculation. r=botond

Backed out for causing reftest failures @ 1166147.html

REFTEST TEST-UNEXPECTED-FAIL | layout/reftests/pagination/1166147.html == layout/reftests/pagination/1166147-ref.html | image comparison, max difference: 10, number of differing pixels: 1452
Flags: needinfo?(hikezoe.birchill)

Thanks to the test case, found a silly mistake that we need to use BStart but I did use BEnd there.

Flags: needinfo?(hikezoe.birchill)
Pushed by hikezoe.birchill@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/41ffc2364844 Ignore __underflow__ area for the minimum scale size calculation. r=botond

Backed out for causing reftests failures in 1133905-1-vh-rtl.html.

  • Backout link
  • Push with failures
  • Failure Log
  • Failure line: REFTEST TEST-UNEXPECTED-FAIL | layout/reftests/bugs/1133905-1-vh-rtl.html == layout/reftests/bugs/1133905-ref-vh-rtl.html | image comparison, max difference: 54, number of differing pixels: 320

Please also check these reftests failures.
Failure log

Flags: needinfo?(hikezoe.birchill)
See Also: → 1931482

The incorrect rendering is the reference one, 1133905-ref-vh-rtl.html. It has <meta name="viewport" content="initial-scale=1.0"> so that even though the correct minimum-scale of the document is less than 1.0, the content gets rendered as 1.0 zoom scale.

Without the change for this bug, the minimum-scale is incorrectly calculated as 1.0, thus we have never seen bug 1931482.

With the change for this bug, the minimum-scale is correctly calculated, thus we see bug 1931482.

Anyways, I am going to leave this bug open, since I have no idea how to fix bug 1931482, it would take more time.

Depends on: 1931482
No longer depends on: viewport-compat
Flags: needinfo?(hikezoe.birchill)
See Also: 1931482
Webcompat Priority: --- → P2
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: